Giappone costringe Apple ad aprire iOS: cosa cambia?

Con iOS 26.2 Apple introduce in Giappone il supporto per marketplace alternativi e sistemi di pagamento di terze parti, ma una complessa burocrazia digitale continua a mantenere il controllo sull’ecosistema.

Se c’è una cosa che noi sviluppatori abbiamo imparato negli ultimi quindici anni è che il giardino cintato di Apple — quel famoso walled garden lodato per la sicurezza e criticato per il controllo monopolistico — non si apre mai per gentile concessione.

Si apre solo a colpi di martello legislativo.

E ieri, 17 dicembre 2025, il governo giapponese ha sferrato un colpo decisivo che ha costretto Cupertino a riscrivere le regole fondamentali di iOS, almeno per quanto riguarda il mercato nipponico.

Con il rilascio di iOS 26.2, Apple ha ufficialmente introdotto in Giappone il supporto per marketplace alternativi, sistemi di pagamento di terze parti e, forse l’aspetto tecnicamente più rilevante, la possibilità di utilizzare motori di rendering per i browser diversi da WebKit.

Non è una rivoluzione volontaria, ma una “compliance” forzata.

La Mobile Software Competition Act (MSCA), approvata dalla Dieta giapponese nel giugno 2024, è entrata nella fase operativa e l’architettura monolitica dell’App Store sta mostrando le sue prime, vere crepe strutturali in Asia.

Tuttavia, chi conosce il codice sa che il diavolo si nasconde nei dettagli dell’implementazione. Leggendo la documentazione tecnica rilasciata nelle scorse ore, emerge chiaramente come Apple abbia costruito un sistema di “apertura controllata” estremamente sofisticato.

Non stiamo assistendo a un liberi tutti in stile Android dei primi anni 2000, ma a una complessa burocrazia digitale fatta di API, token di autorizzazione e processi di notarizzazione che permettono ad Apple di mantenere una presa salda sull’ecosistema, anche mentre finge di lasciarlo andare.

L’illusione della libertà e il controllo dei binari

La novità più evidente è la possibilità per gli sviluppatori di distribuire app al di fuori dell’App Store ufficiale. Tecnicamente, questo avviene attraverso nuove entitlement (permessi specifici nel codice dell’app) che abilitano l’installazione da marketplace autorizzati.

Ma qui sta il punto critico: “autorizzati”.

Apple non sta permettendo il sideloading indiscriminato di file .ipa come si farebbe con un .apk su Android.

Ogni singola applicazione, anche se distribuita altrove, deve passare attraverso il processo di “Notarizzazione” di Apple. Si tratta di una scansione automatizzata (e talvolta umana) che verifica la presenza di malware e il rispetto di standard tecnici di base.

Se da un lato questo garantisce che l’iPhone non diventi un ricettacolo di virus, dall’altro mantiene Apple nel ruolo di giudice supremo: è Cupertino a decidere chi può entrare nel sistema, anche se passa dalla porta di servizio.

Questa struttura duale crea un attrito intenzionale.

Apple ha dettagliato come gli sviluppatori potranno distribuire app su marketplace alternativi e gestire i pagamenti fuori dal circuito proprietario a partire da iOS 26.2, ma il processo richiede l’accettazione di nuovi termini commerciali che molti potrebbero trovare indigesti.

Non è solo questione di codice, ma di contratti. Per operare un marketplace alternativo, bisogna dimostrare una solidità finanziaria (spesso attraverso lettere di credito ingenti) che taglia fuori di fatto i piccoli attori indipendenti e l’open source “puro”, favorendo solo grandi entità corporate come Epic Games o Microsoft.

La narrazione ufficiale di Apple rimane focalizzata sui rischi. Non si perde occasione per sottolineare come queste aperture siano un pericolo per l’utente, piuttosto che un’opportunità per il mercato.

Per conformarsi al Mobile Software Competition Act (MSCA), Apple sta introducendo modifiche a iOS che creano nuove opzioni per le app degli sviluppatori in Giappone.

— Apple Developer Team, Portavoce Ufficiali

È una dichiarazione fredda, puramente tecnica, che nasconde una battaglia ideologica. Ma se guardiamo oltre la distribuzione delle app, c’è un cambiamento ancora più profondo che riguarda il cuore di come navighiamo il web.

Il motore sotto il cofano

Per anni, ogni browser su iOS — che fosse Chrome, Firefox o Edge — era costretto a utilizzare WebKit, il motore di rendering di Safari. Di fatto, erano solo “skin” grafiche sopra la stessa tecnologia di Apple.

Questo garantiva uniformità e prestazioni controllate, ma impediva l’innovazione e il supporto a standard web che Apple non riteneva prioritari (o che minacciavano il modello delle app native).

