Öffnen Sie ein iOS-Projekt, das vor 2014 begonnen wurde, und Sie finden mit hoher Wahrscheinlichkeit Dateien mit den Endungen .h und .m, eckige Klammern um jeden Methodenaufruf und ein @ vor jeder Zeichenkette. Das ist Objective-C, über drei Jahrzehnte die Sprache hinter Mac, iPhone und iPad. Neue Dateien im selben Projekt sind dagegen fast immer in Swift geschrieben. Viele Apps sind heute genau diese Mischung.

Der Wechsel von Objective-C zu Swift verlief nicht als harter Schnitt, sondern als langsamer Umbau über mehr als ein Jahrzehnt. Wer eine bestehende App pflegt, eine neue plant oder Entwickler:innen einstellt, sollte verstehen, warum Apple diesen Weg gegangen ist, wo Swift heute steht und wie die beiden Sprachen nebeneinander funktionieren.

Objective-C: Von NeXT zum iPhone

Objective-C entstand Anfang der 1980er-Jahre bei Brad Cox und Tom Love. Die Idee war, die Programmiersprache C um Objekte und Nachrichten nach dem Vorbild von Smalltalk zu erweitern. Jeder gültige C-Code ist auch gültiges Objective-C, darauf setzt eine dünne Schicht für Klassen und Methodenaufrufe auf.

Bekannt wurde die Sprache durch NeXT, das Unternehmen, das Steve Jobs nach seinem ersten Abschied von Apple gegründet hatte. NeXT lizenzierte Objective-C Ende der 1980er-Jahre und baute darauf sein Betriebssystem NeXTSTEP mit den Programmierschnittstellen auf, aus denen später Cocoa wurde. Als Apple NeXT Anfang 1997 übernahm, kamen Technik und Sprache mit. Mac OS X und später iOS beruhen auf diesem Erbe, weshalb Klassennamen wie NSString bis heute das Kürzel „NS“ für NeXTSTEP tragen.

Objective-C hat Stärken, die man nicht unterschätzen sollte. Die Sprache ist sehr dynamisch: Welche Methode ein Aufruf tatsächlich trifft, entscheidet die Laufzeitumgebung erst während der Ausführung. Darauf bauen Techniken wie Key-Value Observing oder das nachträgliche Austauschen von Methoden. Zugleich schleppt sie das C-Erbe mit: Zeiger, Headerdateien, eine eigenwillige Syntax und wenig Schutz vor Fehlern wie dem Zugriff auf nil, der in Objective-C stillschweigend nichts tut, statt einen Fehler zu melden.

2014: Warum Apple eine neue Sprache brauchte

Auf der Entwicklerkonferenz WWDC im Juni 2014 stellte Apple Swift vor. Die Arbeit daran hatte Chris Lattner um 2010 begonnen, der zuvor das Compilerprojekt LLVM mitbegründet hatte. Swift nutzt diese Compiler-Infrastruktur bis heute, wie der Beitrag über LLVM als Baukasten moderner Compiler erklärt.

Die Gründe für eine neue Sprache lagen auf der Hand. Objective-C ließ sich kaum weiter modernisieren, ohne die Kompatibilität mit C zu brechen. Für Einsteiger wirkte die Syntax fremd, und viele Fehlerklassen ließen sich mit dem C-Unterbau nicht verhindern. Apple wollte eine Sprache, die so schnell ist wie kompilierter Code, aber Fehler früher abfängt.

Ein Vergleich zeigt den Unterschied. So sieht eine einfache Klasse mit Methode in Objective-C aus:

// Kunde.h
@interface Kunde : NSObject
@property (nonatomic, copy) NSString *name;
- (NSString *)begruessung;
@end

// Kunde.m
@implementation Kunde
- (NSString *)begruessung {
    return [NSString stringWithFormat:@"Guten Tag, %@", self.name];
}
@end

Dieselbe Logik in Swift, ohne getrennte Headerdatei:

struct Kunde {
    var name: String

    func begruessung() -> String {
        "Guten Tag, \(name)"
    }
}

