Da quando Apple ha messo un po’ a dieta i suoi rilasci major, la qualità di ciò che vediamo arrivare in autunno sui nostri dispositivi è tendenzialmente aumentata. I grossi aggiornamenti lo sono di meno, con funzionalità più ridistribuite durante il ciclo vitale della versione e nessun timore nel rinviare quelle troppo immature (com’è successo quest’anno a SharePlay e Universal Control). Ci sono tuttavia ancora importanti margini di miglioramento, dimostrato da alcuni bug di Monterey cui non si sarebbe dovuti assistere in un rilascio considerabile pronto all’uso pubblico.

Il primo è il più pesante dei due di cui parliamo stasera, entrambi portati alla ribalta da MacRumors nonché da varie segnalazioni online. L’installazione di Monterey sta rendendo completamente inutilizzabili vari Mac, costringendo a procedure di ripristino del firmware e non solo del sistema operativo. Al momento, tutti i computer coinvolti nelle segnalazioni sono dotati di processori Intel – i modelli con Apple Silicon che hanno fatto il loro debutto sul mercato con Big Sur (esclusi quindi i nuovi MacBook Pro 14″ e 16″, che dispongono di Monterey come versione di fabbrica) sembrerebbero al sicuro dalle problematiche. Un bug dotato di una sua ciclicità, dato che uno simile riguardò pure Big Sur, fortunatamente dall’impatto molto inferiore coinvolgendo solo alcune unità di MacBook Pro 2013-14. Il “bricking” quest’anno non sembra purtroppo fare distinzioni generazionali, al di là della già citata immunità apparente dei Mac M1.

Tutti sulla stessa barca, invece, per il secondo bug. Esso riguarda un consumo eccessivo di memoria RAM da parte di alcuni componenti, sia di terze parti sia integrati nel sistema, che non occorrevano con Big Sur. Se da una parte è vero che tendenzialmente la memoria inutilizzata è memoria sprecata, dall’altra è pure vero che vedere il Centro di Controllo mangiarsi oltre 26 su 64 GB come nel tweet sottostante appare in tutta franchezza esagerato. E non è il caso più limite, visto che vari utenti hanno segnalato la ricezione di messaggi da macOS sulla memoria piena. I casi sembrano spaziare su tutte le configurazioni di RAM e non hanno una causale specifica, dal momento che possono accadere con qualsiasi app. In questi casi il riavvio del Mac viene considerato d’aiuto, ma non risolutivo, col problema che si ripresenta dopo non molto tempo; per alcuni nemmeno riavviare è sufficiente per ridurre quello che in gergo tecnico viene definito memory leak.

È bene ribadire come i bug descritti coinvolgano una piccola parte dell’utenza: nella grande maggioranza dei casi l’aggiornamento è andato o andrà perfettamente liscio. Tuttavia, anche se si tratta di percentuali ristrette, non sarebbero dovuti arrivare nel rilascio pubblico. Soprattutto il primo, che per i meno avvezzi comportano procedure di riattivazione da non pochi grattacapi, facendo prediligere un passaggio presso Genius Bar o centri d’assistenza con annessi costi, probabili economici, sicuri temporali; il secondo è invece senza dubbio risolvibile con un prossimo aggiornamento, sperando sia la 12.1 già in cantiere.

Dopo aver ridotto la bulimia di feature aggiunte da una versione all’altra, forse potrebbe essere giunto il momento di rivedere la fase di testing. I nuovi sistemi Apple ci vengono infatti presentati alla WWDC di giugno in uno stato praticamente quasi fatto e finito, con gli ultimi 3-4 mesi di Beta aperta dedicati perlopiù a correggere noie nell’esperienza d’uso e nelle API destinate agli sviluppatori. Si tratta di una platea piccola e controllata, in cui bug del genere magari finiscono a non avere priorità in quanto considerati relativi a pochi, singoli casi specifici. Il grosso dei test viene fatto internamente da Apple nei mesi antecedenti la presentazione, dunque in uno scenario ancora più ristretto, e sebbene dovrebbe già servire a scremare i bug più pesanti alcuni arrivano lisci lisci fino al debutto pubblico autunnale, com’è successo per quanto sopra descritto.

Potrebbe esserci una soluzione? Sgombro subito ogni dubbio: una che funzioni al 100% non esisterà mai, visto che il bug è un errore e l’errore è umano, potrà sempre capitare. Qualcosa che li filtri almeno in larga parte sarebbe però fattibile e lo dimostra Microsoft col programma Windows Insider. Le nuove versioni di Windows passano diverso tempo (anche quasi un anno) in questa incubatrice prima di arrivare agli utenti finali, nuove build vengono rilasciate ai tester con cadenza periodica, con inviti a provarle fino in fondo, avvertenze chiare sui bug già noti in cui potrebbero imbattersi e un’app dedicata per inviare i feedback dotata di contatto diretto col team Microsoft. Non protegge del tutto dagli strafalcioni (né da frettolose decisioni commerciali, come nel caso di Windows 11), ma ha di certo aiutato a migliorare la qualità dei rilasci.

Gli strumenti per un macOS Insider Program ci sarebbero già: basterebbe ampliare lo scopo di AppleSeed e dell’app Feedback Utility, sfruttandoli sin da novembre-dicembre dell’anno antecedente al rilascio definitivo, concentrando le build di test dei primi mesi principalmente sugli aspetti dietro le quinte (kernel, librerie, ecc. – aggiungendo giusto ogni tanto qualche sparuto eye candy minore per non rendere tutto troppo noioso), preservando per la futura WWDC il grosso delle novità visibili, che verranno così perfezionate durante l’estate su una base già stabile. La segretezza sarebbe in larga parte preservata, col beneficio di ridurre sensibilmente le chance che bug come quelli discussi oggi passino inosservati troppo a lungo e rendere meno necessario il consiglio di aspettare gli aggiornamenti .1/.2 prima di fare il salto. La Apple di Tim Cook si è già dimostrata in più occasioni ben disposta ad ascoltare gli utenti; chissà che prima o poi non decida dunque di fare un’ulteriore apertura di cui godrebbe per prima i frutti.