Aplicația ta de Mac primește acces la microfon — apoi îl uită la fiecare pornire

Iată un bug care te face să te îndoiești de propriii ochi. Instalezi GeekBye, îți cere acces la microfon, apeși Allow, iar transcrierea funcționează. Grozav. Închizi, îl redeschizi a doua zi dimineață — și îți cere acces la microfon din nou. Te duci să verifici Setări de sistem → Confidențialitate și securitate → Microfon ca să repari manual, iar GeekBye nici măcar nu e în listă. Nici refuzat. Nici permis. Pur și simplu absent, de parcă nu ar fi cerut niciodată.

Fiecare piesă individuală părea corectă. Promptul era real. Permisiunea funcționa în acel moment. Aplicația era semnată și notarizată corespunzător, cu șirurile de utilizare potrivite. Și totuși acordarea se evapora la fiecare pornire. GeekBye v2.0.6 a reparat-o — iar cauza de bază e unul dintre cele mai viclene lucruri pe care macOS le face ca să te protejeze.

Funcția care ascundea aplicația de ea însăși

Vinovatul e macOS App Translocation, o funcție de securitate Gatekeeper. Când descarci o aplicație și o rulezi direct din DMG sau din folderul tău ~/Downloads — oriunde e încă „în carantină" — macOS nu o rulează de fapt de acolo de unde o vezi. O copiază transparent într-o cale randomizată, doar-citire, adânc sub /private/var/folders/.../AppTranslocation/… și rulează acea copie. E o apărare bună: împiedică o descărcare malițioasă să modifice fișiere de lângă ea.

Dar iată ciocnirea. Sistemul de permisiuni al macOS (TCC — cel care urmărește cine îți poate folosi microfonul, camera, ecranul) identifică o aplicație după calea și identitatea ei de cod. Când aplicația e translocată, acea cale e aleatorie și temporară. Așa că, atunci când acorzi acces la microfon, macOS înregistrează cuminte acordarea — pentru o cale care nu va exista la următoarea pornire. Redeschizi aplicația, macOS o translochează la o cale aleatorie diferită, vede o aplicație despre care nu are nicio evidență și cere din nou. Și, pentru că acea cale fantomă nu e niciodată o locație stabilă, aplicația nu câștigă niciodată un rând permanent în Setări de sistem → Microfon.

Aplicația acorda permisiune unei fantome.

De aceea, de asemenea, doar unii oameni o întâlneau. Dacă copia ta de GeekBye locuia deja în /Applications — pentru că ai tras-o acolo, sau pentru că a ajuns acolo prin auto-actualizare — nu există carantină, nu există translocare, o cale stabilă, și totul persistă perfect. Bug-ul era invizibil pentru noi și pentru oricine trecut de prima instalare, exact genul de bug care supraviețuiește cel mai mult.

Fix-ul: dă-i aplicației o casă adevărată

Din moment ce întreaga problemă e o cale instabilă, fix-ul e să duci aplicația pe una stabilă. v2.0.6 detectează când GeekBye rulează translocat (sau pur și simplu rulează din afara /Applications) și oferă un „Move to Applications" cu un singur clic — folosind apelul de relocare al macOS care copiază bundle-ul în /Applications și îl relansează de acolo. Din acel moment aplicația are o identitate fixă: acordarea de microfon rămâne, înregistrarea ecranului rămâne, iar GeekBye apare în sfârșit în Setări de sistem, acolo unde te-ai aștepta.

Promptul e politicos în privința asta. Oferă Move to Applications, Not Now și Don't Ask Again — și își amintește ultima alegere, așa că aplicația nu bate niciodată la cap pe cineva care are un motiv deliberat să o ruleze din altă parte. Decizia dacă să afișeze măcar promptul e izolată în funcții mici și pure (este acest build translocat? este în afara /Applications? a suprimat utilizatorul?) astfel încât logica e testată unitar fără să fie nevoie să lansezi un build notarizat real pe un volum real în carantină.

Aceeași lansare a simplificat și experiența de permisiuni în sine. GeekBye obișnuia să afișeze o fereastră de permisiuni personalizată, făcută pe comandă — câteva sute de linii de UI care încercau să reproducă ceva ce sistemul de operare face deja bine. v2.0.6 a șters-o și s-a bazat pe promptul nativ de permisiuni macOS, susținut de un banner discret, ne-blocant, care apare doar când o permisiune necesară lipsește cu adevărat. Mai puțin cod, și un comportament pe care utilizatorii îl recunosc deja pentru că orice altă aplicație de Mac funcționează la fel.

Partea de care sunt cel mai mândru: am dovedit-o înainte să o credem

Ar fi fost ușor să ghicim translocarea și să livrăm un fix. În schimb, lansarea a livrat mai întâi un diagnostic la pornire: la lansare, GeekBye își raportează acum propria cale a executabilului și dacă e translocat, dacă e în interiorul /Applications, și starea curentă a permisiunilor de microfon și ecran. Acea telemetrie a transformat o teorie plauzibilă într-una confirmată — datele de producție au arătat că sesiunile afectate rulau, într-adevăr, din căi translocate în afara /Applications, exact cum am prezis.

Acea ordine contează. „Promptul apare, dar permisiunea nu rămâne" are mai multe explicații posibile — o problemă de semnare, un șir de utilizare lipsă, o problemă de entitlement, o ciudățenie a bazei de date TCC. Am exclus cauzele la nivel de API (traseul cererii era demonstrabil corect), apoi am lăsat datele din lumea reală să indice stratul de identitate/cale în loc să livrăm un fix plin de speranță și să sperăm că ticketele de suport se opresc.

Trei lucruri pe care le predă acest bug

1. O permisiune care solicită dar nu persistă e o problemă de identitate, nu o problemă de API. Dacă codul cererii e corect și acordarea tot dispare, oprește-te din rescris cererea. Întreabă de ce cale și identitate de cod leagă sistemul de operare acordarea — și dacă acea identitate e stabilă între porniri.
2. Livrează diagnosticul cu (sau înaintea) fix-ului. Câteva câmpuri — de unde rulez, care e starea permisiunilor mele — au transformat o presupunere educată într-o cauză de bază verificată și ne-au spus exact ce utilizatori erau afectați. Instrumentează granița pe care o suspectezi înainte să o repari.
3. Bug-urile care se ascund de dezvoltatori sunt cele care rulează în mediul „greșit". Al nostru locuia în /Applications pe fiecare mașină de dezvoltare, așa că bug-ul era structural invizibil pentru noi, în timp ce lovea utilizatorii la prima instalare. Când un raport nu se reproduce, prima întrebare e ce e diferit la locul unde rulează, nu se înșeală utilizatorul.

GeekBye v2.0.6 a livrat promptul de relocare și diagnosticul împreună. Pentru arcul mai larg de fiabilitate în care se încadrează, vezi ce presupune cu adevărat o versiune 2 (v2.0.0) și de ce înregistrarea ecranului capturează monitorul greșit (v2.0.10) — un alt bug care a apărut doar într-un mediu specific. Pentru lansarea de detalii mărunte de alături, software calm: fix-ul de flicker și chip-ul de mod-de-răspuns (v2.0.3 + v2.0.5).