¿Cómo abordas la optimización del rendimiento en una app móvil?

El rendimiento en móvil no es negociable porque los usuarios desinstalarán una app que se sienta lenta, y a diferencia de una app web, no puedes enviar un arreglo al instante. Mi enfoque comienza con la medición: uso Xcode Instruments para iOS y Android Profiler para Android para identificar los verdaderos cuellos de botella antes de escribir una sola línea de código de optimización. Los problemas más comunes que encuentro son el bloqueo del hilo principal, los re-renderizados excesivos en React Native y la carga ineficiente de imágenes. Para el trabajo en el hilo principal, muevo cualquier cómputo o I/O fuera del hilo principal usando operaciones asíncronas. Para la carga de imágenes uso lazy loading con una capa de caché, dimensionando las imágenes a la resolución de visualización en lugar de descargar assets de alta resolución y escalarlos. También perfilo el tiempo de arranque por separado porque afecta desproporcionadamente a la retención: apunto a menos de 2 segundos de arranque en frío en un dispositivo de gama media.

¿Cómo gestionas la funcionalidad offline-first en una app móvil?

El offline-first es una decisión de diseño que debe tomarse a nivel de arquitectura, no añadirse como reflexión posterior. La idea central es que el dispositivo local es la fuente de verdad para las lecturas, y la red se usa para sincronizar el estado, no para servir cada solicitud. Uso una base de datos local, SQLite a través de Room en Android o Core Data o SQLite en iOS, para persistir todos los datos que los usuarios podrían necesitar sin conexión. Las operaciones de escritura se encolan localmente con un indicador de estado y un mecanismo de reintento, y se reproducen contra el servidor cuando se restaura la conectividad. El problema difícil es la resolución de conflictos: cuando un usuario edita datos en un dispositivo sin conexión y el servidor tiene una versión más reciente, necesito decidir cuál gana. Mi preferencia es una estrategia de último en escribir gana con un timestamp del servidor, con una interfaz de resolución manual de conflictos para los casos críticos.

¿Cómo gestionas el estado en una aplicación móvil compleja?

La complejidad de la gestión de estado escala rápidamente en las apps móviles a medida que crece el número de pantallas y flujos de datos. Mi enfoque depende de la plataforma: en iOS uso una combinación de la gestión de estado integrada de SwiftUI para el estado UI local y un patrón de flujo de datos unidireccional de estilo Redux para el estado compartido de la aplicación, usando una biblioteca como TCA para apps más grandes. En React Native uso Zustand o Redux Toolkit según las convenciones existentes del equipo, y soy deliberado sobre separar el estado del servidor del estado del cliente, usando React Query para el primero. El error más común que veo es poner todo en un único store global, lo que hace los tests difíciles y causa re-renderizados innecesarios. Estructuro el estado en módulos que corresponden a funcionalidades, y mantengo el estado local al componente a menos que genuinamente necesite ser compartido.

¿Cómo abordas el proceso de envío y publicación en los app stores?

Los envíos a los app stores son lentos y los rechazos son costosos, así que invierto mucho en el proceso de revisión antes de enviar. Mi checklist cubre: ejecutar la suite de tests completa incluyendo tests UI en dispositivos reales, comprobar el uso de APIs deprecadas que podrían provocar rechazo, verificar que todas las declaraciones del manifiesto de privacidad coincidan con los permisos que la app usa realmente, y probar en la versión OS mínima soportada. Uso TestFlight para iOS y la pista de tests internos en Google Play para dar a los stakeholders una versión para revisar antes de la publicación pública. Para los lanzamientos graduales uso la función de lanzamiento gradual de App Store y el staged rollout de Google Play, empezando al 5% y monitorizando las tasas de crash y las reseñas antes de expandir.

Cuéntame sobre un problema de rendimiento significativo que identificaste y solucionaste en una app móvil.

