Nota: quella che segue è una versione aggiornata del post originale, risalente al 29 gennaio 2024 e col DMA non ancora in pieno vigore. A seguito della sua operatività effettività e delle modifiche effettuate da Apple nel frattempo per conformarsi ulteriormente (a suo modo), il post è stato rivisto il 2 aprile 2024 (con alcune nuove integrazioni il 6). Potrebbero seguire ulteriori revisioni sulla base dei futuri sviluppi.

Se n’era parlato prima, se ne parla anche dopo la data chiave del 7 marzo e sicuramente se ne parlerà ancora per tanto tempo. Quello citato è il giorno da cui Apple ha dovuto conformarsi ufficialmente al Digital Markets Act dell’Unione Europea – un conto alla rovescia iniziato a settembre 2023, quando il gigante di Cupertino è rientrato nel novero dei gatekeeper, ovvero quelle aziende tech che per determinati motivi Bruxelles ritiene abbiano un’eccessiva influenza in uno o più ambiti di mercato (il “club” comprende anche Alphabet/Google, Amazon, ByteDance/TikTok, Meta, Microsoft). Nello specifico, ad Apple è stata imposta l’attuazione di modifiche tecniche e commerciali con un impatto su iOS, Safari e App Store; non toccati iMessage e iPadOS, il cui fato nell’ambito del DMA è stato oggetto di un’indagine supplementare che non ha ravvisato la necessità di correttivi.

A gennaio la mela ha reso note le prime modifiche ritenute da essa adeguate per soddisfare il DMA, che hanno raggiunto l’utenza iPhone nell’Unione Europea con iOS 17.4 a ridosso della giornata fatidica. Vi erano, però, tanti aspetti su cui il comunicato stampa non si dilungava e che hanno richiesto un approfondimento, spulciando nella documentazione di supporto destinata agli sviluppatori. A complicare il tutto, ci sono già state delle correzioni di rotta, modificando determinati aspetti sulla base dei primi riscontri ricevuti, tanto dagli sviluppatori quanto dietro le quinte dalle autorità europee. Inoltre, alcune novità non sono esclusiva dei 27 Paesi UE né del solo iOS. Anche grazie ad un recente PDF ufficiale pubblicato da Apple, proviamo qui a fare maggiore chiarezza trattando vari argomenti in ordine alfabetico.

Prima di procedere, poiché abbiamo citato la presenza di alcune modifiche con più ampio raggio sia geografico sia di piattaforma, è bene fare alcune precisazioni.

Innanzitutto, sul Digital Markets Act stesso. Concepito nell’arco di due anni, tra il 2020 ed il 2022, esso è stato voluto al fine di verificare potenziali situazioni lesive della libera competizione e prevenirne il prosieguo. L’iter di finalizzazione ha previsto i seguenti step:

• ottobre 2022: promulgazione nella gazzetta ufficiale dell’Unione Europea
• novembre 2022: entrata in vigore a livello legale ma non ancora efficace sul campo
• maggio 2023: entrata in vigore completa
• luglio 2023: identificazione dei potenziali gatekeeper

La qualifica di gatekeeper considera tre dati fondamentali: i ricavi nel territorio europeo (pari o superiori a 7,5 miliardi di Euro negli ultimi tre esercizi finanziari), il numero complessivo di utenti attivi (almeno 45 milioni finali e 10.000 commerciali) e la sussistenza di una situazione consolidata nel tempo. A luglio 2023, le aziende rientranti in questi tre casi hanno inviato notifica alle autorità europee, che hanno effettuato ulteriori analisi prima di ufficializzare a settembre la lista definitiva e i prodotti coinvolti, su cui apportare rimedi nei successivi 6 mesi.

L’elenco dei gatekeeper è destinato a mutare periodicamente con nuovi ingressi e pure notifiche aggiuntive provenienti da aziende già coinvolte in precedenti tornate. Prova ne è il round di marzo, che ha visto le dichiarazioni di Booking ed X, non toccate nel 2023, ma anche aggiunte da ByteDance. La lista è aperta anche in uscita, qualora le cambiate condizioni di mercato rendessero un gatekeeper non più tale oppure l’UE non trovasse motivi per confermare necessità d’intervento a seguito dei suoi supplementi d’indagine. È ad esempio il caso di Samsung, che a luglio 2023 si era notificata come potenziale gatekeeper ma è stata scagionata due mesi dopo.

Il DMA ha vigenza nella sola Unione Europea; tuttavia, l’apertura del chip NFC ha effetto all’interno di tutto lo Spazio Economico Europeo o EEA. Si tratta di un accordo commerciale che oltre agli stati dell’UE comprende pure Islanda, Liechtenstein e Norvegia.

Al di sopra di UE ed EEA esiste un’ulteriore organizzazione: l’Associazione Europea di Libero Scambio o EFTA (in cui è presente anche la Svizzera). Il Paese elvetico non è però soggetto ad alcuna variazione, se non quelle applicate a livello globale, ovvero la disponibilità dei servizi di cloud gaming.

Allo stesso modo, il Regno Unito, che ha lasciato l’Unione Europea il 31 gennaio 2020 e non rientra né nell’EEA né nell’EFTA, resta escluso da tutte le modifiche introdotte, al di fuori di quelle con valenza mondiale. È comunque probabile che molti aspetti raggiungeranno il suolo britannico nel prossimo futuro, essendo in preparazione il Digital Markets Bill dotato di uno scopo in gran parte similare al DMA.

In termini di piattaforme supportate, per quelle poche modifiche contrassegnate con la disponibilità su tutte, intendiamo iOS, iPadOS, macOS, tvOS e watchOS. Per i dispositivi non supportati da iOS 17, nulla è cambiato, Apple non ha previsto di fare il backporting delle modifiche né l’UE sembra richiederlo – su iOS 16 e precedenti l’App Store nativo resterà l’unico a disposizione per installare le app, così come i browser continueranno ad appoggiarsi esclusivamente al motore WebKit.

A come App Store

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Iniziamo proprio dal punto più importante delle novità di iOS legate al DMA: l’App Store. Da marzo, il negozio digitale Apple ha perso la sua esclusiva sugli iPhone, con la possibilità di installare applicazioni anche da marketplace concorrenti, in maniera analoga a quanto si può fare su Android. Ci sono altre modifiche legate direttamente all’App Store nativo, ma verranno approfondite nei punti successivi, dove necessario. Qui ci preme fornire una panoramica sulla questione degli store terzi. Come funzionano nello specifico?

Gli sviluppatori di store alternativi per l’Unione Europea hanno a disposizione il MarketplaceKit, un framework dedicato allo scopo, insieme ad un set di API (interfacce di programmazione). Con questi strumenti possono creare l’app-negozio, sfruttare strumenti di distribuzione delle app simili a quelli disponibili per lo Store nativo, integrarsi con le funzionalità di iOS e creare banner per facilitare dal web l’installazione di app.

È bene tuttavia chiarire che questo non comporta la possibilità per chiunque di realizzarsi il proprio app store. Apple ha posto una nutrita serie di condizioni:

• essere registrati al Developer Program e avere sede legale nel territorio UE (se la casa madre risiede al di fuori, può ovviare operando tramite una filiale locale)
• realizzare un prodotto il cui scopo primario è la distribuzione di applicazioni (inizialmente Apple aveva posto la condizione aggiuntiva che lo store avrebbe dovuto ospitare anche app di altri sviluppatori – per fare un esempio pratico, un ipotetico Google Play Store per iOS sarebbe stato accettabile, mentre uno Spotify Store che preveda solo le app del servizio musicale no –, ma questa parte è stata stralciata semplificando così la regola)
• rendere pubbliche le condizioni commerciali e d’uso dello store, così come quelle del trattamento dei dati personali, seguendo anche le altre normative europee in merito, a partire da DSA (Digital Services Act) e GDPR (General Data Protection Regulation)
• acconsentire ad effettuare il controllo delle app caricate di modo da accertarsi che non effettuino e/o portino ad effettuare illeciti, includano elementi malevoli e/o violino proprietà intellettuali, reagendo prontamente alle richieste di chiarimenti o modifiche provenienti da Apple tenendosi pronti a ritirare i software non conformi (anche dietro richieste governative)
• adempiere ad una delle due seguenti opzioni: fornire annualmente una lettera di credito “stand-by” da almeno 1 milione di Euro proveniente un’istituzione finanziaria di classe A (oppure dalle agenzie di rating Fitch, Moody’s e S&P) per garantire di avere fondi sufficienti all’operatività; essere membri del Developer Program da almeno due anni, in buona condotta e con un’app che contava più di un milione di installazioni nell’UE durante l’anno precedente

