Como Publicar Jogos Mobile: Google Play e App Store

Publicar na loja é a parte que mais assusta quem nunca passou por ela, e quase nunca é onde o projeto morre. O jogo morre antes, em build que não roda no aparelho do amigo, em conta de desenvolvedor que trava na verificação, em descrição que ninguém acha. Esse guia é o caminho que eu queria ter tido na mão da primeira vez: o que cada loja cobra, o que dá pra automatizar e onde você vai perder tempo se não souber.

Vou falar de Google Play e App Store, dos requisitos técnicos, de ASO (App Store Optimization, que é basicamente o SEO das lojas) e de monetização. O código aqui é mínimo e de propósito: a parte difícil de publicar não é programar, é configurar.

Antes de mais nada: pra quem isso vale a pena

Mobile é o maior pedaço da receita de games do mundo. Isso não significa que é o lugar mais fácil pra ganhar dinheiro. Significa o contrário: é o mercado mais competitivo e mais barato de entrar que existe, o que enche a loja de concorrente.

A barreira de entrada baixa é a vantagem e a armadilha. Você consegue subir um jogo na Play Store por 25 dólares, e por isso tem milhão de jogo abandonado lá dentro. Publicar é trivial. Ser achado é que é o trabalho. Guarde isso, porque metade desse guia é sobre não ser invisível.

Vale lembrar que mobile é só um dos canais: se o seu jogo também roda em PC, existem outras lojas além da Steam, como Epic, GOG e itch.io, e diversificar onde você vende reduz o risco de depender de uma plataforma só.

Preparação técnica

A maior dor de cabeça do mobile não é a loja, é a quantidade de aparelho diferente. Um jogo que roda liso no seu celular topo de linha pode engasgar num Android intermediário de 2 GB de RAM, que é onde está grande parte do público no Brasil. Teste em aparelho fraco, não só no seu.

Os dois ajustes que mais resolvem performance logo de cara são limitar o framerate e cuidar da textura. Rodar a 60 fps num jogo simples só esquenta o aparelho e come bateria sem ninguém perceber diferença. Em Unity, dá pra fixar o alvo de framerate assim:

using UnityEngine;

public class MobileSetup : MonoBehaviour
{
    void Awake()
    {
        // Sem isso, a Unity tenta empurrar o máximo de fps que o aparelho aguentar.
        // Em mobile, 30 fps estável vence 60 fps oscilando: gasta menos bateria
        // e esquenta menos o aparelho.
        Application.targetFrameRate = 30;

        // Trava a orientação se o seu jogo é vertical. Evita o rage do
        // jogador quando a tela gira sozinha no meio de uma fase.
        Screen.orientation = ScreenOrientation.Portrait;
    }
}

Se quiser oferecer 60 fps só em aparelho parrudo, a lógica honesta é checar memória ou GPU em runtime e subir o alvo só nesses casos. Não tem fórmula mágica de "detectar aparelho top": você define um corte (por exemplo, RAM acima de 4 GB) e testa.

Sobre o notch e a barra do iPhone: não chute as margens. A Unity te entrega Screen.safeArea, um Rect em pixels com a área segura da tela. Você posiciona HUD e botões dentro dela pra nada importante ficar embaixo do entalhe. É leitura, não comando: var area = Screen.safeArea; e você usa esse retângulo pra ancorar a UI.

Privacidade não é opcional

As duas lojas vão te cobrar uma política de privacidade e te perguntar o que o jogo coleta. Não dá pra empurrar com a barriga, é motivo de rejeição. Os pontos que você precisa resolver antes de submeter:

• iOS, App Tracking Transparency (ATT): se o jogo usa anúncios ou qualquer SDK que rastreia o usuário entre apps, a Apple exige o popup pedindo permissão pra rastrear. Sem ele, sua build é rejeitada.
• Android, Data Safety: o Google Play exige um formulário declarando que dados você coleta e pra quê. Mentir ali é suspensão na certa, porque eles cruzam com o que os SDKs realmente fazem.
• LGPD/GDPR: se você coleta qualquer dado pessoal, precisa de consentimento real e de uma forma do usuário pedir exclusão. Vale entender bem como cuidar da LGPD e dos dados do jogador antes de submeter, porque é a parte que mais gera dor de cabeça depois. Os SDKs de anúncio sérios (AdMob, por exemplo) já trazem o fluxo de consentimento pronto, use o deles em vez de inventar o seu.

