Construcción y publicación de aplicaciones Ionic para Android e iOS

Preparar la app para distribución

Publicar una app Ionic implica convertir el mismo código base (HTML/CSS/TypeScript) en binarios nativos: APK/AAB para Android y IPA para iOS. En Ionic, esto se logra normalmente con Capacitor, que genera proyectos nativos (Android Studio y Xcode) conectados a tu app web. La preparación para distribución se centra en: identificadores, recursos (iconos/splash), variables de entorno, builds de producción y firma.

Identificadores (App ID / Bundle ID) y metadatos básicos

El identificador es el “nombre único” de tu app en cada plataforma. Debe definirse antes de firmar y publicar, y no conviene cambiarlo después porque afecta actualizaciones, notificaciones push, deep links y datos asociados.

• Android: applicationId (ej. com.tuempresa.tuapp)
• iOS: CFBundleIdentifier (ej. com.tuempresa.tuapp)

En Capacitor, el identificador se define en capacitor.config.ts y se sincroniza a los proyectos nativos.

import type { CapacitorConfig } from '@capacitor/cli'; const config: CapacitorConfig = { appId: 'com.tuempresa.tuapp', appName: 'TuApp', webDir: 'www', bundledWebRuntime: false }; export default config;

Tras cambiarlo, sincroniza:

npx cap sync

Recomendación: usa un appName amigable (lo que ve el usuario) y un appId estable (lo que usan las tiendas y el sistema).

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Iconos y splash (recursos de marca)

Para distribución necesitas iconos y pantallas de inicio con tamaños correctos por plataforma. En proyectos Ionic es común usar el pipeline de assets para generar variantes automáticamente.

Flujo típico:

• Coloca un icono base (por ejemplo resources/icon.png) y un splash base (por ejemplo resources/splash.png), con buena resolución.
• Genera assets para Android/iOS.
• Sincroniza cambios a los proyectos nativos.

Comandos (según configuración del proyecto):

npm run build npx cap sync

Nota práctica: si al abrir Android Studio/Xcode no ves cambios, limpia cachés/derivados (en iOS) o ejecuta un Clean Project (Android) y vuelve a compilar.

Variables de entorno y configuración por “sabores”

En distribución es habitual tener entornos: dev, staging y prod (URLs de API, claves públicas, flags de analítica, etc.). La idea es que el código sea el mismo, pero la configuración cambie según el build.

En Angular (Ionic Angular), se suele usar environment.ts y reemplazos por configuración de build. Ejemplo de estructura:

src/environments/environment.ts src/environments/environment.prod.ts

Ejemplo de contenido:

// environment.ts export const environment = { production: false, apiBaseUrl: 'https://api-dev.tuempresa.com', sentryDsn: '' }; // environment.prod.ts export const environment = { production: true, apiBaseUrl: 'https://api.tuempresa.com', sentryDsn: 'https://...' };

Regla importante: no incluyas secretos reales (tokens privados, claves con permisos de escritura) dentro del bundle. En apps móviles, el código puede inspeccionarse. Usa backend para emitir tokens temporales o mecanismos seguros.

Builds de producción (web) antes del empaquetado nativo

Capacitor empaqueta el resultado del build web dentro del contenedor nativo. Por eso, antes de generar binarios, debes crear un build optimizado.

Flujo recomendado:

1. Genera build de producción web.
2. Copia/sincroniza al proyecto nativo.
3. Compila y firma en Android Studio / Xcode.

Comandos típicos:

// 1) Build web de producción (Angular) npm run build -- --configuration production // 2) Sincronizar con nativos npx cap sync

Si usas variables por entorno, asegúrate de que el build realmente está usando environment.prod.ts (o el equivalente de tu stack).

Generar binarios para Android e iOS desde el mismo código base

El núcleo es el mismo: tu app web. La diferencia está en el “shell” nativo y en configuraciones específicas (permisos, capacidades, firma, compatibilidad). Capacitor crea y mantiene dos carpetas principales: android/ e ios/. Tu trabajo es mantener la app web lista y luego compilar cada plataforma con sus herramientas.

