La tua app Mac concede l’accesso al microfono — poi lo dimentica a ogni avvio

Ecco un bug che ti fa dubitare dei tuoi stessi occhi. Installi GeekBye, chiede l’accesso al microfono, clicchi su Consenti e la trascrizione funziona. Ottimo. Chiudi, lo riapri la mattina dopo — e chiede l’accesso al microfono di nuovo. Vai a controllare in Impostazioni di Sistema → Privacy e sicurezza → Microfono per sistemarlo a mano, e GeekBye non è nemmeno nell’elenco. Né negato. Né consentito. Semplicemente assente, come se non avesse mai chiesto.

Ogni singolo pezzo, preso da solo, sembrava corretto. L’avviso era reale. Il permesso funzionava sul momento. L’app era firmata e autenticata correttamente, con le giuste stringhe d’uso. Eppure il permesso evaporava a ogni avvio. GeekBye v2.0.6 l’ha corretto — e la causa radice è una delle cose più subdole che macOS fa per proteggerti.

La funzione che nascondeva l’app a sé stessa

La colpevole è l’App Translocation di macOS, una funzione di sicurezza di Gatekeeper. Quando scarichi un’app e la avvii direttamente dal DMG o dalla tua cartella ~/Downloads — ovunque sia ancora "in quarantena" — macOS non la esegue davvero da dove tu la vedi. La copia in modo trasparente in un percorso casuale e in sola lettura, sepolto sotto /private/var/folders/.../AppTranslocation/…, ed esegue quella copia. È una buona difesa: impedisce a un download malevolo di manomettere i file accanto a sé.

Ma ecco la collisione. Il sistema di permessi di macOS (TCC — quello che tiene traccia di chi può usare il tuo microfono, fotocamera, schermo) identifica un’app dal suo percorso e dalla sua identità di codice. Quando l’app è traslocata, quel percorso è casuale e temporaneo. Quindi quando concedi l’accesso al microfono, macOS registra diligentemente il permesso — contro un percorso che non esisterà al prossimo avvio. Riapri l’app, macOS la trasloca in un percorso casuale diverso, vede un’app di cui non ha alcuna traccia, e chiede di nuovo. E poiché quel percorso fantasma non è mai una posizione stabile, l’app non si guadagna mai una riga permanente in Impostazioni di Sistema → Microfono.

L’app stava concedendo il permesso a un fantasma.

È anche per questo che solo alcuni ci finivano dentro. Se la tua copia di GeekBye viveva già in /Applications — perché ce l’hai trascinata tu, o perché ci è arrivata via aggiornamento automatico — non c’è quarantena, né traslocazione, il percorso è stabile e tutto persiste alla perfezione. Il bug era invisibile a noi e a chiunque avesse superato la prima installazione, che è esattamente il tipo di bug che sopravvive più a lungo.

La correzione: dare all’app una casa vera

Dato che l’intero problema è un percorso instabile, la correzione consiste nel portare l’app su uno stabile. La v2.0.6 rileva quando GeekBye è in esecuzione traslocato (o semplicemente in esecuzione fuori da /Applications) e offre uno "Sposta in Applicazioni" con un clic — usando la chiamata di ricollocazione di macOS che copia il bundle in /Applications e lo riavvia da lì. Da quel momento l’app ha un’identità fissa: il permesso del microfono tiene, la registrazione dello schermo tiene, e GeekBye compare finalmente in Impostazioni di Sistema dove te lo aspetteresti.

L’avviso è educato al riguardo. Offre Sposta in Applicazioni, Non ora e Non chiedere più — e ricorda l’ultima scelta, così l’app non assilla mai chi ha una ragione deliberata per eseguirla da altrove. La decisione se mostrare o meno l’avviso è isolata in piccole funzioni pure (questa build è traslocata? è fuori da /Applications? l’utente l’ha silenziata?), così la logica viene testata con test unitari senza dover avviare una vera build autenticata su un vero volume in quarantena.

Lo stesso rilascio ha anche semplificato l’esperienza dei permessi in sé. GeekBye apriva prima una finestra dei permessi personalizzata e su misura — qualche centinaio di righe di interfaccia che cercavano di riprodurre qualcosa che il sistema operativo fa già bene. La v2.0.6 l’ha eliminata e si è appoggiata all’avviso di permessi nativo di macOS, sostenuto da un banner discreto e non bloccante che compare solo quando manca davvero un permesso richiesto. Meno codice, e un comportamento che gli utenti riconoscono già perché ogni altra app Mac funziona allo stesso modo.

La parte di cui vado più fiero: l’abbiamo dimostrato prima di crederci

Sarebbe stato facile indovinare la traslocazione e rilasciare una correzione. Invece, il rilascio ha spedito prima una diagnostica di avvio: all’avvio, GeekBye ora riporta il proprio percorso dell’eseguibile e se è traslocato, se è dentro /Applications, e lo stato attuale dei permessi di microfono e schermo. Quella telemetria ha trasformato una teoria plausibile in una confermata — i dati di produzione hanno mostrato che le sessioni colpite giravano, di fatto, da percorsi traslocati fuori da /Applications, esattamente come previsto.

Quell’ordine conta. "L’avviso compare ma il permesso non tiene" ha diverse spiegazioni possibili — un problema di firma, una stringa d’uso mancante, una questione di entitlement, una stranezza del database TCC. Abbiamo escluso le cause a livello di API (il percorso della richiesta era dimostrabilmente corretto), poi abbiamo lasciato che i dati del mondo reale puntassero al livello identità/percorso invece di rilasciare una correzione speranzosa incrociando le dita perché i ticket di supporto smettessero.

Tre cose che questo bug insegna

1. Un permesso che viene chiesto ma non persiste è un problema di identità, non di API. Se il codice della richiesta è corretto e il permesso svanisce comunque, smetti di riscrivere la richiesta. Chiediti a quale percorso e identità di codice il sistema operativo sta legando il permesso — e se quell’identità è stabile tra un avvio e l’altro.
2. Rilascia la diagnostica con (o prima della) correzione. Pochi campi — da dove sto girando, qual è il mio stato dei permessi — hanno trasformato un’ipotesi informata in una causa radice verificata e ci hanno detto esattamente quali utenti erano colpiti. Strumenta il confine che sospetti prima di applicare la patch.
3. I bug che si nascondono agli sviluppatori sono quelli che girano nell’ambiente "sbagliato". Il nostro viveva in /Applications su ogni macchina di sviluppo, quindi il bug era strutturalmente invisibile per noi mentre colpiva gli utenti alla prima installazione. Quando una segnalazione non si riproduce, la prima domanda è cosa c’è di diverso in dove gira, non l’utente si sbaglia.

GeekBye v2.0.6 ha rilasciato l’avviso di ricollocazione e la diagnostica insieme. Per l’arco di affidabilità più ampio in cui si inserisce, vedi cosa serve davvero per una versione 2 (v2.0.0) e perché la registrazione dello schermo cattura il monitor sbagliato (v2.0.10) — un altro bug che affiorava solo in un ambiente specifico. Per il rilascio dei piccoli dettagli qui accanto, software sereno: la correzione dello sfarfallio e il chip della modalità di risposta (v2.0.3 + v2.0.5).