A regra prática: cada SDK que você adiciona (analytics, anúncio, crash report) traz uma obrigação de privacidade junto. Liste os SDKs antes de submeter e preencha o formulário olhando essa lista.

Google Play: o processo

A conta de desenvolvedor da Google custa 25 dólares, pagamento único (não é anual). Depois do cadastro, você passa por uma verificação de identidade e fiscal, e ganha acesso ao Google Play Console, que é onde tudo acontece.

AAB no lugar de APK

O Google não aceita mais APK pra publicar jogo novo: o formato obrigatório é o AAB (Android App Bundle). A diferença prática: em vez de você gerar um arquivo gigante que serve pra todo aparelho, você sobe um bundle e o próprio Google monta um APK enxuto pra cada celular, baixando só a resolução de textura e a arquitetura que aquele aparelho precisa. O download fica menor, o que ajuda na conversão.

No build.gradle do app, o que importa pra publicação é manter targetSdkVersion atualizado (o Google sobe o mínimo exigido todo ano, e build com SDK velho é barrada) e ligar a divisão do bundle:

android {
    defaultConfig {
        applicationId "com.suaempresa.seujogo"
        minSdkVersion 21
        targetSdkVersion 34   // mantenha no alvo que o Play exige no ano
        versionCode 1
        versionName "1.0.0"
    }

    bundle {
        // Divide o bundle por idioma, densidade de tela e arquitetura.
        // Cada aparelho baixa só o pedaço que usa.
        language { enableSplit = true }
        density  { enableSplit = true }
        abi      { enableSplit = true }
    }
}

Detalhe que pega muita gente: o AAB precisa estar assinado com sua chave de upload, e você perde o acesso à conta se perder essa chave. Use o Play App Signing (o Google guarda a chave de assinatura final pra você) e guarde a chave de upload em lugar seguro, com backup. Já vi gente ter que publicar o jogo de novo do zero, como app novo, porque perdeu a keystore.

Login, conquistas e ranking

Se o seu jogo vai ter conquista, ranking ou salvar progresso na nuvem, isso vem do Google Play Games Services, configurado no Console e plugado via SDK na Unity. Os três blocos que você normalmente usa:

• Autenticação: loga o jogador na conta Google dele, o que destrava o resto.
• Achievements: você cria cada conquista no Console (com um ID), e o jogo reporta o progresso por esse ID.
• Leaderboards: mesma lógica, você cria o ranking no Console e envia a pontuação.

A ordem importa: nada de conquista ou ranking funciona antes do jogador estar autenticado. Trate a autenticação como passo zero e só habilite os botões de ranking depois que ela deu certo.

ASO no Google Play

Aqui é onde você decide se vai ser achado. Se quiser ir além do básico, vale estudar como otimizar o ASO do seu jogo na Play Store e na App Store com calma. Os campos que pesam:

• Título, até 30 caracteres. Coloque o nome do jogo e, se couber, uma palavra de gênero. "Nome do Jogo: RPG de Ação" trabalha mais por você do que só o nome.
• Descrição curta, até 80 caracteres. É o que aparece antes do "ler mais". Trate como uma headline: a promessa do jogo numa frase.
• Descrição completa, até 4000 caracteres. O algoritmo do Google lê esse texto pra indexar. Escreva pra pessoa, mas use de verdade as palavras que alguém digitaria pra achar um jogo como o seu. Sem encher de palavra-chave repetida, que isso o Google penaliza.

No Google Play não existe um campo separado de keywords como na Apple: a indexação sai do título e das descrições. Por isso elas valem ouro.

Uma honestidade necessária sobre descrição de loja: aqueles textos cheios de "JOGO DO ANO, 1 milhão de downloads, gráficos impressionantes" só funcionam quando são verdade e têm o print pra provar. Reivindicação inflada sem lastro espanta mais do que atrai, e mente sobre número de download pode dar suspensão.

App Store (iOS): o processo

A conta da Apple é mais cara e mais chata: 99 dólares por ano, com verificação de identidade mais rígida. Toda a gestão fica no App Store Connect.

A diferença que importa: revisão humana

