Was ist neu in Swift (2026): Das WWDC26-Update

Apple veröffentlichte zwei Swift-Releases in einem einzigen WWDC-Zyklus: 6.3 und 6.4 erschienen gemeinsam, und die Session „What’s new in Swift” behandelte beide als einen zusammenhängenden Arbeitsbogen¹. Diese Rahmung ist von Bedeutung, weil sich die Änderungen sauber in zwei Zielgruppen aufteilen. Die meisten Entwickler erhalten kleinere Ergonomieverbesserungen für den täglichen Gebrauch (lassen Sie die Klammern um any-Optionals weg, fassen Sie ein Dutzend @available-Plattformnamen zu einem einzigen anyAppleOS zusammen, unterdrücken Sie eine Veraltungswarnung in genau einer Deklaration). Eine kleinere Gruppe, die leistungskritischen Code schreibt, erhält eine seit Jahren erwartete Belohnung: Das Ownership-System reicht nun bis zu for-Schleifen, berechneten Eigenschaften und der Standardbibliothek selbst.

Swift ist 2026 zudem sichtbar ein plattform- und sprachübergreifendes Projekt. Apple kündigte ein offizielles Swift SDK für Android an, das über swift.org vertrieben wird⁶, schnelleres JavaScript-Bridging über WebAssembly, die Möglichkeit, Swift-Funktionen mit einem neuen @C-Attribut zurück nach C zu exportieren, sowie ein Swift-Build-Backend, das nun standardmäßig den Swift Package Manager antreibt¹. Dieser Beitrag durchläuft die vier Sessions, die die Swift-Geschichte 2026 definieren: die Sprach- und Bibliotheks-Updates (262), den Migrationspfad für Swift Testing (267), Echtzeitdienste mit gRPC (265) und numerisches Rechnen mit MLX Swift (328).

TL;DR

• Swift 6.3 und 6.4 erschienen gemeinsam auf der WWDC26. Tägliche Ergonomie: optionales any/some ohne Klammern, anyAppleOS-Verfügbarkeit, das @diagnose-Attribut zur Warnungssteuerung pro Deklaration sowie Modulselektoren (::) für Namenskollisionen¹.
• Das Ownership-System erreichte gewöhnlichen Code: Ein neues Iterable-Protokoll lässt for-Schleifen Elemente ausleihen, statt sie zu kopieren, und borrow/mutate-Accessoren ersetzen get/set, um das Kopieren großer Werte in berechneten Eigenschaften zu vermeiden¹.
• Neue Typen der Standardbibliothek liefern die sicheren Versionen alter unsicherer Muster: UniqueArray, UniqueBox, eine Continuation mit Einmal-Resume sowie Ref/MutableRef, um einen Borrow oder eine Mutation in einer Variablen zu halten¹.
• Swift Testing interoperiert nun in beide Richtungen mit XCTest, mit vier Modi (limited, complete, strict, none); Xcode 27 aktiviert die Interoperabilität standardmäßig². Die Oberfläche aus @Test, @Suite, #expect und #require ist in Apples Swift-Testing-Referenz dokumentiert⁵.
• gRPC Swift erreichte den Punkt, an dem Sie aus einer .proto-Datei einen typisierten Client generieren und unäre sowie bidirektionale Streaming-RPCs erhalten, die in Linux-Container in der Cloud deploybar sind³.
• MLX Swift bringt Array-Computing im NumPy-Stil nach Swift, mit automatischer GPU-Ausführung und automatischer Differentiation per grad, wobei eine Engine über die Swift-, Python-, C++- und C-Frontends hinweg geteilt wird⁴.

Sprachergonomie: Die Ärgernisse verschwinden

Die Session beginnt mit Änderungen, die „Ihnen kaum auffallen dürften, außer als kleine Ärgernisse, die verschwinden”¹. Sie verdienen es, benannt zu werden, weil sie Reibung beseitigen, die sich über ein Jahrzehnt der Sprache angesammelt hat.

