Was Apples Swift-Team im WWDC26-Lab gesagt hat

Apple hat das Swift Group Lab der WWDC26 als eine Stunde ungeskripteter Fragerunde mit vier Ingenieuren aus den Teams für Swift, Foundation und Server-Networking veröffentlicht – und dann ohne Untertitel ausgeliefert.¹ Wir haben das Video durch einen lokalen Transkriptionsdurchlauf geschickt, um nachzulesen, was sie tatsächlich gesagt haben. Die polierten Sessions sagen Ihnen, was eine Funktion macht. Das Lab ist der Ort, an dem Holly zugibt, dass sie sich bei einer zentralen Concurrency-Entscheidung geirrt hat, an dem Corey das Cleanup-Muster erklärt, das in abgebrochenem Code stillschweigend versagt, und an dem das Panel einen Ratschlag wiederholt, den das Marketing nie geben wird: Hören Sie auf, Sprachfunktionen zu sammeln. Die offene Version steht hier.

Eine Anmerkung zur Quellenlage: Apple hat kein offizielles Transkript zum Lab veröffentlicht. Jedes Zitat unten ist eine Paraphrase aus einer lokalen Transkription des veröffentlichten Videos, mit ungefähren Zeitstempeln. Die Sprecher werden mit Vornamen und Team genannt, so wie das Transkript sie ausweist: Holly (Swift-Sprachteam, Generics und Concurrency), Corey (Swift-Server-Networking-Team), Tony (Foundation und Standardbibliothek) und Doug (Swift-Sprachteam).¹

TL;DR

• Holly sagte, würde das Team Swift Concurrency heute entwerfen, würden nonisolated async-Funktionen von Anfang an im Kontext des Aufrufers laufen. Sie hielt „sehr lange Zeit” an der gegenteiligen Überzeugung fest und änderte ihre Meinung anhand von Erfahrungen aus der Praxis. Swift 6.2 machte den Aufrufer-Kontext zum Standard.¹
• Der wiederkehrende Rat: Machen Sie Typen bewusst nicht-Sendable. ~Sendable (SE-0518, implementiert in Swift 6.4) bietet eine sauberere Schreibweise, und Foundation annotiert Typen neu, die es zuvor als tabu markiert hatte – wobei UserDefaults eine Sendable-Konformanz auf der globalen Instanz erhält.²¹
• Coreys Muster für asynchrones Cleanup: Abgebrochene Kontexte überspringen async-Cleanup stillschweigend; prüfen Sie deshalb jedes async defer auf suspendierende await-Aufrufe und kapseln Sie diese in einen Cancellation-Shield. SE-0493 (async defer) und SE-0504 (withTaskCancellationShield) kommen beide in Swift 6.4.³⁴
• Offenheit zur Roadmap: Der Disconnected-Typ ist ein aktiver Forums-Pitch, Tuple-Konformanzen sind „fast fertig”, befinden sich formal aber wieder in der Überarbeitung, UniqueArray ist im Prinzip angenommen, Subprocess 1.0 erscheint, und SwiftPM vereinheitlicht sich auf Swift Build.⁵⁶⁷⁸
• Das wiederkehrende Leitmotiv des Panels: „Sprachfunktionen sind keine Sammelstücke.” Profilen Sie zuerst, übernehmen Sie das eng zugeschnittene Werkzeug, auf das der Profiler zeigt, und lassen Sie den Rest in Ruhe.¹

Die Concurrency-Entscheidung, die Apple heute anders treffen würde

Hollys Concurrency-Rückblick beginnt etwa bei 33:42. Das vollständige Lab hat keine offiziellen Untertitel; das Transkript unten stammt aus lokaler ASR.

Ein Entwickler stellte dem Panel eine Frage, zu der polierte Sessions selten einladen: Jetzt, da Swift-6-Concurrency lange genug im Feld ist, um die Verbreitung zu beobachten – gibt es etwas, das das Team heute anders entwerfen würde? Holly antwortete ohne Umschweife. Ja, ganz sicher.