Estaba trabajando en una app React Native donde la pantalla de inicio tardaba 4,2 segundos en volverse interactiva en un dispositivo Android de gama media. Los usuarios abandonaban antes de que apareciera el contenido. Empecé con el perfilador de rendimiento de React Native e identifiqué rápidamente que hacíamos seis llamadas API secuenciales al montaje, cada una esperando a que terminara la anterior, antes de renderizar ningún contenido. El primer arreglo fue paralelizar las llamadas API, lo que redujo el tiempo a 2,8 segundos. El segundo problema era que renderizábamos toda la lista al montaje aunque solo los cinco primeros elementos eran visibles: cambiar a una FlatList con extracción de claves y estimación de altura de elementos adecuadas redujo el tiempo a 1,9 segundos. El tercer problema era la carga de imágenes. Después de cambiar a imágenes del tamaño adecuado con caché, el tiempo de interactividad era de 1,1 segundos.

Describe una situación en la que tuviste que dar soporte a múltiples versiones de plataforma y cómo gestionaste la complejidad.

Trabajé en una app iOS que necesitaba soportar iOS 15 hasta iOS 17, que introdujo diferencias significativas de SwiftUI entre versiones. El desafío era que varias APIs que queríamos usar solo estaban disponibles en iOS 16 o posterior, mientras que el 30% de nuestros usuarios seguían en iOS 15. Usé un enfoque de feature flags combinado con comprobaciones de versión de OS para proporcionar dos implementaciones para las funcionalidades afectadas: una implementación completa para iOS 16+ y una versión de reserva para iOS 15. También configuré una matriz de dispositivos en nuestro pipeline CI cubriendo las versiones OS mínima y máxima soportadas. La decisión más importante fue acordar con el equipo de producto un calendario de fin de soporte para iOS 15, lo que nos permitió planificar la simplificación de la base de código en lugar de acumular caminos legacy indefinidamente.

Da un ejemplo de un bug difícil que rastreaste en una app móvil. ¿Cuál fue tu proceso de depuración?

Tenía un crash que aparecía en Crashlytics afectando alrededor del 0,3% de las sesiones, pero solo en dispositivos Samsung específicos con Android 11. El crash estaba en nuestra biblioteca de caché de imágenes, pero el stack trace no era reproducible en ningún dispositivo que tuviéramos en la oficina. Mi proceso de depuración comenzó aislando las condiciones: encargué un Samsung A32 y reproduje el crash en el tercer intento. El stack trace apuntaba a un fallo de asignación de memoria durante una decodificación de bitmap. Miré el uso de memoria en el momento del crash y encontré que los dispositivos afectados tenían significativamente menos memoria heap disponible debido a las restricciones de memoria más estrictas de la implementación Android 11 de Samsung. El arreglo fue añadir una comprobación de memoria antes de intentar grandes asignaciones de bitmap y degradarse graciosamente a una imagen de menor resolución cuando la memoria estaba limitada.

¿Cómo abordas las pruebas en una aplicación móvil?

Las pruebas en móvil requieren una estrategia en capas porque la pirámide de pruebas parece diferente del desarrollo del lado del servidor. La capa más grande y rápida son las pruebas unitarias para la lógica de negocio y la gestión de estado, que escribo con XCTest en iOS o JUnit en Android. Estas cubren funciones puras, lógica de view models y transformación de datos sin ninguna participación de la UI. La segunda capa son las pruebas de integración que verifican la interacción entre módulos. La tercera capa y la más pequeña son las pruebas de UI, que mantengo al mínimo porque son lentas y frágiles, y las enfoco en los recorridos críticos del usuario. Para React Native uso Jest para las pruebas unitarias y Detox para las pruebas de extremo a extremo. La métrica clave no es el porcentaje de cobertura sino "¿podemos detectar regresiones en los flujos más críticos antes de que lleguen a producción?"

¿Cómo gestionas las notificaciones push en iOS y Android y cuáles son los principales desafíos de implementación?

La implementación de notificaciones push tiene diferente complejidad en cada plataforma, y los principales desafíos son la gestión de tokens de dispositivo, los estados de permisos de notificación y el manejo de notificaciones cuando la app está en diferentes estados (primer plano, segundo plano, cerrada). En iOS uso APNs a través de Firebase Cloud Messaging. Los tokens de dispositivo cambian cuando los usuarios reinstalan la app, así que siempre renuevo el token en cada lanzamiento y lo sincronizo con el backend. La gestión de permisos es la complejidad más visible para el usuario: iOS requiere permiso explícito, que solicito en un momento contextualmente apropiado en lugar de en el primer lanzamiento, porque las solicitudes en el primer lanzamiento tienen tasas de aceptación bajas. Implemento un diálogo previo al permiso que explica por qué las notificaciones son valiosas. En Android, el permiso POST_NOTIFICATIONS se volvió obligatorio desde Android 13, así que gestiono los tres estados.

