XCode 4

Nach relativ langer Zeit, zumindest empfindet man als Visual-Studio-Nutzer so, hat Apple eine komplett neue Major-Version seiner Entwicklungs-Umgebung XCode heraus gebracht. codingfreaks installiert die Version 4 (Build 4A304a vom 09.03.2011).

Download, Preise und Setup

Die Zeiten, in denen XCode selbst komplett kostenfrei nutzbar waren sind vorbei. Auch wenn die Preisgestaltung ganz anders als bei MS läuft. Entweder man hat bereits ein Developer-Abo oder man zahlt 5 € für den Einzeldownload des Pakets. Der kleine Preis erklärt sich schnell, wenn man weiß, dass der Vertrieb über den MacStore läuft. Gerade durch die Änderung bei XCode wird ein wenig klarer, wie Apple sich die Lizensierungs-Zukunft so vorstellt, auch wenn es wenig überraschend kommt.

Der Gesamtumfang des DMGs nimmt 4,6 GB auf der Platte ein. Die Installation selbst verläuft Apple-typisch ohne Reibereien (Snow Leopard). Das Setup meldet, dass es 10,5 GB Platz für die eigentlichen Installationsdateien haben möchte. Die Setup-Optionen zeigen sich wie folgt:

Optionen

Wer vorhat, ein bestehendes XCode 3 nach der Installation weiter zu nutzen, sollte als Ort einen eigenen Ordner für XCode 4 wählen. Wer tatsächlich upgraden möchte, wie ich, kann dies einfach ignorieren.

Die Installation selbst dauerte auf meinem Mac mini rund 15 Minuten und benötigt Admin-Rechte (wie immer). Ein Neustart ist nicht erforderlich.

Neuerungen

Apple bietet eine eigene Seite für die Neuerungen in XCode 4 an (Link). Die wichtigen Änderungen, die dort aufgelistet sind in Kürze:

  • XCode startet alle Funktionen innerhalb eines einzelnen Fensters (Code-Editor, Interface Builder, Debugger usw.)
  • Die Projektstruktur (Baum) wurde um Navigatoren erweitert, die das Filtern der Informationen erleichtern und beschleunigen soll
  • Über die „Jump Bar“ wird eine Art Breadcrumb-Navigation ähnlich der im Windows-7-Explorer eingeführt.
  • Der Interface Builder ist nun endlich integraler Bestandteil von XCode. Damit wird XCode eigentlich erstmalig zur IDE.
  • Der „Assistant“ soll intelligent erkennen, welche Dateien zu einem Arbeitsschritt dazu gehören und die Übersicht steigern.
  • Der Compiler wurde auf „LLVM 2.0“ gewechselt. Er basiert auf dem OpenSource-Compiler von LVVM.org und soll um Größenordnungen schneller arbeiten, als der alte.
  • Der neue Compiler läuft ständig im Hintergrund mit und erlaubt so das in VS bereits länger erhältliche Live-Compiling mit Hinweisen zu Fehlern bereits zur Editier-Zeit.
  • XCode kann nun bestimmte Probleme ähnlich der VS-Smart-Tag-Technik selbst beheben.
  • Der „Version Editor“ erlaubt das TimeMachine-artige Handling von unterschiedlichen Versionen der gleichen Datei.
  • Der Compiler ist neu, also auch der Debugger. Konsequenterweise wird auch hier auf LLVM.org zurückgegriffen. Neben zusätzlichen Funktionen wurde vor allem die Performance verbessert.
  • „Instruments“ dient quasi dem Testen und Messen der Anwendungen. Es spielt in Themen wie Unit Testing und Continous Integration ein.

Insgesamt ist das schon ein deftiger Schluck aus der Pulle. Vom reinen Lesen der Features her wurden eine Menge lange bekannter Entwicklerwünsche erfüllt. Gerade das nervige Handling mit dem alten Interface Builder war eher eine Zumutung. Wir sehen uns nun an, ob die Erwartungen unsererseits erfüllt wurden.

