Se você já submeteu seu primeiro app, o que vem a seguir será familiar. Se não fez isso ainda, marque esta página — você vai querer se referir a ela na segunda semana do processo.
O estado inicial: uma nova conta da App Store Connect
Você pagou os $99. Verificou o número DUNS. Aguardou três dias úteis para que a Apple o matricule.
Agora está olhando para a App Store Connect, tentando descobrir como realmente submeter o app que construiu. O painel mostra ícones para iTunes Connect (descontinuado, mas ainda visível), Certificados, TestFlight, Usuários e Acesso, Contratos. Nenhum deles diz "Submeta um App." Essa opção está sob "Meus Apps" — que é um dos ícones, mas não está rotulado assim.
Você gastou quinze minutos e fez zero progresso.
Tela por tela, através do fluxo real
Tela 1: Registro de ID Bundle. No portal do desenvolvedor — um site diferente da App Store Connect. Se errar aqui, não pode renomeá-lo depois.
Tela 2: Certificado + perfil de provisionamento. Dois para cada, desenvolvimento e distribuição. A interface do usuário da Apple o guia através disso, mas assume que você já sabe o que um certificado faz.
Tela 3: Configuração de assinatura no Xcode. Seis dropdowns, três dos quais parecem idênticos. Se qualquer um estiver errado, a compilação falha com "nenhum perfil de provisionamento corresponde", e você vai ao Google procurar pelo erro exato.
Tela 4: Arquivar + upload. Dez minutos de "processando", geralmente seguidos por sucesso. Às vezes, um email trinta minutos depois: "Seu build tem um ou mais problemas." Sem indicação de qual.
Tela 5: Informações do App. Categoria, subcategoria, direitos de conteúdo, classificação etária. A última é uma pesquisa com vinte perguntas.
Tela 6: Preços e Disponibilidade. Escolha os países. Escolha a categoria. Explique se o app é gratuito mas tem compras dentro do aplicativo.
Tela 7: Privacidade do App. Responda perguntas sobre coleta de dados. Cada "sim" desencadeia quatro a seis perguntas adicionais. Se perder uma, sua submissão é rejeitada.
Tela 8: A versão que você está enviando. Descrição, palavras-chave (100 caracteres), texto promocional, URL de suporte, URL de marketing, screenshots (seis tamanhos de iPhone mínimo), vídeo prévia.
Tela 9: Informações para a revisão. Informações de contato, credenciais da conta demo, notas de revisão. Então, finalmente, o botão "Enviar para Revisão".
E isso não inclui o lado do TestFlight, que são outras cinco telas.
O momento das três da manhã de "binary inválido"
Toda desenvolvedora independente tem esse momento. Você terminou todas as nove telas. Envia o build. Vinte minutos depois, uma mensagem chega:
O build enviado tem arquitetura binária inválida.
OU:
O perfil de provisionamento não inclui a capacidade Push Notifications.
O Google diz: recompile com configurações diferentes do Xcode. Você faz isso. Mesmo erro. Você pesquisa mais no Google. Descobre que também precisava adicionar uma capacidade no portal do desenvolvedor. Você faz isso. Compilação. Upload. Espera vinte minutos. Novo erro.
É aqui que a maioria das pessoas desiste de sua linha temporal do primeiro mês.
Por que esse padrão de experiência do usuário persiste
A Apple tem zero pressão para simplificar a submissão. Cada desenvolvedor independente que desiste é substituído por dez outros. E o cliente real da Apple não é o desenvolvedor independente — é a empresa de estúdios com uma equipe dedicada a esse fluxo de trabalho.
Isso não vai mudar internamente na Apple. Mas isso significa que a alavancagem para ferramentas independentes é enorme — quem resolver essa lacuna de experiência do usuário ganha lealdade de um segmento mal atendido.
Como uma boa ferramenta de submissão deve ser
Uma boa ferramenta de submissão seria:
- Pergunte as perguntas de Privacidade do App em inglês simples, uma vez. Em seguida, preencha o App Store Connect automaticamente.
- Cross-check seu build contra as principais 20 razões para rejeição antes de upload. Fale alto se alguma for atingida.
- Mostre status em tempo real. "Em revisão, 47h na fila, média para sua categoria é 26h" — não "Aguardando Revisão" por cinco dias.
- Lide com rejeições como tíquetes. A razão de rejeição analisada em um diff que você pode aplicar, com um botão para resubmissão.
- Nunca deixe que você chegue a uma hora 3am de momento inválido-binário. Cada modo de falha deve se tornar visível antes do upload, não vinte minutos depois.
Esse é o produto que quero usar como desenvolvedor indie — e por isso construímos RapidNative para lidar com o caminho de geração a submissão, para que os nove telas deixem de ser seu problema.
Tirando lições
A fluidez de envio da App Store é um artefato do incentivo da Apple, não uma lei da natureza. Até que melhore, trate como o desafio que é: reserve uma semana inteira, espere uma rejeição e mostre cada modo de falha que puder antes de clicar em upload.
Qual motivo de rejeição da App Store te pegou às 3am — binário inválido, permissão ausente ou um rótulo de privacidade preenchido incorretamente? Compartilhe nos comentários.