Capítulo 26 — Aplicativo Mobile

26.1 Objetivo do Capítulo

Este capítulo detalha o Aplicativo Mobile do Cidadão — o canal digital para dispositivos iOS e Android por meio do qual os cidadãos acessam os serviços públicos da plataforma com experiência adaptada a dispositivos móveis.

O aplicativo mobile não é uma versão reduzida do portal web. É o canal que explora as capacidades nativas do dispositivo — câmera, notificações push, biometria, armazenamento seguro — para oferecer jornadas que o navegador não proporciona com a mesma naturalidade, mantendo o mesmo contrato de backend do Portal Web.

26.2 Papel do Aplicativo Mobile na Plataforma

O aplicativo mobile coexiste com o Portal Web como canal complementar. Compartilha os mesmos contratos de API, os mesmos domínios de negócio e o mesmo design system — diferenciando-se pela experiência adaptada ao dispositivo.

Cidadão no dispositivo iOS ou Android
        │
Aplicativo Mobile (React Native)
        │
API Gateway
        │
Serviços de Domínio (Java / Spring Boot)
        │
IAM + GOV.BR + RabbitMQ + Data Lake + IA

O aplicativo concentra experiência e adaptações de dispositivo. Regras de negócio, autorização, persistência e processamento residem exclusivamente no backend.

26.3 Tecnologia e Arquitetura

26.3.1 Stack

O aplicativo é construído em React Native com TypeScript e NativeWind para estilização. A escolha permite: compartilhamento de lógica de interface e contratos de API com o Portal Web, suporte simultâneo a iOS e Android com uma base de código, e acesso controlado às APIs nativas do dispositivo quando necessário.

26.3.2 Design System Compartilhado

O aplicativo consome o design system compartilhado da plataforma, definido no pacote @brasfy/core. Tokens de design — cores, tipografia, espaçamento, ícones e componentes base — são centrais. A identidade visual do tenant (cores primárias, logomarca) é aplicada por injeção de tokens na inicialização.

26.3.3 Arquitetura de Navegação

A navegação segue o modelo de pilha com abas principais no nível raiz: Início, Serviços, Solicitações, Mensagens e Perfil. Jornadas mais profundas (detalhe de serviço, abertura de solicitação, visualização de documento) são empilhadas sobre as abas.

26.3.4 Gerenciamento de Estado

O estado de interface é local ao componente quando possível. Estado compartilhado entre telas é gerenciado de forma controlada. Estado de negócio é sempre consultado do backend — o aplicativo não armazena dados de domínio como fonte de verdade local.

26.4 Princípios do Aplicativo Mobile

1. Mesmos contratos do portal — o aplicativo consome as mesmas APIs REST que o Portal Web; nenhum endpoint exclusivo do mobile implementa lógica de negócio;
2. Adaptações de experiência, não de lógica — as diferenças entre mobile e web são de interface e de recursos de dispositivo; o comportamento de negócio é idêntico;
3. Primeiro o offline-aware — o aplicativo comunica claramente ao cidadão quando não há conexão e não apresenta dados desatualizados como se fossem atuais;
4. Permissões mínimas — o aplicativo solicita permissões de câmera, notificação e biometria apenas no momento em que são necessárias, com explicação contextual;
5. Segurança por padrão — tokens em armazenamento seguro do sistema operacional; sem dados sensíveis em logs locais; sem secrets no bundle;
6. Degradação graciosa — funcionalidades que dependem de recursos do dispositivo (câmera, biometria) têm alternativas quando o recurso não está disponível;
7. Versão com ciclo de vida — o backend suporta versões anteriores do aplicativo por período definido; cidadãos não são forçados a atualizar imediatamente.

26.5 Diferenciadores do Canal Mobile

O aplicativo mobile oferece, além das jornadas disponíveis no portal:

26.6 Estrutura de Jornadas

O aplicativo cobre as mesmas áreas funcionais do portal, com navegação adaptada ao padrão mobile:

