Estou Publicando 3 Apps ao Mesmo Tempo — Aqui Está Como Automatizei Tudo

Três apps. Duas lojas. Seis configurações de metadata. Doze conjuntos de screenshots. Certificados, provisioning profiles, age ratings, privacy policies, keywords em múltiplos idiomas.

Quando comecei a publicar o segundo app, percebi que ia enlouquecer fazendo tudo pelo painel web. Quando chegou o terceiro, já tinha automatizado quase tudo.

O problema real: a loja é mais trabalho que o app

Desenvolver o app é a parte divertida. O inferno começa quando você abre o App Store Connect ou o Google Play Console pela primeira vez.

Para cada app, você precisa:

• Criar o app ID, configurar certificados e provisioning profiles
• Escrever título, subtítulo, descrição, keywords — em cada idioma
• Gerar screenshots para 4+ tamanhos de tela (iPhone 6.7", 6.5", 5.5", iPad)
• Configurar age rating (respondendo uns 15 campos sobre violência e conteúdo)
• Definir categorias, preço, política de privacidade
• Build, assinar, upload, esperar review

Multiplique isso por 3 apps e duas lojas. São dezenas de horas clicando em formulários web.

A boa notícia: tudo isso pode ser feito pela linha de comando.

As ferramentas que uso (e como se complementam)

Depois de muito apanhar, cheguei numa stack de 4 ferramentas que cobrem 100% do fluxo. Cada uma tem seu papel.

Fastlane — o canivete suíço local

O Fastlane é open source, gratuito, e faz tudo. Screenshots automatizados, code signing, metadata, upload para TestFlight e Play Store. Você define "lanes" (fluxos) num arquivo Ruby e roda do terminal.

No meu Fastfile, tenho lanes separadas para cada operação:

# Build local + TestFlight
fastlane ios build_beta

# Só metadata e screenshots, sem build
fastlane ios metadata

# Build Android + upload para track interno
fastlane android build_beta

# Promover de interno para produção
fastlane android release

O Fastlane brilha no controle total. Consigo fazer build local, assinar com meus certificados, e subir direto — sem depender de nenhum serviço cloud.

O lado ruim: roda local. Build de iOS consome CPU e leva minutos. E a configuração inicial em Ruby pode ser chata se você não está acostumado.

ASC CLI — o App Store Connect no terminal

O ASC CLI é mais recente e resolve um problema específico: gerenciar o App Store Connect sem abrir o navegador.

Eu uso para coisas que o Fastlane também faz, mas de forma mais direta:

# Listar builds recentes
asc builds list --app 6760364479 --limit 5

# Upload de IPA
asc builds upload --app 6760364479 --ipa build/reino.ipa

# Push metadata (título, descrição, keywords)
asc metadata push --app 6760364479 --version 1.3.0 --dir .asc/metadata

# Ver status do auth
asc auth status

O ponto forte é que funciona como CLI pura — sem Ruby, sem configuração complexa. Instalou, autenticou, usou.

Combinei o ASC CLI com scripts Node.js para automatizar coisas mais complexas como age rating, pricing, e submissão para review:

# Setup completo de um app novo
node scripts/setup-app-store.js    # Preço, privacy, categorias
node scripts/fix-age-rating.js     # Age rating automático
node scripts/upload-ios-screenshots.js  # Screenshots por locale
node scripts/submit-for-review.js  # Submeter para Apple Review

EAS (Expo Application Services) — build na nuvem

Se seus apps são Expo/React Native (os meus são), o EAS é a forma mais simples de fazer build sem precisar de um Mac.

O free tier dá 30 builds por mês (até 15 iOS), com prioridade mais baixa. Para 3 apps em desenvolvimento ativo, é suficiente na maioria dos meses.

# Build de produção e auto-submit para TestFlight
eas build --platform ios --profile production --auto-submit --non-interactive

# Submit separado (se já tem o build)
eas submit --platform ios --latest

Configuração mínima no eas.json:

{
  "submit": {
    "production": {
      "android": {
        "serviceAccountKeyPath": "./google-service-account.json",
        "track": "internal"
      },
      "ios": {
        "ascAppId": "6760364479"
      }
    }
  }
}

O EAS resolve o maior problema de quem não tem Mac disponível 24/7 ou não quer torrar CPU local com builds. Mas quando os 30 builds acabam, o plano pago começa em US$19/mês.

GitHub Actions — CI/CD automático

Para o fluxo mais maduro, tenho um workflow que builda e faz submit automaticamente quando faço push:

name: EAS Build & Submit
on:
  push:
    branches: [develop]

jobs:
  build-and-submit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: eas build --platform ios --profile preview --auto-submit --non-interactive

Push no develop → build automático → TestFlight. Push no main → build de produção → App Store. Sem tocar em nada.

GitHub Actions é gratuito para repos públicos e dá 2000 minutos/mês para privados. Como o build pesado roda no EAS (não no runner do GitHub), os minutos do Actions são consumidos minimamente.

O workflow completo: do código à loja

Com tudo configurado, meu fluxo para publicar uma versão nova é:

1. Desenvolvimento — codar, testar no simulador
2. Push para develop — GitHub Actions dispara build EAS → TestFlight automático
3. Testar no TestFlight — instalar no iPhone real, validar
4. Merge para main — build de produção automático
5. Metadata — asc metadata push + fastlane ios metadata para screenshots
6. Submit — node scripts/submit-for-review.js ou via painel se preferir

Do push ao TestFlight: zero interação manual. Do TestFlight à App Store: 2 comandos.

O ângulo que ninguém fala: IA + CLI = superpoderes

Aqui está o que conecta tudo. Quando toda a configuração de loja é feita via CLI, agentes de IA conseguem operar a loja por você.

Eu uso o Claude Code como meu SRE — ele gerencia minha infraestrutura inteira via Telegram. E porque Fastlane, ASC CLI e EAS são todos CLI-first, o Claude consegue:

• Gerar metadata — descrições otimizadas, keywords por idioma, textos promocionais
• Executar deploys — rodar fastlane ios build_beta ou eas build --platform ios
• Diagnosticar problemas — "por que o build falhou?" → ler logs e sugerir fix
• Configurar apps novos — rodar os scripts de setup automaticamente

Isso é impensável com interfaces web. Você não consegue pedir para um AI agent "abrir o App Store Connect, clicar em App Information, mudar a categoria para Business." Mas pode pedir: "roda asc metadata push com a descrição atualizada."

Ferramentas CLI-first não são só conveniência — são a interface que conecta humanos e agentes de IA.

Comparação rápida

Não tente usar só uma

A tentação é escolher uma ferramenta e usar para tudo. Não funciona. O Fastlane não faz build na nuvem. O EAS não faz metadata. O ASC CLI não faz build.

A combinação que funciona para mim:

• EAS para builds (cloud, sem esquentar meu Mac)
• ASC CLI para metadata e gerenciamento do App Store Connect
• Fastlane para screenshots e quando preciso de build local
• GitHub Actions para o gatilho automático

E por cima de tudo: Claude Code como orquestrador, rodando qualquer uma dessas ferramentas quando preciso.

O takeaway

Se você está publicando mais de um app, automatize a loja antes de automatizar o build. O build você faz uma vez e funciona. A loja é um inferno de formulários que muda a cada update da Apple e do Google.

Comece pelo metadata — título, descrição, keywords. Depois screenshots. Depois code signing. Cada camada que você automatiza economiza horas em cada release futuro.

E quando tudo for CLI, você vai poder delegar para agentes de IA. Esse é o futuro que já está funcionando aqui.

Se você está construindo apps e quer acelerar seu fluxo de deploy, eu faço mentoria individual para devs que querem operar como senior.