Con l’MSCA, questo vincolo cade. Gli sviluppatori possono ora portare i propri motori: Blink per Chrome, Gecko per Firefox.

Dal punto di vista ingegneristico, è un passo avanti enorme verso la neutralità della piattaforma.

Significa che un bug in WebKit non comprometterà più la sicurezza di tutti i browser sul sistema e che le Progressive Web Apps (PWA) potrebbero finalmente ottenere quelle funzionalità avanzate che Apple ha storicamente rallentato.

Tuttavia, anche qui la libertà ha un prezzo.

Apple ha implementato schermate di scelta (“choice screens”) che obbligano l’utente a selezionare attivamente il proprio browser predefinito e il motore di ricerca, interrompendo il flusso di configurazione iniziale.

Le modifiche a iOS includono nuove schermate per la scelta del browser e dei motori di ricerca predefiniti, oltre a controlli specifici per le app di navigazione, un approccio che ricorda molto il “Browser Ballot” imposto a Microsoft in Europa decenni fa.

L’ironia tecnica è palpabile: Apple ha costruito un sistema operativo capace di gestire motori di rendering diversi in modo sicuro (con sandboxing appropriato), dimostrando che la restrizione precedente era, con ogni probabilità, più una scelta di business che una necessità tecnica imprescindibile.

La complessità non stava nel “se” si potesse fare, ma nel “quanto” sarebbe costato in termini di controllo sull’esperienza web mobile.

Ma se la tecnologia si adatta, l’economia fa resistenza. E qui entriamo nel territorio scivoloso delle commissioni.

Sicurezza o rendita di posizione?

La critica più feroce che si può muovere a questa implementazione riguarda il modello di business sottostante. Anche se un sviluppatore sceglie di non usare l’App Store e di gestire i pagamenti in proprio, Apple richiede comunque una commissione. In Giappone, si parla di cifre ridotte rispetto al passato, ma pur sempre presenti.

Le nuove regole impongono ad Apple di aprire l’hardware dell’iPhone e permettono commissioni ridotte fino al 5% su alcune vendite nei marketplace alternativi, una mossa che tenta di placare i regolatori senza prosciugare il flusso di entrate dei servizi.

Il concetto introdotto da Apple è quello della “Core Technology Fee” (o varianti simili regionali): l’idea che gli sviluppatori debbano pagare non per la distribuzione (che ora fanno da soli), ma per l’uso delle API di iOS e della proprietà intellettuale di Apple.

Dal punto di vista di un tecnico, è un argomento affascinante e controverso. È vero che Apple fornisce il framework (Cocoa Touch, Metal, ecc.), ma è altrettanto vero che il valore di un OS è dato dalle applicazioni che ci girano sopra.

Tassare l’uso delle API suona come se un produttore di sistemi operativi desktop chiedesse una percentuale su ogni software installato tramite CD-ROM o download diretto.

Apple difende questa posizione con le unghie e con i denti, citando la sicurezza come giustificazione primaria per i costi e le restrizioni residue.

Gli sviluppatori possono distribuire app su marketplace alternativi, gestire marketplace alternativi, processare pagamenti per beni e servizi digitali al di fuori degli Acquisti In-App di Apple, utilizzare motori browser web alternativi e altro ancora.

— Apple Developer Support Team, Portavoce Ufficiali

Dietro questo elenco di “possibilità” si nasconde l’avvertimento implicito: fuori dal nostro recinto è pericoloso. Apple ha ribadito che la notarizzazione serve a mitigare rischi di frode e abusi, ma non può garantire lo stesso livello di sicurezza dell’App Store.

È una mezza verità.

Un sistema operativo moderno dovrebbe essere sicuro a livello di kernel e di permessi utente, indipendentemente da dove provenga il codice. Affidarsi alla review centralizzata come unico baluardo di sicurezza è un’ammissione di debolezza architetturale, o più probabilmente, una scusa conveniente.

Ci troviamo di fronte a una frammentazione globale di iOS. Lo stesso iPhone 17, con lo stesso chip A19, si comporta in modo radicalmente diverso se attivato a Tokyo, a Parigi o a New York.

Per noi sviluppatori, questo significa gestire build condizionali e logiche di business duplicate. Il sogno di “scrivi una volta, esegui ovunque” si sta infrangendo non per limiti tecnici, ma per confini giurisdizionali.

La domanda che rimane sospesa non è se queste modifiche funzioneranno — il codice compila, le API rispondono — ma se riusciranno davvero a creare un mercato competitivo.

Se l’alternativa è tecnicamente possibile ma economicamente insostenibile a causa di fee e burocrazia, Apple avrà rispettato la legge violandone lo spirito.

E mentre guardiamo il Giappone fare da apripista, il resto del mondo prende appunti: la tecnologia per abbattere i muri esiste, manca solo la volontà politica di usarla fino in fondo.