Permissoes no app React Native: camera, notificacoes e arquivos sem atrito

Permissao mal tratada no app costuma gerar um efeito curioso: a funcionalidade existe, mas a operacao real falha nos pontos em que o negocio mais sente. A camera nao abre, a galeria devolve acesso parcial, a notificacao nao chega em Android 13, o texto do iOS fica generico demais para a App Store, o fluxo pede tudo cedo demais e a pessoa fecha a porta antes de entender o valor.

Em app corporativo, esse problema encosta direto em upload, push, biometria, release, review de loja e suporte. O desafio nao e apenas chamar uma API de permissao. E alinhar configuracao nativa, momento certo do prompt, explicacao clara e degradacao elegante quando a resposta for nao.

Este artigo organiza um caminho pratico para React Native com Expo: como pensar permissoes de camera, notificacoes e arquivos sem criar atrito desnecessario nem surpresa no release.

1. Permissao e uma decisao de produto, nao so de codigo

A documentacao da Expo abre o tema de forma objetiva: quando um app precisa acessar informacao sensivel do dispositivo, como localizacao ou contatos, ele deve pedir permissao antes. O ponto importante e que isso nao e so um detalhe tecnico. Se voce nao configurar ou explicar corretamente as permissoes nativas, o app pode ser rejeitado ou removido das lojas.

Traduzindo para o dia a dia: permissao nao deveria entrar no backlog apenas como "fazer funcionar camera". Ela precisa responder pelo menos tres perguntas:

• qual fluxo de negocio realmente depende daquele acesso;
• em que momento a pessoa entende por que aquilo faz sentido;
• como o app continua utilizavel se a resposta for negativa.

2. Em Expo, permissao tem parte de build e parte de runtime

O guia oficial de permissions da Expo deixa isso bem claro: em standalone apps e development builds, permissoes exigem configuracao nativa em tempo de build antes de poderem ser pedidas pelo JavaScript em runtime. Esse ajuste nao e necessario quando voce testa no Expo Go, mas passa a ser obrigatorio quando o app vira binario real.

Esse detalhe explica varios bugs de homologacao. Em dev parece tudo simples, mas o release real precisa de manifest, Info.plist e configuracao de plugin alinhados ao que o app vai pedir depois.

No Android, a Expo documenta os campos android.permissions e android.blockedPermissions no app config. Ela tambem explica que muitas permissoes entram automaticamente pelas bibliotecas, e que blockedPermissions existe para remover permissoes puxadas por manifests de dependencias quando elas nao fazem sentido no seu produto.

Isso e valioso para evitar excesso. App corporativo pequeno nao deveria levar permissao nativa sobrando para producao so porque uma dependencia trouxe algo por padrao.

3. O prompt nao deve aparecer cedo demais

A recomendacao oficial do Android e direta: o dialogo de permissao diz o que o app quer, mas nao explica por que. Por isso, e uma boa pratica explicar antes do requestPermissions() por que aquele acesso sera usado. O mesmo documento diz que as pessoas ficam mais confortaveis quando entendem se a permissao sustenta um recurso central ou algo acessorio.

Em app corporativo, isso derruba um erro comum: pedir camera, notificacao e arquivos na abertura da home, antes de a pessoa tentar qualquer acao. O sistema mostra um pedido valido tecnicamente, mas sem contexto. A resposta natural muitas vezes vira negacao.

O fluxo mais saudavel costuma ser:

• mostrar a funcionalidade primeiro;
• explicar o ganho real em uma tela ou estado educativo curto;
• pedir a permissao so quando a pessoa tenta usar aquele recurso.

Esse principio conversa diretamente com o artigo de formularios no app: o pedido entra no momento da acao, nao como barreira arbitraria no inicio da jornada.

4. Android pede contexto e, em alguns casos, uma UI educativa

O mesmo guia oficial do Android recomenda verificar primeiro se a permissao ja foi concedida. Se nao foi, e se o sistema indicar shouldShowRequestPermissionRationale(), a orientacao e mostrar uma UI educativa explicando por que aquele recurso precisa do acesso solicitado.