Una volta ricevute le necessarie autorizzazioni tecniche ed aver iniziato l’attività, sopra il milione di installazioni dello store sarà da corrispondere anche la commissione Core Technology Fee, di cui parleremo nel dettaglio più avanti. Ci sono comunque alcune eccezioni, costituite da enti no profit, educativi e/o governativi: in tal caso, però, anche le app distribuite nello store dovranno rientrare nelle medesime categorie.

Comprensibilmente, chi creerà questi negozi digitali non avrà alcun supporto da Apple in merito ad assistenza clienti e rimborsi, così come per eventuali grane legali. In tutte queste situazioni il gestore sarà il solo responsabile. Anche a livello tecnico e commerciale, tutta l’infrastruttura (server, accordi, pagamenti con servizi non Apple, ecc.) dietro le quinte dovrà essere gestita per conto proprio. Apple si limiterà alla fornitura dei succitati kit di sviluppo, nonché all’autenticazione di base delle applicazioni, punto che verrà approfondito più avanti. Dal canto suo, in questi casi la mela non potrà più opporsi a priori a categorie di app sinora precluse nel suo Store, come quelle a luci rosse. A tal proposito, pensiamo sia sottinteso, ma ai fini della completezza lo confermiamo: per le app distribuite nello Store di sistema, il regolamento riguardante le tipologie consentite (cui sono però state apportate delle aggiunte, prossimamente trattate) resta quello di sempre.

Vista la questione dal punto di vista dello sviluppatore, passiamo a dettagliare l’esperienza lato utente. Come prevedibile, Apple non distribuirà direttamente gli store alternativi sul suo né reputa di avere obblighi a riguardo (che in effetti il DMA non prevede). L’utente che vuole installare uno store alternativo dovrà andare sul sito dello sviluppatore e scaricarlo da lì. Sopra è visibile la schermata che verrà presentata, comprensiva di informazioni e screenshot. Una volta installato, basterà abilitarlo nelle Impostazioni di iOS, renderlo predefinito se lo si vorrà e poi procedere all’uso. Lo store terzo godrà di quasi tutte le integrazioni di sistema (Spotlight, backup, ecc.), fatta eccezione per quelle strettamente legate all’App Store come Condivisione In Famiglia o la limitazione degli acquisti tramite Tempo Di Utilizzo (a tale proposito ce n’è una più generale, che approfondiremo a breve). Anche qui, sarà il gestore a dover prevedere funzionalità equivalenti. Le prime prove del processo di installazione riportano una situazione non complicata, ma articolata su diversi passaggi, il cui obiettivo finale sembra essere di scoraggiare l’utente a proseguire o quantomeno renderlo ben cosciente degli eventuali rischi. Molto probabili modifiche future, avendo l’UE già esposto serie perplessità in merito.

Ma cosa succede nel caso in cui un’app sia già stata installata tramite lo Store di Apple? L’utente dovrà prima disinstallarla, poi procedere alla sua reinstallazione dal nuovo store. Facendo un esempio pratico, supponendo che Meta smetta di distribuire Facebook dall’App Store nativo, per ricevere i futuri aggiornamenti si dovrà rimuovere l’app e rimetterla ex-novo dall’ipotetico Meta Store. Lo stesso vale al contrario, se si installa un’app dallo store terzo e poi si vuole proseguire con quella disponibile sull’App Store tradizionale sarà necessario fare quanto appena descritto. E non vale solo per passare da o verso lo Store di Apple – uguale limitazione sussiste se si passa tra un marketplace terzo e l’altro, le app vanno installate di nuovo. La motivazione è puramente tecnica: non si può garantire che la sovrascrittura migri correttamente i dati salvati dall’utente nell’app. Una preoccupazione più che comprensibile ed accettabile.

Anticipiamo la risposta ad un’altra domanda: si potranno avere più store installati contemporaneamente sul dispositivo. Se ne potrà impostare solo uno di default, ma nulla vieterà di approvvigionarsi delle app da diverse fonti. Gli altri negozi potranno essere abilitati dalle Impostazioni allo stesso modo dell’App Store e/o del primo alternativo installato. Queste abilitazioni saranno revocabili in qualsiasi momento. Le app installate dagli store disabilitati, rimossi o non più operativi, resteranno installate ma non riceveranno più ulteriori aggiornamenti, il che può comportare rischi futuri di malfunzionamento (se non una cessazione totale). Per tornare ad ottenere le nuove versioni si dovrà togliere l’app e rimetterla da un altro store, come detto sopra; ovviamente questo può comportare pure la necessità di riacquistarla.

Un’altra questione meritevole di approfondimento è quella relativa ai contesti lavorativi, dove gli amministratori IT fanno spesso uso di soluzioni MDM (Mobile Device Management) per gestire la flotta di iPhone aziendali e non solo, regolando anche l’installazione così come la distribuzione delle app. Secondo quanto era stato rinvenuto da 9to5Mac, di fatto il supporto agli app store terzi si appoggia in buona parte alle medesime modalità. Ed effettivamente, tra le restrizioni applicabili attraverso MDM, vi è “allowMarketplaceAppInstallation” che se impostata su “false” (di partenza è “true”) blocca l’installazione di store alternativi. Qualora invece i reparti IT volessero avvalersene, resta attualmente poco chiaro se le soluzioni MDM abbiano a disposizione un’interfaccia con essi per installare specifiche app così come possono già fare ora con l’App Store.

Non sono solo gli IT a poter applicare restrizioni – chiunque è in grado di farlo. La via più semplice è offerta dall’iPhone stesso, entrando in Impostazioni e poi nella sezione Tempo di utilizzo. Una volta attivata questa funzionalità di iOS se non lo si è già fatto, scorrendo al suo interno si troverà la sottosezione Restrizioni contenuti e privacy. Abilitandole, in Installazioni di app e acquisti sarà disponibile l’opzione per negare l’installazione di negozi terzi senza intaccare lo Store nativo (che può essere parimenti disabilitato, qualora si desiderasse essere così tanto drastici). Quanto detto può tornare soprattutto utile ai genitori per evitare che i propri pargoli installino contenuti inappropriati per la loro età. In questi casi la stessa sottosezione delle restrizioni offre anche un’opzione meno estrema, che lascia la possibilità di installare store alternativi ma non app prive di classificazione per età e/o classificate per età superiori a quella di chi sta utilizzando l’iPhone.

In conclusione di questo capitolo, diamo uno sguardo agli store alternativi in arrivo. Il primo pubblico dovrebbe essere quello di Setapp, curato da MacPaw e già noto agli utenti Mac per il comodo abbonamento comprendente numerosi software celebri (tra cui quelli dell’azienda stessa, come CleanMyMac). Proprio di recente è stata diramata la lista delle 31 app con cui il negozio debutterà nel corso della primavera. A livello aziendale, invece, si è già lanciata la tedesca mobivention. Tra gli altri arrivi già annunciati vi sono AltStore, da tempo già operativo attraverso particolari modalità, presto non più necessarie in UE, e naturalmente il tanto atteso Games Store di Epic, sempre che si calmino i battibecchi con Apple.