┌────────────────────────────────────────────────────────────┐
│  ABA INÍCIO                                                 │
│  Destaques, serviços frequentes, status de solicitações    │
├────────────────────────────────────────────────────────────┤
│  ABA SERVIÇOS                                               │
│  Catálogo, busca, categorias, detalhes, assistente IA      │
├────────────────────────────────────────────────────────────┤
│  ABA SOLICITAÇÕES                                           │
│  Abertura, acompanhamento, complementação, documentos      │
├────────────────────────────────────────────────────────────┤
│  ABA MENSAGENS                                              │
│  Central de mensagens, conversas, notificações             │
├────────────────────────────────────────────────────────────┤
│  ABA PERFIL                                                 │
│  Dados pessoais, documentos, agendamentos, ouvidoria,      │
│  preferências, privacidade, empresas, ajuda                │
└────────────────────────────────────────────────────────────┘

26.7 Autenticação

26.7.1 Login por IAM Próprio

O cidadão autentica com e-mail e senha. MFA configurável pelo tenant. Política de senha gerenciada pelo IAM.

26.7.2 Login via GOV.BR

O aplicativo inicia o fluxo OpenID Connect com Authorization Code + PKCE, abrindo o navegador nativo do dispositivo (In-App Browser Target configurado para evitar vulnerabilidades de WebView customizada). O retorno é recebido via deep link registrado. O backend valida a transação completa.

Cidadão toca "Entrar com GOV.BR"
    │
Aplicativo prepara state e code_challenge (PKCE)
    │
Abre navegador nativo com Authorization Request
    │
Cidadão autentica no GOV.BR
    │
GOV.BR redireciona com code para o deep link do app
    │
App recebe code via Universal Link / App Link
    │
App envia code + code_verifier ao backend
    │
Backend valida e retorna token de sessão da plataforma
    │
App armazena token em armazenamento seguro do SO

26.7.3 Biometria Local

A biometria (Face ID, Touch ID, impressão digital) é usada para desbloquear o acesso ao aplicativo depois que o cidadão já autenticou. Ela não substitui a autenticação com o backend — é uma conveniência local que dispensa redigitar a senha em usos subsequentes. O token de sessão permanece no armazenamento seguro e é reenviado ao backend em toda requisição.

26.7.4 Armazenamento Seguro

Tokens de sessão são armazenados em: Keychain (iOS) e EncryptedSharedPreferences ou Android Keystore (Android). Nenhum token em AsyncStorage sem criptografia. O token é limpo no logout e quando a sessão expira.

26.8 Notificações Push

26.8.1 Infraestrutura

Notificações push são enviadas via: APNS (Apple Push Notification Service) para iOS e FCM (Firebase Cloud Messaging) para Android. O Communication Service aciona o adaptador correspondente ao enviar uma notificação destinada ao canal PUSH.

26.8.2 Conteúdo

Notificações push apresentam: título, corpo resumido, ícone do órgão e, quando aplicável, link deep para a tela correspondente. Dados sensíveis não aparecem no conteúdo da notificação — a notificação informa que há uma atualização; o cidadão acessa o detalhe dentro do aplicativo após autenticação.

26.8.3 Permissão

A solicitação de permissão de notificação é feita de forma contextual — após o cidadão completar o cadastro ou ao acessar uma jornada que claramente se beneficia de notificações. Uma explicação do benefício precede a solicitação do sistema operacional.

26.8.4 Gestão de Tokens de Push

O token de push do dispositivo é registrado no Communication Service vinculado ao cidadão. Quando o token expira ou o aplicativo é desinstalado, o sistema operacional retorna erro de entrega, e o Communication Service marca o token como inativo. Nenhuma notificação é reentregue indefinidamente a token inativo.

26.9 Captura de Documentos por Câmera

26.9.1 Scanner de Documentos

O aplicativo oferece captura de documentos por câmera com correção de perspectiva. O cidadão aponta a câmera para o documento; o aplicativo detecta as bordas, aplica correção de perspectiva e apresenta prévia para confirmação antes de enviar.

26.9.2 Fluxo