Der erste Start

Gleich nach dem ersten Start begrüßt einen wie in der alten Version auch das Willkommen-Fenster:

Willkommen

Leider übernimmt XCode die zuletzt geöffneten Projekte nicht in die Recent-Liste, aber das ist wohl zu verschmerzen. Interessant ist der Punkt „Connect to a repository“. Klickt man zum ersten Mal darauf, kann man einen URI zu einer Sammlung der eigenen Projekte eingeben. Ich wähle den Projekt-Ordner unterhalb meines „/User“-Pfads. Im zweiten Schritt darf man sich aussuchen, ob man Subversion oder GitHub als Repository-Backend benutzen möchte. Subversion ist standardmäßig voreingestellt.

Ich entscheide mich dagegen und öffne stattdessen einfach nur eines meiner bestehenden Testprojekte (sicher ist sicher):

Nach dem Öffnen

Welch ein Unterschied! In vorliegendem Beispiel habe ich eine iPhone-Anwendung geöffnet. Links erkennt man schön die durch die kleinen schwarzen Symbole repräsentierten Bereiche zwischen denen man im Menu umschalten kann.

Gleich daneben gehts aber ans Eingemachte. Jeder iPhone-Entwickler wird laut schreien vor Glück angesichts der Tatsache, dass endlich das dämliche Geklicke durch die plists ein Ende hat. Sehr übersichtlich werden das Projekt und die Targets im Schnellzugriff gezeigt. Der Target-Dialog daneben ist eine weitere Augenweide.In meinem Beispiel hat XCode die berüchtigte „Base-SDK-missing“-Meldung gleich im Projektbaum links gebracht. Klickt man nun im rechten Bereich bei „Build Settings“ auf den Filter „All“ und dann einmal auf die Fehlermeldung im Navigationsbereich „Issues“ (das kleine Warndreieck oben), selektiert XCode gleich die richtige Einstellung zum Ändern des Base-SDKs! Das wird zwar stackoverflow.com traurig machen, hilft aber ungemein bei der Entwicklung. Super!

Nach einer Weile des Arbeitens überraschte mich XCode übrigens mit einem Admin-Kennwort-Dialog. Nach kurzem Erstaunen stellte ich dann fest, dass XCode einfach nur die Hilfedateien nachladen und installieren will. Sehr gut gelöst, denn diese Suche im Browser war nicht wirklich eine Lösung!

F5!!!

Natürlich ist es nicht F5, aber nachdem nun keine Issues mehr auftauchen kann ich nicht widerstehen. Ich klicke auf das Play-Dreieck oben in der Ecke und warte auf meinen Simulator. Er erscheint auch und noch etwas fällt dabei positiv auf. In der Mitte des XCode-Fensters erscheinen wie bei iTunes Statusmeldungen des Debuggers:

Statusmeldungen

XCode wirkt dadurch viel ruhiger beim Start und lenkt den Blick gut auf das wesentliche.

Bei laufender Abwendung kann man nun sehr einfach in das Equivalent der alten GDB-Konsole kommen, indem man im Navigator auf das Sprechblasensymbol klickt und dann den ersten Eintrag auswählt. Noch bequemer ist allerdings das Einblenden der sog. „Debug Area“. Dazu reicht ein Klick auf das Symbol „Debug Area“ im Bereich „View“ oben rechts in XCode. Diese schnellen Umschalter sind ein segen für alle Entwickler, die auf kleinen Screens arbeiten müssen. Ein paar Klicks und XCode ist optimal angepasst. Sehr gut!

Interface Builder

Eines der am meisten herbei gesehnten Features war die Integration des Interface Builders. Bevor ich aber das Icon aus meiner Taskbar nehme, teste ich das erstmal.

Und, was soll ich sagen? Es klappt! Ein einfacher Klick auf eine XIB-Datei reicht und der integrierte Interface Builder öffnet sich:

Interface Builder

Leider ist es noch zu früh zu einer tieferen Analyse, das Look & Feel ist aber ziemlich großartig. Wir werden erst einmal eine Weile arbeiten und „abkühlen“ und dann objektivere Bewertungen abgeben. Auf jeden Fall verschwindet jetzt aber das Task-Symbol!

Code-Editor

Was nützen die besten Tools, wenn man nicht vernünftig Code schreiben kann? Genau, nichts. Also ran und die erste Objective-C-Datei editiert. Zunächst einmal läuft das Syntax-Highlighting deutlich schneller ab, als in 3. Es ist zwar noch nicht so schnell, wie in VS, aber man wartet nicht ewig auf das Einfärben.

Gleich zu beginn fällt mir das eingängigere Verhalten der Codevervollständigung auf. Optisch wirkt sie übersichtlicher

Code-Vervollständigung

und vom Handling her erinnert sie mich endlich an Visual Studio (Enter und Tab sind zur Selektion erlaubt, einfach weiterschreiben darf man aber immer noch nicht).

Interessant wird nun auch das bereits erwähnte Feature der „Jump Bar“. Über dem Code-Fenster erscheint die komplette Navigations-Hierarchie bis zur aktuell selektierten Code-Stelle. Befindet man sich z.B. in einer Funktion, könnte die Jump Bar wie folgt enden:


Klickt man nun auf z.B. den Funktionsnamen, erscheint eine Liste aller anderen Funktionen, getrennt ggf. durch die alt-bekannten Pragmas.

So richtig lustig wirds beim Einschalten des ebenfalls bereits angekündigten Assistent. Er blendet sich standardmäßig rechts neben der Code-Klasse ein (muss keine Code-Klasse sein) und ist erstmal leer. Man muss dem Assistenten nämlich mit dem darüber gezeigten kleinen grauen Button „Related Files“ sagen, was man dort angezeigt haben möchte. Die *.h zu einer *.c-Datei, die Superklasse zu einer Klasse und was sonst noch alles für Beziehungen erkannt werden. Über ein kleines graues „+“ rechts über dem Assistenten-Fenster kann man dies in diverse Fenster unterteilen. Möchte man keine Assistenten mehr sehen, wechselt man einfach wieder in den reinen Editor-Modus über das Symbol „Standard-Editor“ ganz oben in XCode.

Es wird noch vieles mehr zum Editor zu sagen geben, aber auch hier reicht es in diesem Eintrag nur für erste Eindrücke.

Organizer

Gerade für iPhone-Entwickler ist der Organizer eine zentrale Anlaufstelle. Der Organizer ist jedoch nicht mehr nur das, was er mal war. In ihm bringt Apple nun die Geräteverwaltung, die Quellcodeverwaltung, eine Projekt-Zentrale, Archive und die Dokumentation an einer zentralen Stelle unter:

Organizer

Resumé und Ausblick

Wir haben so viel Neues gesehen und doch nur an der Oberfläche kratzen können. Ich wollte denjenigen unter den codingfreaks-Lesern, die genau wie ich erstmal einen Eindruck aus Sicht eines Entwicklers haben wollten, der upgraded und die Unterschiede entdecken möchte. Ich hoffe, das ist gelungen und werde bestimmt bald die Zeit finden, noch mehr Einzelheiten in weitere Artikel zu XCode 4 zu packen. Ich kann nur sagen, dass Apple ein gutes Stück aufgeholt hat und endlich ein ernsthaftes Programmierwerkzeug zur Verfügung steht. Jetzt muss nur noch C# rein und die Tastaturlayouts müssen endlich mal stimmig werden, dann mache ich nur nopch iOS :-)). Nein, keine Angst, ich bleibe Windows-affin!!! Aber cool ist es doch.

Eine Antwort auf „XCode 4“

  1. Pingback: gowland

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.