Becca und Evan aus dem Swift-Team führen durch Swift 6.3 und 6.4. Der Sprachabschnitt beginnt etwa bei 0:45.

Sie können jetzt any P? schreiben, ohne es in Klammern zu setzen. Sie erhalten eine Warnung, wenn ein Swift-Concurrency-Task einen geworfenen Fehler stillschweigend verwirft, was Sie dazu auffordert, ihn entweder im Task zu behandeln oder den Task zu speichern und später zu prüfen. Die alte Einschränkung, dass async-Funktionen aus einem defer-Block nicht aufgerufen werden durften, ist verschwunden, sodass asynchrones Aufräumen genauso abläuft, wie es zurückgestelltes synchrones Aufräumen schon immer getan hat (SE-0493, Swift 6.4)⁷. Eine Klasse, die nur wegen einer weak var-Eigenschaft @unchecked Sendable benötigte, kann diese Eigenschaft auf weak let umstellen und für eine ordentliche Sendable-Prüfung infrage kommen. Ein Typ, der nicht Sendable sein sollte, kann dies mit der neuen ~Sendable-Syntax explizit angeben, was Unterklassen nicht daran hindert, Sendable zu sein¹.

Zwei Änderungen werden Ihnen mit Sicherheit auffallen. Die erste betrifft die Verfügbarkeit: Apple hat seine Betriebssystem-Versionsnummern letztes Jahr angeglichen, und Swift geht noch weiter, indem es Ihnen erlaubt, jeden Plattformnamen zu einem einzigen zusammenzufassen, anyAppleOS. Wenn die Verfügbarkeit über die Plattformen, die Ihnen wichtig sind, übereinstimmt, geben Sie alle auf einmal an; gibt es Ausnahmen, setzen Sie anyAppleOS als Standard und fügen für die Ausnahmen plattformspezifische Attribute hinzu. Derselbe Name funktioniert in #if os(...)-Bedingungen¹.

Die zweite ist das @diagnose-Attribut, das das Verhalten bestimmter Warnungen innerhalb einer einzelnen Deklaration ändert. Sie können Swift anweisen, die Warnungsgruppe deprecated declaration in einer Funktion zu ignorieren, während Sie zu einer neuen API migrieren, ohne sie projektweit zu unterdrücken. Sie können es auch in die andere Richtung einsetzen: strikte Speichersicherheit innerhalb einer sicherheitskritischen Funktion aktivieren oder eine zukünftige Fehlerwarnung sofort zu einem Fehler hochstufen¹. Holly Borla, Engineering Manager im Swift-Team, nannte es ihr herausragendes Feature, als sie die WWDC26 abschloss: „Eines meiner liebsten neuen Features ist das @Diagnose-Attribut, mit dem Sie das Verhalten von Warnungen in Ihrem Code steuern können; damit können Sie etwa Veraltungen unterdrücken, aber auch Dinge tun wie strikte Speichersicherheit oder strikte Concurrency-Diagnosen auf einer feingranulareren Basis aktivieren, was beispielsweise bei der Migration zum Swift-6-Sprachmodus hilft.”⁸ Sie rahmte das gesamte 6.4-Release auf dieselbe Weise: Die Updates „beseitigen Dinge, die Reibungspunkte sind”, damit Entwickler sich darauf konzentrieren können, ihre Ideen in klarem, schönem Code auszudrücken⁸.

Dann gibt es die Modulselektoren. Wenn zwei importierte Module beide einen Typ namens View deklarieren, war die alte Lösung die Punkt-Syntax (Rocket.SaturnV), die jedoch versagt, wenn ein Modul namens Rocket ebenfalls einen Typ namens Rocket enthält, weil Swift den Typ bevorzugt und dann das Mitglied nicht findet. Swift 6.3 führt :: ein, bei dem der Name auf der linken Seite immer ein Modulname ist, sodass Rocket::SaturnV direkt zum Modul führt. Der Selektor funktioniert auch bei Methoden- und Eigenschaftsnamen. Apples Empfehlung ist eindeutig: Nutzen Sie ihn für Konflikte zwischen Modulen, die Sie nicht kontrollieren, und defensiv in makrogeneriertem Code, aber entwerfen Sie keine APIs, die absichtlich kollidieren, und stützen Sie sich dann auf Selektoren zur Auflösung¹.

