Magazin Alternative zu Xcode: AppCode 3.1 veröffentlicht

[Tobias Scholze]

Vor wenigen Tagen hat die tschechische Softwareschmiede JetBrains ihre Entwicklungsumgebung AppCode in der Version 3.1 veröffentlicht. Mit diesem Release hielt nicht nur die Unterstützung für Swift Einzug in die IDE, sondern auch viele Verbesserungen im Detail wie eine Überarbeitung des integrierten Interfaces Builders.[prbreak][/prbreak]

​

JetBrains ist unter anderem bekannt für ihre Entwicklungsumgebungen wie IntelliJ für Java, PhpStorm für PHP oder RubyMine für Ruby. All diese IDEs teilen sich im Grunde die gleiche Basis und erlauben daher meist die Arbeitsweise wiederzuverwenden. AppCode macht hier keine Ausnahme. Wer sich in IntelliJ auskennt, wird sich auch sofort in AppCode heimisch fühlen.

Diese Gleichschaltung mit anderen IDEs kann sich jedoch auch negativ auswirken. Produkte von JetBrains sind in ihrem Funktionsumfang und ihrer Schnelligkeit nahezu unerreicht. Die großen Pluspunkte der Programme kann man jedoch meist erst nach einer längeren Eingewöhnungsphase wirklich abrufen. Aus diesem Grund ist diese IDE eventuell nichts für den kompletten Apple-Development Einsteiger. Vor allem vor dem Gedanken, dass selbst im öffentlichen Xcode noch nicht alle Swift Eigenheiten umgesetzt sind. Als Beispiel seien hier die strong References bei IBOutlets angeführt.

​

Nichtsdestotrotz bietet AppCode Features welche man in Xcode vermissen könnte. Neben einem integrierten CocoaPod-Manager ist auch das Refactoring innerhalb von Swift ist in der alternativen Entwicklungsumgebung möglich.

Es steht eine dreißig Tage Testversion von AppCode zum Download bereit. Eine Jahresabo ist ab 57 Euro (zzgl. MwSt.) erhältlich.

Ganz auf Xcode kann man jedoch nicht verzichten. Alles was direkt mit dem App Store oder iTunes Connect zu tun hat muss weiterhin über die Apple-eigene IDE erledigt werden.

Werdet ihr AppCode ausprobieren? Was stört euch sonst in Xcode?

 

[marcozingel]

Gibt es doch aber schon länger.Herzlichen Dank für die Info.

 

[MacMark]

Als Beispiel seien hier die strong References bei IBOutlets angeführt.

Wer sollte so etwas wollen? Das Ziel, der Subview, hängt ja eh schon mit einer Strong Reference an seinem Parent-View. Zudem würde eine weitere externe Strong Reference das Wegwerfen des referenzierten Subviews bei Memory Warnings verhindern.

 

[appahappa]

Ich benutze das Programm schon seit ein paar Jahren und sehr zufrieden damit. Der Code-Editor ist auf jeden Fall um einiges besser als der von Xcode, ist aber alles eher Geschmacksache. Die CocoaPods-Unterstützung ist auch praktisch. Ich benutze meistens Beide, in AppCode schreibe ich den Code und in Xcode wird nur am UI gebastelt. Muss noch dazu sagen, dass ich auch viel in Java programmiere und dafür IntelliJ IDEA einsetze, da muss ich mich nicht umgewöhnen. Das neue Android Studio von Google basiert auch auf der gleichen Plattform.

 

[Scotch]

Neben einem integrierten CocoaPod-Manager ist auch das Refactoring innerhalb von Swift ist in der alternativen Entwicklungsumgebung möglich.

Bitte führe doch einmal konkret aus, was "Refactoring innerhalb von Swift" sein soll und inwieweit da AppCode etwas "möglich" macht.

 

[MacApple]

Wer sollte so etwas wollen? Das Ziel, der Subview, hängt ja eh schon mit einer Strong Reference an seinem Parent-View.

Na ja, man braucht auch schon mal ein Outlet zu etwas anderem, als einen Subview.
Davon abgesehen weiß ich auch nicht, was es da für ein Problem mit Swift und starken Referenzen geben soll.

 

[MacApple]

Bitte führe doch einmal konkret aus, was "Refactoring innerhalb von Swift" sein soll und inwieweit da AppCode etwas "möglich" macht.

Refactoring ist dir bekannt? Xcode gibt beim Versuch Swift Code zu refactorieren nur folgendes von sich:

 

[Scotch]

Oh ja, mir ist refactoring bekannt. Ich habe gerade ein phyton-Skript in pico "gerefactored". Das pico tatsächlich dafür Unterstützung anbietet... und ich hab' gar keine Funktion dafür benutzen müssen...

Neu war/ist mir, dass refactoring etwas ist, was der Editor/die IDE macht. Sarkasmustags bitte nach belieben setzen.

Ich präzisiere daher meine Frage: Was macht denn Xcode, wenn es ObjC oder C Code "refactored"?

 

[Tobias Scholze]

Refactored ist ein Menüpunkt der neben banalen Dingen wie Renaming auch Moving und Signaturänderungen beinhaltet.

LG, Tobi

 

[Scotch]

Ich bin tief beeindruckt. Refactoring ist also ein Menüpunkt. Der "Renaming" beinhaltet. Das ist so... BS-Bingo-mäßig, da kann ich einfach nur zitieren:

Refactoring ist dir bekannt?