B come Browser

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Un’altra importante modifica imposta dal DMA concerne i browser alternativi e riguarda tutti i canali di distribuzione, incluso quindi l’App Store di Apple. Sino al 7 marzo, le condizioni poste su iOS e iPadOS in merito erano piuttosto stringenti: qualsiasi browser pubblicato sullo Store doveva necessariamente utilizzare il motore di rendering WebKit, lo stesso di Safari e di tutto il sistema. Un netto contrasto con quanto avviene su altre piattaforme, incluso macOS, dove Chrome ed Edge usano il loro Blink mentre Firefox sfoggia Gecko, per fare gli esempi più famosi. Da ora in poi, nella sola Unione Europea, questo limite decade pure su iPhone, dando libertà agli sviluppatori di adottare un motore diverso da WebKit. Lo stesso vale per i cosiddetti browser in-app, ad esempio quelli implementati nei social come X o Threads per aprire al loro interno il link a siti esterni.

Analogamente al caso degli App Store, anche qui Apple ha previsto dei framework specifici, BrowserEngineKit e Browser Engine Core. A seconda della tipologia, ci sono delle condizioni da rispettare per ottenere le necessarie qualifiche da Apple. I requisiti per i browser che vogliono intraprendere su iOS l’uso di motori alternativi sono numerosi:

• se il browser è disponibile anche in una versione che adopera WebKit, quella con motore diverso dovrà essere mantenuta in modo separato
• si dovrà disporre in primis delle qualifiche necessarie per essere impostato come browser di default nelle Impostazioni (ciò comporta l’osservanza di ulteriori requisiti tecnici e, da febbraio, la compilazione di un form soggetto a verifica da parte di Apple)
• si dovrà aderire agli standard web di base, passando i test dedicati con determinati punteggi minimi
• si dovrà sviluppare il browser tenendo in alta considerazione la sicurezza nello sviluppo, impegnandosi a correggere tempestivamente le eventuali vulnerabilità, documentandole in forma pubblica, adottando tutte le più recenti tecniche di mitigazione contro gli exploit ed evitando l’uso di librerie di sviluppo con falle e/o non più sviluppate attivamente
• si dovrà proteggere la privacy dell’utente con vari accorgimenti, tra cui il blocco predefinito dei cookie di tipo cross-site e altro ancora

Per i browser in-app, con un raggio d’azione più ristretto, i requisiti sono molto simili, fatte salve alcune eccezioni: non possono richiedere le qualifiche per diventare browser predefinito e, poiché contengono porzioni di codice sviluppate in modo diverso tra loro, dovranno accertarsi che tanto l’app quanto il motore non presentino vulnerabilità. E se quest’ultimo viene aggiornato, gli sviluppatori che ne fanno uso nelle loro app dovranno implementare la nuova versione entro 15 giorni. Per quel che concerne l’esperienza utente, le linee guida base rimangono simili a quelle già in vigore: l’interfaccia dovrà dare quanto più spazio possibile al contenuto, fatta eccezione per gli elementi essenziali, come l’indicazione dell’indirizzo web aperto, un pulsante per proseguire la navigazione in un browser vero e proprio e un altro per uscire dalla modalità di navigazione.

Insomma, una situazione alquanto articolata, che comporta benefici ma pure rischi. Per gli sviluppatori si tratta di un lavoro enorme da fare, anche per i grossi nomi. Consideriamo i requisiti da rispettare per i browser: se da un lato è vero che in larga parte qualsiasi motore di rendering moderno riuscirà a soddisfarli facilmente, dall’altro costringerà a tenere sviluppate due versioni: una esclusiva per l’Unione Europea, col motore di propria scelta; l’altra per il resto del mondo (e iPadOS) che continuerà ad usare WebKit. Una questione giustamente sollevata da Mozilla, che però attacca il bersaglio sbagliato. Apple ha effettuato le modifiche solo dove le sono state richieste in modo esplicito, cioè nell’Unione Europea, e per quanto sarebbe stato auspicabile avesse aperto ai motori alternativi su scala globale ad oggi non è tenuta a farlo. Il vero problema è l’assenza di un qualsiasi concerto tra gli enti regolamentatori globali, che porta ognuno ad intraprendere diverse vie. È verosimile che in futuro ci sarà un’armonizzazione, visto che iniziative di portata simile al DMA sono in sviluppo al di fuori dell’UE, ma la situazione attuale è quella descritta.

Un altro aspetto controverso, su cui invece Apple potrebbe avere qualche responsabilità in più a cui rispondere, è la sussistenza di alcuni limiti per i browser non-WebKit: principalmente, l’impossibilità di aggiungere i siti web alle schermate home degli iPhone. A detta di Apple, implementare un tale livello d’integrazione in iOS comporterebbe la necessità di modifiche troppo estese, con l’aggiunta di rischi per la privacy e la sicurezza degli utenti. Questa discutibile restrizione comporta anche il rischio di vedere le web app intraprendere strade sinora non percorse per mantenere la loro massima disponibilità col minimo sforzo, venendo distribuite sugli store di terze parti attraverso framework-contenitori come Electron, noti per non fare un uso proprio ottimale delle risorse del dispositivo su cui girano, tant’è vero che la loro crescente adozione viene additata tra le responsabili del fenomeno della “app enshittification”, toni forti anglosassoni per indicare il calo di qualità percepito in molte applicazioni recenti.

Per dovere di cronaca, citiamo anche il curioso tentativo poi annullato di applicare parte di questa restrizione allo stesso Safari. Non essendo sicuri che i succitati limiti fossero ben accolti dall’UE, in una Beta di iOS 17.4 Apple aveva optato per ridurre il supporto alle web app previsto nel browser di sistema. Si sarebbero potute comunque aggiungere alle schermate home, ma la loro apertura avrebbe comportato il coinvolgimento della versione completa di Safari con tutti gli elementi della sua interfaccia – in sostanza, le web app avrebbero perso la loro caratteristica principale, ovvero la possibilità di comportarsi anche a livello di esperienza utente come app vere e proprie. Le proteste degli utenti, insieme a qualche azione diplomatica sotto traccia da Bruxelles, hanno convinto Apple a tornare sui suoi passi nella Beta successiva.

Le responsabilità ricadono invece sull’Unione Europea per la parte successiva di questa sezione. Tra i requisiti del DMA, Apple deve dare agli utenti una modalità più rapida di cambiare il browser predefinito. Alla prima apertura di Safari in iOS 17.4, agli italiani sono state presentate le seguenti 12 opzioni:

• Aloha
• Brave
• Chrome
• DuckDuckGo
• Ecosia
• Edge
• Firefox
• Ivanti Web@Work
• Onion Browser
• Opera
• Safari
• You.com AI Search Assistant

La visualizzazione avviene in forma casuale e, benché alcuni nomi siano sconosciuti alla stragrande maggioranza, la lista è stata redatta sulla base del loro uso in Italia (gli altri Paesi presentano liste lievemente diverse, ad esempio in Spagna è presente Vivaldi invece di Web@Work). Agli utenti di più lunga data, specialmente se lo sono stati su Windows alcuni anni fa, questa iniziativa ricorderà qualcosa. La schermata di scelta del browser venne in primis implementata da Microsoft per ottemperare alle decisioni stabilite dall’antitrust europeo, volte allora a ridurre la quota di mercato detenuta da Internet Explorer. Anche in quel caso l’elenco comprendeva un mix tra nomi noti ed altri molto meno e il risultato ottenuto non fu proprio quello sperato: il dominio di IE è stato infatti sostituito da quello di Chrome, situazione che viviamo tuttora.

Google, anch’essa soggetta al DMA, ha dovuto implementare lo stesso meccanismo nel suo browser, il che tecnicamente metterebbe Chrome sullo stesso terreno degli altri, ma è lecito temere che in quel di Mountain View possano sfruttare proprio le modifiche su iOS per cementare ancora più la posizione dominante e si può solo sperare che negli uffici europei stiano già tenendo conto del rischio con annessi rimedi possibili. Detto questo, un segnale positivo in tal senso sembra arrivare dagli sviluppatori di Brave, che su X hanno mostrato il picco di installazioni del loro browser a seguito dell’arrivo di iOS 17.4.

