Nella newsletter Hello Developer di maggio 2026, pubblicata il 12 maggio, Apple ha indicato che macOS 27 sarà l’ultimo rilascio a includere Rosetta. La comunicazione non è in una release note ufficiale né in un documento tecnico separato: il testo compare nella sezione dedicata alla migrazione Apple Silicon della newsletter mensile, con un invito esplicito ad aggiornare le app Mac basate su Intel prima che il supporto termini.
macOS 27 è atteso con l’annuncio al WWDC26 dell'8 giugno e la disponibilità pubblica in autunno 2026. La versione successiva, macOS 28, non includerà Rosetta secondo quanto comunicato da Apple. La timeline ha quindi una finestra di circa un anno: chi inizia la migrazione adesso ha tempo fino alla release di macOS 28 per completarla, ma i cicli di sviluppo, test e distribuzione riducono il margine effettivo.
macOS 27 Rosetta: cosa significa per le app Intel e le dipendenze x86
La notizia riguarda tre categorie di sviluppatori. La prima sono quelli con app macOS mai ricompilate per Apple Silicon: se l’app ha ancora solo un binario x86_64 e nessun binario arm64, smette di funzionare su Mac con Apple Silicon non appena Rosetta viene rimossa. La seconda categoria include app già aggiornate ma con dipendenze che non lo sono: librerie di terze parti, plugin, estensioni, framework closed-source con soli binari Intel. Rosetta smette di funzionare anche per queste componenti. La terza categoria riguarda pipeline CI/CD con agent o tool non migrati: un sistema di build che usa binari Intel per firmare, notarizzare o testare app si blocca allo stesso modo.
Apple indica nella newsletter un’eccezione specifica per “older gaming titles using Intel-based frameworks”: per questi titoli potrebbe esistere una gestione separata, ma la formulazione nella newsletter non fornisce dettagli tecnici. Conviene non affidarsi a questa eccezione senza una conferma più esplicita.
La differenza pratica rispetto agli anni precedenti è che fino ad oggi Rosetta ha attutito la pressione della migrazione. Dal momento in cui macOS 28 arriva sui Mac degli utenti, le app non migrate smettono semplicemente di partire.
Come verificare l’esposizione
Il punto di partenza è sapere quali binari nell’app non sono nativi Apple Silicon. Activity Monitor mostra, nella colonna “Kind”, se un processo sta girando come Apple, Intel o tramite Rosetta. Per un’analisi più precisa sui binari distribuiti si usa lipo -info <percorso_binario>: se l’output riporta solo x86_64, il binario non ha un fat binary con il segmento arm64 e richiede Rosetta per girare.
Per le dipendenze da pacchetti Homebrew il punto di partenza è brew list --formula seguito da file $(brew --prefix)/bin/<nome_tool> per verificare l’architettura di ciascun eseguibile. Molti pacchetti Homebrew hanno già un binario universale o arm64 nativo, ma quelli installati prima della transizione Apple Silicon potrebbero non averlo, specialmente se il tap non viene aggiornato regolarmente.
Instruments, con il template “CPU Profiler” attivato su un Mac Apple Silicon, evidenzia i thread in esecuzione tramite Rosetta. App Store Connect mostra invece se l’app nel catalogo è distribuita come binario universale: nella sezione “App Information” il campo “Supported Architectures” indica arm64 solo se il build caricato include il segmento corretto.
Per le pipeline CI, il punto critico è spesso l’agent di build. GitHub Actions usa runner macOS con Apple Silicon per gli ambienti macos-14 e successivi, ma se i workflow eseguono binari x86_64 custom (script, tool proprietari, sidecar) senza averli verificati, la pipeline può funzionare oggi grazie a Rosetta e rompersi senza avviso evidente dopo la rimozione.
Accessibility Nutrition Labels: cosa richiede l’audit
La stessa newsletter introduce un secondo tema per gli sviluppatori: le Accessibility Nutrition Labels. Sono attualmente volontarie e non hanno ancora una data di obbligo comunicata da Apple. Il concetto è quello di dichiarare esplicitamente, nelle informazioni dell’app su App Store, quali funzioni di accessibilità l’app supporta.
L’audit richiesto copre cinque aree: VoiceOver, Voice Control, Dynamic Type, Dark Mode e Differentiate Without Color. Non si tratta solo di dichiarare il supporto formale, ma di verificare che queste funzioni siano effettivamente utilizzabili nell’app senza comportamenti anomali. Un’app che non blocca VoiceOver ma non lo supporta davvero, per esempio, non supera l’audit nel senso che Apple intende.
La parte operativa richiede tempo: testare VoiceOver su ogni schermata dell’app è un lavoro manuale non banale, soprattutto se l’app non è stata sviluppata con accessibilità come requisito esplicito fin dall’inizio. Chi inizia adesso è avvantaggiato rispetto a chi aspetta che diventi obbligatorio.
Apple non ha comunicato quando le Nutrition Labels diventeranno un requisito di submission. La finestra tra la comunicazione e l’obbligo, se segue lo schema di altri requisiti App Store, è tipicamente di sei-dodici mesi. Ma non è ancora una certezza.
Cosa seguire nel ciclo WWDC26
Il WWDC26 dell’8 giugno è il momento in cui Apple renderà pubblici i dettagli tecnici di macOS 27. Tra le cose concrete da aspettarsi ci sono eventuali strumenti di migrazione aggiornati, note di deprecazione ufficiali per Rosetta nelle release notes di macOS 27 beta, e possibili sessioni dedicate alla migrazione Apple Silicon.
La comunicazione nella newsletter Hello Developer è un segnale importante ma non costituisce ancora una deprecation notice formale con le specifiche di versione e le istruzioni di migrazione complete. Quella documentazione arriverà con le beta del WWDC. Segnarsi la data dell'8 giugno e accedere alle note di rilascio di macOS 27 beta non appena disponibili è il passo più concreto che si può fare adesso.