Ja, ist 'ne rhetorische Frage.

Anstatt sich mit "Menüpunkten" abzugeben, mal zwei sehr ernst gemeinte Literaturtips, wenn du weiterhin über Entwickler-Tools schreiben willst - einmal in Englisch und auch 'ne deutsche Empfehlung.
Heutzutage scheint ein "Programmierer" i.W. die Featurelisten von Tools herunterzubeten - vmtl. in der Hoffnung, dass sinnvoller Code vom Himmel fällt - anstatt programmieren zu lernen.

"Refactored ist ein Menüpunkt"... ja, genau so eine Antwort hab' ich erwartet.

Und "Renaming" ist ein Buzzword für diff, sed & awk, mit denen man das schon seit anno tobak macht(e), bevor es irgendein Agilist für notwendig erachtete, dafür auch noch ein Wort zu "branden".

 

[Tobias Scholze]

Hi @Scotch,
der Beitrag als auch die Kommentare sind für nicht komplett fachkundiges Publikum geschrieben.

Was genau JetBrains unter dem Punkt Refactoring besteht kannst du im Change-Log oder unter den Beispielsvideos von AppCode ansehen.

LG, Tobi

 

[Scotch]

Ich kann überhaupt alles aus deinem Artikel auf der JetBrains-Webseite nachlesen - das ist ja mal eine echt lahme Antwort für einen Redakteur.

Ich gehe doch recht in der Annahme, dass du im Leben noch kein refactoring jenseits von search & replace über ein Repo (sorry - "Rename Refactoring" heisst da wohl bei dir/JetBrains) gemacht hast?!

 

[Tobias Scholze]

Hi,
da es hier um einen Artikel und nicht um eine Person geht verzichte ich auf eine solch Diskussion.

LG, Tobi

 

[Scotch]

Und du meinst ernsthaft, du bist qualifiziert für Fragen wie

Werdet ihr AppCode ausprobieren? Was stört euch sonst in Xcode?

Zumal du dich nach eigenen Angaben an "nicht komplett fachkundiges Publikum" wendest?

Noch lahmer geht's nicht. Aber du hast Recht: Eine Diskussion macht wahrlich keinen Sinn.

 

[Scotch]

Ich mach' mal die Edith:

Bitte führe doch einmal konkret aus, was "Refactoring innerhalb von Swift" sein soll und inwieweit da AppCode etwas "möglich" macht.

3.1 führt volle Unterstützung für XCT für Swift ein. Natürlich kann das Xcode auch. Und natürlich kann man auch ohne das alles refactoring betreiben - aber das ist (für AppCode) die wirkliche Neuerung in Sachen Swift & refactoring.

 

[DubiDuh]

Wenn Bücher, dann aber auch Clean Coder [1] und Refactoring to Patterns [2].

[1] http://www.amazon.de/Clean-Coder-Co...F8&qid=1419800963&sr=8-2&keywords=Clean+coder

[2] http://www.amazon.de/Refactoring-Pa...01036&sr=8-1&keywords=refactoring+to+patterns

 

[MacApple]

Neu war/ist mir, dass refactoring etwas ist, was der Editor/die IDE macht. Sarkasmustags bitte nach belieben setzen.
Ich präzisiere daher meine Frage: Was macht denn Xcode, wenn es ObjC oder C Code "refactored"?

Xcode kann da verschiedene Sachen. Mal ein Beispiel. Nehmen wir mal an, du hast eine Klasse A und eine Klasse B, die von A abgeleitet ist. Nun erstellst du eine Klasse C, die auch von A abgeleitet werden soll, aber auch die eine oder andere Methode von Klasse B gebrauchen kann. Also wäre es sinnvoll diese Methoden in die Klasse A zu verschieben. Dieses Verschieben kann Xcode für dich übernehmen. Das geht auch in die andere Richtung, also von der Superklasse in die Subklasse.

 

[MacMark]

Na ja, man braucht auch schon mal ein Outlet zu etwas anderem, als einen Subview.
Davon abgesehen weiß ich auch nicht, was es da für ein Problem mit Swift und starken Referenzen geben soll.

Auch alles andere in der GUI sollte bereits an einer Strong Reference hängen, da es alles Kind-Elemente im View des jeweiligen ViewControllers sind. Meines Wissens benötigen nur die obersten Elemente im Nib/Xib-File Strong References. So eine verbindet zum Beispiel den obersten View mit seinem ViewController.
Man kann natürlich mutwillig und hier unnötige Strong References anlegen. Vielleicht ging das ja irgendwie nicht mit AppCode

Um ernsthaft für Apple zu entwickeln, würde ich jedenfalls keine Dritt-IDE verwenden, die zwangsläufig immer mindestens 6 Monate technisch hinterherhinkt.

 

[Scotch]

Nun erstellst du eine Klasse C, die auch von A abgeleitet werden soll, aber auch die eine oder andere Methode von Klasse B gebrauchen kann. Also wäre es sinnvoll diese Methoden in die Klasse A zu verschieben.

Das wäre nicht sinnvoll, sondern schlechter Programmierstil. Aber ich verstehe, was du meinst. Es ist auch unbestritten, dass moderne IDEs Tools mitbringen, die einem das Leben leichter machen. Aber refactoring ist eine Methode - wenn man TDD und/oder CI macht vielleicht sogar eine Art "Grundhaltung" - und keine Sammlung von Menüoptionen.