Pesquisa: alternativas (pt-BR)

O que aconteceu com o CodePush

O CodePush era um serviço do Visual Studio App Center (Microsoft). Em 2024 a Microsoft anunciou a aposentadoria do App Center inteiro, que foi desligado em 31/03/2025 junto com o CodePush hospedado. O motivo foi uma decisão de produto da Microsoft (concentrar esforços em Azure/GitHub), não um problema técnico do CodePush. A Microsoft publicou um code-push-server standalone para auto-hospedagem, mas os repositórios foram arquivados em maio/2025 (somente leitura, sem manutenção). O SDK react-native-code-push também ficou sem evolução e acumula incompatibilidades com a New Architecture.

Soluções existentes hoje

solução	modelo	pontos fortes	limitações
EAS Update (Expo)	SaaS	padrão de mercado; rollouts, canais, fingerprint de runtime, diff de bytecode Hermes	cobrado por MAU; SDK expo-updates puxa o ecossistema Expo; não é auto-hospedável oficialmente
hot-updater (gronxb)	open-source, self-host	plugins para Supabase/AWS/Cloudflare; console web	projeto pequeno, API ainda mudando
Revopush, Stallion	SaaS estilo CodePush	migração fácil a partir do CodePush	dependência de fornecedor, preço por uso
Codemagic Patch	self-host	dashboard + instalador	atrelado ao Codemagic
code-push-server (Microsoft)	self-host	compatível com o SDK antigo	arquivado; sem suporte

Todas as opções atualizam apenas JavaScript e assets.

Dá para atualizar código nativo?

Não de forma permitida:

• Apple: o Developer Program License Agreement (§3.3.1(B)) e a guideline 2.5.2 proíbem baixar código executável; código interpretado (JS) é permitido desde que não mude o propósito principal do app. Além disso, a assinatura de código do iOS impede carregar binários nativos novos.
• Google Play: a política Device and Network Abuse proíbe baixar código executável (DEX, .so) de fora da Play Store. Tecnicamente seria possível no Android, mas o app seria removido.

A alternativa correta, adotada aqui, é tornar mudanças nativas seguras: cada update é vinculado a uma runtime version; binários antigos continuam recebendo JS compatível e binários novos só recebem JS compilado para eles.

Como o react-native-airdrop se diferencia

1. Self-hosted no Cloudflare (Workers + D1 + R2): custo muito baixo, sem egress no R2, cache na borda, sem fornecedor intermediário.
2. Download diferencial por arquivo: arquivos endereçados por SHA-256; o device só baixa o que mudou e copia o resto do update atual.
3. Assinatura ponta a ponta (ECDSA P-256) com a chave pública dentro do binário: nem um servidor comprometido consegue publicar código.
4. Rollback automático em crash na inicialização, com blacklist do update e telemetria.
5. Compatível com RN 0.71+ (old e new architecture) sem depender do Expo.

Próximos passos sugeridos (pós-MVP)

• Diff binário do bundle Hermes (bsdiff) para updates ainda menores.
• Dashboard web (Cloudflare Pages) com gráficos de adoção/rollback.
• Multi-tenant com contas/organizações (hoje é um servidor por empresa).
• Política fingerprint automática para runtime version (hash das dependências nativas).
• Integração com Expo (expo export:embed já funciona via --bundle-dir).

Fontes: Codemagic: React Native OTA tools in 2026, Bitrise: CodePush alternatives, Microsoft code-push (arquivado), Expo: OTA updates, Bitrise: o que as lojas permitem, hot-updater.