Esse ponto e importante porque o pedido de permissao nao deveria ser um loop cego. Se a pessoa ja recusou uma vez, o app precisa reagir com mais maturidade:

• explicar o impacto da recusa no fluxo;
• oferecer uma alternativa, quando existir;
• evitar insistencia agressiva que pareca chantagem de UX.

Na pratica, "libere a permissao para continuar" quase sempre comunica pior do que "para anexar uma foto da vistoria, o app precisa abrir sua camera".

5. Camera e galeria pedem contratos diferentes

A documentacao do expo-image-picker separa bem duas coisas que muita equipe mistura: requestCameraPermissionsAsync() pede acesso a camera, enquanto requestMediaLibraryPermissionsAsync() pede acesso a fotos da biblioteca. Sao fluxos diferentes, e o app nao precisa pedir ambos ao mesmo tempo se a tela vai usar apenas um deles.

O proprio metodo de media library aceita o argumento writeOnly, permitindo distinguir entre gravar e ler+gravar. Isso ajuda a reduzir pedido excessivo quando o caso de uso e mais restrito.

Outro detalhe valioso da documentacao: o assetId pode vir null quando o ID nao esta disponivel ou quando a pessoa concedeu acesso limitado a biblioteca. Isso muda decisao de produto e de persistencia. Se o fluxo depende de identificar ou reconciliar um asset depois, o app precisa tolerar esse cenario, e nao assumir que a biblioteca sempre devolvera o mesmo nivel de acesso.

Esse tema se conecta direto com upload de fotos e anexos e com persistencia local.

6. Notificacao mudou de patamar no Android 13

A documentacao do expo-notifications registra uma mudanca importante: no Android 13, a pessoa usuaria precisa fazer opt-in para receber notificacoes, e o prompt so aparece depois que pelo menos um notification channel e criado. O mesmo trecho orienta chamar setNotificationChannelAsync() antes de getDevicePushTokenAsync() ou getExpoPushTokenAsync().

Do lado do Android oficial, a regra tambem e clara: em novas instalacoes em Android 13 ou superior, as notificacoes ficam desligadas por padrao. Se o app targeta Android 13+, ele ganha controle sobre quando mostrar o dialogo e deve aproveitar esse momento para explicar por que precisa da permissao.

Ou seja: notificacao deixou de ser algo que voce configura "em algum ponto do boot" e esquece. Agora ela precisa de orquestracao melhor:

• criar canal antes de tentar obter token;
• pedir permissao no momento em que o valor fica claro;
• nao assumir que toda pessoa instalada aceita push por padrao.

Isso conversa com notificacoes push no app corporativo e com deep links e navegacao.

7. No iOS, texto ruim de permissao vira risco de review

Na secao de iOS do guia de permissions, a Expo explica que a Apple exige uma explicacao de uso para recursos como camera ou fotos. A documentacao tambem alerta que as mensagens padrao fornecidas por bibliotecas normalmente precisam ser adaptadas ao caso especifico do app para aumentar a chance de aceite na App Store.

Esse ponto merece atencao porque uma string generica demais enfraquece tanto a confianca da pessoa usuaria quanto a coerencia da revisao. Nao basta dizer "o app quer acessar a camera". O texto precisa refletir o uso real, por exemplo captura de evidencias, anexos de atendimento ou leitura de documento operacional.

O proprio guia mostra que essas mensagens entram em ios.infoPlist ou em propriedades do config plugin da biblioteca. E deixa outro recado importante: mudancas em Info.plist nao podem ser entregues por OTA; elas so chegam com um novo binario nativo.

Isso conecta o tema de permissoes com EAS Update e com app review, privacidade e metadata.

8. Permissao e tambem uma decisao de release

