Como publicar aplicativo com a sua marca nas lojas

Decidir que o curso precisa de um aplicativo com a sua marca é a parte fácil. A parte que trava é o que vem depois: abrir conta de desenvolvedor, montar a ficha da loja, esperar a fila de revisão e, quase sempre, corrigir alguma coisa que a Apple ou o Google apontaram antes de aprovar de vez. Isso pesa igual pra quem vai publicar o primeiro app sozinho e pra quem já tem catálogo maior e só quer riscar mais esse item da lista sem virar um projeto de meses.

Este texto cobre só essa parte: o caminho entre decidir ter um app e o aluno encontrar esse app com o seu nome na loja. O guia como lançar o aplicativo de cursos nas lojas cobre a jornada inteira, da decisão de ter um app até o prazo esperado e a política de cada loja; aqui o assunto é só a execução: o que preparar, o que a loja pede e o que fazer quando ela devolve o app com uma reprovação. E se o termo "aplicativo white-label" ainda soa vago, o texto o que é aplicativo white-label explica a diferença antes de você seguir adiante.

O que precisa estar pronto antes de abrir a conta de desenvolvedor

Antes de preencher qualquer formulário de conta, existe um pacote de conteúdo que as duas lojas exigem: ícone em vários tamanhos (da tela do app até o ícone menor de configurações do sistema), capturas de tela nos formatos que cada loja pedir, uma descrição curta e uma longa, e uma URL de política de privacidade publicada e ativa. Preparar isso primeiro, e só depois abrir a conta de desenvolvedor, evita o retrabalho mais comum: começar o cadastro com texto provisório, enviar assim mesmo pra "não perder tempo" e receber a reprovação só por ficha incompleta.

Cor, ícone e identidade visual do app costumam sair do mesmo pacote de marca que já roda no resto da operação. Se esse pacote ainda não está fechado (paleta, logo, identidade do certificado), o texto sobre área de membros personalizada sem programar cobre o que dá pra deixar pronto antes de chegar nessa etapa do app.

Tem ainda um item técnico que passa batido na primeira vez: o identificador único do app (bundle ID na Apple, package name no Google). O identificador do pacote é definido antes do primeiro envio, então vale decidir sem provisório.

Conta de desenvolvedor: a validação que trava quem publica sozinho

Publicar sob o nome da sua empresa, não como pessoa física, exige provar isso pra loja: documentos da empresa que a loja pedir na verificação. Essa validação tem prazo próprio, fora do seu controle, e é esse passo, mais do que qualquer parte técnica do app em si, que costuma esticar o prazo de quem faz sozinho: a conta da empresa não libera na hora, e enquanto ela não libera, nenhuma outra etapa do processo anda.

Depois da verificação vem o aceite de um conjunto de termos e políticas específicas de cada loja, que muda de tempos em tempos e precisa ser revisto a cada atualização relevante. Não é uma etapa opcional nem um clique de formalidade: o conteúdo desses termos define o que o app pode e o que não pode fazer depois de publicado.

Enviar pra revisão: o que muda de loja pra loja

Com a conta aberta e a ficha preenchida, o envio em si é rápido: você sobe a versão compilada do app, associa os textos e as imagens da ficha e manda pra fila de revisão. A partir daí, o controle sai da sua mão. Cada loja revisa no próprio ritmo, sem horário fixo pra devolver resposta. A primeira submissão costuma ser a mais lenta das duas; atualizações seguintes tendem a passar mais rápido.

Enquanto a fila roda, dá pra fazer pouco: revisar de novo a ficha, confirmar que a política de privacidade continua no ar e aguardar.

Vale separar dois tipos de mudança que se confundem à primeira vista. Mudar a interface do próprio aplicativo (uma tela nova, um fluxo de navegação diferente, qualquer alteração na estrutura do app) pede compilar uma versão nova e mandar essa versão de novo pra fila de revisão, no mesmo ritmo de qualquer submissão. Conteúdo novo é outra situação: aula, módulo ou curso que você publica dentro da plataforma chega pro aluno sem passar por loja nenhuma, porque quem sobe essa atualização é o time da EngagED, direto na plataforma, sem gerar release novo do app. Na prática, publicar aula não pede revisão de Apple ou Google; mudar a estrutura do próprio aplicativo pede.

Um ponto que pega quem tenta vender curso direto dentro do app: a Apple exige que qualquer venda de conteúdo digital feita de dentro do aplicativo passe pelo sistema de pagamento da própria Apple, não pelo checkout que você já usa no site. Essa taxa fica em 30% numa venda avulsa e cai pra 15% numa assinatura depois dos primeiros 12 meses, e é por isso que quem já passou por essa regra costuma vender no site, fora do app, deixando o aplicativo só pra o aluno assistir o que já comprou. Ignorar essa regra é motivo comum de reprovação, mesmo em apps que já funcionam bem do lado técnico.