Standardbibliothek und Foundation

Die Standardbibliothek erhielt gezielte Ergänzungen. Ein Task-Cancellation-Shield (withTaskCancellationShield, SE-0504, Swift 6.4) führt eine kurze Region aus, in der Abbruchprüfungen stets false zurückgeben, sodass asynchrones Aufräumen wie das Beenden eines Schreibvorgangs auf die Festplatte weiterhin läuft, nachdem der umgebende Task abgebrochen wurde⁷. mapKeyedValues übergibt sowohl den Schlüssel als auch den alten Wert an den Mapping-Closure und ersetzt damit die manuelle Wörterbuch-Rekonstruktion, zu der mapValues zwang, wenn Sie den Schlüssel benötigten. Ein neuer Dateipfad-Typ, basierend auf jenem aus Swift System, behandelt die Plattformunterschiede in der Pfaddarstellung¹.

Foundation setzte seine mehrjährige Migration weg von Objective-C und hin zu Swift fort. Apple modernisierte mehr von Data (schnellere Span-Zugriffe, Gleichheitsprüfungen, Iteration und Mutation) und vereinheitlichte NSURL und CFURL zu einer einzigen Swift-Implementierung, die schneller läuft und weniger Speicher verbraucht. ProgressManager ist ein neuer Fortschrittsmeldungs-Typ, gebaut für async/await, und das Subprocess-Paket erreichte 1.0 mit einem vereinfachten Ausführungstyp, gestreamter Ausgabe als AsyncBufferSequence und einer strings()-Methode, die die Ausgabe Zeile für Zeile liest und dabei Graphemcluster-Grenzen respektiert¹.

Ownership erreicht gewöhnlichen Code

Die Performance-Geschichte ist diejenige, die man genau lesen sollte, denn sie markiert den Moment, in dem ein mehrjähriges Compiler-Projekt zu etwas wird, das Sie in alltäglichen Typen verwenden können. Das Kernproblem ist das Kopieren: Sie haben Daten an einer Stelle, brauchen sie an einer anderen, also kopiert das Programm sie. Wenn der Speicher allokiert bleibt und beide Seiten Swifts Exklusivitätsregeln befolgen, ist die Kopie unnötig. Ein Borrow gewährt Lesezugriff auf vorhandenen Speicher, ohne ihn zu kopieren; eine Mutate gewährt exklusiven Schreibzugriff. Der Compiler verifiziert beide zur Kompilierzeit, was die Technik dort sicher macht, wo rohe UnsafePointer es nicht waren¹.

Der Abschnitt zu Ownership und Performance-Tuning beginnt etwa bei 19:55 und behandelt Inlining-Steuerung, Spezialisierung und die neuen Accessoren.

Mehrere Protokolle funktionieren nun ohne Kopieren. Equatable, Comparable und Hashable können auf nicht kopierbaren Typen verwendet werden, und Equatable sowie Comparable erweitern sich auf nicht entweichbare Typen. Assoziierte Typen können nun nicht kopierbar oder nicht entweichbar sein, was das Hauptfeature überhaupt erst ermöglicht: ein neues Iterable-Protokoll, das for-Schleifen direkt unterstützen¹.

Das Sequence-Protokoll, das jeder kennt, kopiert Elemente beim Iterieren heraus. Iterable lässt die Schleife sie stattdessen ausleihen, was bedeutet, dass es mit nicht kopierbaren Elementen funktioniert und das Reference-Counting bei Objekten und Copy-on-Write-Typen überspringt. Es kann während der Iteration werfen, so wie es eine AsyncSequence kann. Weil Ausleihen Mutation verbietet, hindert Sie die Exklusivitätsprüfung daran, die Sammlung während des Schleifendurchlaufs zu mutieren (eine häufige Performance-Falle bei Sequence). Eine for-Schleife bevorzugt Sequence, wenn verfügbar, und greift auf Iterable zurück, und der Iterable-Iterator liefert Elemente in Batches von Spans statt einzeln, was die Schleife für Typen, die alles in einem einzigen Span zurückgeben können, messbar effizienter macht¹.

