Preguntas de entrevista Desarrollador mobile

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.

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.

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.

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.

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.

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.

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.

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?"

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.

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.