Da lunedì 28 aprile, qualsiasi nuova build o aggiornamento inviato ad App Store Connect deve essere compilato con Xcode 26 e l’SDK corrispondente alla piattaforma target: iOS 26, iPadOS 26, tvOS 26, visionOS 26 o watchOS 26. Il requisito è pubblicato da Apple su developer.apple.com da febbraio 2026. Mancano due giorni alla scadenza.
Cosa cambia e cosa no
Il requisito riguarda l’SDK con cui si compila, non il deployment target dichiarato. Un’app compilata con iOS 26 SDK può ancora supportare iOS 17 o 18 come versione minima: gli utenti su versioni precedenti continueranno a scaricarla e usarla normalmente. Le app già pubblicate in store non vengono toccate — nessuna rimozione forzata, nessun aggiornamento obbligatorio. Il limite si applica solo alle nuove submission e agli update: chi non vuole pubblicare nulla non è costretto a fare niente adesso.
Chi distribuisce su watchOS ha un requisito aggiuntivo: Apple richiede la compilazione a 64 bit. Le app watchOS ancora in 32 bit non possono più essere inviate.
Liquid Glass per default
Ricompilare con iOS 26 SDK ha un effetto visivo immediato su qualsiasi app che usa componenti UIKit nativi. Il design system Liquid Glass — introdotto con iOS 26 — viene applicato per default a navigation bar, tab bar, toolbar, fogli modali e altri elementi senza modifiche al codice.
Non esiste un flag di opt-out globale. Chi vuole controllare il comportamento deve usare le API specifiche introdotte da Apple per personalizzare o disabilitare Liquid Glass componente per componente. Per le app con layout costruiti su UIKit standard, vale la pena compilare in locale con Xcode 26 prima di inviare: alcune combinazioni di colori e bordi possono produrre risultati diversi da quelli attesi.
Le app che usano SwiftUI vedranno comportamenti analoghi sui componenti di sistema. Le app con UI completamente custom su Metal o CALayer non sono interessate direttamente.
Infrastruttura di build
Xcode 26 richiede macOS Sequoia 15.6 o versioni successive. Se le macchine di build CI/CD girano su versioni precedenti, l’aggiornamento del sistema operativo viene prima dell’aggiornamento a Xcode 26.
Su GitHub Actions, i runner macos-26 (arm64) e macos-26-xlarge (Apple Silicon, large) sono disponibili in release con Xcode 26 preinstallato da febbraio 2026. I workflow che usano macos-latest andrebbero verificati: la versione a cui punta il selettore automatico può variare, e un cambio inatteso dell’immagine di base ha effetti a cascata sul toolchain usato nelle pipeline.
Bitrise, CircleCI e altri servizi CI hanno pubblicato immagini macOS 26 nelle settimane precedenti. Se si usano immagini pinned a versioni precedenti, la modifica va pianificata prima del 28.
SDK e dipendenze di terze parti
Librerie di analytics, advertising, autenticazione e strumenti di crash reporting devono essere compatibili con Xcode 26 per non generare avvisi o errori a runtime. I principali vendor hanno rilasciato aggiornamenti nelle ultime settimane.
Un modo pratico per verificare: aprire il progetto con Xcode 26 in locale, fare una clean build, e controllare se compaiono errori di linking o deprecation warning inattesi prima di portare la build su App Store Connect. Meglio scoprirli localmente che dopo aver inviato una build e aspettare la validazione.
Screenshot e pagine prodotto
Le screenshot su App Store riflettono l’interfaccia della versione pubblicata. Se la ricompilazione introduce variazioni visive significative — per esempio nei componenti UIKit che adottano Liquid Glass — le immagini in vetrina potrebbero non corrispondere più all’esperienza reale. Apple non blocca le submission per screenshot non aggiornati, ma una discrepanza evidente tra anteprima e app reale può incidere sulle conversioni.
Aggiornare le screenshot non è obbligatorio per inviare, ma è consigliabile farlo in parallelo se le variazioni visive sono sostanziali.
Cosa aspettarsi dopo il 28
La scadenza del 28 aprile è anche il primo punto di pressione reale per chi aveva rimandato la valutazione del design Liquid Glass: da quella data, ogni aggiornamento pubblicato richiede già una scelta su come gestire i componenti nativi. Non è una decisione che può essere posticipata indefinitamente.
Il prossimo elemento da seguire: come si comportano le app nelle review di App Store dopo la transizione, in particolare quelle che contengono SDK di terze parti non ancora aggiornati o che mostrano artefatti visivi nelle screenshot. Apple può richiedere aggiornamenti ai metadati anche senza bloccare la submission, ma la cronologia di review per queste casistiche è ancora da costruire.
