Noções Básicas de Entrega Mobile

Q: Podemos enviar OTA durante a revisão da App Store?

Sim, se runtimeVersion corresponder ao binário em revisão e o OTA não alterar o comportamento que os revisores testarão. Mantenha os OTAs de produção atrás de flags até a aprovação - os revisores podem testar um build que recebe um OTA ao iniciar.

Q: Com que frequência as equipes corporativas devem executar trens da loja?

Quinzenalmente é comum para aplicativos de consumo; mensalmente para indústrias regulamentadas. OTA preenche a lacuna entre os trens - diariamente ou semanalmente para correções de JS. Combine a cadência com o risco de revisão da loja e as janelas de dependência do backend.

Q: Quem é o proprietário do calendário de lançamentos?

Gerente de engenharia ou capitão de lançamento - responsável. Mobile, backend, QA e suporte são consultados. O calendário vive em um documento compartilhado ou epic do Jira, não no caderno de um engenheiro.

Q: iOS e Android precisam de envios OTA separados?

Um eas update atende a ambas as plataformas quando elas compartilham runtimeVersion e canal. Os envios para a loja permanecem por plataforma - EAS Submit.

Dez exemplos para coordenar lançamentos de lojas nativas com trens JavaScript OTA - a base operacional que as equipes móveis corporativas precisam antes de escalar além de um engenheiro marcando builds de sexta-feira.

Pré-requisitos

A entrega corporativa assume que você já configurou EAS Build e EAS Update:

npx create-expo-app@latest EnterpriseDelivery --template blank-typescript@sdk-57 --yes
cd EnterpriseDelivery
npx expo install expo-updates
npx eas init
npx eas update:configure
npx eas build:configure

Confirme o "stack pin":

{
  "dependencies": {
    "expo": "~57.0.4",
    "react": "19.2.3",
    "react-native": "0.86.0"
  }
}

Ferramentas: Estes exemplos visam Expo SDK 57 (expo ~57.0.4), React Native 0.86.0 e React 19.2.3. Leia Noções Básicas de EAS Build e Noções Básicas de Atualizações OTA antes de coordenar trens.

Exemplos Básicos

1. Dois Relógios de Entrega

Toda decisão de lançamento corporativo começa com a qual relógio a alteração pertence:

Clock A - Store binary (eas build + eas submit)
  Changes: native modules, SDK bumps, permissions, entitlements, icons
  Cadence: biweekly or monthly release train
  Rollback: new store version (hours to days)
 
Clock B - OTA bundle (eas update)
  Changes: JS, TypeScript, assets, copy - same runtimeVersion as Clock A
  Cadence: daily to weekly between store trains
  Rollback: eas update:rollback (minutes)

Relógio	Ponto de entrada de CI	Proprietário	Impacto no usuário se mal cronometrado
A	`eas build` em tag	Plataforma Móvel	Crash ao iniciar, rejeição da loja
B	`eas update` em merge	Recurso Móvel	UI incorreta, erros de JS no binário antigo

Relógio A é lento, mas altera o "shell" nativo - Hermes, módulos nativos, entitlements de push.
Relógio B é rápido, mas não pode adicionar código nativo - apenas JS que o binário já suporta.
Equipes corporativas documentam ambos os relógios em um calendário compartilhado - Calendário de Trens de Lançamento.

2. Mapeie Alterações para o Relógio Correto

Use uma tabela de decisão simples em cada template de PR:

Alteração	Relógio	Por quê
Correção de cor de botão	B (OTA)	Puro JS
Nova dependência `expo-camera`	A (loja)	Módulo nativo + strings de permissão
Cliente de API lê novo campo opcional	B (OTA)	Leitor tolerante em JS
Atualização Hermes / SDK 57	A (loja)	Alteração de runtime nativo
Troca de imagem principal (asset)	B (OTA)	Asset empacotado
Adicionar `NSCameraUsageDescription`	A (loja)	Info.plist no binário

# PR checklist snippet - paste into .github/pull_request_template.md
## Delivery path
- [ ] JS-only → preview soak → production OTA
- [ ] Native change → eas build required; OTA blocked until new binary ships

