Tempo de análise da App Store: 64 decisões reais, mediana de 73 horas

Resumo: Eu juntei todos os e-mails de decisão do App Review que a minha conta de desenvolvedor já recebeu: 64 decisões sobre 21 apps de iPhone, de 10 de setembro a 12 de outubro de 2026, cada uma com o horário "Submitted" informado pela própria Apple e o momento em que a decisão chegou. A espera mediana foi de 73 horas. A página da Apple diz que ela analisa "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (pelo menos 50% das submissões em menos de 24 horas e 90% em menos de 48 horas). Os meus números: 19% em até 24 horas, 27% em até 48. Atualizações de apps que já estavam na loja levaram uma mediana de 64 horas, compras dentro do app enviadas sozinhas levaram 12, e 0 de 21 apps novos foram aprovados na primeira submissão.

Resposta curta para quem chegou pela busca. Se você está planejando um lançamento em 2026, reserve 3 dias por rodada de análise para uma atualização, de 2 a 5 dias para a aprovação de um app novinho, e pelo menos uma rodada extra para um app novo numa conta nova, porque a primeira costuma voltar com uma pergunta. Uma análise que fica parada uma semana não é uma aprovação lenta. Nos meus dados, toda espera acima de 5,1 dias, menos uma, terminou numa rejeição por spam pela guideline 4.3.

Se você ainda está na fase de "quanto isso vai me custar", a calculadora gratuita de custo de app para iPhone transforma funcionalidades em horas e dólares; este artigo trata da parte que nenhuma calculadora mostra, o tempo de calendário entre "Submit" e "Ready for Distribution". Eu crio esses apps num PC com Windows, sem Mac (aqui está o pipeline), então todas as submissões abaixo saíram de um job de CI ou do site do App Store Connect, nunca do Xcode.

Quanto tempo leva a análise da App Store em 2026?

Aqui estão os números, divididos do jeito que você vai encontrá-los na prática. "Espera" é o tempo entre a linha "Submitted" no e-mail da Apple e o momento em que o e-mail de decisão chegou, então inclui a fila, não só os minutos que um revisor passou com o app.

O que você envia	Decisões	Espera mediana	Mais rápida	Mais lenta	Aprovados
Só compras dentro do app	5	12,2 h	11,7 h	13,4 h	5 de 5
Atualização de um app publicado	16	64,4 h	6,3 h	203,6 h	11 de 16
App novo (rodadas normais)	21	51,2 h	3,1 h	120,5 h	8 de 21
App novo (os dois lotes de spam 4.3)	22	187,8 h	167,7 h	223,3 h	0 de 22
Todos	64	73,1 h	3,1 h	223,3 h	24 de 64

Duas coisas saltam aos olhos. Rejeições e perguntas sobre apps novos voltam rápido (as 13 normais tiveram mediana de 27,8 horas), porque o revisor para no primeiro problema. Aprovações demoram mais: as 8 aprovações de primeira versão tiveram mediana de 69,9 horas e nenhuma voltou em menos de 48. Então uma resposta rápida é, estatisticamente, má notícia.

O experimento: um par de horários por e-mail

O App Store Connect não oferece um histórico da duração das análises. A sua caixa de entrada oferece. Toda decisão que a Apple manda tem o mesmo formato: um assunto que diz "Review of your App (iOS) submission is complete." ou "There's an issue with your App (iOS) submission.", e uma linha no corpo como Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time. O horário de envio do próprio e-mail é o horário da decisão. Esse é o conjunto de dados inteiro.

Fiz uma busca no Gmail com uma consulta usando operadores de pesquisa, from:no_reply@email.apple.com newer_than:60d, em 17 de outubro de 2026. Ela retornou 69 conversas; 64 são decisões (as outras cinco são as boas-vindas do App Store Connect, a aprovação do acesso à API, duas mensagens de "Welcome to the App Store" e um "Thank you for submitting"). A conta foi aberta em 10 de setembro, então este é o histórico completo, não uma amostra. Depois, o parsing:

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

Cada linha também é marcada pelo que havia na submissão: a primeira versão de um app novo, uma atualização, ou compras dentro do app sozinhas. Tirei isso dos próprios registros de cada app (o histórico de commits dos repositórios e as minhas anotações) e conferi o lote ambíguo com o corpo do e-mail, que lista os itens: a submissão do Chain na noite de 8 de outubro diz In-App Purchases (6) e nenhuma versão do app. Os motivos de rejeição não aparecem nos e-mails (o corpo só diz "We noticed an issue"), então vieram dos textos do Resolution Center que eu tinha salvado e das respostas que enviei.