Accessoren erhielten dieselbe Behandlung. Apples Beispiel ist eine UniqueBox, die ein InlineArray aus 256 Ints hält, ein zwei Kilobyte großes Struct auf einem 64-Bit-Gerät. Mit get/set kopiert das Ändern eines Elements das gesamte Array heraus und wieder zurück. Wenn Sie die berechnete Eigenschaft auf einen borrow-Accessor (schreibgeschützter Zugriff ohne Kopieren) und einen mutate-Accessor (exklusive In-Place-Modifikation) umstellen, kann Swift ein Element an Ort und Stelle ändern, und der Typ kann nicht kopierbare Werte halten¹.

Mehrere neue Typen der Standardbibliothek liefern die sicheren Ersetzungen für Muster, die zuvor unsicheren Code erforderten:

• UniqueArray verhält sich wie Array, ist aber nicht kopierbar, sodass es nicht kopierbare Elemente speichert und den Reference-Counting-Overhead vermeidet, ohne sich auf eine feste Größe festzulegen.
• UniqueBox ist ein echter Typ der Standardbibliothek, der die neuen Accessoren verwendet.
• Continuation prüft zur Kompilierzeit, dass Sie sie genau einmal fortsetzen, was sie sicherer als CheckedContinuation und so effizient wie UnsafeContinuation macht.
• Ref und MutableRef verhalten sich wie ein Span für einen einzelnen Wert: ein Container für einen Borrow oder eine Mutation, den Sie in einer Variablen speichern, übergeben, zurückgeben und in generischen Typen verwenden können. Sie erstellen ein MutableRef aus einem Schreibzugriff mit einem vorangestellten &, und weil Refs nicht entweichbar sind, weiß Swift, dass der Zugriff endet, wenn die Variable den Gültigkeitsbereich verlässt¹.

UniqueArray und das kapazitätsfeste RigidArray leben in einem neuen Containers-Modul (SE-0527, prinzipiell akzeptiert), und Sie können beide heute schon über swift-collections 1.3 verwenden, bevor sie sich in der Standardbibliothek niederlassen⁷.

Zur Optimierersteuerung fügt Swift 6.4 @inline(always) hinzu, um das langjährige @inline(never) zu ergänzen (kombinieren Sie es bei Klassenmethoden mit final, da eine überschreibbare Methode möglicherweise dennoch nicht inlined wird), und Swift 6.3 fügt @specialized hinzu, wobei eine where-Klausel dem Compiler mitteilt, eine spezialisierte Version einer generischen Funktion für die konkreten Typen vorab zu generieren, die Sie am häufigsten verwenden¹. Sie werden diese selten benötigen. Wenn doch, dann, wie es die Session formuliert, „werden Sie froh sein, dass Sie sie haben”¹.

Swift Testing: Migration ist jetzt bidirektional

Swift Testing erschien in Xcode 16 als die moderne, makrobasierte, standardmäßig parallele Testbibliothek². Die Geschichte 2026 ist Migration, und die wichtigste Ergänzung ist die Test-Framework-Interoperabilität: die Fähigkeit, API aus einem Framework innerhalb eines Testkörpers des anderen aufzurufen, und das in beide Richtungen².

Jerry aus dem Swift-Testing-Team demonstriert das Aufrufen von XCTest-Helfern aus Swift-Testing-Tests. Die Interoperabilitäts-Durchführung beginnt etwa bei 5:48.

Die von Apple empfohlene Migrationsstrategie hat sich nicht geändert: Lassen Sie die meisten XCTests an Ort und Stelle, schreiben Sie neue Tests in Swift Testing und migrieren Sie diejenigen, die Sie am häufigsten anfassen. Beide Frameworks koexistieren bereits in einem Target. Neu ist, dass Sie den Helfercode, den Sie auf XCTest aufgebaut haben, wiederverwenden können. Wenn ein Swift-Testing-Test einen assertUnique-Helfer aufruft, der XCTFail umschließt, erzeugt das ein Cross-Framework-Issue, und Xcode behandelt es nun mit vier Modi²:

• Limited: Cross-Framework-Issues von XCTest sind Warnungen. Testpläne, die vor Xcode 27 erstellt wurden, erben diesen Modus, und Swift-Pakete auf swift-tools-version: 6.3 verwenden ihn standardmäßig.
• Complete: Dieselben Issues bleiben Fehler. Xcode 27 verwendet den Complete-Modus für neue Projekte; Swift-Pakete melden sich dafür an, indem sie auf swift-tools-version: 6.4 oder neuer anheben.
• Strict: Cross-Framework-Issues von XCTest stoppen den Test mit einem fatalen Fehler und weisen Sie auf jede Stelle hin, an der XCTest-API zu ersetzen ist.
• None: vollständige Abmeldung (nur vorübergehend verwenden, da diese Issues echte Bugs aufzeigen können).

Cross-Framework-Issues von Swift Testing bleiben in jedem Modus Fehler, sodass Sie #expect und #require gefahrlos aus einem XCTestCase heraus aufrufen können. Sie überschreiben den Standard in einem Paket mit der Umgebungsvariablen SWIFT_TESTING_XCTEST_INTEROP_MODE (Modusname in Kleinbuchstaben)². Die XCTest-Session 262 bestätigt die passende Seite der Standardbibliothek: XCTest-Assertion-Fehler erscheinen nun als Test-Issues, wenn sie aus Swift Testing aufgerufen werden, sodass Sie migrieren, ohne stillschweigend Abdeckung zu verlieren¹.

Das Migrations-Kochbuch deckt die gängigen Muster ab. XCTSkip wird zu Test.cancel (oder, besser, einem .enabled/.disabled-Trait, das die Aktivierungslogik aus dem Testkörper herausverlagert). continueAfterFailure = false wird zu #require, das bei einem Fehler wirft und den Test anhält, sodass Sie pro Erwartung wählen können, welche Fehler die Ausführung stoppen². Die Interoperabilität unterstützt einen begrenzten, aber praktischen API-Satz: alle XCTest-Assertions, beide Erwartungs-Makros (#expect und #require), die Known-Issue-API zum Markieren von XCTest-Fehlern als bekannt sowie Test.cancel zum Überspringen von XCTest-Fällen².

Für die API-Oberfläche selbst (die Makros, das Trait-Vokabular, was in XCTest bleibt) behandelt der Begleitbeitrag zu Swift Testing vs. XCTest das mentale Modell. Zwei Hinweise tragen sich von dort weiter: UI-Automatisierung und Performance-Tests bleiben ausschließlich XCTest, und Code, der Objective-C-Exceptions wirft, muss in XCTests verbleiben, die in Objective-C geschrieben sind, weil Swift-Code diese Exceptions nicht sicher behandeln kann². Nach der Migration erhalten Sie parametrisierte Tests (jedes Argument ein eigener Fall, alle laufen parallel) und Exit-Tests, die Code ausführen, von dem ein Absturz erwartet wird, und zwar in einem Kindprozess, um die Beendigung zu verifizieren, verfügbar auf macOS, Linux, FreeBSD und Windows².

gRPC Swift: Typisierte Echtzeitdienste

Die Server-Geschichte ist die klarste Demonstration dafür, dass Swift nun Client und Backend mit einer Sprache abdeckt. Die gRPC-Session baut eine iOS-App, die mit einem Swift-Server kommuniziert, vollständig aus einer .proto-Spezifikation generiert³.

George aus dem Swift-Server-Team erklärt die vier RPC-Typen. Der Streaming-Abschnitt, einschließlich bidirektionalem Streaming, beginnt etwa bei 11:06.