Das konkrete Bedauern betrifft die Frage, wo eine nonisolated async-Funktion läuft. Zwei Swift-Evolution-Proposals bewegten dieses Verhalten in entgegengesetzte Richtungen. Der erste sorgte dafür, dass nonisolated async-Funktionen stets zum globalen nebenläufigen Thread-Pool wechseln. Der spätere, in Swift 6.2, ließ sie auf dem Kontext bleiben, der sie aufgerufen hat – eine vom Main Actor aufgerufene Funktion bleibt also beim Main Actor.¹ Holly führte die Kehrtwende auf Erfahrungen von Leuten zurück, die die frühen Concurrency-Prüf-Flags in echten Apps und Bibliotheken einsetzten: Sie reichten nicht-Sendable-Typen zwischen einem actor-isolierten Kontext und diesen nonisolated async-Funktionen hin und her, und der Standard des globalen Pools erzeugte Data-Race-Fehler, weil der ursprüngliche Actor diese Werte noch hielt, während die async-Funktion anderswo lief.¹

Dann der Teil, der in keiner Session-Aufzeichnung auftaucht. „Ich hielt sehr lange Zeit an der Überzeugung fest, dass das Laufen auf dem globalen nebenläufigen Thread-Pool das richtige Modell für die langfristigen Vorteile war”, sagte Holly, „aber ich wurde mit der Zeit durch Probleme in realen Projekten überzeugt” (ASR-Paraphrase, ~35:50).¹ Doug stellte die ursprüngliche Entscheidung als vertretbare Wette auf das Gesamtsystem dar: mehr verfügbare Concurrency bedeutet mehr potenzielle Parallelität, was bessere Performance bedeuten kann. Die Kosten zeigten sich erst, als die Leute das vollständige Sicherheitsmodell nutzten, und es drängte zu viele Typen in Richtung Sendable, was Doug als „nicht die natürliche Art, all diese Ideen auszudrücken” bezeichnete.¹ Der Aufrufer-Kontext als Standard ist zugänglicher, weil er sich wie nicht-nebenläufiger Code verhält, bis Sie sich ausdrücklich für Parallelität entscheiden. Wenn Sie Swift 6.2 übernommen und sich gefragt haben, warum sich die Concurrency-Geschichte plötzlich ruhiger anfühlte, lautet die Antwort: Die Leute, die sie entworfen haben, gestanden ein, dass der erste Standard der falsche war, und lieferten die Korrektur aus.

Machen Sie Ihre Typen bewusst nicht-Sendable

Der kontraintuitivste Rat des Labs läuft zwei Jahren Migrationsgewohnheit zuwider. Holly sagte, sie treffe ständig auf Entwickler, die fragen, wie sie ihre Typen Sendable machen können, und dass die bessere Frage oft die umgekehrte sei: Sollte dieser Typ nicht-Sendable sein?¹ Bei kurzlebigen Typen, die innerhalb einer einzigen Berechnung verwendet werden, erzeugt die explizite Markierung als nicht-Sendable ein saubereres Datenmodell und eine schärfere Trennlinie zwischen dem, was Sie über Isolationsgrenzen hinweg übergeben wollen, und dem, was nicht. Es hilft auch der Performance, denn die Kosten für das Herumreichen eines Typs sind etwas, das Sie bei Zwischenwerten, die nie wandern mussten, vermeiden wollen.¹

Swift 6.4 gibt dieser Absicht eine echte Schreibweise. Mit ~Sendable (SE-0518) können Sie die Konformanz direkt unterdrücken, so wie ~Copyable die Kopierbarkeit unterdrückt, statt eine unavailable-Konformanz zu schreiben.² Holly zog die Unterscheidung präzise: Eine unavailable Sendable-Konformanz erklärt den Typ und jede Unterklasse definitiv als nicht sendbar und propagiert das durch die gesamte Hierarchie, während ~Sendable lediglich das Fehlen einer Konformanz ist – eine Unterklasse, die keinen veränderlichen Zustand hinzufügt, kann also weiterhin ihre eigene Sendable-Konformanz ergänzen.²¹