Swift 1.0 erschien im September 2014. Ende 2015 stellte Apple die Sprache samt Compiler und Standardbibliothek unter der Apache-Lizenz 2.0 als Open Source bereit und lieferte von Anfang an eine Fassung für Linux mit. Die ersten Jahre waren unruhig: Vor allem Swift 3 benannte 2016 große Teile der Programmierschnittstellen um, was Teams viel Migrationsarbeit kostete. Mit Swift 5 wurde 2019 auf Apple-Plattformen die sogenannte ABI-Stabilität erreicht. Das bedeutet, dass kompilierter Swift-Code mit künftigen Versionen der Laufzeitbibliothek zusammenarbeitet. Seither liefert Apple die Swift-Laufzeit mit dem Betriebssystem aus, und Apps müssen sie nicht mehr selbst mitbringen.

Was Swift im Alltag anders macht

Die Werbung sprach 2014 von „schnell, sicher, modern“. Interessanter ist, was das in der Praxis bedeutet.

Optionals statt stiller nil-Fehler

In Swift kann ein normaler Wert nie leer sein. Soll eine Variable auch „nichts“ enthalten dürfen, muss sie als Optional gekennzeichnet werden, mit einem Fragezeichen hinter dem Typ. Der Compiler zwingt Sie dann, den leeren Fall zu behandeln, bevor Sie den Wert nutzen.

func lieferadresse(fuer kundenID: Int) -> String? {
    // Gibt nil zurück, wenn keine Adresse hinterlegt ist
    kundenID == 42 ? "Domstraße 1, Köln" : nil
}

if let adresse = lieferadresse(fuer: 42) {
    print("Versand an \(adresse)")
} else {
    print("Bitte Adresse ergänzen")
}

Angenommen, ein Webshop-Team baut eine Bestell-App. In Objective-C würde eine fehlende Adresse einfach als nil durch den Code wandern und erst beim Druck des Versandetiketts auffallen. In Swift weist der Compiler schon beim Schreiben darauf hin, dass dieser Fall fehlt.

Werttypen, Protokolle und Typinferenz

Swift unterscheidet klar zwischen Werttypen (struct, enum), die beim Weitergeben kopiert werden, und Referenztypen (class), die geteilt werden. Viele Fehler durch unbeabsichtigt geteilte Daten entfallen so. Statt tiefer Vererbungshierarchien setzt Swift auf Protokolle, also Schnittstellen, die auch Standardimplementierungen mitbringen können. Den Typ einer Variablen leitet der Compiler meist selbst ab (Typinferenz): let preis = 19.90 ist automatisch ein Double, und let macht den Wert unveränderlich.

Speicherverwaltung mit ARC

Swift hat keinen Garbage Collector, der periodisch aufräumt. Wie modernes Objective-C nutzt es Automatic Reference Counting (ARC): Der Compiler fügt Zähler ein, die ein Objekt freigeben, sobald niemand es mehr referenziert. Das ist berechenbar und sparsam, schützt aber nicht vor zyklischen Referenzen. Wer zwei Objekte sich gegenseitig festhalten lässt, muss eine Seite mit weak markieren. Das gilt in beiden Sprachen gleichermaßen.

Swift 6, Concurrency und SwiftUI: Der heutige Stand

Die größte Neuerung der vergangenen Jahre betrifft die nebenläufige Programmierung, also Code, der mehrere Aufgaben gleichzeitig erledigt. Mit Swift 5.5 kamen 2021 async/await und Actors hinzu. Ein Actor ist ein Objekt, das seinen Zustand nur jeweils einer Aufgabe zugänglich macht und so gleichzeitige Schreibzugriffe verhindert.

actor Warenkorb {
    private var positionen: [String] = []

    func hinzufuegen(_ artikel: String) {
        positionen.append(artikel)
    }

    var anzahl: Int { positionen.count }
}

let korb = Warenkorb()
await korb.hinzufuegen("Kaffeebohnen")
print(await korb.anzahl)

Swift 6 erschien im September 2024 und macht diese Prüfungen im neuen Sprachmodus verbindlich: Der Compiler meldet mögliche Data Races, also unkoordinierte gleichzeitige Zugriffe auf dieselben Daten, als Fehler statt erst im Betrieb. Für bestehende Projekte war das ein spürbarer Aufwand, weshalb der Swift-6-Modus pro Modul eingeschaltet werden kann und ältere Modi weiter unterstützt werden. Mit Swift 6.2 kamen 2025 Erleichterungen hinzu, etwa die Möglichkeit, Code standardmäßig auf dem Haupt-Thread laufen zu lassen. Welche 6.x-Version aktuell ist, sollten Sie vor einem Projektstart in den Release Notes auf swift.org nachsehen.