Segnaliamo in conclusione di questo capitolo le modifiche previste per l’arrivo in una fase successiva. Entro il 2024 Apple ha promesso di permettere agli utenti UE di disinstallare Safari da iOS, alla stessa maniera di quanto già fattibile per molte delle app preinstallate; si potrà rimettere in qualsiasi momento attraverso l’App Store. Simile tempistica, seppur non viene esclusa una dilazione agli inizi del 2025, per l’implementazione di un metodo di scambio dati e preferenze utente tra i browser installati su iPhone. Ciò comporterà lavoro non solo per Apple ma anche per la concorrenza, così come una imprescindibile forma di cooperazione in tutta la filiera per oliare a dovere il sistema.

C come Commissioni

• In quali territori si applica: UE
• A quali piattaforme si applica: tutte

Passiamo al prossimo punto, anch’esso oggetto di complessità e controversie. Da marzo, gli sviluppatori hanno la possibilità di scegliere nell’Unione Europea due set di condizioni commerciali per la distribuzione delle loro app. Il primo set di condizioni è quello già implementato, ossia:

• continueranno a distribuire le applicazioni solo sull’App Store ed utilizzare il suo servizio di pagamento per tutte le transazioni
• per le app a pagamento e/o gli acquisti in-app, continueranno a versare ad Apple la commissione del 30%, che viene ridotta al 15% se gli sviluppatori rientrano nell’ambito del programma Small Business o se i contenuti vengono forniti su abbonamento e l’utente rinnova dopo il primo anno

Il secondo e nuovo set di condizioni commerciali disponibile prevede che:

• gli sviluppatori potranno distribuire le loro app iOS su qualsiasi store
• su tutte le piattaforme, potranno utilizzare circuiti di pagamento alternativi, in affiancamento (sia nell’app sia rimandando al proprio sito) o in sostituzione di quello fornito da Apple
• per le app iOS a pagamento e/o gli acquisti in-app, chi resterà sull’App Store (in esclusiva o no) verserà una commissione ridotta del 17%, che scende ulteriormente al 10% se gli sviluppatori rientrano nell’ambito del programma Small Business o se i contenuti vengono forniti su abbonamento e l’utente rinnova dopo il primo anno
• sulle altre piattaforme, tali percentuali rimarranno più simili alle precedenti, rispettivamente 27% e 12%
• le percentuali succitate non sono comprensive delle transazioni effettuate sul servizio di pagamento dell’App Store – se adoperato, ciascuna operazione sarà soggetta ad una commissione aggiuntiva del 3%, il che significa su iOS percentuali totali del 20% e del 15% a seconda della situazione, mentre torneranno ai soliti 30% e 15% sulle altre
• solo su iOS, si dovrà corrispondere una commissione aggiuntiva denominata Core Technology Fee, che prevederà 50 centesimi aggiuntivi per ogni prima installazione di un’app (inclusi gli store alternativi stessi) oltre il milione annuo

Lo sviluppatore deve prestare attenzione in sede decisionale: si potrà passare in qualsiasi momento dai vecchi ai nuovi termini, ma il contrario lo si potrà fare solo una volta. In caso di ulteriore ripensamento, il passaggio alle condizioni DMA diventerà irreversibile. Entreremo più nei dettagli dei metodi di pagamento successivamente: ora ci concentreremo sull’approfondire la commissione aggiuntiva.

A detta di Apple, la Core Technology Fee è stata strutturata per riguardare un numero limitato di sviluppatori e, come già osservato parlando degli app store alternativi (i cui sviluppatori, va precisato, non avranno il primo milione di installazioni gratis come gli altri – pagheranno da subito la commissione), non sarà dovuta da organizzazioni no profit, educative e governative. Cerchiamo di capire meglio la logica di funzionamento. Come abbiamo scritto sopra, la CTF non scatta subito ma al superamento del milione annuo di installazioni. Il conteggio viene effettuato sulla base dei seguenti aspetti:

• coinvolge la prima installazione annua di un app iOS fatta da un singolo ID Apple nell’Unione Europea; qualsiasi successiva reinstallazione effettuata dallo stesso profilo nei 12 mesi successivi non concorre nella quota (l’esenzione è senza limiti temporali nel caso di trasferimento dell’app da un iPhone ad un altro)
• vale a prescindere dalla provenienza, il che significa non solo dagli app store ma pure altri metodi distributivi, come TestFlight o gli acquisti a volume con gli strumenti aziendali ed educativi
• coinvolge in eguale misura sia le app gratuite (anche quelle open source, se non sono provenienti da no profit) sia quelle a pagamento
• superato il milione di prime installazioni univoche, per ognuna delle successive lo sviluppatore corrisponderà ad Apple 50 centesimi (per evitare fenomeni di “install bombing”, che possano aumentare in modo artificiale il numero di installazioni danneggiando economicamente l’autore dell’app, sono previsti meccanismi di verifica)

Facciamo degli esempi pratici con alcuni utenti totalmente non a caso:

Maurizio

• Marzo 2024: Maurizio installa un’app, il cui sviluppatore ha aderito alle nuove condizioni commerciali e dunque alla CTF; il suo ID viene conteggiato come il numero 1 ad aver installato l’app
• Maggio: Maurizio rimuove per errore l’app, se ne accorge e la rimette; le reinstallazioni successive alla prima non rientrano nel computo per i successivi 12 mesi
• Novembre: la rimuove di nuovo, perché non ne ha più necessità
• Aprile 2025: Maurizio reinstalla l’app; poiché il passato termine di 12 mesi è scaduto, questa nuova installazione viene conteggiata e fa ripartire il ciclo

Giovanni

• Aprile 2024: Giovanni installa la stessa app di Maurizio; essendo un altro ID Apple, viene conteggiato a parte, installazione numero 150.000, e inizia il suo ciclo annuo di reinstallazioni illimitate concesse
• Settembre: Giovanni rimuove l’app
• Luglio 2025: Giovanni rimette l’app; il passato ciclo di reinstallazioni è però nel frattempo terminato e dunque questa nuova viene conteggiata, inoltre essendovene state già più di un milione lo sviluppatore dovrà corrispondere 50 centesimi ad Apple
• Novembre: Giovanni toglie e rimette ancora l’app perché di nuovo necessaria; il ciclo delle reinstallazioni era ripartito da luglio e lo sviluppatore aveva già corrisposto l’obolo correlato, non dovrà versarlo ancora

Massimiliano ed Elio

• Luglio 2024: Massimiliano installa l’app, è l’ID Apple numero 999.999 a farlo; lo sviluppatore non paga la CTF per la sua installazione
• Pochi minuti dopo: Elio installa pure lui l’app, è l’ID numero 1.000.000; scatta la CTF e quindi lo sviluppatore deve 50 centesimi ad Apple

Serviranno sicuramente più riletture, purtroppo non riusciamo a semplificarlo ancora meglio, ma speriamo che aiuti comunque a comprendere il meccanismo. Come anticipato all’inizio, la Core Technology Fee è un aspetto controverso e già indigesto. Si parte dalle grandi come Spotify, che l’ha paragonata senza troppi giri di parole ad un’estorsione – tuttavia, non sono le corporation dalle spalle grosse a subire le botte maggiori, ma i piccoli sviluppatori indipendenti. Facciamo una simulazione con la calcolatrice di commissioni messa a disposizione da Apple: ipotizzando di avere un’app completamente gratuita, con la previsione di raggiungere 2 milioni di installazioni uniche all’anno, viene stimata una CTF di 41.667€ al mese. Se l’app è a pagamento, le spese aumentano ancor di più e si dovrà sperare o nel pochi ma buoni (vuoi per stare sotto il radar della CTF, vuoi per pagarla ma senza perdite grazie ad un prezzo elevato per l’app) o in un successo di massa tale da portare numeri annui almeno vicini al milione di incassi. Una potenziale scappatoia è di addebitare de facto la commissione ai propri clienti, come sta facendo mobivention col suo store per le aziende – un conto è però richiederla ad entità che possono assorbirne gli effetti, un altro sarebbe farlo anche sui negozi rivolti direttamente ai clienti finali, dove risulterebbe un obolo difficile da giustificare.