A diferença de cultura entre as lojas é essa. No Google, sua build entra rápido e a fiscalização é mais automática e posterior. Na Apple, um humano testa seu jogo antes de aprovar, e ele reprova por coisas que no Android passariam batido: crash no primeiro abrir, botão que não faz nada, login obrigatório sem motivo, screenshot que não bate com o jogo real. Conte com pelo menos uma rejeição na primeira submissão e leia o motivo com calma, porque a Apple costuma dizer exatamente o que quebrou.

Na preparação da build iOS, os pontos que mais reprovam:

• Versão mínima de iOS coerente. Não force suporte a um iOS antigo demais se você não vai testar nele.
• Ícones em todos os tamanhos, incluindo o de 1024x1024 da loja. Faltar um tamanho trava o upload.
• Assinatura e provisioning corretos. É a parte mais burocrática do iOS e a que mais custa tempo de quem vem do Android. Reserve uma tarde só pra isso na primeira vez.

Game Center

O equivalente da Apple ao Play Games é o Game Center, e a lógica é a mesma: autentica o jogador primeiro, depois reporta conquista e pontuação. Conquistas e rankings você cria no App Store Connect, e o jogo referencia pelo ID. Mesma regra do Android: não tente reportar nada antes da autenticação dar certo.

ASO na App Store

A grande diferença pra Apple é que ela tem um campo dedicado de keywords, separado da descrição, com limite de 100 caracteres no total. Esse campo é seu instrumento de ASO mais direto. Como usar bem:

• Não repita palavras que já estão no nome ou no subtítulo do app. A Apple já indexa essas, repetir é desperdiçar caractere.
• Separe por vírgula, sem espaço: rpg,acao,aventura,offline rende mais palavras no limite do que com espaço depois da vírgula.
• Singular ou plural, escolha um: a Apple costuma cobrir a variação, então gastar caractere com "jogo" e "jogos" é redundante.

Além das keywords, você tem nome (até 30 caracteres), subtítulo (até 30), descrição (até 4000, que na Apple não conta pra indexação, é pra convencer o humano) e texto promocional (até 170, que você pode trocar sem reenviar a build pra revisão, ótimo pra avisar de evento ou promoção).

Monetização

Os três modelos que você vê em mobile são anúncio, compra dentro do app e assinatura. Quase todo jogo free-to-play mistura pelo menos dois.

Anúncios

Três formatos, e eles não valem a mesma coisa pro jogador:

• Premiado (rewarded): o jogador escolhe ver o anúncio em troca de algo (uma vida, moeda, dobrar recompensa). É o único formato que o jogador agradece, porque ele aceitou. Em geral é o que mais fatura sem espantar.
• Intersticial: aquele de tela cheia entre uma fase e outra. Funciona se aparecer em momento natural (fim de fase, game over) e com frequência sã. Enfiar um a cada toque destrói a experiência e derruba retenção.
• Banner: a faixa fixa. Atrapalha pouco, mas paga pouco também.

A regra que separa quem ganha de quem afasta o jogador: anúncio premiado o jogador escolhe, então pode ter à vontade. Intersticial é interrupção, use com parcimônia. Em build de teste, sempre ligue o modo de teste do SDK de anúncio. Clicar no próprio anúncio real pra "ver se funciona" é caminho pra ter a conta de anunciante banida.

Compras dentro do app (IAP)

Aqui mora a parte que mais confunde iniciante: os três tipos de produto, e errar o tipo dá problema na revisão.

• Consumível: o jogador compra, usa e pode comprar de novo. Pacote de moedas, vidas. A loja não "lembra" que ele já comprou.
• Não consumível: compra uma vez e tem pra sempre. "Remover anúncios", desbloquear o jogo completo. A loja precisa restaurar essa compra se o jogador trocar de aparelho.
• Assinatura: cobrança recorrente. Passe de batalha mensal, por exemplo.

Os dois erros clássicos: marcar "remover anúncios" como consumível (aí o jogador paga, troca de celular e perde o que comprou, e abre reclamação) e esquecer de implementar o botão de restaurar compras, que a Apple exige por regra pra produtos não consumíveis. Faltou esse botão, a build é rejeitada.

