Busque em todas as páginas da documentação
Exemplos de ADR mobile para decisões que todo líder do Expo enfrenta: OTA vs loja, módulo nativo customizado vs Expo SDK, e como escrever registros que sobrevivem a upgrades do SDK 57 → 58. ADRs são curtos, datados e linkados - não ensaios de wiki que ninguém lê.
Esqueleto de ADR de referência rápida - copie para
docs/adr/ou.adr/no repositório.
# ADR-NNNN: <Título>
- **Status:** proposto | aceito | substituído pelo ADR-XXXX
- **Data:** AAAA-MM-DD
- **Decisores:** @mobile-lead, @platform
- **Relógio de release:** OTA | binário da loja | backend | nenhum
## Contexto
Qual problema e restrições? (tamanho da equipe, brownfield, conformidade)
## Decisão
Nós iremos <escolha> porque <um parágrafo>.
## Consequências
### Positivas
- …
### Negativas
- …
### Rollback / reversão
- OTA: `eas update --roll-back --channel <ch>`
- Loja: envie o binário <versão>; feature flag <nome> desativada
## Alternativas consideradas
| Opção | Rejeitada porque |
| --- | --- |
| … | … |# Layout do repositório
docs/adr/
0001-ota-vs-store-for-checkout-copy.md
0002-expo-camera-vs-custom-scanner.md
README.md # índice com tabela de statusQuando usar isso:
# ADR-0007: Copiar erro de checkout via OTA
- **Status:** aceito
- **Data:** 2026-03-12
- **Decisores:** @mobile-lead, @pm-checkout
- **Relógio de release:** OTA (`production` channel)
## Contexto
O suporte precisa de mensagens mais claras de recusa de cartão antes da campanha de fim de semana.
Nenhuma mudança de API, nativa ou `runtimeVersion`. Binário ao vivo: `2.4.1` (runtimeVersion `2.4.0`).
## Decisão
Enviar a mudança de cópia com `eas update` para `production` após QA do canal de staging.
Não cortar release da loja `2.4.2` para mudança apenas de texto.
## Consequências
### Positivas
- Envio no mesmo dia; rollback em minutos
- Evita a fila de revisão da loja durante a campanha
### Negativas
- Usuários em builds antigos sideloaded fora do canal podem não receber a atualização
### Rollback
`eas update --roll-back --channel production`
ID da atualização conhecida e boa: registrado no ticket de release MOB-4821
## Alternativas consideradas
| Opção | Rejeitada porque |
| --- | --- |
| Submissão para loja 2.4.2 | 2–5 dias de revisão para benefício nativo zero |
| Cópia apenas via backend | Checkout offline ainda precisa de strings locais |expo-camera vs módulo Vision customizado# ADR-0008: Scan de código de barras - expo-camera vs módulo Vision customizado
- **Status:** aceito
- **Data:** 2026-04-02
- **Decisores:** @mobile-lead, @android-lead, @ios-lead
- **Relógio de release:** binário da loja (nova dependência nativa)
## Contexto
O aplicativo do armazém precisa de scan Code 128 a 30 fps em Android de gama média.
A API de código de barras do `expo-camera` atende ao MVP; um wrapper ML Kit customizado promete 2× velocidade.
## Decisão
Usar o scan de código de barras `CameraView` do **expo-camera** para a v1.
Revisitar módulo customizado apenas se as métricas de campo mostrarem >5% de falha de scan em classe Pixel 6a.
## Consequências
### Positivas
- Caminho de upgrade do plugin de configuração + Expo SDK mantido pelo Expo
- Um módulo Swift/Kotlin a menos para juniores manterem
### Negativas
- Pode não corresponder à latência de hardware de scanner dedicado
- Ainda requer reconstrução do **dev client** - não pode ser OTA como adição nativa
### Rollback
Feature flag `warehouse_scan_v1` desativada; o fluxo de entrada manual anterior permanece
## Alternativas consideradas
| Opção | Rejeitada porque |
| --- | --- |
| TurboModule customizado + ML Kit | 2 meses-engenheiro de manutenção; nenhum dado de campo ainda |
| WebView + scan do navegador | Ruim offline; risco de política de WebView da loja |
| Scanner RN de terceiros (não mantido) | Último commit 18 meses atrás; RN 0.86 não testado |# ADR-0009: Push - Expo Notifications vs OneSignal SDK
- **Status:** aceito
- **Data:** 2026-05-18
- **Decisores:** @mobile-lead, @growth
- **Relógio de release:** binário da loja se mudar mais tarde
## Contexto
Growth quer rich push A/B; engenharia quer superfície nativa mínima.
## Decisão
**expo-notifications** + ferramentas de campanha do lado do servidor para v1.
OneSignal avaliado - adiar até que o marketing precise de IAM in-app além do escopo do produto.
## Consequências
### Positivas
- Alinha-se com credenciais EAS e fluxo de token push do Expo
- Binário nativo menor vs SDK duplo
### Negativas
- Segmentação avançada vive em nosso backend, não na UI do fornecedor
### Rollback
Permanecer no expo-notifications; nenhum SDK de fornecedor para remover
## Alternativas consideradas
| Opção | Rejeitada porque |
| --- | --- |
| OneSignal RN SDK | Dependência nativa extra + fiação FCM/APNs duplicada |
| Apenas Firebase (sem wrapper Expo) | Perde DX push unificado do Expo para fluxo gerenciado |# Índice de ADR
| ID | Título | Status | Clock |
| --- | --- | --- | --- |
| 0007 | Copiar checkout OTA | aceito | OTA |
| 0008 | Scan expo-camera | aceito | loja |
| 0009 | expo-notifications | aceito | loja |
| 0010 | Expo Router (greenfield) | aceito | - |Link as escolhas arquiteturais para os documentos ranqueados existentes:
Registre apenas a substituição específica da equipe - não duplique páginas ranqueadas inteiras.
| Situação | ADR? |
|---|---|
| Cor do botão OTA | Não - comentário de ticket é suficiente |
| Primeira OTA para o canal de produção | Sim - estabelece ritual de rollback |
| Novo módulo nativo | Sim - proprietário da manutenção é necessário |
| Expo Router em novo app | Sim - linka ADR ranqueado + escolha de template |
| Zustand vs Context para uma tela | Não - reverte rapidamente |
| Estratégia de upgrade SDK 57 → 58 | Sim - substitui ADRs de SDK anteriores |
ADR sem linha de rollback - A decisão aceitável se torna irreversível em incidentes. Correção: Cada ADR aceito nomeia o rollback OTA ou o pin da versão da loja.
Editar ADRs antigos no local - O histórico do Git mente. Correção: Status: substituído pelo ADR-0012 e novo arquivo.
"Decidimos no Slack" - O onboarding repete o debate. Correção: Link da thread do Slack no contexto do ADR; a decisão vive no repositório.
Ignorar runtimeVersion - O ADR diz OTA mas a incompatibilidade do binário quebra os usuários. Correção: Mandar linha runtimeVersion no Contexto.
ADR nativo sem proprietário - O módulo apodrece quando o autor sai. Correção: Nomeado @ios-lead / @android-lead nos Decisores.
| Formato | Use Quando | Não Use Quando |
|---|---|---|
Markdown em docs/adr/ | Padrão para equipes RN | A organização exige ferramentas de ADR (ex: Log4brains) |
| Template Nygard (Contexto/Decisão/Consequências) | Arquitetura entre equipes | Precisa de campos específicos de relógio mobile - estenda o template |
| RFC com período de comentários | Organização grande, muitos stakeholders | Equipe de dois pizzas - overhead mata a velocidade |
| Apenas Wiki | Nunca para decisões | ADRs do repositório são versionados com o código |
Uma a duas páginas. Se for mais longo, divida em ADR (decisão) + cookbook (como fazer). Link Trade-offs Nativo vs JavaScript para profundidade de framework.
Líder técnico + um especialista afetado (iOS, Android, backend). Produto assina ADRs sensíveis à política (IAP, UGC, saúde).
Use IDs monotônicos (0008) - datas escorregam; IDs permanecem ordenáveis. Tabela de índice mostra o status em um piscar de olhos.
Não. ADRs documentam por que você aceitou uma dependência nativa; CI ainda bloqueia instalações enviesadas.
architecture-design contém frameworks de decisão ranqueados. ADRs de tech-leadership contêm a escolha registrada da sua equipe e exceções.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0, e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026