SwiftUI @State wird zum Makro – Xcode 27 bricht einige Ihrer Builds

WWDC 2026 liegt hinter uns, die iOS 27- und Xcode 27-Betas sind erschienen, und der Großteil der Berichterstattung widmete sich Liquid Glass mit einem Farbton-Schieberegler und einer intelligenteren Siri. Das ist die Verbraucherperspektive. Die Entwicklerperspektive ist präziser, und sie beginnt mit drei Zeichen, die Sie in fast jede SwiftUI-View schreiben: @State.
Ab Xcode 27 ist @State kein Property-Wrapper mehr, der DynamicProperty konformiert. Es ist jetzt ein Swift-Makro. Apple hat das neue Verhalten rückwirkend auf iOS 17, macOS 14, tvOS 17, watchOS 10 und visionOS 1 portiert, sodass Sie Ihr Deployment-Target nicht anheben müssen, um es zu erhalten. Bauen Sie denselben Code mit Xcode 26, verwendet SwiftUI weiterhin den alten Property-Wrapper. Der praktische Vorteil: In @State gespeicherte Klassen werden jetzt lazy initialisiert – einmal pro View-Lebensdauer –, anstatt bei jedem View-Re-Init neu allokiert zu werden.
Das ist das Gute. Der Haken ist, dass ein verbreitetes Muster nicht mehr kompiliert. Wenn Sie in der Deklaration einen Standardwert setzen und dann in init einen anderen Wert zuweisen, blockiert Xcode 27 Sie mit einem harten Fehler:
struct ProfileView: View {
@State private var name = "Guest" // Standardwert hier
init(user: User) {
name = user.displayName // hier neu zugewiesen -> Fehler in Xcode 27
}
}Früher hat das stillschweigend den falschen Wert verwendet. Jetzt ist es ein Fehler „variable used before being initialized“. In einer einzelnen View trivial, aber genau die Art von Problem, das sich in Dutzenden von Views einer ausgereiften App versteckt.
Die Fristmathematik arbeitet tatsächlich zu Ihren Gunsten
Hier ist der Teil, den Teams falsch machen. Sie geraten entweder in Panik oder ignorieren es – beides ist falsch.
Apples Einreichungsuntergrenze hat sich nicht verschoben. Seit dem 28. April 2026 erfordert App Store Connect nur, dass Sie mit Xcode 26 und dem iOS 26 SDK bauen. Es gibt keine angekündigte Frist, die Sie zum iOS 27 SDK zwingt, also liefern Sie nicht im Eiltempo gegen iOS 27.
Aber „keine Frist“ bedeutet nicht „keine Arbeit.“ Der @State-Fehler ist ein Kompilierfehler, und Kompilierfehler sind am günstigsten zu beheben, wenn Sie aktiv danach suchen – nicht wenn ein September-Release-Zug bereits rollt. In unseren nativen iOS- und Android-Projekten haben wir dieselbe Lektion mehr als einmal gelernt: Die Migration, die Sie planen, verläuft ruhig; die Migration, die auf einen Launch fällt, ist Chaos.
Der Schritt, den Sie heute machen können: Fügen Sie eine Xcode 27 Beta Lane in Ihrem CI hinzu und lassen Sie es jetzt gegen die neue Toolchain bauen. Sie müssen nicht liefern, was es produziert. Sie wollen nur, dass das rote X in einem Pull Request im Juli erscheint – nicht in einem Hotfix-Branch im Herbst. Durchsuchen Sie dabei Ihre Codebasis nach @State-Deklarationen, die einen Standardwert tragen und in einem Initialisierer neu zugewiesen werden. Das ist Ihre Fix-Liste, und sie ist endlich.
Die stilleren Änderungen, die Ihre Zeit wert sind
@State bekommt die Schlagzeile, aber einige andere SwiftUI-Updates verändern, wie wir Dinge bauen würden.
AsyncImage verwendet jetzt standardmäßig HTTP-Caching. Es berücksichtigt Server-Cache-Header ohne Codeänderungen, sodass das zweimalige Scrollen einer Liste das erneute Herunterladen derselben Bilder verhindert. Wir bauen bildintensive Apps in E-Commerce und Healthcare, und ein guter Teil der „Warum ist diese Liste so ruckelig“-Bugs geht auf naives Bildladen zurück. Kostenloses Caching ist willkommen – mit einem Vorbehalt aus unserer Infrastruktur- und Sicherheitsarbeit: Caching ist nur so gut wie Ihre Header. Wenn Ihr CDN oder Origin schwache Cache-Control-Werte sendet, cachen Sie entweder nichts oder cachen zu lange. Wenn wir Cloudflare für Kunden konfigurieren, sind Cache-Header eine echte Konfigurationsfläche, die wir bewusst abstimmen – kein Nachgedanke. Dieselbe Disziplin gilt hier.
Es gibt auch ein neues Dokumentmodell. SwiftUI ergänzt WritableDocument- und ReadableDocument-Protokolle mit asynchronem, inkrementellem Datenträgerzugriff, und Schreibvorgänge nutzen jetzt Snapshot-basiertes Diffing, sodass ein DocumentWriter nur die geänderten Teile speichert. Wenn Sie eine dokumentbasierte App pflegen, ist das ein echter Leistungshebel für große Dateien. Umsortierbare Container sind die andere schöne Ergänzung: Benutzer können Elemente jetzt per Drag-and-Drop in jedem Container neu anordnen – nicht nur in List –, mit demselben Code für List und LazyVStack.
Auf der Tooling-Seite wurden Swift 6.3 und 6.4 zusammen im Xcode 27 Beta veröffentlicht. Die Änderung, die die meisten Teams spüren werden, ist die bidirektionale Interoperabilität zwischen Swift Testing und XCTest. Sie können XCTest-Assertions aus einem Swift Testing-Test aufrufen, und das Umgekehrte funktioniert jetzt ebenfalls. Im standardmäßigen Limited-Modus erscheinen Framework-übergreifende Probleme als Warnungen; aktualisieren Sie Ihr Paket auf swift-tools-version: 6.4 für den Complete-Modus. Wenn Sie Swift Testing aufgeschoben haben, weil Ihre XCTest-Suite groß ist, ist diese Hürde größtenteils verschwunden. Schreiben Sie Ihren nächsten Test in Swift Testing und lassen Sie die alten dort, wo sie sind.
Was wir einem Team diese Woche raten würden
Testen Sie jetzt gegen Xcode 27, liefern Sie gegen iOS 26 wie bisher. Behandeln Sie den @State-Fehler als geplante Aufgabe, nicht als Notfall. Überprüfen Sie Ihr Image-Caching, solange AsyncImage in Ihrem Kopf ist, und beginnen Sie, neue Tests in Swift Testing zu schreiben. Nichts davon ist nach Apples Kalender dringend. Alles ist im Juli günstiger als im September.
Wir haben viele mobile und Web-Codebasen durch genau diese Art von Toolchain-Wechsel geführt – ohne Feueralarm in der Launch-Woche –, und die Art der Arbeit, die wir leisten, können Sie in unseren vergangenen Projekten sehen.
Wenn das Durchführen einer großen SwiftUI-App durch die Xcode 27-Build-Änderungen vor dem herbstlichen Release-Ansturm vertraut klingt, sprechen wir miteinander.