gRPC ist ein Projekt der Cloud Native Computing Foundation, bei dem Sie APIs als Funktionen mit typisierten Eingaben und Ausgaben statt als HTTP-Endpunkte definieren und den Client-Code aus der Spezifikation generieren³. Der Ablauf: Definieren Sie den Dienst in einer .proto-Datei, fügen Sie grpc-swift-nio-transport (Netzwerk auf SwiftNIO) und grpc-swift-protobuf (das Build-Plugin) als Paketabhängigkeiten hinzu, hängen Sie das Run-Build-Tool-Plugin GRPCProtobufGenerator an und kompilieren Sie neu, um den typisierten Client zu generieren.

Ein unärer RPC wie ListRaces sendet eine Anfrage und erhält eine Antwort. Die Go-Kart-Demo der Session verdrahtet ihn in einer SwiftUI-View mit withGRPCClient, refaktoriert dann, um über die SwiftUI-Umgebung einen einzelnen Client zu teilen, sodass Views Verbindungen wiederverwenden, und trennt die Verbindung, wenn die Szene in den Hintergrund wechselt³. Protobuf serialisiert Nachrichten zu Binärdaten, die nach Feldnummer statt nach Feldname geschlüsselt sind, was eine Nachricht „etwa halb so groß wie die äquivalente JSON-Nachricht” macht³, ein echter Gewinn in schlechten Mobilfunknetzen. Apple merkt an, dass dieselbe Effizienz die eigene Infrastruktur antreibt: gRPC Swift treibt die Interprozesskommunikation im quelloffenen Containerization-Framework an und untermauert Private Cloud Compute, iCloud-Schlüsselbund und -Fotos sowie die SharePlay-Dateifreigabe³.

Die Streaming-Unterstützung ist das, was Echtzeit ermöglicht. Über unäre RPCs hinaus gibt es Client-Streaming (viele Anfragen, eine Antwort), Server-Streaming (eine Anfrage, viele Antworten, wie ein Live-Kommentar-Feed) und bidirektionales Streaming. Die Demo verwendet bidirektionales Streaming für Live-Rennen-Updates: Der Client streamt, welche Ereignistypen er möchte, während der Server passende Ereignisse streamt. Auf der Serverseite wird daraus eine async-Funktion, deren Anfrageparameter eine AsyncSequence von Nachrichten und deren Antwortparameter ein Writer ist, behandelt mit einer Task-Group und einem mutex-geschützten Set abonnierter Ereignistypen³. Das Deployment ist ein mehrstufiges Containerfile (Build mit swift:latest, Kopieren der Release-Binary in swift:slim), läuft auf Google Cloud Run mit HTTP/2, und dann schaltet der Client seine Transportsicherheit von Klartext auf TLS um³.

MLX Swift: Numerisches Rechnen, das sich wie Mathematik liest

Die MLX-Session richtet sich an einen völlig anderen Entwickler: jeden, der Simulationen, Signalverarbeitung, Rendering oder Modelltraining schreibt. MLX Swift verwendet n-dimensionale Arrays als zentrale Abstraktion, so wie es NumPy tut, sodass sich „der meiste NumPy-Code mit minimalen Änderungen in MLX Swift übersetzen lässt”⁴.

David Koski führt durch das Mandelbrot-Beispiel. Der Vergleich des Array-Computings mit reinem Swift beginnt etwa bei 4:28.

MLX steht neben dem bestehenden numerischen Apple-Stack, statt ihn zu ersetzen: Accelerate für handoptimierte CPU-Vektor-Primitive, BNNS für Bausteine neuronaler Netze, Metal Performance Shaders für direkte GPU-Kernel und Swift Numerics für den Complex-Typ. Sie greifen zu MLX Swift, wenn das Ziel „das Schreiben mathematischen Codes mit Blick auf Performance” ist und der Code wie die Mathematik aussehen soll⁴.

