Noções Básicas de Operações de Loja

10 exemplos para você começar com Operações de Loja - 7 básicos e 3 intermediários. Cada exemplo avança um passo no caminho compilação → teste → envio → lançamento → monitoramento para aplicativos Expo SDK 57 na App Store Connect e Google Play Console.

Pré-requisitos

Operações de loja pressupõem que você já envia binários com EAS Build. Crie ou confirme um projeto Expo fixado no SDK 57:

npx create-expo-app@latest MyStoreApp --template blank-typescript
cd MyStoreApp
npx expo install expo-dev-client
eas init

Confirme as versões em package.json:

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

Vincule o projeto ao EAS e configure pelo menos um perfil de compilação production em eas.json. Uploads para a loja exigem compilações de distribuição para loja - não artefatos de development ou simulador.

Ferramentas: Estes exemplos visam Expo SDK 57, React Native 0.86 e React 19.2.3. Automatize uploads com EAS Submit; detalhes da política estão em App Store Review Guidelines e Permissions & Play Policy.

Exemplos Básicos

1. Aumento de Versão em app.config.ts

Todo upload para a loja precisa de um novo número de compilação (iOS) e versionCode (Android). A version de marketing pode permanecer a mesma para hotfixes; inteiros nativos devem sempre aumentar.

// app.config.ts
import type { ExpoConfig } from "expo/config";
 
const config: ExpoConfig = {
  expo: {
    name: "ShopApp",
    slug: "shop-app",
    version: "2.4.0",
    ios: {
      bundleIdentifier: "com.example.shopapp",
      buildNumber: "240012", // CFBundleVersion - increment every upload
    },
    android: {
      package: "com.example.shopapp",
      versionCode: 240012, // monotonic integer - increment every upload
    },
  },
};
 
export default config;

• version é o semver visível ao usuário em ambas as lojas
• buildNumber / versionCode devem aumentar mesmo para reconstruções de "mesma versão"
• CI pode derivar inteiros de git rev-list --count HEAD - documente o esquema no README
• Execute npx expo config --type public antes da compilação para capturar erros de digitação

Relacionado: Fluxo de Trabalho da App Store Connect - metadados vinculados a strings de versão

2. Compilação EAS de Produção para Ambas as Plataformas

O envio para a loja começa com binários com formato de lançamento assinados com credenciais de produção.

# One command per platform (or both)
eas build --profile production --platform ios
eas build --profile production --platform android
 
# Verify build finished
eas build:list --limit 5

// eas.json - minimum production profile
{
  "build": {
    "production": {
      "distribution": "store",
      "ios": { "simulator": false },
      "android": { "buildType": "app-bundle" }
    }
  }
}

• distribution: "store" produz IPA para App Store e AAB para Play - não links internos ad-hoc
• Baixe e teste rapidamente em dispositivos físicos antes do envio - simuladores ocultam push, biometria e IAP
• Marque o commit git que produziu a compilação - incidentes de loja rastreiam de volta à origem

3. Portão Pré-Loja com expo-doctor

Capture desvios de SDK e erros de configuração antes de gastar um ciclo de revisão.

npx expo-doctor
npx expo config --type public > /tmp/public-config.json
npm run typecheck
npm test -- --ci

<!-- docs/release-gates.md - copy into every release PR -->
## Pre-submit gate
- [ ] expo-doctor green
- [ ] Release build installed on iOS + Android device
- [ ] Cold start, login, paywall, push tap, deep link, logout, account delete
- [ ] Privacy labels / Data safety match SDK inventory
- [ ] Review notes updated with demo credentials

• expo-doctor sinaliza versões de pacotes incompatíveis com o SDK 57
• Trate o teste rápido em dispositivo como não negociável - rejeições da Diretriz 2.1 são frequentemente "travamentos na inicialização"
• Mantenha os portões no git para que novos engenheiros não dependam de memória tribal

4. TestFlight e Faixa Interna do Play Antes da Revisão Pública