O que este método não enxerga: submissões que cancelei antes de uma decisão (sem e-mail, sem linha) e o momento exato em que um revisor abriu o app. Se você quer o "tempo em análise" em vez do "tempo de espera", a API do App Store Connect expõe o estado da versão, mas não o histórico, então você teria de consultá-la periodicamente por conta própria.

O número de 24 horas da Apple vs o meu

A redação da Apple é cuidadosa: ela diz que analisa metade das submissões em menos de 24 horas. Isso pode ser verdade e mesmo assim não bater com o que você sente, por três motivos que aparecem nos meus dados.

Primeiro, o relógio começa numa fila. As minhas aprovações se concentram quase exatamente no mesmo tempo decorrido. Sete das 16 atualizações saíram entre 63,5 e 64,5 horas, porque foram enviadas juntas na manhã de sábado, 26 de setembro, e decididas juntas, num intervalo de 32 minutos, no fim da noite de segunda-feira, horário do Pacífico. Independentemente de quanto a análise em si levou, a espera foi definida pelo momento em que a fila chegou nelas.

Segundo, a Apple parece não trabalhar aos sábados em decisões novas, pelo menos não nas minhas. Das 64 decisões, no horário do Pacífico: segunda 35, sexta 10, quinta 7, quarta 5, domingo 4, terça 3, sábado 0. A pilha de segunda está inflada pelos dois lotes de spam (22 decisões), mas mesmo sem eles nada caiu num sábado. Então sim, o App Review trabalha aos domingos (duas das quatro decisões de domingo foram aprovações), mas uma submissão de sábado de manhã ainda esperou até segunda à noite.

Terceiro, a cauda lenta não é aleatória. Sem os dois lotes 4.3, os meus números ficam bem mais perto dos da Apple: 29% em até 24 horas, 40% em até 48. As 22 rejeições por spam levaram de 7 a 9,3 dias cada. Esperas longas eram um sinal, não azar.

A via rápida são as compras dentro do app. Cinco submissões só de IAP (temas e pacotes novos para cinco apps publicados, enviados pela API tarde da noite de quinta-feira, 8 de outubro) voltaram todas aprovadas entre 11,7 e 13,4 horas depois, num intervalo de 95 minutos entre si. Se você precisa lançar um novo preço ou um pacote rapidamente, envie como submissão própria e deixe o binário em paz.

Apps novos: 0 de 21 aprovados na primeira tentativa

Cada um dos 21 apps teve a primeira submissão devolvida. Parece alarmante até você ler os motivos. Dez dos 21 e-mails da primeira rodada foram guideline 2.1 "Information Needed" (os outros 11 foram o lote de spam abaixo), as perguntas de rotina que uma conta de desenvolvedor nova recebe: mande uma gravação de tela do app num aparelho, explique as funções principais, diga se precisa de login, liste os serviços externos. As diretrizes da Apple pedem isso de antemão; os revisores perguntam de novo mesmo assim quando a conta é nova.

A solução que funcionou foi parar de tratar as notas de análise como formalidade. Todo app agora vai com um Store/review-notes.md que o pipeline envia para os detalhes de análise do App Store Connect, escrito como um roteiro que um revisor consegue seguir em menos de um minuto, incluindo como chegar a cada tela paga:

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

Depois da primeira rodada de 2.1, Chain, Ironbook e Quiver foram reenviados em 22 de setembro às 4h21 da manhã, horário do Pacífico, com respostas e uma gravação de tela, e os três foram aprovados de 51 a 67 horas depois. Dos 8 apps que chegaram à loja, o tempo mediano entre a primeiríssima submissão e a primeira aprovação foi de 4,4 dias (de 3,75 a 7,2). Esse é o número honesto para colocar num plano de lançamento de um app novo numa conta nova: não 24 horas, mais perto de uma semana útil.

Os outros motivos da primeira rodada valem a pena conhecer, porque cada um é barato de evitar:

• 5.1.1 privacidade, duas vezes, mesmo app. O Minder, um timer de foco cujos olhos de desenho podem seguir o seu rosto (a animação dos olhos está neste texto sobre SwiftUI), recebeu a pergunta sobre exatamente quais dados do rosto coleta, guarda e compartilha. A resposta (uma posição x/y vinda do framework Vision da Apple, no próprio aparelho, nunca armazenada) tinha de estar na política de privacidade, não só na resposta. Uma semana depois ele foi rejeitado de novo porque a própria URL da política de privacidade tinha parado de carregar. Corrigi a hospedagem, reenviei seis minutos depois do e-mail, e ele foi aprovado 24,8 horas depois.
• 1.4.1, alegações de saúde precisam de fontes. O Race Fuel dá metas de carboidrato, líquidos e sódio para provas de resistência. A Guideline 1.4.1 exige que números próximos da área médica venham com citações. A solução foi uma tela de fontes com sete artigos com link de DOI e um link embaixo de cada número.