Cidadão acessa "Enviar documento" em uma solicitação
    │
Seleciona "Capturar com câmera" (ou "Upload de arquivo")
    │
Aplicativo solicita permissão de câmera (se não concedida)
    │
Scanner ativo com guia visual de posicionamento
    │
Documento detectado → prévia com perspectiva corrigida
    │
Cidadão confirma ou refaz
    │
Imagem enviada ao Document Service via upload
    │
Pipeline de quarentena e processamento assíncrono iniciado
    │
Status de processamento exibido ao cidadão

26.9.3 Qualidade Mínima

O scanner informa quando a iluminação é insuficiente ou o documento está fora de foco. O cidadão pode tentar novamente antes de confirmar. A validação de qualidade técnica do arquivo (formato, integridade, conteúdo) ocorre no backend.

26.9.4 Privacidade

A imagem capturada não é armazenada permanentemente no dispositivo após o envio. O acesso à galeria de fotos do dispositivo é solicitado separadamente, somente quando o cidadão opta por "Upload de arquivo" a partir da galeria.

26.10 Jornada: Abertura de Solicitação no Mobile

O fluxo é equivalente ao do portal web, com adaptações de experiência:

• formulários multipágina são apresentados como etapas sequenciais com indicador de progresso;
• campos de data e seleção usam pickers nativos do sistema operacional;
• upload de documentos oferece as opções: capturar com câmera, selecionar da galeria, ou escolher documento já enviado;
• o teclado virtual é gerenciado para não ocultar o campo em edição;
• ao confirmar a solicitação, o aplicativo solicita ao cidadão que permita notificações push (se ainda não autorizadas) para acompanhar o protocolo.

26.11 Jornada: Acompanhamento de Protocolo

Lista de solicitações com situação atual visível sem precisar entrar no detalhe. O Pull-to-Refresh atualiza a lista consultando o backend. O detalhe do protocolo exibe histórico de situações com datas, documentos vinculados e ações disponíveis.

Quando há uma complementação pendente, o cidadão recebe notificação push e, ao abrir o aplicativo, é direcionado diretamente à tela de complementação via deep link.

26.12 Jornada: Documentos no Mobile

O cidadão acessa a lista de seus documentos, captura novos via câmera ou galeria, substitui versões vencidas e acompanha o status de processamento. Documentos com validade próxima ao vencimento aparecem destacados.

A reutilização de documentos em novas solicitações — sem reenvio — funciona igualmente no mobile.

26.13 Jornada: Agendamentos no Mobile

Calendário com disponibilidade apresentado em formato nativo mobile. Seleção de data e horário com pickers. Confirmação com protocolo. Lembretes automáticos via push notification nas configurações do tenant.

26.14 Assistente de IA no Mobile

O assistente no mobile suporta texto e entrada por áudio:

26.14.1 Entrada por Texto

Interface de chat com streaming de resposta — o texto aparece progressivamente enquanto é gerado, com efeito visual animado durante o processamento. Respostas são formatadas com negrito, listas e links de navegação para telas do aplicativo.

26.14.2 Entrada por Áudio

O cidadão ativa o microfone e fala sua pergunta. O áudio é transcrito localmente quando possível, ou via serviço de speech-to-text configurado. O texto transcrito é enviado ao backend do assistente. A transcrição não é armazenada após o processamento da sessão. A resposta é textual; o dispositivo pode lê-la em voz alta via acessibilidade nativa do sistema operacional.

26.14.3 Transferência para Humano

Quando o assistente transfere para atendimento humano, o cidadão recebe confirmação de que um atendente retornará pelo canal preferido configurado. O HandoffContext completo é preservado no CRM.

26.15 Deep Links

O aplicativo processa deep links para jornadas específicas:

• plataforma://protocolo/2026001234 → tela de detalhe do protocolo;
• plataforma://agendamento/abc-uuid → tela de detalhe do agendamento;
• plataforma://solicitacao/new?serviceId=svc-uuid → início de solicitação para um serviço específico;
• plataforma://mensagens → central de mensagens.