Valide assinaturas, permissões e formulários de política em pipelines reais da loja antes que usuários de produção ou a Revisão de Aplicativo vejam a compilação.

# iOS → TestFlight (same binary as App Store submit)
eas build --profile production --platform ios
eas submit --platform ios --latest
 
# Android → internal testing track
eas submit --platform android --profile production --latest
# eas.json submit.android.track: "internal"

• Faixas internas capturam ID de bundle incorreto, permissão de push ausente e lacunas de Segurança de dados de forma barata
• TestFlight externo e beta aberto adicionam latência de revisão - planeje o calendário de acordo
• Veja TestFlight Distribution e Internal Testing Tracks

5. Instantâneo de Metadados da Loja no Repositório

Cópia de listagem, URLs e palavras-chave não devem existir apenas no App Store Connect ou Google Play Console - versione-os ao lado do código.

// store/metadata.ts - single source for both stores
export const storeMetadata = {
  appName: "ShopApp",
  subtitle: "Scan, save, checkout fast",
  shortDescription:
    "Shop smarter with barcode scan, saved lists, and secure checkout.",
  fullDescription: `ShopApp helps you build grocery lists, compare prices, and check out in seconds.
 
• Barcode scanner for in-aisle adds
• Shared household lists
• Secure sign-in and account deletion in Settings`,
  keywords: ["grocery", "scanner", "shopping", "list"],
  privacyPolicyUrl: "https://example.com/privacy",
  supportUrl: "https://example.com/support",
  marketingUrl: "https://example.com",
} as const;

• Cole deste arquivo no Connect e Play - reduz a deriva de erros de digitação entre plataformas
• URL da política de privacidade deve carregar sem login - revisores e bots do Play verificam isso
• Localize em store/metadata.en.ts, store/metadata.de.ts quando adicionar locais

Relacionado: Fluxo de Trabalho da App Store Connect - lista completa de metadados

6. Modelo de Notas de Revisão para a Revisão de Aplicativo

Revisores precisam de credenciais funcionais, recursos desativados e caminhos de reprodução - especialmente para aplicativos Expo com login restrito.

<!-- store/review-notes-ios.md -->
## App Review notes (iOS)
 
**Demo account**
- Email: reviewer@example.com
- Password: ReviewDemo2026!
 
**How to test core flow**
1. Launch app → tap Sign In → use demo account above
2. Home → tap Scan → grant Camera when prompted → scan any UPC
3. Profile → Settings → Delete Account (required for account-creation apps)
 
**Backend**
- Production API; no VPN required
- Push notifications: send test from Profile → Notification test
 
**ATT / tracking**
- We do not track users across apps; ATT prompt is not shown
- Analytics: first-party only (Sentry crashes, no ad ID)
 
**Contact**
- engineering-mobile@example.com (responds within 4 business hours)

• Anexe o mesmo conteúdo em App Store Connect → Informações de Revisão do Aplicativo → Notas
• Atualize senhas a cada lançamento - contas de demonstração expiradas causam falsas rejeições
• Mencione se os recursos são restritos por geolocalização ou exigem hardware (NFC, LiDAR)

7. eas submit para Ambas as Lojas

Automatize o upload após a aprovação do QA - humanos ainda escolhem quando a compilação vai ao ar.

eas submit --platform ios --latest
eas submit --platform android --latest

// eas.json - submit profiles
{
  "submit": {
    "production": {
      "ios": {
        "appleId": "you@example.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCDE12345"
      },
      "android": {
        "serviceAccountKeyPath": "./secrets/play-service-account.json",
        "track": "production"
      }
    }
  }
}

• O upload iOS vai para App Store Connect → TestFlight primeiro; você envia manualmente para revisão
• track: "production" do Android carrega para produção - use internal até que os formulários de política sejam aprovados
• Armazene credenciais da loja em Segredos do EAS ou cofres de CI criptografados - nunca comite chaves JSON