Relacionado: Noções Básicas de Atualizações OTA - o que OTA pode e não pode alterar.

3. Vincule o Binário da Loja ao OTA com runtimeVersion

runtimeVersion é o contrato entre o Relógio A e o Relógio B:

// app.config.ts
import type { ExpoConfig } from "expo/config";
 
const config: ExpoConfig = {
  name: "EnterpriseDelivery",
  slug: "enterprise-delivery",
  version: "2.5.0",
  runtimeVersion: {
    policy: "appVersion", // "2.5.0" line receives 2.5.x OTAs only
  },
  updates: {
    url: "https://u.expo.dev/<project-id>",
  },
  ios: { bundleIdentifier: "com.example.enterprisedelivery" },
  android: { package: "com.example.enterprisedelivery" },
};
 
export default config;

// eas.json - channel embedded at build time
{
  "build": {
    "production": {
      "channel": "production",
      "environment": "production"
    }
  }
}

Binários de produção compilados com runtimeVersion: 2.5.0 recebem apenas OTAs publicados para 2.5.0.
Incrementar version para 2.6.0 sem um novo build da loja deixa os usuários 2.5.0 com JS desatualizado.
Veja Política de Versão de Runtime para alternativas de fingerprint e sdkVersion.

4. Alinhe o Canal eas.json com o Alvo de Atualização

Todo binário de produção deve escutar no mesmo canal para o qual você publica:

# Build production binary - channel baked in at compile time
eas build --profile production --platform all --non-interactive
 
# OTA must target the same channel
eas update --channel production --environment production \
  --message "fix: checkout total rounding"

# Verify alignment before every production OTA
eas channel:view production
# Confirm channel points at production branch and runtimeVersion matches app.config

Canais incompatíveis causam tickets de suporte "a atualização nunca chega" - não crashes.
Aplicativos white-label precisam de canais separados por ID de pacote - nunca compartilhe um único canal de produção.
Canais e Branches de Lançamento documenta o fluxo de promoção.

5. Trem da Loja + Trem OTA em Um Calendário

Equipes corporativas mantêm um calendário compartilhado - não planilhas separadas de iOS, Android e JS:

# Release 2.5.0 - Week of 2026-07-14
 
## Clock A (store)
- Thu W1: code freeze 18:00 UTC
- Fri W1: tag v2.5.0; eas build production; gated submit
- Mon W2: Play staged 10% → 50%
- Wed W2: ASC phased release 100%
 
## Clock B (OTA)
- Mon–Wed W1: OTA to preview channel only (behind flags)
- Thu W1: freeze OTA to production until store RC signed
- Wed W2: OTA hotfix lane open if runtimeVersion unchanged
 
## Dependencies
- [ ] API v3 on prod - @backend - Thu W1
- [ ] Feature flag checkout_v3 at 0% - @mobile - Fri W1

Congelamento de OTA durante o RC da loja impede a deriva de JS entre a aprovação do QA e o envio.
Lane de hotfix reabre após o binário da loja estar ativo e o runtimeVersion estar estável.
Template completo: Calendário de Trens de Lançamento.

6. Fixe o build_id do QA ao Submit

O artefato testado pelo QA deve ser o artefato que as lojas recebem:

# Release pipeline records build_id in ticket
eas build --profile production --platform ios --non-interactive
# build_id: abc123-def456-...
 
# QA signs off on abc123 - never rebuild before submit
eas submit --platform ios --id abc123-def456-... --non-interactive

# .github/workflows/release.yml - submit pinned ID from workflow output
- name: Submit iOS (pinned build)
  run: eas submit --platform ios --id ${{ needs.build.outputs.ios_build_id }} --non-interactive

Reconstruir entre QA e submit invalida o mapeamento de symbolication de crash e as capturas de tela de revisão.
--latest submit é apenas para emergências - documente quando é permitido.
Promoção Automatizada de Loja automatiza o pin.

7. Coordene o Backend Antes do OTA Móvel

O JS que chama uma nova API não deve ser enviado via OTA até que o backend esteja ativo:

Wrong order:  OTA ships Monday → API deploys Thursday → 3 days of 404s
Right order:  API deploys Thursday (backward compatible) → OTA ships Friday

// src/api/checkout.ts - tolerant reader until flag ramps
export async function fetchCheckoutConfig(): Promise<CheckoutConfig> {
  const res = await api.get("/v3/checkout/config");
  if (res.status === 404) {
    return api.get("/v2/checkout/config"); // fallback for old path
  }
  return res.json();
}

API compatível com versões anteriores é implantada primeiro; OTA móvel habilita a UI via feature flag em segundo lugar.
Remoção de API que quebra compatibilidade requer binário da loja do Relógio A sem chamadas antigas - coordene a janela de depreciação.
Testes de contrato em verificações de PR capturam desvios - Testes de Contrato para APIs.

8. Feature Flags Unem Binário e OTA

Binários da loja podem ficar em revisão por dias enquanto o JS é enviado diariamente - flags desacoplam ativo de visível:

Day 1: eas build ships v2.5.0 to TestFlight - checkout_v3 flag OFF
Day 3: eas update ships checkout UI - still hidden behind flag
Day 5: App Review approves; staged rollout begins - flag 0%
Day 7: OTA + flag ramp to 10% internal cohort
Day 10: flag 100% after metrics pass

Binário ativo significa que o shell nativo está na loja - os usuários podem instalá-lo.
Recurso visível significa que a flag (ou canal) expõe a nova experiência.
Mergulho profundo: Feature Flags em Mobile.

9. Semana Apenas com OTA (Sem Trem da Loja)

Quando o trem é apenas JS, pule o Relógio A, mas mantenha a disciplina:

# Mon - merge behind flags; publish preview
eas update --channel preview --environment preview --message "feat: loyalty points UI"
 
# Tue - QA soak on preview binary (same runtimeVersion as production)
# Wed - staged production rollout
eas update --channel production --environment production \
  --rollout-percentage=10 --message "rollout: loyalty @ 10%"
 
# Thu - monitor Sentry; roll back if crash-free drops
# Fri - 100% if metrics hold

Semanas apenas com OTA ainda precisam de teste em preview em caminhos de receita - rollouts não são um substituto.
Registre o último ID de atualização bom conhecido em cada ticket - Runbook de Rollback.
Lançamentos Graduais documenta os portões de porcentagem.

10. Caminhos de Rollback por Relógio

Documente o rollback antes de precisar dele - incidentes corporativos se movem mais rápido com cartões pré-escritos:

Relógio	Gatilho	Ação	ETA
B (OTA)	Crash-free -2% após publicação	`eas update:rollback` + desativar flag	< 15 min
B (OTA)	Sucesso de pagamento -1%	Desativar flag primeiro; rollback em segundo	< 10 min
A (loja)	Crash nativo ao iniciar	Interromper lançamento gradual; promover versão anterior	1–24 h
A (loja)	Rejeição da loja	Corrigir binário; reenviar - OTA não pode corrigir nativo	dias

# OTA rollback card - fill per release
eas update:list --branch production --limit 3
# Last known-good: <update-group-id>
eas update:rollback

OTA não pode corrigir crashes nativos - escale para um binário de hotfix do Relógio A.
Incompatibilidade de runtimeVersion requer um novo build da loja - não republicação de canal.
Padrões avançados: Canary OTA & Blue-Green.

FAQs

Podemos enviar OTA durante a revisão da App Store?

Sim, se runtimeVersion corresponder ao binário em revisão e o OTA não alterar o comportamento que os revisores testarão. Mantenha os OTAs de produção atrás de flags até a aprovação - os revisores podem testar um build que recebe um OTA ao iniciar.

Com que frequência as equipes corporativas devem executar trens da loja?

Quinzenalmente é comum para aplicativos de consumo; mensalmente para indústrias regulamentadas. OTA preenche a lacuna entre os trens - diariamente ou semanalmente para correções de JS. Combine a cadência com o risco de revisão da loja e as janelas de dependência do backend.