Fast ebenso wichtig ist SwiftUI, das Apple 2019 vorstellte. Statt Oberflächen Schritt für Schritt mit Objekten aus UIKit oder AppKit aufzubauen, beschreiben Sie in SwiftUI deklarativ, wie die Oberfläche bei einem bestimmten Zustand aussehen soll:

import SwiftUI

struct BestellungView: View {
    @State private var menge = 1

    var body: some View {
        Stepper("Menge: \(menge)", value: $menge, in: 1...10)
            .padding()
    }
}

SwiftUI funktioniert nur mit Swift. Neue Apple-Schnittstellen erscheinen daher zunehmend zuerst oder ausschließlich für Swift, etwa das Persistenz-Framework SwiftData von 2023 oder das Testframework Swift Testing von 2024. UIKit bleibt für anspruchsvolle Oberflächen weiter im Einsatz und lässt sich mit SwiftUI kombinieren.

Wie Objective-C und Swift zusammenarbeiten

Dass Apple den Umstieg ohne Bruch geschafft hat, liegt an der Interoperabilität. Beide Sprachen können im selben Xcode-Projekt stehen und sich gegenseitig aufrufen.

• Objective-C aus Swift nutzen: Über einen sogenannten Bridging Header machen Sie Objective-C-Header für Swift sichtbar. Die Klassen erscheinen dann wie Swift-Typen. Mit Annotationen wie nullable und nonnull im Objective-C-Header teilen Sie Swift mit, welche Werte leer sein dürfen. Ohne diese Angaben werden sie als implizit entpackte Optionals importiert, was die Sicherheitsvorteile teilweise aufhebt.
• Swift aus Objective-C nutzen: Xcode erzeugt automatisch einen Header, der Swift-Klassen für Objective-C bereitstellt. Sichtbar sind allerdings nur Klassen, die von NSObject erben, und Mitglieder, die mit @objc markiert sind.

import Foundation

@objc class PreisRechner: NSObject {
    @objc func brutto(netto: Double) -> Double {
        netto * 1.19
    }
}

Die Grenze verläuft dort, wo Swift Dinge kann, die Objective-C nicht kennt: Structs, Enums mit zugehörigen Werten, generische Typen oder async-Funktionen, die Objective-C nur als Methoden mit Completion-Handler zu sehen bekommt. Wer Swift-Code für Objective-C öffnen will, schreibt dafür oft eine schmale Klasse als Adapter. Inzwischen spricht Swift außerdem direkt mit C++ (seit Swift 5.9), was für Projekte mit C++-Bibliotheken interessant ist.

Ein Migrationspfad in der Praxis

Angenommen, ein Mittelständler betreibt seit 2012 eine Außendienst-App in Objective-C. Ein vollständiges Neuschreiben wäre teuer und riskant. Bewährt hat sich ein schrittweises Vorgehen:

1. Neue Funktionen und Bildschirme konsequent in Swift schreiben.
2. Objective-C-Header mit Nullability-Annotationen versehen, damit Swift sauber importiert.
3. Module mit vielen Fehlern oder anstehenden Änderungen gezielt portieren, stabile Altteile vorerst belassen.
4. Erst wenn ein Großteil in Swift vorliegt, über die Ablösung des Rests entscheiden.

Apple hat Objective-C nicht abgekündigt. Der Compiler unterstützt die Sprache weiterhin, und viele Systembibliotheken stellen ihre Schnittstellen nach wie vor für beide Sprachen bereit. Es gibt also keinen Zwang, funktionierenden Altcode sofort zu ersetzen. Neue Schnittstellen und Beispiele von Apple sind aber fast nur noch in Swift gehalten, und Entwickler:innen mit frischer Objective-C-Erfahrung werden seltener.

Swift jenseits von iPhone und Mac

Swift ist nicht an Apple-Geräte gebunden. Offizielle Toolchains gibt es für Linux und seit Swift 5.3 auch für Windows. Auf Servern laufen Swift-Anwendungen etwa mit dem Webframework Vapor oder der von Apple gepflegten Netzwerkbibliothek SwiftNIO. Mit Embedded Swift zielt das Projekt seit 2024 auf Mikrocontroller. Für Android und WebAssembly stellt swift.org inzwischen eigene Swift SDKs bereit, die Android-Unterstützung treibt eine eigene Arbeitsgruppe des Projekts voran.

