Compilação e publicação no desenvolvimento móvel: o que é, quais formatos e como funciona

Formatos de compilação: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — o formato tradicional de compilação e publicação de aplicativos móveis no Android. O APK contém todo o código, recursos e manifesto do aplicativo. AAB (Android App Bundle) — um formato introduzido pelo Google em 2018 e tornado obrigatório para novos aplicativos em agosto de 2021. O AAB não é instalado diretamente — o Google Play gera dinamicamente um APK otimizado para cada dispositivo a partir do AAB.

Vantagens do AAB: o tamanho do download é em média 15% menor (ao entregar apenas os recursos necessários: densidades de tela corretas, idiomas, arquiteturas de CPU). O AAB também suporta entrega modular — você pode carregar módulos sob demanda (Play Feature Delivery) ou diferidos (Play On-Demand). Para desenvolvedores, o AAB é obrigatório; para distribuição fora do Google Play (sideloading, marketplaces) — apenas APK.

IPA

IPA (iOS App Store Package) — o arquivo instalável do iOS, que é um arquivo ZIP contendo um aplicativo assinado. O IPA contém uma pasta Payload/ com o bundle .app, Provisioning Profile e assinatura. O IPA é compilado apenas no macOS através do Xcode, que cria um arquivo (.xcarchive) e exporta o IPA. Para distribuição pela App Store, o IPA é assinado com um Apple Distribution Certificate; para Ad Hoc ou Enterprise — com os certificados correspondentes.

Compilação e otimização: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — compilação de código durante a execução do aplicativo, afetando a velocidade de compilação e publicação. No Android até a versão 5.0 (Lollipop), era usado o Dalvik VM com compilação JIT. A cada inicialização do aplicativo, o bytecode DEX era convertido em código de máquina «em tempo real». Desvantagem: lentidão na primeira inicialização e consumo adicional de energia. AOT (Ahead-Of-Time) — compilação de código antes da inicialização do aplicativo, durante a instalação. A partir do Android 7.0 (Nougat), o ART (Android Runtime) compila o aplicativo completamente durante a instalação.

ART (Android Runtime) — o ambiente de execução que substituiu o Dalvik no Android 5.0. O ART usa uma abordagem híbrida: compilação AOT durante a instalação + JIT para métodos executados com frequência. Isso combina a velocidade do AOT (inicialização rápida) com a flexibilidade do JIT (otimização adaptativa). Resultado: o desempenho dos aplicativos Android aumentou 20-30% em comparação com o Dalvik. Para os desenvolvedores, a transição para o ART é transparente — o código não requer alterações.

Bitcode e App Thinning

Bitcode — uma representação intermediária de código (IR) que a Apple usa para recompilar o IPA para diferentes arquiteturas de processador. O Bitcode é opcional: para aplicativos iOS, está ativado por padrão; para watchOS e tvOS, é obrigatório. A Apple pode recompilar o Bitcode quando novos processadores forem lançados, sem envolvimento do desenvolvedor. App Thinning — a tecnologia da Apple que inclui Slicing (entrega apenas dos recursos necessários para o dispositivo) e On-Demand Resources (carregamento de recursos sob demanda). O App Thinning reduz o tamanho do download da App Store em 30-50%.

DEX — formato de bytecode para Android, executado pelo ART/Dalvik. O código-fonte Kotlin/Java é compilado em arquivos class, depois em DEX via dx ou d8 (uma ferramenta moderna e mais rápida). Multidex — um mecanismo para aplicativos que excedem o limite de 65.536 métodos em um único arquivo DEX. Em projetos modernos, o multidex é ativado automaticamente se targetSdkVersion >= 21.

Assinatura de código: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — um arquivo contendo a chave privada e o certificado para assinar um aplicativo Android durante a compilação. O Keystore é criado via keytool (o comando -genkey) ou Android Studio. Importante: o Keystore não pode ser perdido — sem ele, você não poderá atualizar o aplicativo no Google Play. Parâmetros de assinatura: keyAlias, keyPassword, storePassword e storeFile. Formato: JKS (Java KeyStore) ou PEPK (Play Encrypted Private Key) para AAB.

App Bundle ID (Android) — o identificador único do aplicativo em notação de pacote (com.example.app). Version Code — um número inteiro para numeração interna de versões (cada nova compilação o incrementa). Version Name — uma string exibida ao usuário (1.2.3). Esses parâmetros são definidos no build.gradle no nível do app.

iOS: Apple Certificate e Provisioning Profile

Apple Certificate — um certificado digital que verifica a identidade do desenvolvedor. Tipos: Development (para depuração), Distribution (para App Store), Ad Hoc (para distribuição limitada). Os certificados são criados na Apple Developer Account e baixados no Keychain. Provisioning Profile — um arquivo que vincula o certificado, o App ID (Bundle Identifier) e uma lista de dispositivos permitidos. Sem um Provisioning Profile, o aplicativo não será executado em um dispositivo.

Bundle ID (iOS) — o identificador único do aplicativo (com.example.app). Build Number — o número da compilação, incrementado a cada build. Marketing Version — a versão mostrada ao usuário. Gerenciamento de versões: para iOS, os parâmetros são definidos no Info.plist e Project Settings; para Android — no build.gradle. Na IT Sectr, automatizamos as atualizações de versão via Fastlane — isso elimina erros humanos durante o lançamento.

Processo de publicação nas lojas

Google Play Console

Google Play Console — uma ferramenta para publicar aplicativos Android. Processo: registrar uma conta de desenvolvedor ($25 única), criar um aplicativo, preencher metadados (nome, descrição, capturas de tela, categoria), enviar AAB, configurar preços e distribuição, revisão. O Google verifica o aplicativo automaticamente (vírus, conformidade com políticas) e manualmente para algumas categorias. A revisão leva de algumas horas a 2-3 dias.

App Store Connect

App Store Connect — a plataforma da Apple para publicar aplicativos iOS. Processo: conta de desenvolvedor Apple ($99/ano), criar um aplicativo no App Store Connect, preparar o IPA no Xcode (Archive → Distribute App → App Store Connect), enviar via Transporter ou Xcode, preencher metadados, enviar para revisão. App Review — a revisão manual da Apple pode levar de 24 horas a 7 dias. Razões típicas de rejeição: botões que não funcionam, conteúdo incompleto, solicitação de permissões sem explicação.

Testes beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — a ferramenta oficial da Apple para testes beta de aplicativos iOS. O TestFlight suporta Internal Testing (até 100 testadores por e-mail, sem revisão) e External Testing (até 10.000 testadores, com revisão da Apple). As compilações ficam disponíveis por 90 dias, após os quais uma nova compilação deve ser enviada. O TestFlight atualiza automaticamente o aplicativo nos dispositivos dos testadores quando uma nova compilação é enviada.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — até 100 testadores, sem revisão do Google, a compilação está disponível imediatamente. Closed Beta — até 1000 testadores por e-mail ou Google Groups, sem revisão. Open Beta — testadores ilimitados através de um link público, com revisão do Google. Staged Rollout — aumento gradual da porcentagem de usuários que recebem a atualização (5% → 20% → 50% → 100%). Este é o método de lançamento mais seguro.

App Thinning (iOS) — redução automática do tamanho do IPA baixado: Slicing (apenas recursos necessários para o dispositivo), Bitcode (otimização do processador), On-Demand Resources (download sob demanda). Na IT Sectr, usamos o TestFlight para testes beta do iOS e o Internal Testing para Android — isso permite detectar problemas antes de um lançamento em massa.