Escrever o app é metade do trabalho; colocá-lo na mão dos usuários é a outra. Publicar nas lojas envolve gerar um build de release assinado, passar pelo review da Apple ou do Google, versionar corretamente e atualizar sem quebrar quem já tem o app instalado. Dominar esse pipeline de release é responsabilidade típica de um sênior.
Build de debug vs release
O build que você roda no dia a dia (debug) é diferente do que vai para a loja (release). O debug prioriza velocidade de desenvolvimento e diagnóstico; o release prioriza tamanho, performance e segurança.
| Aspecto | Debug | Release |
|---|---|---|
| Otimização de código | Mínima (compila rápido) | Máxima (mais rápido, menor) |
| Ofuscação/minificação | Desligada | Ligada (ex.: R8/ProGuard) |
| Logs e debug | Habilitados | Removidos/desligados |
| Assinatura | Chave de debug automática | Certificado/keystore de produção |
| Destino | Seu aparelho/emulador | App Store / Play Store |
Assinatura de código: o que e por quê
Todo app instalado é assinado criptograficamente. A assinatura prova que o pacote veio de você e não foi adulterado no caminho. No Android isso é uma keystore (sua chave privada); no iOS, certificados e provisioning profiles emitidos pela Apple.
A analogia: a assinatura é o lacre de segurança de um remédio. O SO só instala se o lacre bater, e só aceita uma atualização se for assinada pela mesma chave da versão anterior — caso contrário, recusa.
Perder a chave de assinatura de produção é catastrófico: sem ela você não consegue publicar atualizações do mesmo app, e usuários ficam presos na versão antiga. Guarde-a como guarda um cofre — backup seguro e acesso restrito.
O processo de review
Você não publica direto: envia o build e ele entra em review. A Apple faz revisão majoritariamente manual e mais rigorosa (diretrizes de conteúdo, privacidade, uso de APIs); a Google combina checagens automáticas com revisão, geralmente mais rápida. Motivos comuns de rejeição: pedir permissões sem justificativa, crashes, política de privacidade ausente, ou tentar burlar pagamentos da plataforma. Planeje prazo de review no cronograma de lançamento.
Versionamento: nome vs número de build
Há dois números e eles servem a públicos diferentes:
- Version name / marketing version (ex.:
2.3.0): o que o usuário vê. Semântico, legível. - Build number / version code (ex.:
147): um inteiro que sempre cresce, usado pela loja para saber qual é mais novo.
versionName "2.3.0" // o usuario ve
versionCode 147 // a loja compara; nunca repita nem diminuaÉ comum em entrevista pedir a diferença entre os dois — a chave é: o build number é a identidade técnica monotônica; o version name é a comunicação humana.
Atualizar sem quebrar quem já tem o app
Usuários atualizam em ritmos diferentes; por dias ou semanas, versões antigas e novas coexistem. Cuidados essenciais:
- Compatibilidade de API: o backend precisa atender versões antigas e novas ao mesmo tempo; evite quebrar contratos.
- Migração de dados local: se o esquema do banco mudou, migre os dados de quem atualizou sem perder nada.
- Forçar atualização com parcimônia: só bloqueie versões realmente incompatíveis.
Rollout gradual
Em vez de liberar para 100% de uma vez, as lojas permitem rollout em fases (ex.: 5% → 20% → 50% → 100%). Assim, se a nova versão tiver um crash grave, você o vê nas métricas e pausa antes de atingir toda a base. É a rede de segurança do lançamento — combine com monitoramento de crashes para reagir a tempo.
Conclusão
Publicar é um pipeline: gerar release otimizado, assinar com a chave de produção (e protegê-la), passar pelo review, versionar com nome legível e build number crescente, e atualizar respeitando quem está em versões antigas — tudo idealmente com rollout gradual. Quem domina esse caminho entrega valor ao usuário com segurança, sem transformar um lançamento em incêndio.
Writing the app is half the work; getting it into users' hands is the other half. Publishing to the stores involves generating a signed release build, going through Apple's or Google's review, versioning correctly and updating without breaking those who already have the app installed. Mastering this release pipeline is a typical senior responsibility.
Debug vs release build
The build you run day to day (debug) is different from the one that goes to the store (release). Debug prioritizes development speed and diagnostics; release prioritizes size, performance and security.
| Aspect | Debug | Release |
|---|---|---|
| Code optimization | Minimal (compiles fast) | Maximum (faster, smaller) |
| Obfuscation/minification | Off | On (e.g., R8/ProGuard) |
| Logs and debugging | Enabled | Removed/disabled |
| Signing | Automatic debug key | Production certificate/keystore |
| Destination | Your device/emulator | App Store / Play Store |
Code signing: what and why
Every installed app is cryptographically signed. The signature proves the package came from you and wasn't tampered with along the way. On Android this is a keystore (your private key); on iOS, certificates and provisioning profiles issued by Apple.
The analogy: the signature is the tamper-evident seal on a medicine bottle. The OS only installs if the seal matches, and only accepts an update if it is signed with the same key as the previous version — otherwise, it refuses.
Losing the production signing key is catastrophic: without it you can't publish updates to the same app, and users are stuck on the old version. Guard it like a vault — secure backup and restricted access.
The review process
You don't publish directly: you submit the build and it goes into review. Apple does mostly manual and stricter review (content guidelines, privacy, API usage); Google combines automated checks with review, usually faster. Common reasons for rejection: requesting permissions without justification, crashes, a missing privacy policy, or trying to bypass the platform's payments. Plan review time into your launch schedule.
Versioning: name vs build number
There are two numbers and they serve different audiences:
- Version name / marketing version (e.g.,
2.3.0): what the user sees. Semantic, readable. - Build number / version code (e.g.,
147): an integer that always grows, used by the store to know which is newer.
versionName "2.3.0" // the user sees this
versionCode 147 // the store compares; never repeat or decreaseInterviewers often ask the difference between the two — the key is: the build number is the monotonic technical identity; the version name is human communication.
Updating without breaking those who already have the app
Users update at different paces; for days or weeks, old and new versions coexist. Essential precautions:
- API compatibility: the backend must serve old and new versions at the same time; avoid breaking contracts.
- Local data migration: if the database schema changed, migrate the data of those who updated without losing anything.
- Force updates sparingly: only block versions that are truly incompatible.
Gradual rollout
Instead of releasing to 100% at once, the stores allow phased rollout (e.g., 5% → 20% → 50% → 100%). That way, if the new version has a serious crash, you see it in the metrics and pause before it reaches the whole user base. It is the launch safety net — combine it with crash monitoring to react in time.
Conclusion
Publishing is a pipeline: generate an optimized release, sign it with the production key (and protect it), go through review, version with a readable name and an ever-increasing build number, and update while respecting those on older versions — ideally all with a gradual rollout. Whoever masters this path delivers value to users safely, without turning a launch into a fire drill.