Quem é o proprietário do calendário de lançamentos?

Gerente de engenharia ou capitão de lançamento - responsável. Mobile, backend, QA e suporte são consultados. O calendário vive em um documento compartilhado ou epic do Jira, não no caderno de um engenheiro.

iOS e Android precisam de envios OTA separados?

Um eas update atende a ambas as plataformas quando elas compartilham runtimeVersion e canal. Os envios para a loja permanecem por plataforma - EAS Submit.

Relacionados

Noções Básicas de CI/CD Mobile - verificações de PR vs pipelines de lançamento
Calendário de Trens de Lançamento - coordenação de três relógios
Noções Básicas de EAS Build - fundação do binário da loja
Noções Básicas de Atualizações OTA - alterações seguras para OTA vs. necessárias para a loja
Canais e Branches de Lançamento - promoção de canal
Feature Flags em Mobile - cookbook de exposição controlada
Checklist de Lançamento e Go/No-Go - aprovação pré-envio

Versões do Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Pré-requisitos

A entrega corporativa assume que você já configurou EAS Build e EAS Update:

npx create-expo-app@latest EnterpriseDelivery --template blank-typescript@sdk-57 --yes
cd EnterpriseDelivery
npx expo install expo-updates
npx eas init
npx eas update:configure
npx eas build:configure

Confirme o "stack pin":

{
  "dependencies": {
    "expo": "~57.0.4",
    "react": "19.2.3",
    "react-native": "0.86.0"
  }
}

Ferramentas: Estes exemplos visam Expo SDK 57 (expo ~57.0.4), React Native 0.86.0 e React 19.2.3. Leia Noções Básicas de EAS Build e Noções Básicas de Atualizações OTA antes de coordenar trens.

Exemplos Básicos

1. Dois Relógios de Entrega

Toda decisão de lançamento corporativo começa com a qual relógio a alteração pertence:

Clock A - Store binary (eas build + eas submit)
  Changes: native modules, SDK bumps, permissions, entitlements, icons
  Cadence: biweekly or monthly release train
  Rollback: new store version (hours to days)
 
Clock B - OTA bundle (eas update)
  Changes: JS, TypeScript, assets, copy - same runtimeVersion as Clock A
  Cadence: daily to weekly between store trains
  Rollback: eas update:rollback (minutes)

Relógio	Ponto de entrada de CI	Proprietário	Impacto no usuário se mal cronometrado
A	`eas build` em tag	Plataforma Móvel	Crash ao iniciar, rejeição da loja
B	`eas update` em merge	Recurso Móvel	UI incorreta, erros de JS no binário antigo

Relógio A é lento, mas altera o "shell" nativo - Hermes, módulos nativos, entitlements de push.
Relógio B é rápido, mas não pode adicionar código nativo - apenas JS que o binário já suporta.
Equipes corporativas documentam ambos os relógios em um calendário compartilhado - Calendário de Trens de Lançamento.

2. Mapeie Alterações para o Relógio Correto

Use uma tabela de decisão simples em cada template de PR:

Alteração	Relógio	Por quê
Correção de cor de botão	B (OTA)	Puro JS
Nova dependência `expo-camera`	A (loja)	Módulo nativo + strings de permissão
Cliente de API lê novo campo opcional	B (OTA)	Leitor tolerante em JS
Atualização Hermes / SDK 57	A (loja)	Alteração de runtime nativo
Troca de imagem principal (asset)	B (OTA)	Asset empacotado
Adicionar `NSCameraUsageDescription`	A (loja)	Info.plist no binário

# PR checklist snippet - paste into .github/pull_request_template.md
## Delivery path
- [ ] JS-only → preview soak → production OTA
- [ ] Native change → eas build required; OTA blocked until new binary ships

Relacionado: Noções Básicas de Atualizações OTA - o que OTA pode e não pode alterar.

3. Vincule o Binário da Loja ao OTA com runtimeVersion

runtimeVersion é o contrato entre o Relógio A e o Relógio B:

// app.config.ts
import type { ExpoConfig } from "expo/config";
 