Guideline 4.3: uma semana de silêncio, depois 11 rejeições em 30 segundos

Onze dos meus apps (um registro de manutenção do carro, um timer de estacionamento, um inventário da casa, um registro de preços de mercado, um controle de remédios para pets, um quadro de tarefas domésticas, um controle de gorjetas, uma calculadora de notas, um registro de boulder, uma calculadora de pace de corrida e uma calculadora de horário limite para cafeína) foram enviados em 26 de setembro. Ficaram na fila de 8,7 a 9,3 dias. Então, na segunda-feira, 5 de outubro, os 11 e-mails de rejeição chegaram entre 5:29:32 e 5:30:02 da tarde, horário do Leste. O mesmo texto para todos os apps: guideline 4.3 Spam mais 4.2.6, apps feitos a partir de um template ou de um serviço de geração de apps, com nove perguntas para responder. O Resolution Center mostrava todas as mensagens com horário de 5:29 da tarde.

O texto da rejeição era explícito sobre o que fazer em seguida: se você acha que o app já cumpre as regras, não reenvie, responda à mensagem e responda às nove perguntas. Respondi a cada uma (sem beta público, testado com execuções automatizadas no Simulator; uma classe de compra StoreKit e um driver de teste compartilhados, informados abertamente), abri recursos ao App Review Board para os 11 e também reenviei os 11 naquela mesma tarde. Os reenvios foram o erro. Sete dias depois, na segunda-feira, 12 de outubro, mais 11 rejeições chegaram num intervalo de 27 segundos, cada uma 7,0 dias depois do respectivo reenvio.

O que os dados dizem sobre a 4.3, para você que está planejando o seu próprio lançamento:

• A espera é o sinal. Nos meus dados, toda análise que passou de 5,1 dias, menos uma, foi uma rejeição 4.3. A exceção foi o Clear the Strait 1.1.1, que reenviei junto com uma longa explicação por escrito de como o jogo funciona depois que o revisor perguntou; levou 8,5 dias e foi aprovado.
• A decisão é por desenvolvedor, não por app. Os dois lotes chegaram em menos de 30 segundos. O que quer que tenha sido a análise, não foram 11 sessões separadas com 11 apps.
• Não reenvie sem mudanças. O próprio e-mail da Apple dizia que um reenvio sem mudanças substanciais seria rejeitado de novo. E foi, num relógio de sete dias, o que custou uma semana por rodada.

Antes eu tinha medido quanto código Swift esses apps realmente compartilham. A sobreposição mediana com o resto da conta foi de 34,5%, e os dois apps mais parecidos da conta (um diário de golfe e um diário de tênis) estão ambos publicados. A semelhança de código sozinha não explicou quem foi sinalizado; os números estão no artigo sobre custo de app para iPhone. A minha leitura, apresentada como leitura: 11 utilitários de propósito único vindos de uma conta nova, enviados na mesma manhã, parecem uma fábrica de apps vistos da fila, por mais diferentes que sejam as telas. Se você tem várias ideias pequenas de app, lance uma, deixe ela acumular avaliações e atualizações e espace as outras, ou junte todas num app só com compras dentro do app, que é exatamente o que a guideline 4.3(a) sugere.

O calendário inteiro numa imagem

Visto como calendário, o padrão é óbvio. As duas primeiras semanas são barras vermelhas curtas (perguntas 2.1 rápidas) seguidas de barras verdes de dois a cinco dias. A partir de 26 de setembro a conta se divide em duas: apps que já estavam publicados passam atualizações em cerca de 64 horas, enquanto os 11 utilitários novos ficam em duas barras vermelhas longas que terminam na mesma janela de 30 segundos todas as vezes.

Depois da aprovação: no ar em minutos

O e-mail diz que "pode levar até 24 horas" para um item aprovado aparecer. Para os meus 8 apps publicados, o horário de lançamento público veio bem mais rápido. Li esse dado na própria iTunes Search API da Apple, que retorna um currentVersionReleaseDate para cada app que um desenvolvedor tem na loja:

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

