@State din SwiftUI a devenit un macro, iar Xcode 27 va strica unele build-uri

WWDC 2026 a trecut, betele pentru iOS 27 și Xcode 27 sunt disponibile, iar cea mai mare parte a atenției s-a concentrat pe Liquid Glass care a primit un slider de nuanță și pe Siri care a devenit mai inteligentă. Aceasta este povestea pentru utilizatori. Povestea pentru dezvoltatori este mai precisă și începe cu trei caractere pe care le tastezi în aproape orice view SwiftUI: @State.

Începând cu Xcode 27, @State nu mai este un property wrapper care implementează DynamicProperty. Acum este un macro Swift. Apple a adus comportamentul nou înapoi până la iOS 17, macOS 14, tvOS 17, watchOS 10 și visionOS 1, deci nu trebuie să mărești ținta de deployment pentru a-l obține. Compilează același cod cu Xcode 26 și SwiftUI folosește în continuare vechiul property wrapper. Câștigul practic: clasele stocate în @State se inițializează acum leneș, o singură dată pe durata de viață a view-ului, în loc să fie alocate la fiecare reinițializare a view-ului.

Această parte este bună. Problema este că un tipar comun nu mai compilează. Dacă setezi o valoare implicită în declarație și apoi atribui o altă valoare în init, Xcode 27 te blochează cu o eroare dură:

struct ProfileView: View {
    @State private var name = "Guest"   // default here
    init(user: User) {
        name = user.displayName          // reassigned here -> error in Xcode 27
    }
}

Înainte, aceasta folosea în liniște valoarea greșită. Acum este o eroare „variabilă folosită înainte de inițializare”. Banală într-un singur view, dar este exact genul de lucru care se ascunde în zeci de view-uri dintr-o aplicație matură.

Calculul termenelor lucrează de fapt în favoarea ta

Iată partea pe care echipele o înțeleg greșit. Fie intră în panică, fie ignoră problema, și niciuna dintre variante nu este corectă.

Minimul de submission al Apple nu s-a schimbat. Din 28 aprilie 2026, App Store Connect cere doar să compilezi cu Xcode 26 și iOS 26 SDK. Nu există niciun termen anunțat care să te forțeze să treci la iOS 27 SDK, deci nu ești în grabă să livrezi pe iOS 27.

Dar „fără termen” nu înseamnă „fără muncă”. Eroarea @State este o eroare de compilare, iar erorile de compilare sunt cel mai ieftin de reparat când le cauți tu, nu când trenul de lansare din septembrie este deja în mișcare. În proiectele noastre native iOS și Android am reînvățat aceeași lecție de mai multe ori: migrarea pe care o planifici este calmă, migrarea care se suprapune cu o lansare este haos.

Mișcarea pe care o poți face astăzi: adaugă un lane beta Xcode 27 în CI-ul tău și lasă-l să compileze cu noul toolchain acum. Nu trebuie să livrezi ce produce. Vrei doar ca X-ul roșu să apară într-un pull request în iulie, nu pe o ramură de hotfix în toamnă. Cât ești la asta, caută prin codul sursă declarații @State care au o valoare implicită și sunt reatribuite într-un inițializator. Aceasta este lista ta de reparații și este finită.

Schimbările mai puțin zgomotoase care merită atenția ta

@State are titlul, dar câteva alte actualizări SwiftUI schimbă modul în care am construi lucrurile.

AsyncImage face acum caching HTTP implicit. Respectă header-ele de cache ale serverului fără modificări de cod, deci derularea unei liste de două ori nu mai re-descarcă aceleași imagini. Construim aplicații cu multe imagini în e-commerce și sănătate, și o bună parte din bug-urile „de ce această listă este sacadată” se datorează încărcării naive a imaginilor. Caching-ul gratuit este binevenit, cu o observație din munca noastră de infrastructură și securitate: caching-ul este la fel de bun ca header-ele tale. Dacă CDN-ul sau originea ta trimite valori slabe Cache-Control, ori nu caching nimic, ori caching prea mult. Când configurăm Cloudflare pentru clienți, header-ele de cache sunt o suprafață reală de configurare pe care o ajustăm deliberat, nu o idee de ultimul moment. Aceeași disciplină se aplică și aici.

Există și un nou model de documente. SwiftUI adaugă protocoalele WritableDocument și ReadableDocument cu acces asincron și incremental la disc, iar scrierile folosesc acum diferențiere bazată pe snapshot, astfel încât un DocumentWriter salvează doar părțile care s-au schimbat. Dacă menții o aplicație bazată pe documente, acesta este un element real de performanță pentru fișiere mari. Containerele reordonabile sunt alt plus plăcut: utilizatorii pot acum trage pentru a rearanja elemente în orice container, nu doar List, folosind același cod pentru List și LazyVStack.

Pe partea de tooling, Swift 6.3 și 6.4 au fost livrate împreună în beta-ul Xcode 27. Schimbarea pe care cele mai multe echipe o vor simți este interoperabilitatea bidirecțională între Swift Testing și XCTest. Poți apela aserțiunile XCTest dintr-un test Swift Testing și inversul funcționează acum și el. În modul limitat implicit, problemele cross-framework apar ca avertismente; actualizează pachetul la swift-tools-version: 6.4 pentru modul complet. Dacă ai amânat Swift Testing pentru că suite-ul tău XCTest este mare, acea fricțiune a dispărut în mare parte. Scrie următorul test în Swift Testing și lasă-le pe cele vechi unde sunt.

Ce am spune unei echipe această săptămână

Testează cu Xcode 27 acum, livrează cu iOS 26 cum faci deja. Tratează eroarea @State ca pe o sarcină planificată, nu o urgență. Auditează caching-ul imaginilor cât timp AsyncImage este în mintea ta și începe să scrii teste noi în Swift Testing. Nimic din asta nu este urgent în calendarul Apple. Totul este mai ieftin în iulie decât în septembrie.

Am trecut multe baze de cod mobile și web prin exact acest tip de salt de toolchain fără exerciții de alarmă în săptămâna lansării, și poți vedea genul de muncă pe care o facem în proiectele noastre anterioare.

Dacă ideea de a trece o aplicație SwiftUI mare prin schimbările de build Xcode 27 înainte de aglomerarea lansărilor de toamnă îți sună familiar, hai să vorbim.