Chiaramente, la risposta implicita di Apple a tutto questo è una sola: restate alle vecchie condizioni commerciali e non rischierete di pagare la CTF. Sempre chiaramente, sarà difficile che l’Unione Europea non imporrà cambiamenti in un futuro non troppo lontano. Una commissione aggiuntiva per l’uso della piattaforma tecnica (specie se si abbandona del tutto l’App Store) è comprensibile; la forma in cui è stata proposta meno. La buona notizia proveniente dalla mela è che qualche riflessione è già in corso sul rendere la novità meno onerosa quantomeno per i piccoli sviluppatori, riducendo così anche le probabilità dell’uso di “forza bruta” da parte delle autorità.

D come Default

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Fin da iOS 14, è possibile modificare nelle Impostazioni l’app predefinita per quanto riguarda il browser e il client di posta elettronica, in presenza di due o più applicazioni installate rientranti in queste tipologie. Tra gli impegni presi per conformarsi al DMA, Apple aggiungerà entro marzo 2025 la medesima opzione anche per le app di navigazione. Una modifica che tutto sommato suona curiosa, considerando che l’app nativa può essere liberamente disinstallata e pure su iPhone a fare la parte del leone è Google Maps (rientrante tra i prodotti di Big G toccati dal DMA), nonostante i grossi miglioramenti della soluzione cartografica Apple. Ad ogni modo, un’opzione in più di scelta che male non fa.

A proposito di app da disinstallare, una modifica più impattante che potrebbe avvenire in futuro riguarderebbe Foto. Attualmente è una delle poche app non rimovibili da iOS (in questo club ristretto rientra pure Safari, sebbene ancora per pochi mesi come già spiegato più sopra), ritenute necessarie al corretto funzionamento del sistema. Effettivamente il DMA pone delle eccezioni per quei componenti considerati essenziali per un’operatività di base – l’UE non reputa tuttavia Foto rientrante in questa casistica. Una situazione considerata da molti apparentemente intricata da risolvere, considerato che tale app non si limita a gestire gli album fotografici sugli iPhone, ma ha pure diretta integrazione con altre app e parti del sistema, agendo come rullino foto.

In realtà, Apple potrebbe essersi più o meno involontariamente preparata da tempo ad uno scenario del genere: al di fuori dell’app Foto, l’accesso alle librerie fotografiche viene implementato attraverso PhotoKit. Allo stato attuale, questo set di estensioni si appoggia a Foto in forma esclusiva, ma potrebbe farlo anche con soluzioni concorrenti. A riprova, il noto sviluppatore irlandese Steve Troughton-Smith ha già constatato attraverso il simulatore iOS integrato nell’ambiente di sviluppo Xcode che rimuovendo Foto il selettore nelle altre app va “semplicemente” in errore, non viene del tutto rimosso né provoca crash. Un’apertura che richiederebbe dello sforzo che Apple avrebbe senz’altro sperato di evitare, ma per fortuna nessun cataclisma né tantomeno tempi troppo lunghi. Questa soluzione è già implementata su Android, risparmiato infatti da rimostranze in tal senso (Google ne ha comunque molte altre a cui dovrà far fronte).

Concludendo questo paragrafo, è interessante osservare che al momento l’impossibilità di disinstallare l’App Store non viene messa in discussione dalle autorità europee. È verosimile pensare che rientri nelle sopraccitate eccezioni, trattandosi di un componente base essenziale, non fosse altro che per procurarsi un browser (se si è già rimosso Safari) tramite cui installare uno store alternativo.

F come Form di Interoperabilità

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Tra le prescrizioni del DMA, vi è quella di una maggiore interoperabilità su richiesta per software e dispositivi. A riguardo, Apple ha previsto per gli sviluppatori nell’Unione Europea un nuovo modulo per richiedere l’accesso aggiuntive ad API di iOS e/o tecnologie dell’iPhone attualmente non sfruttabili. Apple analizzerà la richiesta, valutandone la conformità alla normativa (il DMA prevede comunque dei paletti contro “voglie sfrenate”) e chiedendo allo sviluppatore maggiori informazioni se necessario. In caso di riscontro positivo, Apple inizierà a lavorare sulle modifiche richieste, valutando l’impatto sull’integrità della piattaforma e l’efficacia che porterebbe nell’ambito dell’interoperabilità. Qualora non ci fossero ostacoli ritenuti insormontabili, la miglioria sarà implementata in una successiva release di iOS, con aggiornamenti sui progressi ogni 90 giorni (qualora la feature necessiti un prolungato tempo di sviluppo), notifica in prossimità del rilascio e pubblicazione di documenti tecnici per illustrare nel dettaglio l’implementazione.

G come Giochi

• In quali territori si applica: globale
• A quali piattaforme si applica: tutte

Questo è un punto che abbiamo già trattato di recente con un articolo dedicato, ma per completezza lo riportiamo pure qui. A livello mondiale e su qualsiasi suo dispositivo supportato, Apple ha finalmente sdoganato il cloud gaming, e più in generale i giochi in streaming, tra le categorie supportate nell’App Store. Se e quando lo vorranno, ciò permetterà a servizi come quelli di Xbox (anche se Microsoft al momento resta scettica) e GeForce Now di offrire le loro app con catalogo ludico all’interno, invece che richiedere il passaggio tramite browser – come sinora si è dovuto fare.

Sono state poi introdotte ulteriori opportunità anche per mini-app integrate, mini-giochi, chatbot e plug-in, tra cui la possibilità di utilizzare specificatamente per questi gli acquisti in-app. Il 5 aprile si è aggiunta un’altra categoria in più: sono consentiti pure gli emulatori per il retro-gaming, ovvero tutte quelle app che permettono su dispositivi moderni di giocare a titoli rilasciati per vecchie console, ambito che su Mac e PC (nonché su Android) già da tantissimo tempo ha un fedele bacino d’utenza e di sviluppatori. Essendo modifiche riguardanti l’App Store nativo, le sue consuete linee guida devono continuare ad essere seguite.

Ecco, qui potrebbe cascare il proverbiale asino per i citati emulatori, in quanto potranno permettere il download di giochi/ROM da eseguire al loro interno, purché nel rispetto delle leggi. L’emulazione è da sempre dentro una zona grigia, poiché gli emulatori in sé stessi non sono illegali ma l’esecuzione di giochi non regolarmente acquistati in precedenza sì. E per stare nella piena legalità non basta aver effettuato l’acquisto – le copie da emulare devono essere realizzate partendo proprio dagli originali in proprio possesso. A tutti gli effetti il download sarà quindi limitato a giochi “homebrew”, realizzati da sviluppatori indipendenti che hanno deciso di non trarne (più) profitto, oppure a quei rari casi dove la grossa software house di turno opta per rendere di pubblico dominio uno o più titoli (ci sarebbe anche l’eventualità della scadenza dei copyright, ma andiamo molto più in là nelle tempistiche da considerare). Riassumendo, apertura sì ma parecchio condizionale. Apple non si porrà remore a cassare dallo Store gli emulatori problematici sul piano legale, anche considerando quanto alcune aziende siano piuttosto litigiose sul tema. Ogni riferimento a Nintendo è puramente non casuale.

In aggiunta, sono disponibili strumenti analitici in più e oltre 50 nuovi report a disposizione degli sviluppatori sull’App Store Connect, tra cui dettagli relativi all’engagement degli utenti, informazioni aggiuntive su acquisti e transazioni in-app, dati diagnostici su installazioni, rimozioni e crash così come sulle interazioni delle app coi framework di sistema. Questi report saranno anche esportabili all’interno di soluzioni di terze parti. Infine, chi offre varie opzioni di login nelle app può decidere di continuare ad affiancarvi “Accedi con Apple” come sinora fatto o inserirne un’altra che preveda un analogo livello di protezione della privacy.

