Alcune settimane fa sono tornato sulla questione degli aggiornamenti insostenibili, in seguito al rilascio non proprio stellare di iOS 13. Esattamente il giorno dopo la pubblicazione di quel post è arrivata la 13.2, seguita nei giorni successivi dalla 13.2.1 solo per HomePod e poi dalla 13.2.2 e 13.2.3 per tutti; nel frattempo, procede lo sviluppo della 13.3, con la terza Beta arrivata due giorni fa, ed è pressoché scontato attendersi almeno l’arrivo di una 13.4 e una 13.5 nei primi mesi del 2020. Come osservai nella riflessione, ci si aspettava che il nuovo metodo di sviluppo introdotto da Apple con iOS 12, release molto più riuscita al netto di qualche bug quasi fisiologico (vedasi FaceTime di gruppo), avrebbe continuato a mostrare benefici con la tredicesima versione, rivelatasi invece piena di funzionalità instabili, al punto da doverne rinviare un discreto numero agli aggiornamenti minori.

Il buon trascorso di iOS 12 fu mutuato dai cambiamenti interni nella preparazione del software Apple apportati da Craig Federighi e svelati al pubblico da Mark Gurman svariati mesi prima della WWDC 2018. Molto più focus sull’ottimizzazione del sistema e rinvio delle novità più bisognose di tempo ad una versione successiva, appunto iOS 13. Una sorta di piano biennale, dando il giusto tempo al codice di essere perfezionato dagli sviluppatori prima di andare oltre Cupertino. Constatato quest’anno il risultato mezzo negativo dell’iniziativa, ecco che Gurman attraverso le sue fonti rivela ulteriori cambiamenti nelle fasi di sviluppo di iOS, ma anche degli altri sistemi operativi della mela.

Le modifiche sarebbero state annunciate agli ingegneri software Apple da Federighi e dai suoi più diretti assistenti durante un cosiddetto “kickoff meeting” al quartier generale. Essenzialmente, la variazione più di rilievo sarà nella compilazione delle build giornaliere di iOS prima che finiscano nelle mani dei tester interni. Tali build dovranno infatti presentare disabilitate di default le funzionalità incomplete o ancora troppo piene di bachi, lasciando ai tester la facoltà di riabilitarle singolarmente attraverso un menu dedicato nelle impostazioni chiamato “Flags”, valutando così il loro impatto sia singolo che globale sull’usabilità del sistema operativo. Non si può qui fare a meno di notare un’analogia con le “Flags” di Chrome, dove Google nasconde le feature sperimentali del suo browser in attesa che arrivino a maturazione o, se inevitabile, a definitiva bocciatura. Parimenti, chi ha seguito negli anni il mondo Windows e le sue Beta ricorderà senz’altro i tempi in cui le build di prova, pubbliche e trapelate, del sistema Microsoft nascondevano spesso nuove funzionalità non finite da abilitare attraverso modifiche a chiavi di registro e/o ad alcuni file (casi celebri furono le utility “BlueBadge” per le prime build di Windows 7 e “RedPill” per quelle di 8), simulando così il livello di privilegi che gli sviluppatori di Redmond ottenevano tramite strumenti interni.

L’obiettivo è, oltre ad alzare la qualità del prodotto, anche armonizzarne maggiormente l’inclusione tra i vari team, che sinora non sono stati molto sincronizzati: alcuni gruppi aggiungevano funzionalità al codice principale su base giornaliera a prescindere dal livello di completamento, altri più oculatamente a cadenza settimanale. Ciò comportava per i tester notevoli difficoltà, dato che in certi giorni le build compilate erano inutilizzabili, con le conseguenze osservatesi in iOS 13. La versione corrente avrebbe inoltre ottenuto punteggi consistentemente inferiori rispetto alla 12 nel cosiddetto test “a guanti bianchi” adoperato da Apple, che culmina nell’assegnazione di un punteggio da 1 a 100; sotto i 60 è sempre considerato un cattivo risultato, mentre una maggiore riuscita viene attestata se il software supera gli 80 punti. Altri metodi interni di rating prevedono una scala di colori per le feature (verde, giallo o rosso a seconda del loro stato qualitativo) e una numerica crescente da 0 a 5 per i bug (0 indica un problema grave, mentre 5 identifica un baco leggero che può essere trattato con più calma).

Il nuovo metodo è già applicato per lo sviluppo di iOS 14, nome in codice “Azul”, e lo sarà pure per la 15, su cui potrebbero peraltro essere traghettate alcune delle novità originariamente previste per il 2020, ripetendo lo scenario già visto nelle ultime due versioni. Detto questo, non ci si aspettano spostamenti massivi come avvenne in iOS 12 che si presentò decisamente più magro rispetto ai piani originari: a detta delle fonti di Gurman, iOS 14 porterà un parco di migliorie comparabile a quanto visto quest’anno. La speranza, tanto della dirigenza Apple quanto della nostra, è che queste nuove modifiche ottengano il successo sperato. Vedremo tra due anni se torneremo a riparlare dell’argomento finalmente in modo positivo o, purtroppo, negativo per l’ennesima volta.