Reprovação: como corrigir e reenviar

Reprovação é parte esperada do processo, não uma exceção que só acontece com quem fez tudo errado. Ela costuma vir com um motivo (ícone fora do padrão de tamanho, captura de tela que não bate com o app de verdade, função que trava num teste específico, algo na descrição que promete o que o app não entrega) e, às vezes, com uma explicação genérica que exige reler a política pra entender exatamente o que corrigir. Ajustar o ponto apontado e reenviar coloca a versão corrigida de novo em revisão, o que consome tempo de quem ainda não sabe reconhecer o padrão por trás da mensagem.

Boa parte dessas reprovações se repete nos mesmos pontos. Ícone que não segue as regras de dimensão, contraste ou os elementos exigidos por cada loja é uma causa recorrente, e não se resolve só ajustando o tamanho do arquivo. Política de privacidade também reprova quando falta documentação clara sobre o que o app coleta, como usa e por quanto tempo guarda o dado do aluno, mesmo com a URL da política no ar. Descrição que promete algo que o app não entrega segue sendo motivo comum, e o uso indevido de compra dentro do app (vender curso sem passar pelo sistema de pagamento da própria loja) fecha a lista dos motivos que mais aparecem numa reprovação.

Publicar com a EngagED: o time cuida, você aprova a marca

Com a EngagED, você não abre conta de desenvolvedor nem contrata agência pra tocar esse processo. O time técnico conduz o conjunto inteiro: validação ou abertura das contas, configuração técnica do app, geração dos assets a partir da sua marca, envio, acompanhamento da fila de revisão e resposta às reprovações que aparecerem no caminho. Da decisão até o app publicado, a média fica entre 2 e 4 semanas; dentro desse prazo, a revisão da Apple costuma ser o ponto mais lento, de 7 a 14 dias.

Publicar não fecha o assunto, e essa parte também fica com o time técnico: renovação anual da conta de desenvolvedor na Apple, atualização de SDK, novas funcionalidades e resposta a qualquer alerta que a loja mandar quando uma política muda não viram um projeto separado pra você acompanhar depois que o app já está no ar. Essa manutenção roda com o mesmo time que publicou o app, sem que você precise aprender a reconhecer um alerta de loja pra saber o que fazer com ele, nem lembrar sozinho da data de renovação.

O app sai no ar como um app individual, com o seu nome e o seu ícone na loja, não como mais uma conta dentro de um app de marketplace compartilhado. Pra quem vende pra empresa, esse detalhe pesa na conversa: o comprador abre a loja, encontra um app com a identidade de quem está vendendo, e isso muda o nível da negociação. Os exemplos de área de membros por segmento mostram esse padrão se repetindo em quem já vende treinamento corporativo. Como o app funciona depois de publicado está em aplicativo white-label.

Antes de decidir quem vai publicar esse app por você

Boa parte da decisão se resume a separar o que fica com você do que fica com quem publica em seu nome. Ícone, capturas de tela, descrição e o resto da identidade visual são responsabilidade de marca: ninguém publica isso no seu lugar sem que essas peças já estejam prontas. Já abrir conta de desenvolvedor, montar a ficha técnica, acompanhar a fila de revisão e responder reprovação são etapas que pedem alguém acostumado com o ritmo de cada loja, porque a primeira reprovação lida sozinho custa mais tempo do que a segunda.

O mesmo vale depois que o app já está no ar: alguém precisa lembrar de renovar a conta de desenvolvedor e ajustar o app quando a loja mudar uma exigência, e essa parte não termina no dia da publicação. Decidir quem carrega essa etapa (você, um time interno ou quem já publica esse tipo de app com regularidade) é o que separa um app publicado de um app publicado e mantido.

Pra quem já tem alguém de marketing ou operações no time, dá pra dividir essa lista em duas frentes que andam em paralelo: uma pessoa cuida da marca (ícone, textos, capturas de tela) enquanto outra acompanha a fila e responde reprovação. Pra quem opera sozinho, as duas frentes caem na mesma pessoa, e é aí que o tempo gasto pesa mais.

Nenhuma dessas duas frentes inclui ficar de olho pra saber se hoje é dia de mandar aula nova pra revisão: conteúdo publicado dentro da plataforma não entra nessa fila, só a estrutura do próprio app entra. Vale separar isso antes de montar a divisão de tarefas, pra não reservar tempo de time pra uma etapa que, na prática, não existe.