Realistisch betrachtet bleibt Swift trotzdem eine Sprache für das Apple-Ökosystem. Serverseitig ist das Angebot an Bibliotheken, Hosting-Erfahrung und Fachkräften deutlich kleiner als bei Java, Go oder Node.js. Swift auf dem Server lohnt sich vor allem dann, wenn ein Team ohnehin Swift beherrscht und Code zwischen App und Backend teilen möchte.

Auch Swift Playground, bis 2025 „Swift Playgrounds“ genannt, ist erwachsen geworden. Was 2016 als Lern-App für das iPad begann, kann inzwischen auf iPad und Mac einfache Apps bauen und an den App Store übermitteln. Für den Einstieg ist das bequem, für professionelle Projekte bleibt Xcode auf dem Mac das Werkzeug der Wahl.

Was der Wechsel für Ihr Projekt bedeutet

Der Umstieg von Objective-C auf Swift ist weitgehend vollzogen. Für neue Apps auf Apple-Plattformen gibt es kaum einen Grund, mit Objective-C zu beginnen. Swift ist sicherer, besser lesbar und die Sprache, in der Apple neue Funktionen zuerst anbietet.

Für bestehende Apps ist die Lage differenzierter. Funktionierender Objective-C-Code ist kein Notfall. Teuer wird er, wenn er schlecht dokumentiert ist und niemand im Team ihn mehr sicher ändern kann. Hier lohnt eine ehrliche Bestandsaufnahme: Welche Teile ändern sich oft, welche sind stabil, wer kennt sich noch aus?

Überschätzt wird dagegen der Aufwand, einen Swift-6-Umstieg ohne Plan anzugehen. Die strengere Concurrency-Prüfung deckt in älterem Swift-Code oft viele Warnungen auf. Sinnvoll ist, Modul für Modul vorzugehen und die Prüfungen zunächst als Warnungen zu aktivieren.

Eine Grundsatzfrage bleibt: Muss die App überhaupt nativ für iOS gebaut werden? Wenn iOS und Android gleichermaßen wichtig sind, kommen plattformübergreifende Ansätze wie Flutter, React Native oder .NET MAUI in Betracht. Einen Überblick über diesen Weg gibt der Beitrag zur plattformübergreifenden App-Entwicklung für iOS und Android. Auf Android spielte sich übrigens eine ähnliche Ablösung ab, dort von Java zu Kotlin, die im Vergleich von Kotlin und Java beschrieben ist.

Wenn Sie eine bestehende Objective-C-App modernisieren oder eine neue App planen, unterstützt MARTINSFELD bei Architektur, Migration und Umsetzung. Mehr dazu finden Sie auf der Seite zur App-Entwicklung für iOS und Android.

Häufige Fragen zu Swift und Objective-C

Lohnt es sich heute noch, Objective-C zu lernen?

Als erste Sprache nicht. Wer aber ältere Apps pflegt oder tief in Apple-Systembibliotheken einsteigen will, profitiert davon, Objective-C lesen zu können. Für die meisten Entwickler:innen genügt dieses passive Verständnis.

Braucht man einen Mac, um mit Swift zu programmieren?

Für Swift selbst nicht: Die Sprache läuft auch unter Linux und Windows, etwa für Serveranwendungen oder Kommandozeilenwerkzeuge. Für Apps auf iPhone, iPad oder Mac brauchen Sie dagegen in aller Regel Xcode, und das gibt es nur für macOS. Einfache Apps lassen sich alternativ mit Swift Playground auf dem iPad bauen.

Wie schwer ist der Umstieg von Objective-C auf Swift?

Die Grundlagen lernen erfahrene Objective-C-Entwickler:innen schnell, denn die Frameworks wie Foundation und UIKit sind dieselben. Mehr Zeit kosten die neuen Denkweisen: Optionals konsequent nutzen, Werttypen statt Klassen bevorzugen und die Regeln der Swift-Concurrency verstehen.

Lassen sich Objective-C und Swift dauerhaft in einem Projekt mischen?

Ja, technisch ist das dauerhaft möglich und in vielen großen Apps üblich. Der Preis ist mehr Komplexität beim Build und an den Schnittstellen. Je mehr neuer Code in Swift entsteht, desto eher lohnt es sich, die Grenze zwischen beiden Sprachen klar und schmal zu halten.