I come Identificazione

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Questo è un aspetto documentato solo marginalmente in forma pubblica da Apple, ma analizzato attentamente da chi sa come scavare all’interno dei file di sistema. Già nella prima Beta di iOS 17.4 era stato rinvenuto il metodo con cui viene verificato periodicamente se il dispositivo rientra nel raggio d’azione del DMA. Tra le informazioni più rilevanti controllate, vi sono:

• L’indirizzo di fatturazione dell’ID Apple
• L’attuale posizione geografica approssimativa (a livello di nazione) dell’utente
• La zona inserita nelle Impostazioni
• Il tipo di dispositivo (iPhone o iPad)

Ufficialmente, Apple dichiara che le informazioni raccolte le vengono trasmesse con un singolo indicatore di idoneità e in una forma rispettosa della privacy. Resta non chiaro se tali condizioni debbano essere soddisfatte tutte insieme o ne bastano solo alcune, ma è facile capire il motivo dietro queste verifiche: evitare che possano essere sfruttate da utenti non residenti nell’Unione Europea, quantomeno non senza un forte impegno tra ID Apple alternativi e spoofing della posizione. C’è pure un controllo aggiuntivo sulla provenienza del dispositivo, specificatamente se è un’unità per la Cina. Anche qui, facile intuire la motivazione, considerate le forme di controllo governative esercitate in tale territorio. Nella prima Beta di iOS 17.4, era prevista addirittura una predisposizione per visualizzare la zona del dispositivo in fondo nella sezione Info delle Impostazioni. Tuttavia, questo elemento è stato rimosso nella Beta 2 e non più ricomparso nemmeno nel rilascio finale.

Qui sopra abbiamo descritto il processo iniziale di verifica. Ma cosa succede se andiamo in vacanza o per lavoro al di fuori dell’UE, o proprio ci trasferiamo del tutto? Questo Apple lo spiega, seppur comunque in modo parziale: si perde la possibilità di utilizzare gli store alternativi. O meglio, per 30 giorni si potranno continuare ad aggiornare le app installate tramite essi, ma non ottenerne di nuove. Passati i 30 giorni, verranno disattivati anche gli aggiornamenti. Al rientro nel territorio dell’UE, le inibizioni verranno rimosse, ripristinando la disponibilità dei negozi terzi. Perché abbiamo parlato di spiegazione parziale? Perché Apple non chiarisce se la fuoriuscita dall’UE comporti pure l’annullamento delle altre implementazioni legate al DMA. La logica suggerisce di sì. La conferma o smentita pratica ce la darà il tempo, man mano che si vedranno meglio gli effetti delle modifiche: non servirà andare troppo in là, per provare basterebbe una gita a Lugano, in Svizzera, che non è nell’Unione Europea. Pure qui, al di là della scarsa flessibilità di Apple, come già osservato nel caso dei browser sarebbe da dare una tirata d’orecchie agli euro-regolatori che non hanno pensato ad un maggiore concerto con le altre autorità, perlomeno quelle dei Paesi EEA/EFTA (con lo UK sarebbe stata più in salita, visti i rapporti tiepidi post-Brexit) di modo da evitare situazioni del genere nel cortile di casa.

Per chi vive al di fuori dei 27 Paesi UE e spera nell’arrivo delle stesse modifiche pure dalle sue parti, vi è un barlume di speranza: il sistema è già predisposto. L’abilitazione prevede che la zona abbia una corrispondenza nella lista caricata sui server Apple, pertanto se in futuro il Regno Unito e/o la Svizzera implementassero requisiti simili al DMA, non dovrebbe occorrere un aggiornamento di iOS per estendere ad esse tutto quanto descritto qui. Discorso analogo potrebbe riguardare pure iPadOS, per ora lasciato fuori ma non al riparo da futuri euro-ripensamenti: le fondamenta sono tutte pronte e basterà una modifica da remoto.

M come Messaggi

• In quali territori si applica: UE
• A quali piattaforme si applica: tutte

Abbiamo già detto all’inizio che iMessage non rientra nell’ambito del DMA, esclusione confermata dall’Unione Europea a febbraio. Una posizione di tranquillità rafforzata anche dal futuro supporto allo standard RCS annunciato da Apple lo scorso novembre. Non essendo presente in iOS 17.4 né avendo rinvenuto alcuna traccia interna che ne suggerisca un imminente implementazione, quasi sicuramente di RCS ne riparleremo non prima di giugno in vista della WWDC24 e del nuovo iOS 18.

Del resto, se negli Stati Uniti la piattaforma di messaggistica Apple ha una posizione di forte maggioranza al punto da suscitare frequenti dibattiti al limite della “lotta di classe” tra bolle blu e bolle verdi (tutti i messaggi che arrivano su iPhone tramite SMS o MMS), nel Vecchio Continente la situazione è molto diversa. WhatsApp la fa da padrone e infatti è soggetto al DMA, assieme all’altra app di casa Meta per la messaggistica, Facebook Messenger. Cosa prevede la normativa europea per questo tipo di app? Sostanzialmente, l’interoperabilità. La piattaforma gatekeeper deve fornire accesso alle altre che ne facciano richiesta; in termini semplici, significa che Telegram potrà richiedere a Meta di permettere conversazioni incrociate con WhatsApp. La decisione sullo sfruttare o meno questa integrazione resta completamente nelle mani degli utenti.

La stessa richiesta di Telegram, per ipotesi, potrebbe farla anche Apple. Conversazioni WhatsApp all’interno dell’app Messaggi di sistema? Difficile, oseremmo dire improbabile, anche perché Cook e soci hanno già individuato in RCS la piattaforma intermediaria ideale tra piattaforme. Inoltre, l’interoperabilità tra iMessage e WhatsApp e/o Facebook Messenger richiederebbe non solo la firma di un accordo specifico con l’azienda di Mark Zuckerberg, ma anche l’implementazione aggiuntiva (non imposta, tuttavia caldamente consigliata) del protocollo di sicurezza Signal, scelto da Meta per consentire le chat tra diverse piattaforme. Dal canto suo, Apple ha proprio di recente introdotto il nuovo protocollo di sicurezza PQ3 per iMessage, rendendo alquanto remote le possibilità dell’affiancamento di una soluzione tecnicamente concorrente.

N come NFC

• In quali territori si applica: EEA
• A quali piattaforme si applica: iOS

Questa è una novità che riguarda lo Spazio Economico Europeo ed è la sostanziale apertura del chip NFC integrato negli iPhone a circuiti di pagamento contactless rivali di Apple Pay, con l’introduzione di API dedicate per facilitare l’implementazione. Queste alternative possono essere integrate nelle app delle banche o anche in soluzioni che sostituiscono il Wallet di iOS, con la possibilità di impostarle come predefinite. Il principio di funzionamento è lo stesso di Apple Pay: si preme due volte il pulsante laterale (o il pulsante home, per chi usa un iPhone SE), ci si avvicina al POS contactless e verrà avviata la transazione. Si potranno avere anche più circuiti contemporaneamente e adoperarli ciascuno alla bisogna.

Sulla scia delle altre situazioni descritte, anche qui per gli sviluppatori ci sono alcune condizioni da rispettare. Bisogna ottenere una specifica qualifica e rispettare vari requisiti, tra cui avere una valida licenza per i pagamenti nell’EEA, supportare soluzioni NFC nei negozi, rispettare gli standard di sicurezza di settore, fornire tutti i dati principali richiesti da Apple per l’approvazione e presentare istruzioni chiare all’utente quando si sta per effettuare una transazione.