const config: ExpoConfig = {
  name: "EnterpriseDelivery",
  slug: "enterprise-delivery",
  version: "2.5.0",
  runtimeVersion: {
    policy: "appVersion", // "2.5.0" line receives 2.5.x OTAs only
  },
  updates: {
    url: "https://u.expo.dev/<project-id>",
  },
  ios: { bundleIdentifier: "com.example.enterprisedelivery" },
  android: { package: "com.example.enterprisedelivery" },
};
 
export default config;

// eas.json - channel embedded at build time
{
  "build": {
    "production": {
      "channel": "production",
      "environment": "production"
    }
  }
}

Binários de produção compilados com runtimeVersion: 2.5.0 recebem apenas OTAs publicados para 2.5.0.
Incrementar version para 2.6.0 sem um novo build da loja deixa os usuários 2.5.0 com JS desatualizado.
Veja Política de Versão de Runtime para alternativas de fingerprint e sdkVersion.

4. Alinhe o Canal eas.json com o Alvo de Atualização

Todo binário de produção deve escutar no mesmo canal para o qual você publica:

# Build production binary - channel baked in at compile time
eas build --profile production --platform all --non-interactive
 
# OTA must target the same channel
eas update --channel production --environment production \
  --message "fix: checkout total rounding"

# Verify alignment before every production OTA
eas channel:view production
# Confirm channel points at production branch and runtimeVersion matches app.config

Canais incompatíveis causam tickets de suporte "a atualização nunca chega" - não crashes.
Aplicativos white-label precisam de canais separados por ID de pacote - nunca compartilhe um único canal de produção.
Canais e Branches de Lançamento documenta o fluxo de promoção.

5. Trem da Loja + Trem OTA em Um Calendário

Equipes corporativas mantêm um calendário compartilhado - não planilhas separadas de iOS, Android e JS:

# Release 2.5.0 - Week of 2026-07-14
 
## Clock A (store)
- Thu W1: code freeze 18:00 UTC
- Fri W1: tag v2.5.0; eas build production; gated submit
- Mon W2: Play staged 10% → 50%
- Wed W2: ASC phased release 100%
 
## Clock B (OTA)
- Mon–Wed W1: OTA to preview channel only (behind flags)
- Thu W1: freeze OTA to production until store RC signed
- Wed W2: OTA hotfix lane open if runtimeVersion unchanged
 
## Dependencies
- [ ] API v3 on prod - @backend - Thu W1
- [ ] Feature flag checkout_v3 at 0% - @mobile - Fri W1

Congelamento de OTA durante o RC da loja impede a deriva de JS entre a aprovação do QA e o envio.
Lane de hotfix reabre após o binário da loja estar ativo e o runtimeVersion estar estável.
Template completo: Calendário de Trens de Lançamento.

6. Fixe o build_id do QA ao Submit

O artefato testado pelo QA deve ser o artefato que as lojas recebem:

# Release pipeline records build_id in ticket
eas build --profile production --platform ios --non-interactive
# build_id: abc123-def456-...
 
# QA signs off on abc123 - never rebuild before submit
eas submit --platform ios --id abc123-def456-... --non-interactive

# .github/workflows/release.yml - submit pinned ID from workflow output
- name: Submit iOS (pinned build)
  run: eas submit --platform ios --id ${{ needs.build.outputs.ios_build_id }} --non-interactive

Reconstruir entre QA e submit invalida o mapeamento de symbolication de crash e as capturas de tela de revisão.
--latest submit é apenas para emergências - documente quando é permitido.
Promoção Automatizada de Loja automatiza o pin.

7. Coordene o Backend Antes do OTA Móvel

O JS que chama uma nova API não deve ser enviado via OTA até que o backend esteja ativo:

Wrong order:  OTA ships Monday → API deploys Thursday → 3 days of 404s
Right order:  API deploys Thursday (backward compatible) → OTA ships Friday

// src/api/checkout.ts - tolerant reader until flag ramps
export async function fetchCheckoutConfig(): Promise<CheckoutConfig> {
  const res = await api.get("/v3/checkout/config");
  if (res.status === 404) {
    return api.get("/v2/checkout/config"); // fallback for old path
  }
  return res.json();
}