Zwei Features machen das möglich. Lazy Evaluation baut einen Berechnungsgraphen auf, während Sie Array-Operationen schreiben, und führt nichts aus, bis Sie eval aufrufen oder einen Wert lesen, weshalb eine Schleife in jedem Schritt eval aufruft, um den Graphen klein zu halten. Lazy Evaluation treibt auch die automatische GPU-Ausführung und die automatische Differentiation über die Funktionstransformation grad an⁴. Das Mandelbrot-Beispiel kollabiert eine skalare Schleife pro Pixel in zwei Zeilen (z = z * z + c auf das gesamte Gitter angewendet, dann eine Zählung der beschränkten Iterationen), läuft standardmäßig auf der GPU, und die Session merkt an: „10x schneller ist durchaus möglich”⁴. Ein Wärmeverteilungs-Solver drückt die Jacobi-Iteration als einen einzigen conv2d-Aufruf aus. Das Kurvenanpassungs-Beispiel verwendet grad, um exakte Gradienten ohne handgeschriebene Ableitungen zu berechnen, dieselbe Idee, die hinter dem Training jedes ML-Modells steckt⁴.

MLX Swift ist quelloffen unter einer MIT-Lizenz, über den Swift Package Manager installierbar und eines von vier Frontends (Swift, Python, C++ und C), die sich dasselbe Operations- und Lazy-Evaluation-Modell teilen, sodass Sie „in Python prototypisieren und in Swift ausliefern” können⁴. Das Ökosystem umfasst mlx-swift (das Kern-Framework), mlx-swift-lm (Implementierungen von Sprachmodellen) und mlx-swift-examples (ausführbare LLM-, Diffusions- und Trainingsbeispiele)⁴. Für den umgebenden On-Device-ML-Kontext siehe MLX On-Device-ML auf Apple Silicon.

Was zuerst übernehmen

Ordnen Sie die Arbeit danach, wer Sie sind.

Wenn Sie Apps ausliefern und die Performance-Stellschrauben des Compilers selten anfassen, übernehmen Sie jetzt die Ergonomie und ignorieren Sie das Ownership-System. Ersetzen Sie gestapelte @available-Zeilen durch anyAppleOS, wo Ihre Plattformen übereinstimmen, nutzen Sie @diagnose, um Veraltungswarnungen genau dort zu unterdrücken, wo Sie mitten in einer Migration sind, und greifen Sie zu Modulselektoren (::), wenn das nächste Mal eine Abhängigkeit mit SwiftUI bei einem Namen wie View kollidiert¹.

Wenn Sie eine große XCTest-Suite pflegen, aktivieren Sie die Interoperabilität und beginnen Sie heute damit, neue Tests in Swift Testing zu schreiben. Stellen Sie bestehende Testpläne auf den Complete-Modus um, sodass Cross-Framework-Issues Fehler sind, die Sie nicht übersehen können, verwenden Sie Ihre XCTest-Helfer über die Interoperabilität wieder, statt sie vorab umzuschreiben, und migrieren Sie die Dateien, die Sie am häufigsten anfassen. Behalten Sie UI-Automatisierung, Performance-Tests und Objective-C-Exception-Tests in XCTest¹².

Wenn Sie leistungskritischen Code schreiben, sind die Ownership-Ergänzungen das Hauptthema. Prüfen Sie heiße berechnete Eigenschaften, die große Werte halten, und stellen Sie sie von get/set auf borrow/mutate um. Wo Sie zuvor auf UnsafePointer zurückgriffen, schauen Sie sich Ref/MutableRef, UniqueArray und die Continuation mit Einmal-Resume an. Messen Sie, bevor Sie zu @inline(always) oder @specialized greifen, denn der Optimierer hat meist recht, und ihn zu zwingen kann die Binary größer und langsamer machen¹.

Wenn Ihre Arbeit serverseitig oder numerisch ist, sind die neuen Pakete produktionsreife Einstiegspunkte: gRPC Swift gibt Ihnen aus einer .proto-Datei einen typisierten Client und bidirektionales Streaming, und MLX Swift gibt Ihnen GPU-beschleunigtes Array-Computing und automatische Differentiation, die sich wie die Mathematik liest³⁴.

FAQ

Was ist der Unterschied zwischen Swift 6.3 und Swift 6.4?