Genau diese Flexibilität brauchte Foundation. Tony erläuterte die dritte Kategorie aus Foundations ursprünglichem Sendable-Audit: Klassen, bei denen die Oberklasse sicher ist, eine Unterklasse aber möglicherweise nicht. Sein Beispiel war NSString, das unveränderlich und sendbar ist, gegenüber NSMutableString, das eine veränderliche Unterklasse und nicht sendbar ist.¹ Statt eine falsche Annotation zu überstürzen, markierte Foundation die mehrdeutigen Klassen als nicht-Sendable und wartete ab. Jetzt, sagte Tony im Lab, nutzt das Team die Annotation aus Swift 6.4, um diese Typen korrekt neu zu annotieren, und er erwartet, dass die globale Standard-UserDefaults eine Sendable-Konformanz erhält.¹ Behandeln Sie die UserDefaults-Konformanz und die umfassendere Foundation-Neuannotation als Lab-Aussagen: Tony nannte beide in der Fragerunde, und es sind keine Funktionen, die ich unabhängig aus einem veröffentlichten Proposal bestätigen kann. Die ständige Warnung des Panels gilt auch hier, von Tony: Greifen Sie nicht zu @unchecked Sendable, um den Swift-6-Modus zu erzwingen, denn jede unchecked-Annotation verwirft die Sicherheit, die der Compiler für Sie hätte beweisen können.¹

Asynchrones Cleanup, so umgesetzt, dass es tatsächlich läuft

Corey verantwortet die praktischste Korrektur im Lab, und es ist die Art von Bug, die Sie ausliefern, ohne es zu merken. Der charakteristische Vorteil strukturierter Concurrency ist die automatische Propagierung von Abbrüchen: Brechen Sie einen Task ab, und alles, was in seinem Dienst gestartet wurde, wird ebenfalls abgebrochen – genau das wollen Sie, wenn eine View verworfen wird oder ein Client die Verbindung trennt.¹ Die Falle steckt im Cleanup. Vielleicht haben Sie eine halb geschriebene Datei, die in einen bekannten guten Zustand gebracht werden muss, oder eine Datenbanktransaktion, die zurückgerollt werden muss – und dieses Cleanup ist selbst asynchron. Wie Corey es formulierte, weigert sich der meiste Swift-Code, in einem abgebrochenen Kontext ausgeführt zu werden, weil er annimmt, er solle sich so schnell wie möglich abwickeln; async-Cleanup, das innerhalb eines abgebrochenen Tasks läuft, kann seine Aufgabe daher stillschweigend nicht erfüllen.¹

Die Lösung ist ein Cancellation-Shield, und er passt direkt zu async defer. SE-0493 erlaubt einem defer-Block, await-Aufrufe zu enthalten, und kommt in Swift 6.4.³ SE-0504 fügt withTaskCancellationShield hinzu, ebenfalls in Swift 6.4, das einen Block so ausführt, als wäre kein Abbruch angefordert worden, damit suspendierendes Cleanup abgeschlossen wird.⁴ Coreys Audit-Rezept ist konkret: Sehen Sie sich jeden async defer-Block an und fragen Sie, ob ein await darin tatsächlich suspendieren wird. Wenn ja, kapseln Sie es in einen Cancellation-Shield.¹ Er nannte die beiden „eine großartige Ergänzung” und „einen wirklich guten Doppelschlag, um Ihre Ressourcen sauber aufzuräumen.”¹ Nicht-Sendable-Typen verstärken dieselbe Disziplin, wie Corey anmerkte, denn ein Wert, der keine Concurrency-Domänen überqueren kann, zwingt Ihren async-Kontrollfluss dazu, linear und leicht nachvollziehbar zu bleiben.¹