¿Cómo estructuras la arquitectura de una aplicación React Native para la mantenibilidad a largo plazo?

Las elecciones de arquitectura de React Native hechas al principio del proyecto son muy costosas de cambiar más tarde, así que invierto tiempo en estructurarlo bien. Mi arquitectura preferida es una estructura de carpetas basada en funcionalidades donde cada funcionalidad contiene sus propios componentes, pantallas, servicios y estado, en lugar de una estructura basada en tipos. Para la navegación uso React Navigation con rutas tipadas, que detecta los errores de navegación en tiempo de compilación. Para la integración de API creo una capa cliente API tipada que abstrae las llamadas HTTP, para que las pantallas y componentes nunca llamen a fetch directamente. Uso variables de entorno para los endpoints de API y los feature flags, gestionadas a través de un módulo de configuración. Para los módulos nativos escribo una interfaz JavaScript que envuelve la funcionalidad nativa. Documento las decisiones arquitectónicas como ADRs en el repositorio.

Desarrollador mobile

Las entrevistas para Desarrollador mobile evalúan tu capacidad para construir apps de alto rendimiento y fiables en iOS, Android o frameworks multiplataforma. Los entrevistadores quieren ver que entiendes las restricciones de los entornos móviles, incluyendo la batería y la red limitadas, las directrices de los app stores y los desafíos de las pruebas en ecosistemas de dispositivos fragmentados. Esta guía cubre las preguntas más frecuentes y las respuestas que demuestran experiencia real en ingeniería móvil.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Desarrollador mobile

Preguntas conductuales para puestos de Desarrollador mobile

Preguntas técnicas para candidatos a Desarrollador mobile

Lo que buscan los reclutadores en las entrevistas para Desarrollador mobile

Lo que los responsables de selección buscan realmente en los candidatos a Desarrollador mobile:

Profundidad de plataforma sobre amplitud. Es mejor ser genuinamente experto en una plataforma y competente en otra que mediocre en ambas. Conoce qué plataforma está orientada principalmente este rol y prepárate en consecuencia.
Instintos de rendimiento. El hardware móvil tiene limitaciones y los usuarios notan la lentitud de inmediato. Los candidatos que perfilar primero y optimizan después son mucho más valiosos que los que adivinan los cuellos de botella.
Conocimiento del proceso de los app stores. Los rechazos, manifiestos de privacidad, entitlements y directrices de revisión son preocupaciones operativas reales. Los candidatos que los han navegado son mucho más productivos desde el primer día.
Disciplina de pruebas en una plataforma donde probar es genuinamente más difícil. Las pruebas de UI móvil son frágiles; los candidatos que han pensado en qué probar y qué simular muestran madurez.
Comunicación con los equipos de backend. El desarrollo móvil rara vez ocurre de forma aislada. Los candidatos que describen trabajar estrechamente con los equipos de API muestran que trabajan para el flujo de trabajo completo, no solo la app.

Preguntas que puedes hacer al entrevistador

→¿Cuál es la proporción actual entre trabajo de iOS, Android y multiplataforma en el equipo?
→¿Cómo gestiona el equipo el proceso de publicación y cuál es la cadencia actual de envíos a los app stores?
→¿Cuál es el mayor elemento de deuda técnica en la base de código móvil ahora mismo?
→¿Qué tan estrechamente trabaja el equipo móvil con el equipo de backend y cómo se comunican los cambios de API?
→¿Cómo es la infraestructura de pruebas y cuál es la cobertura actual de los recorridos críticos del usuario?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis para empezar. Sin compromiso.

Puestos relacionados

Desarrollador frontend

Tech10 preguntas

Desarrollador full-stack

Tech9 preguntas

UX Designer

Creativo9 preguntas