Flujo unificado (paso a paso)

Android: configuración, permisos, compatibilidad y firma

1) Abrir el proyecto nativo

npx cap open android

Esto abre Android Studio con el proyecto generado.

2) Identificador, versión y versionCode

En Android, además del applicationId, debes gestionar:

• versionName: versión visible (ej. 1.4.0)
• versionCode: entero incremental requerido para actualizaciones (ej. 10400)

Se configuran en Gradle (normalmente en android/app/build.gradle). Ejemplo orientativo:

android { defaultConfig { applicationId "com.tuempresa.tuapp" minSdkVersion 24 targetSdkVersion 34 versionCode 10400 versionName "1.4.0" } }

Compatibilidad: revisa minSdkVersion según tus plugins nativos y tu público objetivo. Subirlo puede excluir dispositivos antiguos.

3) Permisos (AndroidManifest)

Los permisos se declaran en AndroidManifest.xml. Muchos plugins de Capacitor los agregan automáticamente, pero debes validar que:

• Solo pides lo necesario (mejora aprobación y confianza).
• Si un permiso es sensible (ubicación, cámara, micrófono), también implementas el flujo de solicitud en runtime.

Ejemplo (orientativo):

<uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

4) Build de release y firma

Para publicar en Google Play, lo habitual es generar un Android App Bundle (AAB). Para firmar necesitas un keystore.

Pasos típicos:

1. Crear/usar un keystore (guárdalo de forma segura; perderlo impide firmar futuras actualizaciones).
2. Configurar la firma en Gradle (release signingConfig).
3. Generar el bundle desde Android Studio: Build > Generate Signed Bundle / APK.

Ejemplo de configuración (orientativa) en Gradle:

android { signingConfigs { release { storeFile file("tuapp-release.keystore") storePassword System.getenv("ANDROID_KEYSTORE_PASSWORD") keyAlias System.getenv("ANDROID_KEY_ALIAS") keyPassword System.getenv("ANDROID_KEY_PASSWORD") } } buildTypes { release { signingConfig signingConfigs.release minifyEnabled true shrinkResources true } } }

Observa el enfoque: contraseñas vía variables de entorno (no hardcodeadas).

iOS: configuración, capacidades, compatibilidad y firma

1) Abrir el proyecto nativo

npx cap open ios

Esto abre Xcode con el workspace/proyecto iOS.

2) Bundle ID, versión y build number

En iOS, gestiona:

• Bundle Identifier: debe coincidir con el registrado en Apple Developer.
• Version (Marketing Version): ej. 1.4.0
• Build: número incremental por subida (ej. 140)

Se ajusta en Xcode en el target principal (General > Identity).

3) Permisos y descripciones (Info.plist)

iOS requiere no solo habilitar capacidades, sino también declarar mensajes de uso (Usage Descriptions) para permisos sensibles. Si falta, la app puede crashear al solicitar el permiso o ser rechazada.

Ejemplos de claves comunes (orientativas):

• NSCameraUsageDescription
• NSLocationWhenInUseUsageDescription
• NSMicrophoneUsageDescription

Buenas prácticas:

• Texto claro y específico: “Necesitamos la cámara para escanear códigos QR”.
• No pidas permisos al inicio sin contexto; solicita cuando el usuario activa la función.

4) Capacidades (Signing & Capabilities)

Funciones como notificaciones push, Sign in with Apple, iCloud, Background Modes o Associated Domains requieren habilitar capacidades en Xcode y que el App ID esté configurado en Apple Developer.

Checklist rápido:

• Activar la capability en Xcode.
• Verificar que el App ID en Apple Developer tiene esa capability.
• Revisar que el plugin/implementación esté alineado.

5) Firma y exportación (IPA)

Para distribuir necesitas un certificado y un provisioning profile. En Xcode:

1. Selecciona el Team (Signing).
2. Configura “Automatically manage signing” (si aplica) o perfiles manuales.
3. Genera un archivo para distribución: Product > Archive y luego Distribute App.

Para pruebas internas, puedes usar TestFlight (requiere subida a App Store Connect).

Gestionar configuraciones específicas por plataforma

Aunque el código base sea único, hay diferencias inevitables. La clave es aislarlas y documentarlas.

Detección de plataforma y ramas de comportamiento

Cuando una funcionalidad requiere ajustes por plataforma (por ejemplo, rutas de archivos, comportamiento de permisos o UI nativa), usa detección de plataforma de Capacitor.

import { Capacitor } from '@capacitor/core'; const platform = Capacitor.getPlatform(); if (platform === 'ios') { // comportamiento iOS } else if (platform === 'android') { // comportamiento Android } else { // web } 

Evita duplicar lógica de negocio: limita estas ramas a detalles de integración.

Configuración de red y seguridad

En producción, usa HTTPS. Si por motivos internos necesitas HTTP en entornos de prueba, recuerda que:

• Android e iOS pueden bloquear tráfico no seguro por defecto.
• Las excepciones deben ser temporales y específicas (solo para dominios de staging/dev).

Compatibilidad con dispositivos y sistemas

• Android: diversidad de fabricantes y versiones; prueba en al menos un dispositivo de gama media y uno de gama baja si tu público lo requiere.
• iOS: menos fragmentación, pero atención a tamaños de pantalla, permisos y políticas estrictas.

Builds de producción: ajustes recomendados

Minificación, optimización y mapas de fuente

En release, habilita minificación/optimización. Si usas monitoreo de errores, considera generar y subir source maps a tu herramienta de observabilidad (sin exponerlos públicamente).

Logs y flags de depuración

Desactiva logs verbosos y herramientas de debug en builds de producción. Centraliza el logging con un servicio que puedas silenciar por entorno.

Configuración de WebView

Algunas apps requieren ajustes del WebView (por ejemplo, permitir navegación a dominios específicos). Mantén una lista explícita de dominios permitidos y evita comodines amplios.

Checklist de entrega (pruebas finales, versionado y empaquetado)

Checklist técnico

• Versionado: incrementa versionName/versionCode (Android) y Version/Build (iOS).
• Identificadores: appId definitivo y consistente en ambas plataformas.
• Entorno: build apuntando a endpoints de producción; flags de debug desactivados.
• Permisos: solo los necesarios; textos de Info.plist completos en iOS.
• Iconos/Splash: correctos, sin pixelación, y verificados en dispositivos reales.
• Rendimiento: arranque, navegación principal y pantallas críticas sin bloqueos.
• Red: HTTPS, manejo de errores offline, timeouts razonables.
• Almacenamiento: migraciones/compatibilidad si cambiaste esquemas o claves.
• Accesos: login/logout, expiración de sesión, recuperación ante token inválido.

Checklist de pruebas finales

• Smoke test: abrir app, navegar secciones clave, ejecutar acción principal.
• Permisos: denegar/aceptar y verificar comportamiento (sin loops ni bloqueos).
• Interrupciones: llamadas/notificaciones, cambio de app a segundo plano y retorno.
• Rotación y tamaños: al menos un teléfono pequeño y uno grande; en iOS, probar notch.
• Modo avión: pantallas que dependen de red muestran estados adecuados.

Checklist de empaquetado listo para publicación

• Android: generar AAB firmado (y APK si lo necesitas para distribución interna), verificar instalación y actualización sobre una versión anterior.
• iOS: generar Archive en Xcode, exportar/distribuir (TestFlight o App Store), verificar firma y perfiles.
• Notas de release: lista de cambios y compatibilidades.
• Capturas: preparar screenshots por tamaño requerido (se gestionan en la consola de cada store).
• Privacidad: revisar permisos declarados vs. uso real y políticas de datos.