Noções Básicas de Liderança Técnica em Mobile

Equilibrando velocidade de entrega com risco de avaliação da loja em equipes do Expo SDK 57. Líderes técnicos de mobile são donos do mapa do relógio de lançamento - quando OTA é suficiente, quando um build da loja é obrigatório e quando as datas do produto devem ceder à política da Apple ou Google.

Receita

Cartão de líder para referência rápida - cole no planejamento de sprint ou na retrospectiva de lançamento.

Classificação da alteração (cada ticket):
  [ ] Apenas JS, mesmo runtimeVersion     → Candidato a OTA
  [ ] Módulo nativo / plugin / permissão → eas build necessário
  [ ] Política da loja (pagamentos, UGC, saúde) → buffer legal + de avaliação
  [ ] Alteração de contrato de backend            → coordenar Clock C primeiro
 
Regras de velocidade:
  - PRs < 400 linhas, quando possível - revisar no mesmo dia
  - PRs de UI incluem captura de tela ou gravação iOS + Android
  - Nenhum envio para a loja na sexta-feira sem proprietário de rollback na segunda-feira
  - Uma fila de hotfix de incidente documentada em CONTRIBUTING.md

# Antes de prometer "entrega amanhã"
npx expo-doctor
eas build:list --limit 3          # idade do último binário + runtimeVersion
eas channel:list                  # canal de produção ↔ runtimeVersion
git diff main -- package.json app.config.ts eas.json

Quando usar isto:

• Você é o tomador de decisão padrão sobre o caminho de lançamento (OTA vs loja) e a taxa de transferência de avaliações.
• O produto pede uma data antes que a engenharia classifique o impacto nativo.
• A taxa de falhas ou rejeições na loja está aumentando enquanto a velocidade de PR permanece alta.
• Integrando um novo líder de esquadrão em um aplicativo EAS + Expo Router existente.

Exemplo de Trabalho

Planejamento de sprint - classifique o backlog

Documente a tabela no ticket do sprint ou nas notas de lançamento - "vamos enviar via OTA" sem classificação é como as equipes enviam emparelhamentos de runtimeVersion quebrados.

Árvore de decisão de lançamento

Precisa enviar uma correção?
  │
  ├─ Toca em ios/, android/, plugins de app.config, dependências nativas?
  │    └─ SIM → eas build + submit (Clock A). OTA não pode ajudar.
  │
  ├─ Apenas JS/TS/assets E runtimeVersion inalterado no binário ativo?
  │    └─ SIM → eas update no canal (Clock B). Rollback em minutos.
  │
  └─ Mudança na política da loja (login, pagamentos, reivindicações de saúde)?
       └─ SIM → lista de verificação de revisão + buffer de revisão humana antes do envio.

// eas.json - perfis separados para que a velocidade não corte atalhos nas credenciais de produção
{
  "build": {
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production",
      "autoIncrement": true
    }
  }
}

Taxa de transferência de avaliação sem pular portões

# .github/workflows/pr.yml - feedback rápido, os mesmos portões do main
name: PR checks
on: pull_request
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npx expo-doctor
      - run: npm run lint && npm run typecheck && npm test

• PRs pequenos mesclam mais rápido do que maratonas de revisão heroicas - separe a configuração nativa da UI quando possível.
• Revisores nomeados para app.config.ts, eas.json e plugins/ - não aprovação de passagem.
• Etiqueta de pré-visualização aciona o build de pré-visualização EAS - veja Builds de Pré-visualização em PRs.

Orçamento de risco da loja

## Livro de registro de risco de lançamento - sprint 24
 
| Risco gasto | Item | Resultado |
| --- | --- | --- |
| 1 unidade | Alteração de cópia IAP | Aprovado no dia 2 |
| 1 unidade | Novo upload de foto (UGC) | Rejeitado - ADR de moderação ausente |
| 0 (OTA) | Cor do botão | Entregue no mesmo dia |
 
Orçamento: 2 envios para a loja / sprint. Acima do orçamento → adiar para o próximo trem ou semana apenas OTA.

Líderes rastreiam rejeições como dívida de processo - cada rejeição custa mais tempo de calendário do que um dia extra de QA. Pareie com Calendário do Trem de Lançamento para o modelo de três relógios.

Quando desacelerar a velocidade

Armadilhas

• "Vamos corrigir com OTA" após adicionar um pacote nativo - OTA não envia bytecode Hermes para nova vinculação de .so / framework. Correção: Reconstruir binário; comunicar o atraso cedo.

• Expo Go verde, cliente de desenvolvimento vermelho - Juniores demonstram no Go; produção usa módulos nativos personalizados. Correção: Build de pré-visualização na Definição de Conclusão para trabalho que toca no nativo.

• Velocidade = pular typecheck - any mesclado e rotas quebradas se acumulam em refatorações na semana de avaliação. Correção: Mesmo CI em PR e main; sem bypass administrativo.

• Aprovador único em metadados da loja - Etiqueta de nutrição de privacidade incorreta aciona rejeição não relacionada à qualidade do código. Correção: Linha de checklist para campos do App Store Connect / Play Console.

• Deploy de backend após mobile - Novo campo JSON obrigatório quebra versões antigas do aplicativo. Correção: Leitores tolerantes primeiro; veja a matriz de dependência do trem de lançamento.

Alternativas

FAQs

Relacionados

• Calendário do Trem de Lançamento - três relógios e matriz de dependência
• Registros de Decisão de Arquitetura - modelo de ADR OTA vs loja
• Padrões de Revisão de Código para RN - perf, a11y, checklist nativo
• Noções Básicas de Arquitetura Mobile - limites que mantêm os PRs pequenos
• Noções Básicas de Integração - configuração do primeiro dia antes da pressão de velocidade
• Diretrizes de Avaliação da App Store - prevenção de rejeição
• Noções Básicas de Atualizações OTA - restrições do Clock B

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).