Un CV de desarrollador móvil lo leen dos públicos distintos, a menudo seguidos: un reclutador escaneando palabras clave de stack y un líder técnico buscando pruebas de haber lanzado apps reales a usuarios reales. Un CV que gana a los dos está estructurado para que el reclutador vea el stack en el tercio superior y el líder técnico vea la prueba de envío en las viñetas de experiencia.
La mayoría de CVs móviles clava la primera parte y falla la segunda. Esto es lo que conviene arreglar.
Las señales específicas de móvil que buscan los líderes técnicos
Cuando una persona senior de iOS o Android revisa un CV, los patrones que busca no son genéricos. Cinco señales específicas de móvil cargan con casi todo el peso:
- Apps publicadas con enlaces a App Store / Play Store — la señal más fuerte. Una app en vivo con descargas y unas reseñas gana a cinco «lideré el desarrollo» que no llevan a nada cliqueable.
- Versiones de plataforma y mínimos de OS concretos — «iOS 15+» o «Android API 26+» enseña que has tomado decisiones reales de producción sobre soporte de dispositivos.
- Números de tamaño de app y rendimiento — «Cold start reducido de 3,1 s a 1,4 s» o «Binario reducido un 32 %» es el tipo de métrica que un líder técnico verifica con una sola pregunta de seguimiento.
- Nivel nativo declarado con honestidad — la mayoría de CVs móviles infla la profundidad nativa en la plataforma que en realidad no construyó. La solución es la honestidad: si escribiste la app de iOS y revisaste PRs en la Android, dilo así.
- Trabajo de distribución y release — TestFlight, App Store Connect, canales internos de Play Console, despliegues escalonados, in-app updates. Son habilidades operativas específicas de plataforma que separan a un dev móvil senior de alguien que solo ha hecho pantallas.
Una estructura que funciona para el CV de dev móvil
Para un CV de una página (junior a mid) o dos páginas (senior+):
Bloque de cabecera
Nombre, rol (p. ej. Senior iOS Engineer), ubicación, GitHub, y el enlace más importante: una URL de portfolio o un enlace a la App Store de una app publicada. Si tu app principal está en la App Store, el enlace va aquí, no enterrado en un proyecto al final.
Resumen (3 líneas, opcional pero de mucho efecto)
Tres líneas máximo: años de experiencia móvil, plataforma principal, una o dos especialidades de dominio. Ejemplo:
6 años construyendo apps iOS para fintech y salud, 4 apps publicadas en la App Store (400 000+ descargas acumuladas). Especializado en arquitectura offline-first y migraciones de Core Data a escala.
Esa sola línea ya te separa del 80 % de los CVs móviles del montón.
Sección de habilidades
Agrupa por categoría y ordena por relevancia para el puesto objetivo. Para una candidata orientada a iOS aplicando a un puesto Swift:
- Lenguajes: Swift 5, Objective-C (mantenimiento)
- Frameworks iOS: SwiftUI, UIKit, Combine, Core Data, CloudKit, WidgetKit
- Arquitectura: MVVM, TCA, Clean Architecture, modularización con SwiftPM
- Tooling: Xcode, Instruments, fastlane, Bitrise, Sentry
- Release: TestFlight, App Store Connect, despliegues por fases, informes App Privacy
Cuatro a seis categorías, doce a veinte elementos. Si también haces Android, una subsección Android aparte tiene sentido — pero clasifícate con honestidad. Listar Kotlin, Jetpack Compose, Hilt, Room cuando has publicado una sola app de tutorial en Kotlin es el tipo de exageración que se pilla en 15 minutos de screen técnico.
Viñetas de experiencia — el patrón móvil
Las viñetas móviles más fuertes siguen esta forma:
Hice[cosa móvil concreta]usando[framework/herramienta concreta]→ con[resultado móvil medible].
Unos ejemplos para una persona de iOS:
- Migré el flujo de checkout de UIKit a SwiftUI en 18 pantallas, recortando el tiempo de construcción por pantalla un 40 % y reduciendo la tasa de bugs por feature en QA ~25 %.
- Re-arquitecté el acceso a Core Data con un coordinador de sync, llevando la tasa de usuarios sin crash de 99,2 % a 99,85 % en dos releases.
- Hice ownership del pipeline de release en App Store (fastlane + match), pasando la prep de release de 2 días a 90 minutos y permitiendo releases semanales.
- Lancé un widget WidgetKit con el resumen financiero para la pantalla de inicio, adoptado por el 38 % de los usuarios activos mensuales en seis semanas.
Fíjate en el patrón: cada viñeta tiene un artefacto móvil concreto (UIKit, Core Data, fastlane, WidgetKit), un verbo de ownership (migré, re-arquitecté, hice ownership, lancé) y un número que un responsable puede sondear en entrevista.
Para una persona de Android los equivalentes son: migraciones a Jetpack Compose, trabajo de esquema Room, recortes de tiempos de build de Gradle, gestión de release en Play Console, reestructuración de módulos Hilt, trabajo con Baseline Profiles para mejorar el cold start.
Sección de proyectos — donde viven los enlaces a tienda
Si has publicado apps fuera del trabajo — aunque sean pequeñas — lístalas. Cada entrada: nombre de la app, enlace App Store / Play Store, una línea de contexto, una línea de punto técnico destacado.
TideTracker — app iOS de previsión de olas, 12 000 descargas. Construida en solo en SwiftUI con predicción de altura de ola en Core ML en dispositivo. App Store: [enlace].Tres de estas en un CV casi siempre bastan. Funcionan como prueba, no como portfolio en profundidad.
CV iOS Android — el problema de la honestidad cross-platform
La mayoría de candidatos reclama más fluidez cross-platform de la que tiene, y los líderes técnicos están calibrados contra eso. El encuadre honesto:
- Plataforma principal: aquella en la que has publicado, depurado en producción y tomado decisiones de arquitectura.
- Plataforma secundaria: aquella en la que has construido algo no trivial, pero quizá sin poseer la release.
- Familiar: has leído código, contribuido en reviews, sabes moverte por una base de código.
Escribir iOS (principal), Android (familiar) es más creíble que listar las dos a la par y caer en el screen técnico. «Familiar» se lee como honesto y consciente — dos adjetivos que te hacen avanzar.
Frameworks cross-platform — React Native, Flutter, Kotlin Multiplatform
Si tu base es React Native o Flutter, trata el framework como el stack principal y lista los puentes nativos y el trabajo específico de plataforma como prueba de apoyo. Los equipos móviles que contratan para RN quieren ver que has:
- Publicado en ambas tiendas desde la misma base de código.
- Escrito o depurado módulos nativos (Java/Kotlin o Swift/Objective-C) al menos de vez en cuando.
- Manejado los bordes específicos de plataforma: configuración de notificaciones push, deep linking, compras in-app, escaladas de review de app.
Un CV que liste React Native sin nada de esto se lee como dev web probando a hacer móvil. Los equipos móviles que contratan se fijan en quién ha tenido de verdad la cuenta de la App Store, no en quién ha escrito pantallas.
Qué quitar
- Tecnologías móviles obsoletas — Cordova, PhoneGap, Xamarin como habilidad principal en 2026.
- Viñetas genéricas no móviles — «Escribí tests unitarios» sin contexto de plataforma. Especifica XCTest, JUnit, Espresso, etc.
- «Uso Git, JIRA, Slack» — herramientas universales, no habilidades. Ocupan el sitio que debería ser específico de móvil.
- Listas largas de todos los frameworks iOS que has oído — Combine, RxSwift, MapKit, ARKit, CoreImage, AVFoundation, MetricKit apilados señala relleno, no amplitud.
El equipo de Postulit ve a menudo CVs móviles generados desde LinkedIn que arrastran todos los buzzwords de las ofertas desde una lista de aptitudes de LinkedIn — el pase de curación para un CV móvil es más corto y más brutal que para muchos otros roles, precisamente porque los entrevistadores móviles testean a fondo las pocas afirmaciones que les importan.
Publica una app pequeña, pon el enlace, escribe tres viñetas con métricas de la App Store. Eso es más señal que una nube de 50 tecnologías.
Un CV móvil que se lee como honesto, específico y publicado gana a uno que se lee como exhaustivo. Siempre.