Porterà all’arrivo di Google Pay e Samsung Pay, giusto per citare due circuiti del mondo Android, anche su iPhone? Difficile che cane morda cane, anche perché tali servizi vengono giustamente visti come un vantaggio per la propria piattaforma. Ben più plausibile l’arrivo di servizi locali. Considerata la propensione già dimostrata in passato dalle società europee per soluzioni “allegre” (giusto per essere rispettosi) in termini di esperienza d’uso, ci auguriamo che essi possano affiancarsi e non sostituirsi alla semplicità offerta sinora da Apple Pay.

P come Pagamenti

• In quali territori si applica: UE
• A quali piattaforme si applica: tutte

Restiamo in tema pagamenti, ma stavolta all’interno del software e dell’Unione Europea. Tra le modifiche del DMA si annovera per gli sviluppatori la possibilità di utilizzare nelle app metodi di pagamento diversi da quello integrato nell’App Store. In tali casi, come già illustrato più sopra parlando delle commissioni, se si accettano le nuove condizioni commerciali non sarà più necessario corrispondere alcunché ad Apple, dal momento che non fungerà più da intermediaria nella transazione con l’utente (e sarà sgravata da qualsiasi responsabilità in merito). I servizi alternativi potranno essere implementati direttamente all’interno delle app o rimandando a siti esterni. Le modalità saranno tra loro però esclusive: o si usa il sistema di pagamenti dell’App Store o uno di terze parti, scelta secondo Apple necessaria per evitare la confusione che genererebbe l’uso combinato.

Non lasciamo spazio all’immaginazione, anche qui sono necessarie delle qualifiche dedicate e il rispetto di alcune condizioni. Per chi vorrà usare nella propria app un sistema di pagamento alternativo, oltre ad usarlo esclusivamente, dovrà esplicitare il fornitore del servizio, implementare tutto il processo di acquisto in-app all’interno e limitarlo espressamente alle funzionalità per cui è stato pensato. La schermata che precede la transazione, visibile sopra sulla destra, dovrà spiegare nel dettaglio che il pagamento non verrà effettuato con l’intermediazione di Apple e lascerà all’utente la decisione finale. Stesso discorso (schermata sulla sinistra) vale per coloro che invece preferiranno rimandare ad un sito web esterno, da aprire nel browser predefinito, assicurando che non avvengano redirect sospetti su altre pagine. Non è obbligatorio utilizzare i design soprastanti: da Cupertino vengono solo consigliati come template per accelerare l’implementazione e fornire immediata chiarezza all’utente. Nel caso arrivino segnalazioni su usi fraudolenti di questi metodi di pagamento, Apple si riserverà la facoltà di rimuovere l’app se presente sul suo Store ed annullare l’iscrizione al Developer Program dello sviluppatore.

Abbiamo già scritto nel capitolo dedicato alle commissioni che nel caso si usino metodi di pagamento alternativi ma si permanga nell’App Store, restano da corrispondere ad Apple le percentuali di piattaforma più la CTF. Per il calcolo effettivo mensile delle commissioni, è richiesta agli sviluppatori l’implementazione di un’API dedicata che comunichi in quel di Cupertino i dettagli delle transazioni (inclusi anche i rimborsi e le operazioni annullate). In caso di incongruenze, l’azienda guidata da Cook si riserverà il diritto di effettuare accertamenti supplementari e procedere ad ulteriori iniziative in caso di morosità.

Prima di proseguire con la prossima sezione, citiamo una nuova recente modifica, in questo caso valida in tutto lo Spazio Economico Europeo e non direttamente frutto del DMA, bensì della multa da oltre 1,8 miliardi di Euro comminata ad Apple per abuso di posizione dominante nello streaming musicale. Spotify e le altre app rientranti in questa categoria avranno la possibilità di richiedere un’approvazione speciale per offrire metodi di pagamento esterni senza obbligo di passare alle nuove condizioni commerciali (nel caso invece le si accetti, quest’approvazione avrà validità per Islanda e Norvegia). Non mancano alcuni parametri da rispettare, ossia:

• avere lo scopo primario di fornire un servizio di streaming musicale
• avere selezionato Musica come categoria principale per la classificazione sull’App Store
• essere – appunto – disponibile nell’App Store su iOS e/o iPadOS all’interno dell’EEA
• non utilizzare l’altra tipologia di approvazione speciale già disponibile, quella per le app “reader” (che è disponibile a livello globale)
• non participare alle iniziative Video Partner Program e/o News Partner Program

Soddisfatti questi prerequisiti, richiesta ed ottenuta l’approvazione, le osservanze indicate da Apple sono grosso modo simili a quelle già esplicitate sopra per implementare metodi di pagamento esterni nelle altre tipologie di app.

R come Review

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Come abbiamo anticipato nella parte relativa all’App Store, per quelli terzi Apple conserverà comunque un sistema basico di review in forma mista, umana ed automatizzata, col fine di ridurre quanto più possibile eventuali rischi per la sicurezza di iOS e dei suoi utenti. Il sistema di autenticazione (chiamato anche notarizzazione, una traduzione letterale dell’inglese “notarization”) presenta analogie con quello già implementato da tempo per macOS e si occuperà di accertare il soddisfacimento di alcune condizioni:

• le app dovranno riportare informazioni chiare sullo sviluppatore, sulle funzionalità e sui costi, includendo screenshot – tali elementi saranno poi riportati nelle schede informative che l’utente potrà consultare prima di confermare l’installazione
• a livello funzionale dovranno essere prive di bug critici, compatibili con la versione corrente di iOS e se non autorizzate (leggasi sopra per il form di interoperabilità) non potranno sfruttare caratteristiche software e hardware del dispositivo che comportino a detta di Apple un degrado dell’esperienza d’uso (cosa che si può interpretare pure come la conferma che non va considerata una forma ufficiale di jailbreak)
• non dovranno in alcun modo mettere in pericolo l’incolumità fisica dell’utente o del pubblico generale
• non dovranno contenere malware o qualsiasi altro elemento indesiderato né tantomeno scaricare codice eseguibile aggiuntivo non autorizzato, accedere ad aree di sistema non autorizzate e/o abbassare il livello di sicurezza di iOS (anche qualora si limitassero a fornire istruzioni su come farlo); se hanno bisogno di accessi aggiuntivi, dovranno richiedere l’esplicito consenso all’utente motivando le specifiche necessità
• non potranno raccogliere o trasmettere dati personali senza informare l’utente o per scopi diversi da quelli per cui le app sono state sviluppate

Se l’app supererà il processo di verifica, riceverà la firma digitale e le codifiche necessarie per la distribuzione in forma sicura. In ogni caso, i controlli non si fermeranno: iOS si accerterà che l’installazione venga avviata da un metodo distributivo autorizzato e preveda lo scaricamento dell’app così com’è stata approvata, senza modifiche postume. Qualora successivamente fosse rinvenuta la presenza di elementi malevoli, Apple bloccherà da remoto il lancio dell’app e la possibilità di effettuarne nuove installazioni. Queste capacità protettive, a dire il vero, non sono una novità visto che vi è già stato ricorso in passato per alcune situazioni critiche (sino a qualche anno fa i profili di configurazione erano a volte adoperati per fini non proprio leciti).

S come Sideloading

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Andiamo infine all’ultimo punto, ossia quello relativo al sideloading. In tutte le discussioni relative agli effetti che il DMA avrebbe comportato su iOS, la domanda più gettonata era: si potranno installare le app tramite il loro file IPA, direttamente dal web, sulla scia di quanto si può fare su macOS o anche su Android con gli APK, abilitando le opzioni apposite?

La risposta inizialmente data Apple si può riassumere in: sì, ma anche no. Nel senso che è previsto il sideloading, ma in iOS 17.4 vale solo ed esclusivamente per installare gli app store alternativi. Tutto il resto delle applicazioni andrà ottenuto da uno di essi o dallo Store nativo. Si può capire la precauzione di fondo, verosimilmente legata a prevenire il possibile fiorire di versioni pirata delle app a pagamento. Chi pregustava già la possibilità di scaricare l’IPA e ritrovarsi l’app desiderata nella schermata home senza intermediari è rimasto deluso, potendo solo riporre speranze nella richiesta di modifiche da parte dell’UE.