E o ponto que ninguém gosta de ouvir: as lojas ficam com 15% a 30% de cada compra. A faixa de 15% costuma valer pra quem fatura pouco ou no primeiro ano de assinatura; o padrão histórico é 30%. Coloque isso na conta antes de prometer faturamento pra você mesmo.

Lançamento: soft launch antes do lançamento de verdade

Não abra o jogo pro mundo todo no dia um. O profissional faz soft launch: solta primeiro em poucos países pequenos, de idioma que dá pra suportar, e observa os números antes de gastar grana em divulgação no mercado principal. Se você nunca passou por isso, vale entender como rodar um soft launch num mercado limitado antes de abrir o jogo pro mundo. Canadá, Austrália e Nova Zelândia são clássicos pra jogo em inglês, porque o público se comporta parecido com o americano e o tráfego é barato pra testar.

As métricas que você acompanha nessa fase, e o que cada uma te diz:

• Retenção D1, D7, D30: quantos voltam no dia seguinte, na semana, no mês. É o sinal mais importante. Se D1 está baixo, o problema é o começo do jogo, e nenhuma quantia de anúncio conserta isso. Conserte o jogo antes de escalar.
• Crash rate: porcentagem de sessões que travam. Se está alto, pare tudo e arrume. Anúncio pra um jogo que crasha é jogar dinheiro fora.
• Tempo de sessão: quanto tempo a pessoa fica. Curto demais e a primeira experiência não prendeu.
• ARPDAU: receita média por usuário ativo no dia. Junto com o custo de trazer um jogador, te diz se a conta fecha quando você escalar.

Sobre números "ideais" de retenção, vai uma dose de realidade. Você vai achar tabelas dizendo que jogo bom é D1 acima de 40%. Isso varia demais por gênero, plataforma e país, e benchmark de blog raramente é confiável. Use seus próprios números como referência: a pergunta certa não é "bati a tabela da internet?", é "a versão de hoje reteve melhor que a da semana passada?". Some retenção com o custo de aquisição: se trazer um jogador custa mais do que ele rende ao longo da vida, escalar só acelera o prejuízo.

A ferramenta que sustenta tudo isso é o Firebase Analytics (de graça e padrão do mercado), que te dá retenção, eventos customizados e crash report no mesmo lugar. Instale antes de lançar, não depois. Lançar sem analytics é dirigir de olhos fechados.

Depois do lançamento

O lançamento não é a linha de chegada, é o dia em que você finalmente tem dado real. A partir daí o trabalho é olhar número e iterar: onde o jogador trava, em que fase ele abandona, qual tela espanta o pagante.

Os termos que você vai ver toda hora nos painéis, sem mistério:

• DAU / MAU: usuários ativos por dia e por mês. A razão entre eles (DAU dividido por MAU) mostra o quão "viciante" é o hábito, quantos dos jogadores do mês voltam todo dia.
• CPI: custo por instalação, quanto você paga em anúncio pra trazer um jogador.
• LTV: quanto um jogador rende ao longo da vida dele no jogo. A conta de ouro do mobile é simples e implacável: LTV maior que CPI e você pode escalar; menor, e cada instalação paga te dá prejuízo.

Não precisa instrumentar trinta métricas no dia um. Comece com retenção, crash rate e receita. Esses três já te dizem se o jogo está de pé.

Ferramentas que valem a pena

• Google Play Console e App Store Connect: gestão de cada loja, óbvio, mas vá fundo nos relatórios deles antes de pagar ferramenta de terceiro.
• Firebase: analytics e crash report, de graça e suficiente pra começar.
• TestFlight (iOS) e trilhas de teste do Play Console (Android): distribua a build pra testador antes de soltar pro público. Use sempre.

Documentação oficial

• Google Play Developer Documentation
• App Store Connect Help
• Unity Mobile Optimization

Resumindo

Publicar é a parte fácil, e quase ninguém acredita nisso até passar. O custo é baixo (25 dólares na Google, 99 por ano na Apple), o processo é burocrático mas documentado, e o que separa o jogo que vai longe do que some na loja não é a build, é o que vem depois: ASO pra ser achado, retenção pra valer o investimento, e iteração em cima de dado de verdade.

Se você está nessa fase, faça três coisas na ordem: instale analytics antes de lançar, rode um soft launch antes de gastar com divulgação, e só escale quando o número fechar. O resto é repetir.