Der breitere Rat zu strukturierter Concurrency von Corey rundet den Abschnitt ab. Setzen Sie entschlossen darauf, denn die Notausgänge verursachen den Ärger. Vermeiden Sie unstrukturierte Tasks (Task.detached oder ein bloßes Task) „nahezu um jeden Preis”, es sei denn, Sie senden Arbeit bewusst woanders hin – und niemals im Hauptablauf. Machen Sie Task-Gruppen zu Ihrem Standard, passen Sie Objektlebenszyklen an ihren lexikalischen Geltungsbereich an und schreiben Sie linearen async-Code: ein Rezept aus Schritt A, dann B, dann C, und greifen Sie zu Parallelität innerhalb von Task-Gruppen nur, wenn sich die Arbeit wirklich auffächert.¹

Offenheit zur Roadmap

Im Lab trennt das Panel auch ausgelieferte Funktionen von optimistischen, und die Lücke ist wichtig, wenn Sie entscheiden, worauf Sie aufbauen.

Die Frage, wie man einen übergebenen nicht-Sendable-Wert speichert, hat eine echte Antwort in Aussicht. Heute übergeben Sie mit dem Schlüsselwort sending, und regionsbasierte Isolation lässt den Compiler beweisen, dass der ursprüngliche Eigentümer den Zugriff freigegeben hat; wenn Sie einen solchen Wert aber speichern müssen, funktionieren nur die unsicheren Opt-outs.¹ Holly verwies auf Disconnected, einen aktiven Forums-Pitch für einen Typ, der die Übergabe-Eigenschaft über die Speicherung hinweg bewahrt, sodass Sie einen Wert ablegen und später weiterreichen können. Er wird gerade jetzt entworfen und diskutiert, nicht implementiert.⁵¹

Tuple-Konformanzen sind das schärfste Beispiel für Ingenieursoptimismus gegenüber dem formalen Stand. Auf die Frage, was noch fehlt, bis Tupel bedingt Equatable, Hashable und Comparable konform sind, erklärte Holly, es sei eine Weiterentwicklung von Parameter Packs: Die Sprache braucht Syntax, um eine Extension über ein Tupel zu schreiben, dessen Elementtypen ein Parameter Pack sind, mit einer where-Klausel, die von jedem Element Konformanz verlangt.¹ Sie sagte, eine experimentelle Implementierung liege im Compiler-Repository und sei „fast komplett fertig”.¹ Der formale Stand ist vorsichtiger. SE-0283, der ursprüngliche Proposal für Tuple-Konformanzen, wurde zur Überarbeitung zurückgegeben und seine Implementierung von 2020 rückgängig gemacht; der allgemeine Parameter-Pack-Ansatz existiert heute nur hinter einem experimentellen TupleConformances-Compiler-Flag.¹⁰ Lesen Sie Hollys „fast fertig” als die ehrliche Einschätzung einer Ingenieurin zur Implementierung, nicht als ausgelieferte Funktion.

Die Performance-Container sind weiter fortgeschritten. UniqueArray, das Tony erwähnte, stammt aus SE-0527 („RigidArray und UniqueArray”), nun im Prinzip angenommen, und führt ein neues Containers-Modul in der Standardbibliothek ein; es wird in einer frühen Form bereits in swift-collections 1.3 ausgeliefert.⁷ Tony positionierte es als das Upgrade für ein Array, dessen Copy-on-Write-Retain/Release-Verkehr in einem Instruments-Trace auftaucht.¹ Subprocess, die plattformübergreifende Open-Source-Prozess-API, die Tony als seinen Favoriten nannte, erscheint dieses Jahr in Version 1.0; der 1.0-Meilenstein ist angekündigt, das neueste veröffentlichte Tag steht noch bei 0.5, es erscheint also gerade, ist aber noch nicht erschienen.⁶¹ Beim Tooling beschrieb Holly die SwiftPM-Änderung, die Entwickler vielleicht gar nicht bemerken: Xcodes Package-Builds und die Builds der Open-Source-Toolchain teilen sich jetzt eine Implementierung, Swift Build, das zum Standard-Backend des Build-Systems wird (Standard auf main, anvisiert für 6.4).⁸¹

