Noções Básicas de Atualizações OTA

10 exemplos para você começar com Atualizações Over-The-Air (OTA) no Expo SDK 57 - o que o EAS Update pode alterar em minutos versus o que ainda requer uma submissão para a App Store ou Play Store.

Pré-requisitos

Atualizações OTA exigem expo-updates em um binário de release ou preview - não no Expo Go.

npx create-expo-app@latest MyOtaApp --template blank-typescript
cd MyOtaApp
npx expo install expo-updates
npx eas init
npx eas update:configure

Ferramentas: Estes exemplos visam Expo SDK 57 (expo ~57.0.4), React Native 0.86.0 e React 19.2.3.

Exemplos Básicos

1. Dois Caminhos de Entrega: OTA vs Loja

Toda decisão de release mobile começa com uma pergunta: esta alteração afeta o código nativo?

Alteração apenas de JavaScript / assets     →  eas update (minutos)
Shell nativo / permissões / SDK             →  eas build + submissão na loja (dias)

• OTA substitui o bundle JS e os assets baixáveis em dispositivos que já possuem um binário compatível
• Build da loja substitui o shell nativo - runtime Hermes, módulos nativos, entitlements, ícones
• Usuários em versões antigas da loja permanecem em sua linha de runtime até que atualizem o binário
• Veja Regras de Release & OTA para a checklist completa de promoção

Relacionado: expo-updates (API do Cliente) - verificando e aplicando atualizações a partir do código do app

2. Corrigir um Bug de Componente React (Seguro para OTA)

Erros de lógica puramente em JavaScript são o caso de uso clássico para OTA - nenhuma fronteira nativa foi cruzada.

// src/screens/CheckoutScreen.tsx - correção de erro de digitação enviada via OTA
export function CheckoutScreen() {
  const total = useCartTotal();
 
  return (
    <View>
      <Text>Total: {formatCurrency(total)}</Text>
      {/* Corrigido: estava dividindo por 100 duas vezes */}
      <PrimaryButton label="Pagar agora" onPress={submitPayment} />
    </View>
  );
}

# Após a fase de teste de pré-visualização
eas update --channel production --environment production --message "Corrige exibição do total do checkout"

• Árvores de componentes, hooks, estilos e estrutura de navegação são seguros para OTA
• Envie primeiro para preview; faça a fase de teste antes de ir para production em caminhos de receita
• Combine com monitoramento de crashes - OTA é rápido, não isento de riscos

Relacionado: Canais de Release & Branches - promoção de staging → production

3. Trocar Assets de Imagem (Seguro para OTA)

Imagens empacotadas, fontes referenciadas a partir do JS e JSON Lottie são enviadas com o manifesto de atualização.

// src/components/HeroBanner.tsx
import heroImage from "@/assets/hero-summer.png";
 
export function HeroBanner() {
  return <Image source={heroImage} style={{ width: "100%", height: 200 }} />;
}

• Alterações de assets no bundle Metro são seguras para OTA
• Ícone do app e tela de splash são nativos - exigem um novo binário
• Adições de grandes assets afetam o tamanho do bundle e o TTI - fique atento aos orçamentos de performance

4. Adicionar um Módulo Nativo (Requer Loja)

Instalar um pacote com código nativo altera a saída ios/ e android/ - OTA não pode adicioná-lo.

# Esta sequência requer eas build + submissão na loja, NÃO apenas eas update
npx expo install react-native-vision-camera

// app.config.ts - novo plugin = nova build nativa
export default {
  expo: {
    plugins: [
      [
        "react-native-vision-camera",
        { cameraPermissionText: "Precisamos de acesso à câmera para escanear códigos de barras." },
      ],
    ],
  },
};

• A diferença do npx expo prebuild é o sinal - se o projeto nativo mudar, planeje uma build da loja
• Nunca envie JS que importe o novo módulo via OTA antes que os binários existam nas lojas
• Proteja telas novas que dependem de código nativo atrás de flags de recursos até que a adoção da loja ultrapasse seu limite

Relacionado: Noções Básicas de EAS Build - builds na nuvem que recebem atualizações

5. Alterar Strings de Permissão do Info.plist (Requer Loja)

A cópia de permissão vive nos manifestos nativos - os usuários verão texto desatualizado se você fizer OTA sem reconstruir.

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSCameraUsageDescription": "Escaneie códigos de barras para adicionar itens ao seu carrinho."
      }
    },
    "android": {
      "permissions": ["android.permission.CAMERA"]
    }
  }
}