Apple entwickelte und veröffentlichte beide im selben WWDC26-Zyklus und stellte sie gemeinsam vor. Grob gesagt führte Swift 6.3 die Modulselektoren (::) und das @specialized-Attribut ein und lieferte das erste offizielle Swift SDK für Android. Swift 6.4 fügte die anyAppleOS-Verfügbarkeit, optionales any/some ohne Klammern, das Iterable-Protokoll für for-Schleifen, borrow/mutate-Accessoren, @inline(always), das @C-Attribut zum Exportieren von Swift-Funktionen nach C sowie die Debugging-Verbesserungen für Embedded Swift hinzu. Die Session behandelt die beiden als einen durchgängigen Arbeitskörper¹.

Muss ich von XCTest zu Swift Testing migrieren?

Nein. XCTest wird weiterhin ausgeliefert und funktioniert weiterhin, und Apples Empfehlung ist inkrementell: Schreiben Sie neue Tests in Swift Testing und migrieren Sie alte, sobald Sie sie anfassen. Die Test-Framework-Interoperabilität lässt die beiden in einem Target koexistieren und die API des jeweils anderen aufrufen, sodass Sie XCTest-Helfer aus Swift-Testing-Tests wiederverwenden können. UI-Automatisierung, Performance-Tests und Code, der Objective-C-Exceptions wirft, bleiben in XCTest¹².

Was tut das neue Iterable-Protokoll, was Sequence nicht tut?

Sequence kopiert Elemente beim Iterieren heraus. Iterable lässt die for-Schleife Elemente stattdessen ausleihen, sodass es mit nicht kopierbaren Elementen funktioniert und das Reference-Counting bei Objekten und Copy-on-Write-Typen überspringt. Es liefert Elemente in Batches von Spans statt einzeln, was effizienter ist, und es kann während der Iteration werfen. Weil Ausleihen Mutation verbietet, können Sie die Sammlung während des Schleifendurchlaufs nicht mutieren. Eine for-Schleife bevorzugt Sequence, wenn verfügbar, und greift auf Iterable zurück¹.

Wann sollte ich MLX Swift statt Accelerate oder Metal Performance Shaders verwenden?

Verwenden Sie MLX Swift, wenn Ihr Hauptziel das Schreiben mathematischen Codes mit Blick auf Performance ist und der Code sich wie die Mathematik lesen soll, mit automatischer GPU-Ausführung und automatischer Differentiation über grad. Accelerate bleibt die Wahl für handoptimierte CPU-Vektor-Primitive, BNNS für Bausteine neuronaler Netze und Metal Performance Shaders für direkten GPU-Kernel-Zugriff. MLX steht neben ihnen, statt sie zu ersetzen⁴.

Ist gRPC Swift nur für Backend-Dienste?

Nein. Die WWDC-Session baut eine iOS-App als gRPC-Client, generiert einen typisierten Client aus einer .proto-Datei und zeigt unäre sowie bidirektionale Streaming-RPCs, die Live-UI-Updates antreiben. Protobufs Binärkodierung erzeugt Nachrichten, die etwa halb so groß wie äquivalentes JSON sind, was in schlechten Mobilfunknetzen hilft. Apple verwendet gRPC Swift außerdem für die Interprozesskommunikation und in Diensten wie Private Cloud Compute, iCloud-Schlüsselbund und -Fotos sowie der SharePlay-Dateifreigabe³.

Der Apple-Ecosystem-Cluster

Swifts Update 2026 zieht sich durch den Rest der Apple-Ecosystem-Serie: die Aufschlüsselung Swift Testing vs. XCTest des Testmodells, die Observable-Interna in SwiftUI, die die Concurrency-Änderungen berühren, woraus SwiftUI besteht auf Framework-Ebene und MLX On-Device-ML auf Apple Silicon für den Kontext des numerischen Rechnens. Der Knotenpunkt für all das ist die Apple-Ecosystem-Serie. Zum Bauen von iOS-Apps mit KI-Agenten im Loop siehe den Leitfaden zur iOS-Agent-Entwicklung.

Referenzen