Seu app do Mac concede acesso ao microfone — e esquece a cada abertura

Aqui vai um bug que faz você duvidar dos próprios olhos. Você instala o GeekBye, ele pede acesso ao microfone, você clica em Permitir e a transcrição funciona. Ótimo. Você fecha, reabre na manhã seguinte — e ele pede acesso ao microfone de novo. Você vai conferir em Ajustes do Sistema → Privacidade e Segurança → Microfone para corrigir na mão, e o GeekBye nem está na lista. Nem negado. Nem permitido. Simplesmente ausente, como se nunca tivesse pedido.

Cada peça isolada parecia correta. O aviso era real. A permissão funcionava no momento. O app estava corretamente assinado e notarizado, com as strings de uso certas. E mesmo assim a permissão evaporava a cada abertura. O GeekBye v2.0.6 corrigiu isso — e a causa raiz é uma das coisas mais manhosas que o macOS faz para te proteger.

O recurso que escondia o app dele mesmo

A culpada é o App Translocation do macOS, um recurso de segurança do Gatekeeper. Quando você baixa um app e o abre direto do DMG ou da sua pasta ~/Downloads — em qualquer lugar onde ele ainda está "em quarentena" — o macOS não o roda de fato de onde você o vê. Ele o copia de forma transparente para um caminho aleatório e somente leitura, enterrado sob /private/var/folders/.../AppTranslocation/…, e roda essa cópia. É uma boa defesa: impede que um download malicioso adultere os arquivos ao lado dele.

Mas aqui está a colisão. O sistema de permissões do macOS (TCC — o que controla quem pode usar seu microfone, câmera, tela) identifica um app pelo seu caminho e sua identidade de código. Quando o app está translocado, esse caminho é aleatório e temporário. Então, quando você concede acesso ao microfone, o macOS registra fielmente a permissão — contra um caminho que não vai existir na próxima abertura. Você reabre o app, o macOS o transloca para um caminho aleatório diferente, vê um app do qual não tem registro algum, e pergunta de novo. E como esse caminho fantasma nunca é um local estável, o app jamais ganha uma linha permanente em Ajustes do Sistema → Microfone.

O app estava concedendo permissão a um fantasma.

É também por isso que só alguns eram atingidos. Se a sua cópia do GeekBye já morava em /Applications — porque você a arrastou para lá, ou porque ela chegou lá via atualização automática — não há quarentena, nem translocação, o caminho é estável, e tudo persiste perfeitamente. O bug era invisível para nós e para qualquer um que tivesse passado da primeira instalação, que é exatamente o tipo de bug que sobrevive por mais tempo.

A correção: dar ao app um lar de verdade

Como o problema inteiro é um caminho instável, a correção é levar o app para um estável. A v2.0.6 detecta quando o GeekBye está rodando translocado (ou simplesmente rodando fora de /Applications) e oferece um "Mover para Aplicativos" de um clique — usando a chamada de realocação do macOS que copia o pacote para /Applications e o reabre a partir de lá. A partir desse ponto o app tem uma identidade fixa: a permissão do microfone gruda, a gravação de tela gruda, e o GeekBye finalmente aparece em Ajustes do Sistema onde você esperaria.

O aviso é educado quanto a isso. Ele oferece Mover para Aplicativos, Agora não e Não perguntar novamente — e lembra a última escolha, para que o app nunca importune quem tem uma razão deliberada para rodá-lo de outro lugar. A decisão de se deve sequer exibir o aviso é isolada em funções pequenas e puras (esta build está translocada? está fora de /Applications? o usuário a silenciou?), para que a lógica seja testada com testes unitários sem precisar abrir uma build notarizada real num volume em quarentena real.

O mesmo lançamento também simplificou a própria experiência de permissões. O GeekBye costumava abrir uma janela de permissões personalizada, feita à mão — algumas centenas de linhas de interface tentando reproduzir algo que o sistema operacional já faz bem. A v2.0.6 a apagou e se apoiou no aviso de permissões nativo do macOS, respaldado por um banner discreto e não bloqueante que aparece só quando uma permissão necessária realmente está faltando. Menos código, e um comportamento que os usuários já reconhecem porque todo outro app de Mac funciona igual.

A parte de que mais me orgulho: provamos antes de acreditar

Teria sido fácil adivinhar a translocação e lançar uma correção. Em vez disso, o lançamento enviou primeiro um diagnóstico de inicialização: ao abrir, o GeekBye agora reporta o próprio caminho do executável e se está translocado, se está dentro de /Applications, e o estado atual das permissões de microfone e tela. Essa telemetria transformou uma teoria plausível numa confirmada — os dados de produção mostraram que as sessões afetadas estavam, de fato, rodando a partir de caminhos translocados fora de /Applications, exatamente como previsto.

Essa ordem importa. "O aviso aparece mas a permissão não gruda" tem várias explicações possíveis — um problema de assinatura, uma string de uso faltando, uma questão de entitlement, uma esquisitice do banco de dados do TCC. Descartamos as causas no nível da API (o caminho da requisição era comprovadamente correto), e então deixamos os dados do mundo real apontarem para a camada de identidade/caminho em vez de lançar uma correção esperançosa torcendo para que os tickets de suporte parassem.

Três coisas que esse bug ensina

1. Uma permissão que aparece mas não persiste é um problema de identidade, não de API. Se o código da requisição está correto e a permissão ainda assim some, pare de reescrever a requisição. Pergunte a qual caminho e identidade de código o sistema operacional está vinculando a permissão — e se essa identidade é estável entre aberturas.
2. Lance o diagnóstico junto com (ou antes da) correção. Alguns poucos campos — de onde estou rodando, qual é meu estado de permissão — transformaram um palpite fundamentado numa causa raiz verificada e nos disseram exatamente quais usuários estavam afetados. Instrumente a fronteira que você suspeita antes de aplicar o patch.
3. Os bugs que se escondem dos desenvolvedores são os que rodam no ambiente "errado". O nosso morava em /Applications em toda máquina de dev, então o bug era estruturalmente invisível para nós enquanto atingia os usuários de primeira viagem. Quando um relato não se reproduz, a primeira pergunta é o que é diferente em onde ele roda, não o usuário está enganado.

O GeekBye v2.0.6 lançou o aviso de realocação e o diagnóstico juntos. Para o arco de confiabilidade mais amplo em que isso se encaixa, veja o que de fato custa uma versão 2 (v2.0.0) e por que a gravação de tela captura o monitor errado (v2.0.10) — outro bug que só surgia num ambiente específico. Para o lançamento de pequenos detalhes ao lado, software tranquilo: a correção do piscar e o chip de modo de resposta (v2.0.3 + v2.0.5).