Comparado aos e-mails de aprovação, esse horário de lançamento caiu de 0,7 a 7,5 minutos depois da aprovação, mediana de 2,5 minutos, para os 8 apps. Se a data do seu lançamento importa (imprensa, campanha de anúncios, um horário no Product Hunt), escolha o lançamento manual para que uma aprovação às 2 da manhã não entre no ar antes do seu anúncio.

Enquanto espera, você vai querer ver o estado sem abrir o App Store Connect. Esta é a verificação de status que cada um dos repositórios dos meus apps carrega; ela pede à API do App Store Connect as últimas cinco versões e builds:

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

A submissão em si é uma única chamada do fastlane no fim de um job de CI, usando upload_to_app_store. As três respostas de submission_information importam mais do que parece: são as perguntas de conformidade de exportação, identificador de publicidade e direitos de conteúdo, e respondê-las em código significa que uma submissão nunca trava esperando alguém clicar num formulário.

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

A análise da App Store funciona nos fins de semana?

Em parte. Quatro das minhas 64 decisões vieram num domingo, horário do Pacífico: a primeira aprovação do Pocket Beings às 4h05 da tarde de 20 de setembro, e três na noite de 11 de outubro (duas atualizações 1.2 devolvidas, Chain 1.2 aprovado às 10h42 da noite). Nenhuma veio num sábado. As 19 submissões que fiz no sábado, 26 de setembro, foram todas decididas na segunda à noite ou depois, e as cinco atualizações que enviei na quinta-feira, 8 de outubro, voltaram no domingo à noite e no começo da segunda. Se você puder escolher, envie de segunda a quarta; o que for enviado na quinta ou depois, considere que vai cair depois do fim de semana.

O que eu faria no seu projeto

1. Planeje em rodadas, não em dias. Uma rodada é cerca de 3 dias para uma atualização e de 2 a 5 para um app novo. Um app novo numa conta nova precisa de duas rodadas: reserve uma semana útil entre a primeira submissão e a aprovação.
2. Escreva as notas de análise como um roteiro de teste. Login (ou "sem login"), onde está cada tela paga, como provocar os casos-limite, quais dados você coleta. Anexe uma gravação de tela à primeira submissão para que a 2.1 não tenha nada a perguntar.
3. Confira se a URL da sua política de privacidade carrega antes de cada submissão. Um único link quebrado me custou uma rodada inteira.
4. Envie compras dentro do app separadamente quando a velocidade importar. 12 horas, 5 de 5 aprovadas.
5. Trate uma análise de mais de 5 dias como alerta. Prepare respostas para as nove perguntas da 4.3 antes de precisar delas.
6. Quando a Apple disser para responder, não reenvie. Um reenvio sem mudanças me rendeu outra rejeição idêntica, sete dias depois, na hora exata.
7. Corrija e reenvie rápido quando o problema for concreto. O link de privacidade quebrado do Minder: reenviado em 6 minutos, aprovado em 25 horas.
8. Precisa de mais rapidez? A Apple tem um pedido de análise acelerada para correções de bugs críticos e eventos com data marcada. Eu não usei, então não tenho número para isso.
9. Meça os seus. Rode a mesma consulta do Gmail na sua conta. Dez minutos dão a você o seu calendário real de análises, que vale mais do que qualquer média, inclusive esta.

Os dados, e como rodar de novo

Está tudo numa pasta: emails.py (as 64 linhas transcritas dos e-mails, com a consulta do Gmail e o horário da coleta), analyze.py (medianas, faixas, lotes, intervalo entre aprovação e publicação), summary.json (cada número calculado neste artigo) e make_charts.py (os gráficos). Dados coletados em 17 de outubro de 2026 por volta das 10h15 da noite, horário do Leste; a consulta ao iTunes rodou por volta das 10h20 da noite. A afirmação da Apple foi lida em developer.apple.com/distribute/app-review na mesma noite, e o fluxo de submissão está descrito na página de ajuda Submit for review da Apple. Uma conta de desenvolvedor, 21 apps, cinco semanas: uma amostra pequena, mas completa, e o único tipo de dado sobre tempo de análise que você consegue realmente verificar.

Se você desenvolve no Windows e quer o mesmo pipeline (builds na nuvem, assinatura, capturas de tela, submissão via fastlane, o modelo de notas de análise) configurado no seu próprio repositório, esse é o No-Mac iOS Pipeline, $299: o seu primeiro build no TestFlight a partir de um PC com Windows em 5 dias úteis. Se prefere entregar o app inteiro, os builds com preço fechado estão em /build/.