• Qualquer alteração em infoPlist, permissions ou entitlements precisa de eas build
• A Revisão do App lê as strings de permissão no binário, não no bundle JS
• Documente as alterações de permissão nas notas de release da loja, não apenas nos changelogs do OTA

6. Atualizar Expo SDK (Requer Loja)

Atualizações de SDK mudam o runtime nativo, a versão do Hermes e as dependências nativas padrão.

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

• Após a atualização do SDK: eas build para todos os perfis, depois retome eas update na nova linha de runtime
• Binários antigos no runtime anterior param de receber atualizações na nova linha
• Planeje a comunicação com os usuários quando a aplicação de uma versão nativa mínima for necessária

Relacionado: Política de Versão de Runtime - estratégias de appVersion, nativeVersion e fingerprint

7. runtimeVersion É o Portão de Compatibilidade

runtimeVersion informa ao EAS Update quais bundles JS um binário pode baixar. Incompatibilidade = ignorar silenciosamente.

// app.config.ts
export default {
  expo: {
    version: "2.4.0",
    runtimeVersion: {
      policy: "appVersion",
    },
    updates: {
      url: "https://u.expo.dev/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    },
  },
};

# A build incorpora o runtime 2.4.0
eas build --profile production --platform all
 
# A atualização deve ter como alvo o mesmo runtime
eas update --channel production --environment production

• Artefatos do eas build e bundles do eas update devem compartilhar o mesmo runtimeVersion resolvido
• Verifique com npx expo config --type public | jq '.runtimeVersion'
• Uma política incorreta deixa os usuários com JS desatualizado sem um erro óbvio - teste em dispositivos de pré-visualização

Relacionado: Configuração do expo-updates - cookbook completo do app.config

8. Tabela de Decisão OTA vs Loja

Copie esta tabela para o seu runbook de release e exija uma caixa de seleção para cada alteração.

• Quando uma linha diz ⚠️, OTA é tecnicamente possível, mas requer QA extra e planejamento de rollback
• Linhas de receita, autenticação e pagamento são definidas como teste de pré-visualização por padrão, independentemente de serem alterações "pequenas"

9. Proteja o JS até que os Binários Alcancem

OTA permite que você envie JS rapidamente; flags de recursos permitem que você controle quem o executa.

// src/features/barcode/useBarcodeScanner.ts
import * as Application from "expo-application";
 
const MIN_NATIVE_FOR_SCANNER = "2.4.0";
 
export function useBarcodeScannerEnabled(remoteFlag: boolean) {
  const nativeVersion = Application.nativeApplicationVersion ?? "0.0.0";
  const nativeReady = compareSemver(nativeVersion, MIN_NATIVE_FOR_SCANNER) >= 0;
  return remoteFlag && nativeReady;
}

• Flags remotas desativam caminhos ruins imediatamente - mais rápido do que republicar um OTA
• Application.nativeApplicationVersion reflete o binário da loja, não o ID do bundle do OTA
• Autorização do servidor ainda impõe acesso - flags são para UX, não segurança

Relacionado: Flags de Recursos para Rollout Seguro - kill switches ao lado do OTA

10. Saiba Qual Bundle Está em Execução

Suporte e resposta a incidentes precisam do ID da atualização - não apenas da versão de marketing.

// app/_layout.tsx (apenas diagnósticos de dev/preview)
import * as Updates from "expo-updates";
import { useEffect } from "react";
 
export default function RootLayout() {
  useEffect(() => {
    if (__DEV__) return;
    console.info("[updates]", {
      updateId: Updates.updateId,
      runtimeVersion: Updates.runtimeVersion,
      channel: Updates.channel,
      isEmbeddedLaunch: Updates.isEmbeddedLaunch,
    });
  }, []);
 
  return <Stack />;
}

• Updates.updateId identifica o bundle OTA; Updates.isEmbeddedLaunch verdadeiro significa que nenhum OTA foi aplicado ainda
• Registre em analytics em pré-visualização/produção - oculte em telas públicas voltadas para o usuário
• Mantenha o último ID de atualização bom conhecido em tickets de release para o Runbook de Rollback

FAQs

Relacionado

• Configuração do expo-updates - runtimeVersion, URL, verificação no lançamento
• Canais de Release & Branches - fluxo de promoção de canais
• Política de Versão de Runtime - guia de seleção de política
• expo-updates (API do Cliente) - verificação/busca/recarregamento do cliente
• Noções Básicas de EAS Build - binários que recebem payloads OTA
• Regras de Release & OTA - checklist de aplicação pela equipe

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