For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/mobile/publishing.md (or send Accept: text/markdown).

Publicação nas lojas de apps

Diferencie um build funcional de uma versão que os usuários conseguem instalar.

Perguntar sobre este guia

Prepare seu primeiro envio para a loja passo a passo

Primeiro, crie e teste uma versão de desenvolvimento nativa usando versões móveis. O envio da loja envia o aplicativo compilado e sua listagem ao Google ou Apple para revisão; não é o mesmo que abrir uma visualização do Expo Go. Você precisa de seu próprio Expo e contas de desenvolvedor de loja relevantes, um backend HTTPS testado, nome/ícone final do aplicativo, capturas de tela, contato de suporte e uma política de privacidade pública URL.

Abra apps/mobile/app.json no editor e defina o nome do aplicativo, slug, ios.bundleIdentifier e android.package para seu próprio produto antes do primeiro upload. Abra apps/mobile/eas.json e substitua os identificadores de aplicativo da equipe de envio do iOS pelos seus próprios, quando necessário. Os identificadores enviados são exemplos. Leia as compilações do Mobile para os campos exatos e peça ao seu agente de codificação para revisar os dois arquivos antes de compilar.

Se o eas não estiver instalado, execute npm install --global eas-cli. Na raiz do repositório, use o comando de login abaixo, conclua a autenticação do navegador, selecione o comando de construção para uma plataforma em Build e envie. Leia os logs do painel do build; aguarde um .aab ou .ipa bem-sucedido antes de tentar enviar. EAS solicita vinculação de projeto e credenciais de assinatura; estes pertencem às suas contas, não às do vendedor do kit.

Após o upload do binário, abra seu aplicativo no Play Console ou no App Store Connect, preencha a listagem e os questionários necessários, adicione instruções de login do revisor ativo e envie-o para revisão. Carregar um rascunho interno não é um lançamento público. Se a revisão rejeitar, abra o link exato da política na rejeição e corrija o problema antes de reenviar.

corepack pnpm --filter @supastack/mobile exec eas login

Configure as contas uma vez

O envio da loja precisa de três contas: uma conta Expo gratuita para EAS Build and Submit, um registro de desenvolvedor do Google Play Console e uma associação ao Apple Developer Program para iOS. Instale o EAS CLI e execute eas login antes de construir; ambas as inscrições na loja podem levar dias para serem verificadas, portanto, inicie-as com antecedência.

Renomeie os identificadores do aplicativo antes do primeiro upload - android.package e ios.bundleIdentifier são enviados como com.supastack.app em apps/mobile/app.json. O Google Play bloqueia o nome do pacote no primeiro upload, portanto, um identificador errado significa uma nova entrada do aplicativo em vez de uma renomeação.

Deixe EAS gerenciar a assinatura

apps/mobile/eas.json define perfis de desenvolvimento, visualização e construção de produção. O perfil de produção permite que EAS gere e mantenha o armazenamento de chaves do Android e o certificado de distribuição do iOS em sua infraestrutura – inspecione-os posteriormente com eas credentials e mantenha os armazenamentos de chaves locais fora do repositório.

O envio automatizado do Play precisa de uma chave JSON da conta de serviço do Google Play vinculada em Play Console → Configuração → acesso API com permissão de liberação. Armazene-o em apps/mobile/secrets/play-store-service-account.json - o caminho que eas.json espera e um diretório ignorado pelo git. O primeiro upload de um novo app ainda acontece manualmente no Play Console; eas submit assume o lugar da segunda versão.

Construa e depois envie

As compilações são executadas na infraestrutura EAS, portanto, nenhuma instalação do Android Studio ou Xcode é necessária para o binário. O perfil de produção produz um .aab pronto para loja para Play e .ipa para App Store com números de versão gerenciados remotamente. O perfil de visualização produz um APK de distribuição interna para controle de qualidade de dispositivo físico.

O perfil de envio enviado tem como alvo a faixa interna do Play como uma versão de rascunho. Nada chega aos testadores até que você o promova no Play Console após a aprovação na revisão.

corepack pnpm --filter @supastack/mobile build:android
corepack pnpm --filter @supastack/mobile submit:android

corepack pnpm --filter @supastack/mobile build:ios
corepack pnpm --filter @supastack/mobile submit:ios

# Internal-testing APK for a physical device:
corepack pnpm --filter @supastack/mobile build:android:preview

Preencha os formulários do Play Console

Jogue as portas de revisão no conteúdo declarado tanto quanto no binário: uma política de privacidade pública URL, o formulário de segurança de dados, o questionário de classificação de conteúdo, público-alvo e categoria. Resposta Segurança dos dados a partir do comportamento real do aplicativo — o kit coleta e-mails da conta para autenticação, armazena tokens de sessão no armazenamento seguro da plataforma e se comunica apenas com o API configurado; adicione tudo o que seu produto adiciona por cima.

