Objective-C und Swift im Vergleich

Aus Sicht der Entwickler gibt es beim Wechsel von Objective-C zu Swift viele offensichtliche Änderungen. Quer durch die Sprache zieht sich das Ziel, einfachen und selbsterklärenden Code zu schreiben. Der erste Ansatz dafür ist bereits die schlankere Syntax.

Diese ist auffällig gut lesbar. Es wird bewusst auf redundante Informationen verzichtet. Und auf den ersten Blick wird klar: Die eckigen Klammern werden in Swift viel seltener verwendet. Exemplarisch für die Vereinfachungen steht die Variablendeklaration. Hier der direkte Vergleich: Objective-C und Swift im Vergleich
//Objective-C: MeinAuto *einAuto = [[MeinAuto alloc] init];
// Swift: var einAuto = MeinAuto()

Auch das Semikolon am Ende der Zeile fällt weg. Zudem wurden Strings vereinfacht ("ein String" statt @"ein String") und weitere Optimierungen umgesetzt.

Statische Datentypen mit automatischer Erkennung

Darüber hinaus verzichtet Swift überall auf Angaben, wo es der Lesbarkeit dient. Die Type Inference unterstützt dieses Ziel maßgeblich: Der Interpreter erkennt bei der Initialisierung von Variablen den Datentyp. Variablen müssen dann nicht zusätzlich deklariert werden. Trotzdem wird der Datentyp festgelegt. Eine Integer-Variable kann nicht zu einem String werden wie zum Beispiel unter PHP oder Javascript.

Keine explizite Arbeit mit Zeigern (Pointer)

Die noch aus der Sprache C bekannten Zeiger (Pointer) sind auch unter Objective-C ständig präsent (erkennbar beispielsweise am Sternchen, siehe Codebeispiel oben). Swift unterstützt das Konzept noch, es gibt natürlich auch weiterhin Referenzen. Aber die Dereferenzierung muss zum Beispiel nicht mehr explizit erfolgen. Dieser Aspekt macht es Einsteigern viel leichter, was gerade auch aus wirtschaftlicher Sicht ein Faktor sein kann. Werden Quereinsteiger eingestellt, ist der Zugang zu Swift um einiges leichter als zu Objective-C.

Definition und Implementierung vereint

In Objective-C werden pro Klasse jeweils zwei separate Dateien benötigt. Der "Header" (Dateien mit der Endung .h) enthält die öffentlichen Definitionen. Die Logik wird in der Implementierungsdatei (Endung .m) hinterlegt. Es gibt also mehr Dateien. Noch gravierender ist aber die Aufgabe, den Header und die Implementierung auf dem gleichen Stand zu halten. Eine Änderung muss so an zwei Stellen hinterlegt werden. Unter Swift ist das Konzept leichter zu pflegen. Es gibt es nur eine Klassendefinition in der Swift-Datei (.swift).

Playgrounds als praktisches Werkzeug

Um Objective-C oder andere Sprachen zu lernen, muss ein klassisches Projekt als Testumgebung dienen. Der Entwickler verändert Quellcode, übersetzt ihn und führt das fertige Programm aus. Das Ergebnis wird getestet, und der Prozess startet erneut. Was keine Hürde darstellt, machen die Xcode Playgrounds trotzdem noch einfacher. Im Playground wird im Editor Quellcode hinterlegt, der kurz nach der Eingabe übersetzt und automatisch ausgeführt wird. Das ermöglicht unmittelbares Feedback - ohne zusätzliche Schritte. Berechtigter Kritikpunkt ist derzeit die Stabilität. Ein Playground muss hin und wieder nach einem Problem neu gestartet werden.