Quando a permissao entra em manifest, plugin ou Info.plist, ela deixa de ser apenas um detalhe visual. Isso afeta release, review e compatibilidade entre builds. O guia da Expo lembra que changes de Info.plist nao sobem por OTA, e o artigo de EAS Update reforca o mesmo principio: mudanca de permissao pede novo binario.

Na pratica, sempre vale revisar estas perguntas antes de publicar:

• alguma permissao nova entrou por dependencia recente?
• alguma permissao pode ser removida com blockedPermissions?
• as mensagens de iOS correspondem ao uso real do produto?
• o Android 13 foi testado no momento real do prompt de notificacao?

Esse checklist evita o classico caso de "funciona no build antigo, quebrou no release novo, e ninguem percebeu que a diferenca era a permissao".

9. O app precisa continuar util quando a resposta e nao

Outro aprendizado importante das docs e dos sistemas operacionais: negar permissao faz parte do fluxo normal. A pessoa pode recusar camera, recusar notificacao ou liberar apenas acesso limitado a fotos. O app maduro nao trata isso como excecao vergonhosa. Ele explica o limite, oferece alternativa e segue.

Exemplos praticos:

• sem camera, permitir anexo por arquivo quando fizer sentido;
• sem notificacao, deixar pendencias visiveis na home ou em inbox interna;
• com biblioteca limitada, evitar assumir que todos os assets futuros serao identificaveis do mesmo jeito.

Esse cuidado reduz suporte, melhora conversao de fluxo e deixa o produto menos dependente de uma resposta unica do sistema.

10. Uma estrategia simples para times pequenos

Em vez de espalhar pedidos de permissao aleatoriamente, um caminho maduro costuma ser:

1. mapear cada permissao para uma funcionalidade concreta;
2. configurar manifest, plugins e Info.plist antes do build real;
3. pedir o acesso apenas quando a pessoa tentar usar o recurso;
4. explicar antes do prompt, e nao depois da recusa;
5. tratar recusa e acesso limitado como cenario de produto;
6. revalidar a loja e o release sempre que uma permissao nova entrar.

Isso nao exige uma arquitetura gigantesca. Exige intencao.

11. Onde esse tema encosta no restante da trilha

Permissao boa nao vive isolada. Ela conversa com varios pontos que ja amarramos no portal:

• upload e anexos, porque camera e biblioteca precisam de UX e persistencia coerentes;
• push, porque Android 13 mudou o comportamento esperado;
• biometria e reautenticacao, porque acao sensivel e acesso ao dispositivo pedem fronteiras claras;
• review e privacidade, porque permissao mal descrita pesa na leitura da loja;
• beta real, porque esse tipo de detalhe precisa ser exercitado em aparelho e build de verdade.

12. Checklist rapido para permissoes mais saudaveis

1. Nao pedir tudo na abertura do app.
2. Explicar o valor da permissao antes do prompt.
3. Separar camera, galeria e notificacao em fluxos distintos.
4. Revisar se bibliotecas adicionaram permissoes que o produto nao usa.
5. Customizar mensagens de iOS para o caso real do app.
6. Lembrar que mudanca de permissao nao sobe por OTA.
7. Testar Android 13 com o fluxo real de opt-in para notificacoes.
8. Garantir alternativa ou degradacao elegante quando houver recusa.

13. Quando vale um diagnostico tecnico

Se hoje o app pede permissao cedo demais, falha no release real, depende de tentativa e erro para passar na loja ou mistura upload, push e notificacao sem criterio unico, provavelmente o problema nao esta em uma API isolada. Falta desenho de fluxo e governanca de release. Nessa hora, um diagnostico tecnico ajuda a alinhar UX, configuracao nativa, build, review e rotina de validacao antes que o mobile cresca com atrito escondido.

Permissao bem resolvida nao faz o app parecer mais complexo. Faz o app parecer confiavel.

Referencias editoriais: Expo - Permissions, Expo - ImagePicker, Expo - Notifications, Android Developers - Request runtime permissions e Android Developers - Notification runtime permission.