Deep links são validados antes de processar: esquema, host, path e parâmetros. Parâmetros de deep link são tratados como entrada não confiável — nunca utilizados como token de autenticação ou como chave de autorização.

26.16 Segurança no Aplicativo Mobile

26.16.1 Armazenamento Seguro

Tokens de autenticação: Keychain (iOS), EncryptedSharedPreferences / Keystore (Android). Sem dados sensíveis em AsyncStorage comum ou em logs locais do dispositivo.

26.16.2 Secrets no Bundle

Nenhum secret de backend é incorporado ao bundle do aplicativo. Qualquer valor presente no bundle deve ser considerado potencialmente extraível por engenharia reversa. Credenciais de API, chaves de integração e tokens de serviço residem exclusivamente no backend.

26.16.3 Certificate Validation

O aplicativo não desabilita validação de certificados TLS. Certificate pinning é avaliado para a comunicação com as APIs críticas da plataforma, considerando o impacto operacional de rotação de certificados.

26.16.4 WebViews

WebViews são utilizadas de forma restrita: conteúdo externo de origens não confiáveis não executa JavaScript com bridge nativa. Para o fluxo GOV.BR, o navegador nativo do sistema operacional é preferido ao WebView customizado.

26.16.5 Permissões do Dispositivo

O aplicativo solicita apenas: câmera (captura de documentos), notificações push, biometria (autenticação local). Nenhuma permissão de localização, contatos, microfone para fins não funcionais ou acesso irrestrito à galeria.

26.16.6 Screenshots

Telas sensíveis — como a tela de exibição de token de sessão ou dados de autenticação — desabilitam capturas de tela quando o sistema operacional permite.

26.16.7 Logout

O logout limpa: token de sessão do armazenamento seguro, cache local de dados sensíveis, estado de navegação que possa revelar informações. O backend revoga a sessão ativa. Logout local sem revogação no backend não é aceito como logout seguro.

26.16.8 OWASP MASVS

O aplicativo considera as diretrizes do OWASP Mobile Application Security Verification Standard (MASVS) como referência para controles de segurança mobile, incluindo: armazenamento de dados, criptografia, autenticação, comunicação em rede, interação com a plataforma e qualidade de código.

26.17 Acessibilidade no Mobile

O aplicativo observa as diretrizes de acessibilidade das plataformas nativas:

• iOS: suporte ao VoiceOver; rótulos acessíveis em todos os elementos interativos; contraste WCAG 2.1 AA; suporte a Dynamic Type;
• Android: suporte ao TalkBack; contentDescription em elementos visuais; contraste adequado; suporte a fontes grandes do sistema.

Fluxos completos de autenticação, abertura de solicitação e consulta de protocolo são testados com leitores de tela antes de cada release.

26.18 Performance no Mobile

26.18.1 Inicialização

O tempo de inicialização fria do aplicativo é monitorado. Telas de carregamento informativas são exibidas enquanto dados são consultados do backend — o aplicativo não apresenta conteúdo desatualizado de cache local como se fosse o estado atual.

26.18.2 Otimizações

• listas longas utilizam virtualização (FlatList com otimizações de chave e extractor);
• imagens são carregadas com lazy loading e dimensionadas para o dispositivo;
• navegação entre telas utiliza animações nativas para não degradar a experiência;
• requisições de rede utilizam timeout configurado; respostas lentas exibem indicador de carregamento.

26.18.3 Offline

O aplicativo informa claramente quando não há conexão. Não apresenta dados de cache local como se fossem atuais. Ações que exigem conexão (abrir solicitação, enviar documento) são bloqueadas com mensagem explicativa quando offline.

26.19 Distribuição e Atualizações

26.19.1 Lojas

O aplicativo é distribuído via App Store (iOS) e Google Play Store (Android). O processo de publicação inclui assinatura de código, verificação de provenance e conformidade com as políticas das lojas.

26.19.2 Compatibilidade de Versão