Modifiche presumibilmente richieste, dal momento che pochi giorni dopo l’arrivo di iOS 17.4 Apple ha annunciato il cambiamento di rotta: con iOS 17.5 arriverà la possibilità di distribuire le app tramite web, senza necessità di store intermediari. I requisiti previsti presentano similitudini, ma anche differenze, a quelli per offrire store alternativi, ovvero:

• essere registrati al Developer Program e avere sede legale nel territorio UE (se la casa madre risiede al di fuori, può ovviare operando tramite una filiale locale)
• essere membri del Developer Program da almeno due anni, in buona condotta e con un’app che contava più di un milione di installazioni nell’UE durante l’anno precedente
• concordare di distribuire le app compilandole solo tramite il proprio account sviluppatore e su un dominio web valido registrato sull’App Store Connect
• rendere pubbliche le condizioni commerciali e d’uso dello store, così come quelle del trattamento dei dati personali, seguendo anche le altre normative europee in merito, a partire da DSA (Digital Services Act) e GDPR (General Data Protection Regulation)
• acconsentire ad effettuare il controllo delle app caricate di modo da accertarsi che non effettuino e/o portino ad effettuare illeciti, includano elementi malevoli e/o violino proprietà intellettuali, reagendo prontamente alle richieste di chiarimenti o modifiche provenienti da Apple tenendosi pronti a ritirare i software non conformi (anche dietro richieste governative)

Anche in questo caso, la Core Technology Fee resta applicata, con le identiche modalità descritte negli altri casi. Non si sfugge, quindi – chi vorrà distribuire le app tramite il proprio sito dovrà accettare le nuove condizioni commerciali né potrà pentirsene. Rimarranno inoltre altri limiti: oltre al campo perlopiù ristretto alle applicazioni di maggiore popolarità, l’utente dovrà entrare nelle Impostazioni di iOS per acconsentire all’installazione delle app provenienti dallo sviluppatore. In attesa di ulteriori verifiche conseguenti all’inizio della fase Beta di iOS 17.5, è verosimile immaginare che l’opzione implementata sarà quantomeno concettualmente simile a quella presente su macOS e visibile nello screenshot soprastante. Altrettanto verosimile pensare che sistemisti in azienda e genitori potranno bloccare a monte questa fonte alternativa di installazioni con le stesse maniere già descritte per gli altri negozi. Inverosimile invece che si potrà installare liberamente un IPA salvato tramite fonti diverse dal sito ufficiale, sulla falsariga dei PKG sui Mac: magari si arriverà pure a tal punto, tuttavia almeno per ora non appare contemplato. Anche qui, ci riserviamo di rivedere questa parte con l’arrivo di più informazioni e prove pratiche.

È bene precisare comunque che dei metodi per l’installazione tramite IPA in realtà esistevano già da prima, anche tramite strumenti ufficiali Apple, come Configurator o Xcode (su Windows e vecchie versioni di macOS, pure iTunes si presta allo scopo). Tuttavia, la maggioranza di queste vie prevede svariati passaggi da compiere, spesso anche ripetuti nel tempo, e soprattutto sono nati pensando agli sviluppatori per testare le loro app e agli amministratori IT per agevolare la distribuzione di software proprietario aziendale.

Resta invece inalterata, nonché utilizzabile pure per lo sviluppo di app destinate alla distribuzione su store alternativi, la possibilità di sfruttare TestFlight come canale supplementare d’installazione ai fini di effettuare Beta test pubblici.

T come Trasferimento

• In quali territori si applica: UE
• A quali piattaforme si applica: iOS

Non ancora implementata, ma promessa da Apple per l’arrivo nell’autunno 2025, dunque addirittura con iOS 19, arriverà una nuova piattaforma tecnica per migliorare il trasferimento dei dati utente da iPhone ad Android. Per dover di cronaca, la documentazione ufficiale parla di scambio dati con telefoni non Apple, ma considerato che il robot verde è l’unico vero rivale di iOS c’è poco spazio per l’immaginazione. Già oggi sono disponibili soluzioni per il cambio piattaforma, in un verso e nell’altro: Apple ha un’app dedicata su Android, Google ne ha una su iOS. Non si tratta però di soluzioni ritenute soddisfacenti dall’Unione Europea, che col DMA punta molto sulla portabilità dei dati tra piattaforme e servizi. Anche in quel di Mountain View dovranno perfezionare i loro strumenti in tal senso, dunque proprio come già osservato per il trasferimento dati tra i browser anche qui i due colossi dovranno trovare il modo di cooperare per raggiungere risultati ottimali.

Tutto chiaro? Forse sì, forse no. Noi speriamo di esserci riusciti il più possibile. I cambiamenti introdotti sono davvero tanti, ne sono già seguiti altri, ne sono in programma altri ancora e potrebbe non essere finita. Quanto messo in atto da Apple dal 7 marzo verrà infatti sottoposto ad un attento scrutinio da Bruxelles, pronta come già fatto a richiedere di apportare correzioni o aggiunte su punti ritenuti non conformi, anche dietro la spinta delle rivali insoddisfatte dalla proposta, pena “azioni forti”. Leggasi: multe salate, fino al 10% del fatturato annuo globale, che passa al 20% in caso di violazioni ripetute e si spinge a richieste di spin off o vendita di rami d’azienda. Questo processo di revisione è già iniziato. Lunedì 18 marzo a Bruxelles l’azienda ha avuto una prima occasione di spiegare e difendere il suo punto di vista riguardo la conformità al DMA. Punto che non ha trovato granché accoglimento, essendo stati aperti supplementi d’indagine, che entro un anno potrebbero portare alle succitate azioni forti in assenza di rimedi convincenti.

Prevedibilmente e comprensibilmente, da Cupertino continueranno a provare a difendere la loro posizione con le unghie e coi denti, come fatto in altri casi, effettuando rettifiche col contagocce e rendendo molto elevate le probabilità non solo di sanzioni, ma di un vero scontro legale con l’Unione Europea. Varrebbe la pena arrivarci? Questo articolo non è la sede opportuna per stabilirlo: ci limitiamo a dire che se i dirigenti Apple intrattenessero qualche telefonata coi pari grado in Google e (soprattutto) Microsoft, se non già fatto, potrebbero rendersi conto che strappare concessioni non sarebbe affatto una passeggiata. Un assaggio del forte potere sanzionatorio delle autorità europee l’hanno inoltre avuto proprio di recente, come già accennato parlando dei metodi di pagamento.

Concludiamo però con una considerazione rivolta invece proprio all’UE. Torniamo dal già menzionato Steve Troughton-Smith, che nel parlare della situazione di Foto ha lanciato un’altra idea/provocazione: e se pure la schermata home, internamente denominata Springboard, diventasse sostituibile? A Bruxelles potrebbero aver pensato anche a questo, in fondo su Android la facoltà di sostituire il launcher è un’opzione storica. A quel punto però ci sarebbe da chiedersi: vale la pena spingersi a tanto? Ad Apple sono già state chieste tante modifiche, ha già apportato tante concessioni e presumibilmente ne concederà altre ancora, ma quale sarebbe il senso di rendere iOS un clone di Android in tutto e per tutto nella sua operatività? Chiedere troppo rischia di andare proprio nella direzione opposta da quella voluta dal DMA, appiattendo di fatto il mercato riducendo i margini di manovra per la competitività e l’innovazione. Vogliamo confidare che nelle intenzioni europee non si punti ad arrivare a questo e che siano previsti dei limiti dettati dal buonsenso, ancor prima che dai tecnicismi.

Nota: il video sottostante è basato sul set iniziale di implementazioni annunciate da Apple a gennaio e non copre le successive modifiche occorse.