Para um aplicativo iOS que requer login, forneça ao App Review uma conta de demonstração funcional e instruções nas notas de revisão. Revise a regra atual de serviços de login da Apple e suas exceções antes de escolher opções de login social; os requisitos dependem do fluxo de login real do aplicativo. As diretrizes oficiais estão vinculadas na seção de primeira submissão acima.

Compras de portão atrás de RevenueCat primeiro

Quando seu aplicativo oferece compras móveis, configure o fluxo RevenueCat enviado: defina MOBILE_PURCHASES_PROVIDER=revenuecat e EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat e, em seguida, forneça a chave pública correspondente do iOS ou Android SDK. O aplicativo nativo oferece suporte para compra e restauração; depois disso, o acesso é atualizado a partir do direito de espaço de trabalho verificado pelo servidor. Stripe Checkout não é usado no fluxo móvel. Mantenha o acesso pago indisponível quando as compras estiverem desativadas ou quando a configuração necessária estiver faltando. Valide produtos de loja configurados, compre, restaure e atualize direitos em uma versão de desenvolvimento EAS com contas de teste de loja. Verifique as orientações atuais da loja para saber os requisitos aplicáveis ao seu aplicativo e regiões.

Lista de verificação pré-envio

Antes de enviar, confirme cada item abaixo usando seu próprio aplicativo de teste e contas da loja.

android.package e ios.bundleIdentifier renomeados para um identificador de sua propriedade
EXPO_PUBLIC_API_URL no ambiente de construção aponta para a produção API
Política de privacidade hospedada em um URL público e vinculada na listagem da loja
O formulário de segurança de dados corresponde à coleção real: e-mail de autenticação, tráfego API, qualquer coisa que seu produto adicione
Credenciais de conta de demonstração funcionais nas notas de revisão da App Store
Paywall oculto ou apoiado por um direito RevenueCat verificado
Retorno de link direto, restauração de sessão e saída verificada em um dispositivo físico
Capturas de tela e listagem de ativos preparados para cada loja

Recuperar-se de uma rejeição

As rejeições chegam com uma referência política – corrigir a causa declarada em vez de adivinhar o sintoma. Uma incompatibilidade de segurança de dados geralmente significa que o formulário está errado, e não o aplicativo. Uma rejeição obrigatória de login geralmente significa que as notas de revisão não tinham uma conta demo. Reenvie com notas de versão que nomeiem claramente a correção.

O passo a passo completo – comandos de credenciais, ordem de operações do console e um manual de rejeição – está em docs/mobile-store-submission.md no repositório.

Instalação e configuração

Para publicar um app nativo são necessárias contas de desenvolvedor da Apple e/ou Google, identificadores de app, credenciais de assinatura e revisão da loja. O perfil de produção do EAS incrementa os números de build da loja; submit.production envia uma versão em rascunho para a faixa interna do Google Play. Os identificadores de bundle e o esquema do app estão em apps/mobile/app.config.ts.

As implantações web e os lançamentos nas lojas têm ritmos diferentes. Mantenha a API compatível com a versão do app mais antiga ainda suportada ou controle novos recursos com estado gerenciado pelo servidor.

corepack pnpm --filter @supastack/mobile build
eas build --profile production --platform ios
eas build --profile production --platform android
eas submit --profile production --platform ios
eas submit --profile production --platform android

Fluxo de implementação

Antes de habilitar compras nativas, configure o projeto RevenueCat, os produtos das lojas e o entitlement. A chave secreta do servidor e o valor Authorization do webhook devem ficar somente na configuração do servidor; as chaves SDK de iOS e Android são valores públicos de build. Desative o acesso sandbox em produção.

Mantenha materiais da loja — capturas de tela, descrição, respostas de privacidade e avisos de compra — nos materiais de release do próprio produto. Compras e restaurações RevenueCat são verificadas com o estado atual do assinante no servidor antes de o app exibir acesso.

Verificação e resolução de problemas

Teste exatamente o artefato que será enviado: callback de login, restauração de sessão, compra e restauração, atualização dos direitos de acesso no servidor, troca de espaço de trabalho, links profundos e comportamento offline em um dispositivo físico. Um export local bem-sucedido não é um build pronto para as lojas.

Registre número do build, faixa da loja, estado da revisão e ambiente da API usado em cada release. Uma rejeição na revisão é um evento de release: corrija os metadados ou indicadores de capacidade em vez de adivinhar mudanças no código.

Próxima plataforma: a aba Desktop apresenta o mesmo produto no shell Tauri.