Compilación y publicación en el desarrollo móvil: qué es, qué formatos y cómo funciona

Formatos de compilación: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — el formato tradicional de compilación y publicación de aplicaciones móviles en Android. APK contiene todo el código, recursos y manifiesto de la aplicación. AAB (Android App Bundle) — un formato introducido por Google en 2018 y que se volvió obligatorio para aplicaciones nuevas en agosto de 2021. AAB no se instala directamente — Google Play genera dinámicamente un APK optimizado para cada dispositivo a partir de AAB.

Ventajas de AAB: el tamaño de descarga es en promedio un 15% menor (al entregar solo los recursos necesarios: densidades de pantalla correctas, idiomas, arquitecturas de CPU). AAB también admite la entrega modular — puede cargar módulos bajo demanda (Play Feature Delivery) o diferidos (Play On-Demand). Para los desarrolladores, AAB es obligatorio; para la distribución fuera de Google Play (sideloading, marketplaces) — solo APK.

IPA

IPA (iOS App Store Package) — el archivo instalable de iOS, que es un archivo ZIP con una aplicación firmada. IPA contiene una carpeta Payload/ con el bundle .app, Provisioning Profile y la firma. IPA se compila solo en macOS mediante Xcode, que crea un archivo (.xcarchive) y exporta IPA. Para la distribución a través de App Store, IPA se firma con un Apple Distribution Certificate; para Ad Hoc o Enterprise — con los certificados correspondientes.

Compilación y optimización: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — compilación de código durante la ejecución de la aplicación, que afecta la velocidad de compilación y publicación. En Android hasta la versión 5.0 (Lollipop) se usaba Dalvik VM con compilación JIT. En cada inicio de la aplicación, el bytecode DEX se convertía en código máquina «sobre la marcha». Inconveniente: ralentización en el primer inicio y consumo adicional de energía. AOT (Ahead-Of-Time) — compilación de código antes del inicio de la aplicación, durante la instalación. A partir de Android 7.0 (Nougat), ART (Android Runtime) compila la aplicación completamente durante la instalación.

ART (Android Runtime) — el entorno de ejecución que reemplazó a Dalvik en Android 5.0. ART utiliza un enfoque híbrido: compilación AOT durante la instalación + JIT para métodos ejecutados con frecuencia. Esto combina la velocidad de AOT (inicio rápido) con la flexibilidad de JIT (optimización adaptativa). Resultado: el rendimiento de las aplicaciones Android aumentó un 20-30% en comparación con Dalvik. Para los desarrolladores, la transición a ART es transparente — el código no requiere cambios.

Bitcode y App Thinning

Bitcode — una representación intermedia de código (IR) que Apple utiliza para recompilar IPA para diferentes arquitecturas de procesador. Bitcode es opcional: para aplicaciones iOS está habilitado por defecto, para watchOS y tvOS es obligatorio. Apple puede recompilar Bitcode cuando salgan nuevos procesadores sin intervención del desarrollador. App Thinning — la tecnología de Apple que incluye Slicing (entrega solo de los recursos necesarios para el dispositivo) y On-Demand Resources (carga de recursos bajo demanda). App Thinning reduce el tamaño de descarga de App Store en un 30-50%.

DEX — formato de bytecode para Android, ejecutado por ART/Dalvik. El código fuente Kotlin/Java se compila en archivos class, luego en DEX mediante dx o d8 (una herramienta moderna y más rápida). Multidex — un mecanismo para aplicaciones que superan el límite de 65 536 métodos en un solo archivo DEX. En proyectos modernos, multidex se habilita automáticamente si targetSdkVersion >= 21.

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

Android: Keystore

Keystore — un archivo que contiene la clave privada y el certificado para firmar una aplicación Android durante la compilación. Keystore se crea mediante keytool (el comando -genkey) o Android Studio. Importante: Keystore no se puede perder — sin él no podrá actualizar la aplicación en Google Play. Parámetros de firma: keyAlias, keyPassword, storePassword y storeFile. Formato: JKS (Java KeyStore) o PEPK (Play Encrypted Private Key) para AAB.

App Bundle ID (Android) — el identificador único de la aplicación en notación de paquete (com.example.app). Version Code — un número entero para la numeración interna de versiones (cada nueva compilación lo incrementa). Version Name — una cadena que se muestra al usuario (1.2.3). Estos parámetros se establecen en build.gradle a nivel de app.

iOS: Apple Certificate y Provisioning Profile

Apple Certificate — un certificado digital que verifica la identidad del desarrollador. Tipos: Development (para depuración), Distribution (para App Store), Ad Hoc (para distribución limitada). Los certificados se crean en Apple Developer Account y se descargan en Keychain. Provisioning Profile — un archivo que vincula el certificado, App ID (Bundle Identifier) y una lista de dispositivos permitidos. Sin un Provisioning Profile, la aplicación no se ejecutará en un dispositivo.

Bundle ID (iOS) — el identificador único de la aplicación (com.example.app). Build Number — el número de compilación, se incrementa con cada build. Marketing Version — la versión que se muestra al usuario. Gestión de versiones: para iOS, los parámetros se establecen en Info.plist y Project Settings; para Android — en build.gradle. En IT Sectr, automatizamos las actualizaciones de versión mediante Fastlane — esto elimina errores humanos durante el lanzamiento.

Proceso de publicación en tiendas

Google Play Console

Google Play Console — una herramienta para publicar aplicaciones Android. Proceso: registrar una cuenta de desarrollador ($25 una vez), crear una aplicación, completar metadatos (nombre, descripción, capturas de pantalla, categoría), subir AAB, configurar precios y distribución, revisión. Google verifica la aplicación automáticamente (virus, cumplimiento de políticas) y manualmente para algunas categorías. La revisión toma desde unas horas hasta 2-3 días.

App Store Connect

App Store Connect — la plataforma de Apple para publicar aplicaciones iOS. Proceso: cuenta de desarrollador de Apple ($99/año), crear una aplicación en App Store Connect, preparar IPA en Xcode (Archive → Distribute App → App Store Connect), subir mediante Transporter o Xcode, completar metadatos, enviar a revisión. App Review — la revisión manual de Apple puede tardar desde 24 horas hasta 7 días. Razones típicas de rechazo: botones que no funcionan, contenido incompleto, solicitud de permisos sin explicación.

Pruebas beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — la herramienta oficial de Apple para pruebas beta de aplicaciones iOS. TestFlight admite Internal Testing (hasta 100 probadores por correo electrónico, sin revisión) y External Testing (hasta 10 000 probadores, con revisión de Apple). Las compilaciones están disponibles durante 90 días, después de lo cual se debe subir una nueva compilación. TestFlight actualiza automáticamente la aplicación en los dispositivos de los probadores cuando se sube una nueva compilación.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — hasta 100 probadores, sin revisión de Google, la compilación está disponible de inmediato. Closed Beta — hasta 1000 probadores por correo electrónico o Google Groups, sin revisión. Open Beta — probadores ilimitados mediante un enlace público, con revisión de Google. Staged Rollout — aumento gradual del porcentaje de usuarios que reciben la actualización (5% → 20% → 50% → 100%). Este es el método de lanzamiento más seguro.

App Thinning (iOS) — reducción automática del tamaño del IPA descargado: Slicing (solo recursos necesarios para el dispositivo), Bitcode (optimización del procesador), On-Demand Resources (descarga bajo demanda). En IT Sectr, usamos TestFlight para pruebas beta de iOS e Internal Testing para Android — esto permite detectar problemas antes de un lanzamiento masivo.