Il @State di SwiftUI è diventato una macro, e Xcode 27 romperà alcune build

WWDC 2026 è alle spalle, le beta di iOS 27 e Xcode 27 sono disponibili, e la maggior parte della copertura è andata a Liquid Glass che ha ottenuto un cursore per la tinta e a Siri che è diventata più intelligente. Questa è la storia per i consumatori. La storia per gli sviluppatori è più netta, e inizia con tre caratteri che si digitano in quasi ogni vista SwiftUI: @State.

A partire da Xcode 27, @State non è più un property wrapper conforme a DynamicProperty. È ora una macro Swift. Apple ha retrodatato il nuovo comportamento a iOS 17, macOS 14, tvOS 17, watchOS 10 e visionOS 1, quindi non è necessario alzare il deployment target per ottenerlo. Compilare lo stesso codice con Xcode 26 e SwiftUI utilizzerà ancora il vecchio property wrapper. Il vantaggio pratico: le classi memorizzate in @State ora si inizializzano in modo lazy, una volta sola per ciclo di vita della vista, invece di essere allocate a ogni re-init della vista.

Questa parte è positiva. Il problema è che un pattern comune smette di compilare. Se si imposta un valore predefinito nella dichiarazione e poi si assegna un valore diverso in init, Xcode 27 blocca con un errore grave:

struct ProfileView: View {
    @State private var name = "Guest"   // valore predefinito qui
    init(user: User) {
        name = user.displayName          // riassegnato qui -> errore in Xcode 27
    }
}

Prima, questo usava silenziosamente il valore sbagliato. Ora è un errore «variable used before being initialized». Banale in una singola vista, ma è esattamente il tipo di cosa che si nasconde in decine di viste in un'app matura.

La matematica delle scadenze gioca a vostro favore

Ecco la parte che i team sbagliano. O si allarmano o ignorano il problema, e nessuno dei due è corretto.

Il requisito minimo di Apple non è cambiato. Dal 28 aprile 2026, App Store Connect richiede solo che si compili con Xcode 26 e l'SDK iOS 26. Non è stata annunciata alcuna scadenza che obblighi a passare all'SDK iOS 27, quindi non c'è fretta di pubblicare con iOS 27.

Ma «nessuna scadenza» non significa «nessun lavoro». L'errore @State è un errore di compilazione, e gli errori di compilazione sono meno costosi da correggere quando li si affronta per tempo, non quando il treno delle versioni di settembre è già in moto. Nei nostri progetti iOS e Android nativi abbiamo imparato più volte la stessa lezione: la migrazione pianificata è tranquilla, quella che arriva sopra un lancio è il caos.

L'azione che si può fare oggi: aggiungere una lane Xcode 27 beta alla CI e lasciarla compilare con il nuovo toolchain adesso. Non è necessario pubblicare ciò che produce. Si vuole solo che la X rossa appaia in una pull request a luglio invece che in un branch di hotfix in autunno. Nel frattempo, cercate nel codebase le dichiarazioni @State che hanno un valore predefinito e vengono riassegnate in un inizializzatore. Quella è la lista delle correzioni, ed è finita.

Le modifiche più silenziose che meritano attenzione

@State fa i titoli, ma alcuni altri aggiornamenti di SwiftUI cambiano il modo in cui costruiremmo le cose.

AsyncImage ora esegue il caching HTTP per impostazione predefinita. Rispetta le intestazioni di cache del server senza modifiche al codice, quindi scorrere una lista due volte smette di riscaricare le stesse immagini. Costruiamo app ricche di immagini nell'e-commerce e nella sanità, e una buona parte dei bug «perché questa lista è lenta» risale a un caricamento immagini ingenuo. Il caching gratuito è benvenuto, con un caveat dal nostro lavoro di infrastruttura e sicurezza: il caching è buono quanto le vostre intestazioni. Se il CDN o il server di origine invia valori Cache-Control deboli, si memorizza nella cache nulla o si memorizza troppo a lungo. Quando configuriamo Cloudflare per i clienti, le intestazioni di cache sono una superficie di configurazione reale che regoliamo deliberatamente, non un ripensamento. La stessa disciplina si applica qui.

C'è anche un nuovo modello di documenti. SwiftUI aggiunge i protocolli WritableDocument e ReadableDocument con accesso asincrono e incrementale al disco, e le scritture ora utilizzano un diffing basato su snapshot in modo che un DocumentWriter salvi solo le parti cambiate. Se si mantiene un'app basata su documenti, questo è un vero strumento di ottimizzazione delle prestazioni per file di grandi dimensioni. I container riordinabili sono l'altro tocco piacevole: gli utenti possono ora trascinare per riordinare gli elementi in qualsiasi container, non solo List, utilizzando lo stesso codice in List e LazyVStack.

Sul lato degli strumenti, Swift 6.3 e 6.4 sono stati rilasciati insieme nella beta di Xcode 27. La modifica che la maggior parte dei team sentirà è l'interoperabilità bidirezionale tra Swift Testing e XCTest. Si possono richiamare asserzioni XCTest da un test Swift Testing e viceversa ora funziona. In modalità limitata predefinita, i problemi cross-framework appaiono come avvisi; aggiornare il pacchetto a swift-tools-version: 6.4 per la modalità completa. Se si è rimandato Swift Testing perché la suite XCTest è grande, quella difficoltà è per lo più scomparsa. Scrivete il prossimo test in Swift Testing e lasciate quelli vecchi dove si trovano.

Cosa diremmo a un team questa settimana

Testate con Xcode 27 adesso, pubblicate con iOS 26 come già fate. Trattate l'errore @State come un'attività pianificata, non un'emergenza. Verificate il caching delle immagini mentre AsyncImage è nella vostra mente, e iniziate a scrivere i nuovi test in Swift Testing. Niente di tutto questo è urgente nel calendario di Apple. Tutto è meno costoso in luglio che in settembre.

Abbiamo spostato molti codebase mobile e web attraverso esattamente questo tipo di salto del toolchain senza emergenze alla vigilia del lancio, e potete vedere il tipo di lavoro che facciamo nei nostri progetti passati.

Se spingere una grande app SwiftUI attraverso le modifiche di build di Xcode 27 prima del rush delle versioni autunnali vi suona familiare, parliamoci.