O backend mantém compatibilidade com versões anteriores do aplicativo por período definido. Cidadãos não são forçados a atualizar imediatamente. APIs consumidas pelo mobile seguem a política de depreciação com Sunset header e período de suporte.

A versão do aplicativo é enviada ao backend via header (X-Client-Version) para observabilidade e gestão de compatibilidade — nunca como mecanismo de autorização.

26.19.3 Atualizações Críticas

Para correções de segurança críticas, o aplicativo pode exibir aviso de atualização obrigatória. O backend também pode rejeitar versões abaixo de um mínimo configurado com resposta específica (426 Upgrade Required) orientando o cidadão à atualização.

26.19.4 Over-the-Air (OTA) Updates

OTA updates (atualizações de código sem novo release na loja) são avaliadas para o contexto da plataforma. Quando adotadas, estão restritas a atualizações de lógica de interface — nunca a mudanças de permissões, de fluxo de autenticação ou de políticas de segurança. A adoção é registrada como ADR.

26.20 Telemetria do Aplicativo Mobile

26.20.1 Métricas de Experiência

Tempo de inicialização por versão e dispositivo; latência de navegação entre telas; erros de runtime; falhas de requisição (sem payload sensível); versão do aplicativo por tipo de dispositivo.

26.20.2 Crash Reporting

Crashes são capturados e reportados com: tipo, stack trace (sanitizado), versão do app, versão do SO, modelo de dispositivo e identificador técnico de sessão. Nenhum dado pessoal do cidadão é incluído no report.

26.20.3 Dados Pessoais na Telemetria

A telemetria não coleta: conteúdo digitado em formulários, dados pessoais do cidadão, conteúdo de notificações, fotos ou documentos capturados. O identificador de sessão técnico é rotacionado conforme a política de privacidade.

26.21 Rastreabilidade com o Anexo III

26.22 Benefícios do Canal Mobile

• canal complementar ao web com experiência adaptada ao dispositivo;
• notificações push mantêm o cidadão informado sem precisar entrar no portal;
• captura de documentos por câmera reduz atrito no envio de documentos exigidos;
• biometria local agiliza o acesso sem comprometer a segurança do backend;
• deep links para jornadas específicas a partir de notificações;
• mesmo contrato de API do portal — sem duplicação de regras de negócio;
• suporte a iOS e Android com uma única base de código.

26.23 Riscos e Mitigações

26.24 Decisões Arquiteturais

26.25 Considerações Finais

O aplicativo mobile é o canal que acompanha o cidadão no dia a dia. A notificação push que informa a atualização de um protocolo, a câmera que capta um documento sem precisar usar um scanner, a biometria que abre o aplicativo com um toque — esses são os elementos que diferenciam a experiência mobile e determinam se o cidadão vai usar o aplicativo continuamente ou apenas eventualmente.

A solidez arquitetural do aplicativo — mesmo contrato de API, sem regras no cliente, segurança por padrão, compatibilidade preservada — garante que essa experiência superior não venha à custa de segurança ou de inconsistência com os demais canais.

O Capítulo 27 detalha o Painel do Gestor.

26.26 Controle de Versão

26.27 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 1 — itens 1.1, 1.2, 1.6, 1.10 e 1.11 cobertos conforme seção 26.21.
• [ANX-IV] — Capacidades técnicas de canal mobile nativo, notificações push, captura de documentos por câmera, biometria e personalização por tenant.
• [ANX-V] Item 2.2 — Acessibilidade digital: suporte a VoiceOver (iOS) e TalkBack (Android); Dynamic Type; contraste WCAG 2.1 AA; testes com leitores de tela antes de cada release.
• [ANX-V] Item 2.3 — Proteção do usuário: OWASP MASVS como referência; armazenamento seguro nativo; sem secrets no bundle; autorização sempre server-side.
• [PNR] — Aplicativo mobile como canal complementar ao portal web, integrado às capacidades de CRM, BPM, ECM/GED, IA e comunicação da plataforma.
• [EDITAL] — Edital CP001/2026: canal mobile do cidadão com jornadas completas de autoatendimento, notificações push e captura de documentos por câmera.