Roadmap de habilidades de mobile engineer para 2026

La ingeniería mobile en 2026 significa SwiftUI en iOS, Jetpack Compose en Android, y React Native o Flutter si va por cross-platform. Este roadmap cubre el stack moderno, las realidades de la App Store y el plan de 12 meses para convertirse en un mobile engineer que las empresas contraten.

La contratación mobile se dividió en tres carriles: iOS nativo (Swift + SwiftUI), Android nativo (Kotlin + Compose) y cross-platform (React Native o Flutter). Lo nativo todavía paga un pequeño premium y domina las ofertas senior; lo cross-platform domina la contratación en startups. Este roadmap cubre una plataforma nativa en profundidad más suficiente fluidez cross-platform para cambiar de carril más adelante.

Quién es un mobile engineer en 2026

Un mobile engineer entrega apps que corren en iPhones o dispositivos Android y cumplen las políticas de la App Store / Play Store. En concreto:

• Traduce diseños en pantallas con navegación, estado y casos límite reales.
• Maneja networking, persistencia local, refresco en background y modos offline.
• Alcanza objetivos de rendimiento en un dispositivo Android de hace 3 años, no solo en el último iPhone.
• Gestiona el envío a las tiendas, el code signing, TestFlight/Play Console y la estrategia de actualización.
• Es dueño del crash reporting, la analítica y la estrategia de rollback.

Mobile junior: construye pantallas según especificación. Mid-level: es dueño de una funcionalidad incluyendo networking y estado. Senior: toma decisiones de arquitectura (single vs multi-módulo, estrategia de navegación, dependency injection) y guía a los juniors a través de ellas.

Stack core — qué aprender de verdad

Soft skills y pensamiento de sistemas

• Empatía con la realidad del dispositivo. Su portátil tiene 32 GB de RAM; un dispositivo Android económico tiene 3 GB. Pruebe en dispositivos reales.
• Pensar en el ciclo de actualización. Los bugs mobile están en producción durante semanas antes de que los usuarios actualicen. Añada feature flags, rutas de rollback y kill switches del lado del servidor por defecto.
• Pensar en la App Store. Un rechazo significa una semana de retraso. Lea las directrices. Entienda por qué fallan las revisiones.
• Disciplina de rendimiento. Tiempo de cold-start, jank al hacer scroll, consumo de batería. Mídalos.
• Colaboración con diseñadores. Los sistemas de diseño nativos difieren. Material 3 en Android, Apple Human Interface en iOS. Replicar con criterio es su trabajo cuando los diseños ignoran la plataforma.

Plan sugerido de 3 / 6 / 12 meses

Meses 1–3: elija una plataforma, aprenda el lenguaje

• iOS: fundamentos de Swift, luego SwiftUI. Los “100 Days of SwiftUI” de Apple siguen siendo la mejor ruta gratuita.
• Android: fundamentos de Kotlin, luego Jetpack Compose. El curso “Android Basics with Compose” de Google.
• Construya tres apps pequeñas: una lista de tareas, una app del tiempo con networking, una pantalla de ajustes/perfil.

Meses 4–6: una app real

• Construya una app de calidad de producción: auth, llamadas de red, persistencia local, notificaciones push, desplegada a TestFlight o al canal interno de Play Console.
• Añada tests. Al menos 10 tests unitarios y 2 tests de UI.
• Implemente el cuarteto estándar: estados de carga, error, vacío y éxito para cada pantalla.
• Envíela a la App Store o Play Store. El propio envío es la lección.

Meses 7–12: profundidad y entrevistas

• Lea de principio a fin la guía de arquitectura de su plataforma. Los SwiftUI essentials de Apple, la guía de Architecture Components de Google.
• Añada una funcionalidad no trivial: compras in-app, actualizaciones en tiempo real, un layout personalizado de Compose o ML on-device.
• Practique diseño de sistemas mobile: diseñe el feed de Instagram, diseñe la pantalla de mapa de Uber, diseñe una app de chat.
• Postule con un portafolio que incluya un enlace en vivo a la tienda de apps más un repo de GitHub.

Proyectos paralelos para construir

• Una app publicada en la tienda. Aunque sea simple, la experiencia de publicar importa más que la complejidad.
• Una app offline-first. Motor de sincronización, resolución de conflictos, mutaciones en cola. Demuestra pensamiento senior desde temprano.
• Un widget o live activity. Demuestra profundidad de plataforma más allá de la app principal.
• Una funcionalidad con LLM on-device. Un resumidor o reescritor con Core ML o MediaPipe. La contratación de 2026 valora esto.

Realidades del envío a la App Store y lo que los ingenieros mid-level aprenden a las malas

El stack técnico es la mitad fácil de la ingeniería mobile. La mitad poco glamurosa — signing, review, rollouts — es la que causa más incidentes.

• El provisioning es una disciplina en sí misma. Bundle IDs wildcard vs explícitos, certificados de distribución vs desarrollo, claves de la App Store Connect API para CI. Documente las decisiones, rote antes de que expiren, nunca deje que un solo ingeniero tenga la única clave de signing.
• App Review le rechazará. Razones comunes en 2026: faltan etiquetas de privacidad para un SDK de terceros, IAP de bienes digitales enrutados fuera de StoreKit, login requerido sin forma de que el revisor lo pruebe, faltan credenciales de prueba. Anticípese a las cuatro.
• Los rollouts por fases salvan empleos. Despliegue al 1% — 5% — 25% — 100% a lo largo de una semana. Vigile los crash-free users, la tasa de ANR, el funnel que toca el release. Deténgase ante la primera bandera roja.
• Feature flags del lado del servidor. Un bug mobile está en producción durante semanas antes de que los usuarios actualicen. Un feature flag apaga el bug en segundos. Cablee flags en cada funcionalidad arriesgada por defecto.
• Estrategia de force-update. Tenga una forma de avisar a los usuarios de una build antigua y rota de que deben actualizar. Hágalo humano (un aviso descartable una vez) antes de que se vuelva duro (bloqueo total).
• Cumplimiento de la UE y regional. La DMA en la UE cambió las reglas para navegadores y pagos por defecto. App Tracking Transparency sigue siendo relevante. Siguen apareciendo nuevas leyes regionales de privacidad. Suscríbase a las notas de versión de la plataforma.
• El crash-free es la estrella polar. 99,9% de crash-free users es un buen suelo para 2026. Si cae por debajo del 99,5% en un release, pause el rollout.

En las entrevistas senior, la pregunta que separa a los candidatos es “cuénteme su peor release de producción”. El candidato que responde con un rollout por fases, un pico de crashes, un kill switch y un postmortem parece senior. El que responde “realmente no hacemos eso” no.

Cómo conseguir el puesto mobile

• Keywords del currículum. Swift, SwiftUI, Combine (iOS) o Kotlin, Jetpack Compose, Coroutines (Android). Más su framework de testing, herramienta de CI y un SDK de analítica.
• Enlace a la tienda de apps. La señal más fuerte de que ha publicado. Incluso una app pequeña publicada supera a diez proyectos solo en GitHub.
• Rondas de entrevista: coding (a menudo Swift/Kotlin en pizarra, a veces con Xcode/Android Studio), deep dive de plataforma, diseño de sistemas, conductual.
• El deep dive de plataforma. Espere preguntas sobre gestión de memoria, threading, el ciclo de vida de la app de la plataforma, gotchas comunes. Practique responder preguntas de “qué pasa cuando…” sobre su plataforma.
• Diseño de sistemas. El diseño de sistemas mobile es su propia bestia — sincronización offline, caché de imágenes, paginación, jerarquías de navegación. Practique 10 de estos.

FAQ