API compatível com versões anteriores é implantada primeiro; OTA móvel habilita a UI via feature flag em segundo lugar.
Remoção de API que quebra compatibilidade requer binário da loja do Relógio A sem chamadas antigas - coordene a janela de depreciação.
Testes de contrato em verificações de PR capturam desvios - Testes de Contrato para APIs.

8. Feature Flags Unem Binário e OTA

Binários da loja podem ficar em revisão por dias enquanto o JS é enviado diariamente - flags desacoplam ativo de visível:

Day 1: eas build ships v2.5.0 to TestFlight - checkout_v3 flag OFF
Day 3: eas update ships checkout UI - still hidden behind flag
Day 5: App Review approves; staged rollout begins - flag 0%
Day 7: OTA + flag ramp to 10% internal cohort
Day 10: flag 100% after metrics pass

Binário ativo significa que o shell nativo está na loja - os usuários podem instalá-lo.
Recurso visível significa que a flag (ou canal) expõe a nova experiência.
Mergulho profundo: Feature Flags em Mobile.

9. Semana Apenas com OTA (Sem Trem da Loja)

Quando o trem é apenas JS, pule o Relógio A, mas mantenha a disciplina:

# Mon - merge behind flags; publish preview
eas update --channel preview --environment preview --message "feat: loyalty points UI"
 
# Tue - QA soak on preview binary (same runtimeVersion as production)
# Wed - staged production rollout
eas update --channel production --environment production \
  --rollout-percentage=10 --message "rollout: loyalty @ 10%"
 
# Thu - monitor Sentry; roll back if crash-free drops
# Fri - 100% if metrics hold

Semanas apenas com OTA ainda precisam de teste em preview em caminhos de receita - rollouts não são um substituto.
Registre o último ID de atualização bom conhecido em cada ticket - Runbook de Rollback.
Lançamentos Graduais documenta os portões de porcentagem.

10. Caminhos de Rollback por Relógio

Documente o rollback antes de precisar dele - incidentes corporativos se movem mais rápido com cartões pré-escritos:

Relógio	Gatilho	Ação	ETA
B (OTA)	Crash-free -2% após publicação	`eas update:rollback` + desativar flag	< 15 min
B (OTA)	Sucesso de pagamento -1%	Desativar flag primeiro; rollback em segundo	< 10 min
A (loja)	Crash nativo ao iniciar	Interromper lançamento gradual; promover versão anterior	1–24 h
A (loja)	Rejeição da loja	Corrigir binário; reenviar - OTA não pode corrigir nativo	dias

# OTA rollback card - fill per release
eas update:list --branch production --limit 3
# Last known-good: <update-group-id>
eas update:rollback

OTA não pode corrigir crashes nativos - escale para um binário de hotfix do Relógio A.
Incompatibilidade de runtimeVersion requer um novo build da loja - não republicação de canal.
Padrões avançados: Canary OTA & Blue-Green.

FAQs

Podemos enviar OTA durante a revisão da App Store?

Com que frequência as equipes corporativas devem executar trens da loja?

Quem é o proprietário do calendário de lançamentos?

iOS e Android precisam de envios OTA separados?

Um eas update atende a ambas as plataformas quando elas compartilham runtimeVersion e canal. Os envios para a loja permanecem por plataforma - EAS Submit.

Relacionados

Noções Básicas de CI/CD Mobile - verificações de PR vs pipelines de lançamento
Calendário de Trens de Lançamento - coordenação de três relógios
Noções Básicas de EAS Build - fundação do binário da loja
Noções Básicas de Atualizações OTA - alterações seguras para OTA vs. necessárias para a loja
Canais e Branches de Lançamento - promoção de canal
Feature Flags em Mobile - cookbook de exposição controlada
Checklist de Lançamento e Go/No-Go - aprovação pré-envio

Versões do Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Noções Básicas de Entrega Mobile

Buscar na documentação

Noções Básicas de Entrega Mobile