Relacionado: EAS Submit - configuração de credenciais e integração de CI

Exemplos Intermediários

8. Branch de Lançamento Coordenado para Ambas as Lojas

Envie iOS e Android de um único branch de lançamento com um checklist compartilhado e dependências congeladas.

git checkout -b release/2.4.0
# bump version + build numbers in app.config.ts
git commit -am "chore(release): 2.4.0 build 240012"
eas build --profile production --platform all --non-interactive

# .github/workflows/release.yml (excerpt)
jobs:
  store-submit:
    if: github.ref == 'refs/heads/release/2.4.0'
    steps:
      - run: npx expo-doctor
      - run: eas submit --platform ios --latest --non-interactive
      - run: eas submit --platform android --latest --non-interactive

• Não selecione recursos não relacionados em release/* - hotfixes recebem seu próprio branch de patch
• Se uma plataforma rejeitar, marque a compilação aprovada - não reconstrua ambas desnecessariamente
• Registre os horários reais de envio em CHANGELOG.md

9. Dashboard de Monitoramento Pós-Envio

A aprovação da loja não é a linha de chegada - monitore falhas e ANRs à medida que a porcentagem de rollout aumenta.

// lib/releaseHealth.ts - tag sessions with store build
import * as Application from "expo-application";
import Constants from "expo-constants";
 
export function releaseContext() {
  return {
    appVersion: Application.nativeApplicationVersion,
    buildNumber: Application.nativeBuildVersion,
    updateId: Constants.expoConfig?.updates?.checkAutomatically,
    platform: Application.applicationId,
  };
}

## First 72 hours after live
- [ ] Crash-free sessions ≥ 99.5% (Sentry / Play Vitals)
- [ ] No spike in 1-star reviews mentioning "crash" or "login"
- [ ] iOS phased release day 1–2: hold at 1% if crashes climb
- [ ] Play staged rollout: pause at 20% if ANR rate doubles baseline
- [ ] Support inbox macro ready for "update app" replies

• Compare o número de compilação nos relatórios de falha com a compilação que você promoveu - OTA não pode corrigir regressões nativas
• Emparelhe com procedimentos de Phased Release & Rollback
• Defina limites do PagerDuty antes do rollout - não depois que o Twitter notar

10. Calendário do Trem de Lançamento (Compilação → Ao Vivo)

Um calendário recorrente evita surpresas de "envio de sexta-feira" e alinha o marketing com o tempo de lançamento faseado.

<!-- docs/release-train.md -->
| Week | Activity | Owner |
|------|----------|-------|
| T-14 | Feature freeze on `main` | EM |
| T-10 | Cut `release/x.y.z`, bump build numbers | Mobile lead |
| T-7  | TestFlight + Play internal to QA | QA |
| T-5  | Metadata + privacy forms signed off | PM + Legal |
| T-3  | `eas submit` both platforms | Mobile lead |
| T-2  | iOS: submit for review; Android: production with 5% rollout | Mobile lead |
| T-0  | iOS: release with phased 7-day; Android: 20% → 50% → 100% | Mobile lead |
| T+1  | Go/no-go from crash dashboards | On-call |

• Lançamento faseado do iOS leva até 7 dias para atingir 100% - planeje os pushes de marketing após o dia 3-4 se as métricas estiverem limpas
• Rollout escalonado do Play é porcentagem manual - documente quem pode pausá-lo (veja o runbook de incidentes)
• Formulários de comerciante do Digital Services Act da UE e classificações etárias devem ser concluídos antes de T-3 ou os territórios da UE serão bloqueados

FAQs

Relacionados

• Fluxo de Trabalho da App Store Connect - lista iOS e checklist de revisão
• Fluxo de Trabalho do Google Play Console - lista Play e checklist de política
• EAS Submit - upload automatizado
• App Store Review Guidelines - rejeições comuns do iOS
• Permissions & Play Policy - permissões do Android e segurança de dados
• Phased Release & Rollback - pause o rollout com segurança

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