> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Publicação nas lojas de apps Diferencie um build funcional de uma versão que os usuários conseguem instalar. ## 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. [Prepare a compilação nativa e os identificadores](https://supastack.dev/pt/docs/mobile/builds.md) [Instruções atuais de envio da loja de Expo](https://docs.expo.dev/submit/introduction/) [Diretrizes atuais de revisão de aplicativos da Apple](https://developer.apple.com/app-store/review/guidelines/) [Instruções de lançamento do Google Play](https://support.google.com/googleplay/android-developer/answer/9859455) ``` 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. ## Seguinte [Visão geral do desktop](https://supastack.dev/pt/docs/desktop.md)