Zum Schluss der Migrationspfad, mit dem Holly einstieg: @diagnose, das neue Attribut aus SE-0522 („Source-Level Control Over Compiler Warnings”), angenommen.⁹ Es gibt Kontrolle über Warnungen auf Quellcode-Ebene, sodass Sie Deprecation-Warnungen in einem Bereich unterdrücken oder sich für standardmäßig deaktivierte Warnungen wie strict memory safety oder strict concurrency in den Bereichen entscheiden können, in denen es am wichtigsten ist – das macht es zu einem feiner abgestuften Werkzeug für eine schrittweise Swift-6-Migration.¹

Ingenieursratschläge, gesammelt

Der Wert des Labs liegt im angesammelten Praktikerwissen, das nie in die Laufzeit einer Session passt. Die Höhepunkte, mit Zuordnung:

• Schreiben Sie linearen async-Code. Corey: Vermeiden Sie unstrukturierte Tasks nahezu um jeden Preis, halten Sie jeden Task als sequenzielles Rezept und führen Sie Parallelität nur innerhalb von Task-Gruppen ein, wenn sich die Arbeit wirklich auffächert.¹
• Ein Rezept für die MainActor-Migration. Holly: Beginnen Sie mit Blatt-Typen und arbeiten Sie nach außen, oder schalten Sie main-actor-by-default für ein Modul ein, das vollständig main-actor sein soll, und annotieren Sie die ausgelagerten Teile explizit. Markieren Sie Methoden, die keinen veränderlichen Zustand berühren, als nonisolated, und wandeln Sie eine static var, die nie tatsächlich mutiert wird, in eine let um, damit sie nonisolated bleiben kann.¹
• Konformanzkosten sind ungleich. Doug: Eine ungenutzte Equatable- oder Hashable-Konformanz behält ihren Witness-Code in der Binärdatei, weil ein Laufzeit-as?-Cast auf ein Existential ihn entdecken kann – sie kostet also Codegröße; Sendable ist ein reiner Tag zur Compile-Zeit ohne Laufzeitrepräsentation, eine ungenutzte Sendable-Konformanz ist also kostenlos.¹
• Die Kombination aus @inlinable und @inline(never). Coreys Lieblingstrick: @inlinable macht einen Funktionskörper über Modulgrenzen hinweg sichtbar und schaltet generische Spezialisierung und Effekt-Propagierung frei, während @inline(never) verhindert, dass ein kalter, codeschwerer Pfad (eine bytewise Fallback-Kopie) inline gesetzt wird, sodass der heiße Pfad schnell bleibt. Er hat das Paar „dreimal im gesamten Swift-Networking-Portfolio” verwendet, für ungewöhnliche Performance-Probleme auf dem kalten Pfad.¹
• Optimieren Sie den heißesten Pfad, nicht das Projekt. Corey: „Wir hatten großen Erfolg damit, Spans und ein paar Unique Arrays genau entlang des heißesten Pfades einzuführen”, was nahezu den gesamten Performance-Gewinn für eine kleine, compilergestützte Änderung liefert. Halten Sie die neuen Performance-Typen isoliert, damit ihre Übernahme nie ein riesiges Refactoring erzwingt.¹
• Hören Sie auf, Funktionen zu sammeln. Die wiederkehrende Zeile des Panels, von einem Freund, den Corey zitierte: „Sprachfunktionen sind keine Sammelstücke.” Es gibt keinen Preis dafür, sie alle zu nutzen. Profilen Sie zuerst, greifen Sie zu dem eng zugeschnittenen Werkzeug, auf das der Profiler zeigt (non-copyable Typen, UniqueArray, Span), und verbringen Sie den Rest Ihrer Stunden mit Bugfixes und Funktionen.¹

FAQ

Hat Apple das WWDC26-Swift-Lab wirklich ohne Untertitel veröffentlicht?

Ja. Apple stellte das Swift Group Lab (Session 8001) als Video ohne offizielles Transkript oder Untertitel auf der Entwicklerseite ein.¹ Um es korrekt zu zitieren, habe ich die Aufnahme durch einen lokalen Transkriptionsdurchlauf geschickt; jedes Zitat in diesem Beitrag ist also eine Paraphrase aus dieser lokalen ASR mit ungefähren Zeitstempeln, zugeordnet nach Vorname und Team.¹

Was sagte das Swift-Team, würde es an Concurrency ändern?

Holly sagte, würde Apple Swift Concurrency heute entwerfen, würden nonisolated async-Funktionen von Anfang an im Kontext des Aufrufers laufen, statt zum globalen nebenläufigen Thread-Pool zu wechseln. Sie hielt lange an der Überzeugung des globalen Pools fest und änderte ihre Meinung anhand von Erfahrungen aus der Praxis, und Swift 6.2 machte das Verhalten mit Aufrufer-Kontext zum Standard.¹

Sollte ich meine Swift-Typen Sendable oder nicht-Sendable machen?

Der Rat des Labs lautet, kurzlebige Berechnungstypen bewusst nicht-Sendable zu machen. Swift 6.4 fügt dafür die ~Sendable-Schreibweise (SE-0518) hinzu, die sich von einer unavailable-Konformanz unterscheidet, weil Unterklassen weiterhin Sendable ergänzen können, wenn sie keinen veränderlichen Zustand hinzufügen.² Tony sagte, Foundation annotiere seine mehrdeutigen Klassen mit der neuen Funktion neu und erwarte, dass die globale UserDefaults eine Sendable-Konformanz erhält – beides Lab-Aussagen.¹

Wie stelle ich sicher, dass async-Cleanup läuft, wenn ein Task abgebrochen wird?

Abgebrochene Kontexte führen dazu, dass der meiste Swift-Code suspendierende Arbeit überspringt, sodass async-Cleanup stillschweigend versagen kann. Coreys Muster ist, jedes async defer auf await-Aufrufe zu prüfen, die tatsächlich suspendieren, und sie in einen Cancellation-Shield zu kapseln. Async defer (SE-0493) und withTaskCancellationShield (SE-0504) kommen beide in Swift 6.4.³⁴¹

Werden Tuple-Konformanzen in Swift ausgeliefert?

Noch nicht. SE-0283 wurde zur Überarbeitung zurückgegeben und seine ursprüngliche Implementierung rückgängig gemacht; der allgemeine Parameter-Pack-Ansatz existiert nur hinter einem experimentellen TupleConformances-Flag. Holly sagte im Lab, eine experimentelle Implementierung im Compiler sei „fast komplett fertig”, was eher Ingenieursoptimismus als eine ausgelieferte Funktion widerspiegelt.¹

Das Lab ist die offene Ergänzung zu den Ankündigungen: Für die ausgelieferten Funktionen im Kontext lesen Sie Was ist neu in Swift 2026, und für die Migrationsmechanik hinter dem von Holly besprochenen Aufrufer-Kontext-Standard siehe Swift 6.2 Concurrency in der Praxis. Die Philosophie des Panels – „erst profilen, dann das eng zugeschnittene Werkzeug übernehmen” – erstreckt sich auf das Testen in Swift Testing versus XCTest. Die vollständige WWDC26-Berichterstattung finden Sie in der Apple Ecosystem Series.

Referenzen