Preguntas de entrevista para Desarrollador Móvil (con respuestas)

Respuesta modelo

Lo decido con cuatro criterios y, si puedo, con una prueba de concepto de una semana. Primero, cuánta superficie de la app depende de capacidades muy ligadas al sistema: si el núcleo es cámara en tiempo real, audio de baja latencia, Bluetooth intensivo, widgets de pantalla de inicio o integración con el reloj, el coste del puente empieza a superar el ahorro. Segundo, el tamaño y la forma del equipo: con tres personas y dos tiendas que atender, una base compartida en React Native o Flutter es casi siempre la opción sensata. Tercero, el horizonte de mantenimiento, porque una app que va a vivir cinco años y recibir cambios continuos se beneficia mucho más de compartir código que un piloto de tres meses. Y cuarto, el parque de dispositivos del público objetivo: si una parte importante de los usuarios está en Android de gama de entrada, mido antes el arranque en frío y el consumo de memoria en un terminal real, no en un emulador. En mi último proyecto la conclusión fue mixta: base compartida en React Native con dos módulos nativos en Swift y Kotlin para NFC y biometría, unas 900 líneas nativas frente a 38.000 compartidas.

Respuesta modelo

Trabajo con una única versión semántica y un número de build por plataforma, generados en integración continua para que nadie firme desde su portátil. El proceso está automatizado con Fastlane y GitHub Actions: al etiquetar la rama de release se compilan el AAB y el IPA, se suben a Google Play en el canal interno y a TestFlight, y se ejecutan las pruebas E2E con Detox y Maestro sobre los flujos críticos. Google Play lo despliego por fases, al 10 %, 50 % y 100 %, vigilando los usuarios sin fallos en Crashlytics con un umbral de parada del 99,4 %. En Apple uso la publicación manual tras la aprobación para sincronizar ambas tiendas el mismo día, y dejo preparadas las notas de la versión en castellano e inglés. Los metadatos, las capturas y el formulario de Seguridad de los datos de Google Play y las etiquetas de privacidad de Apple los reviso en cada cambio de SDK, porque es la causa más frecuente de rechazo que he visto.

Respuesta modelo

Parto de una regla que acuerdo con diseño al principio del proyecto: la marca y el contenido son idénticos, la navegación y los patrones del sistema son propios de cada plataforma. En la práctica eso significa respetar el gesto de retroceso y el botón físico o gestual de Android, usar las hojas de acción y los selectores de fecha nativos, colocar la navegación donde cada sistema la espera y no imitar el estilo de una plataforma en la otra. En el código lo resuelvo con componentes compartidos que encapsulan la diferencia, no con condicionales dispersos por las pantallas. Cuando la petición de igualdad viene de negocio, la traduzco a datos: en una app de reservas medimos que forzar el patrón de iOS en Android subía el abandono en el paso de pago, y con eso se cerró la discusión sin necesidad de apelar a opiniones.

Respuesta modelo

Sigo un orden. Primero compruebo si existe una solución oficial o una librería con mantenimiento activo, mirando la frecuencia de commits, los issues abiertos y la compatibilidad con la versión del framework que uso. Si no la hay o la que hay arrastra el proyecto, escribo el módulo nativo yo: en React Native con un Turbo Module y en Flutter con un platform channel, con la implementación en Swift y en Kotlin y una interfaz común y tipada hacia la capa compartida. Documento la decisión en un registro corto de decisiones de arquitectura, con el motivo y el coste de mantenimiento, porque dentro de un año alguien preguntará por qué hay código nativo ahí. Lo he hecho seis veces: lectura del DNI electrónico por NFC, firma biométrica, almacenamiento en Keychain y Keystore, y un lector de códigos que en Flutter perdía doce fotogramas por segundo con el plugin genérico.

Respuesta modelo

Con medición en dispositivo real desde el primer sprint, no al final. Tengo un terminal de gama de entrada de referencia, un Samsung Galaxy A13, y en él vigilo cuatro números: arranque en frío, fotogramas descartados en las listas principales, memoria en uso y tamaño de la descarga. Las palancas que más me han rendido son activar Hermes en React Native, sustituir listas por versiones virtualizadas, aplazar la inicialización de servicios como Firebase hasta después del primer render, convertir imágenes a WebP y aplicar R8 y Android App Bundle. En una app de seguros pasé de 3,8 s a 1,5 s de arranque en frío y de un 11 % a un 1,8 % de fotogramas descartados. Además dejo un presupuesto de rendimiento en la integración continua: si el bundle crece más de un 5 % en un pull request, la revisión no pasa sin justificación.

Respuesta modelo

Porque el trabajo que más me interesa está justo en la frontera. Me gusta ser responsable del producto entero en los dos sistemas, ver el efecto de una decisión de arquitectura en las dos tiendas y poder bajar a Swift o a Kotlin cuando hace falta, sin depender de otro equipo para desbloquear una funcionalidad. Además, en equipos del tamaño en el que quiero trabajar, un perfil que cubre las dos plataformas permite ciclos de entrega mucho más cortos. No lo vivo como una renuncia a la profundidad nativa: mantengo actualizado el conocimiento de SwiftUI y de Jetpack Compose precisamente porque los necesito para las partes que no comparto.

En la arquitectura antigua existía un puente asíncrono: JavaScript y la capa nativa intercambiaban mensajes serializados en JSON a través de una cola, lo que introducía latencia y hacía imposible operar de forma síncrona. Eso se notaba sobre todo en gestos, animaciones dependientes del scroll y listas largas. Con la Nueva Arquitectura, JSI permite que el motor de JavaScript mantenga referencias directas a objetos nativos y llame a sus métodos sin serializar; sobre esa base se apoyan los Turbo Modules, que además cargan los módulos de forma perezosa en lugar de inicializarlos todos al arrancar, y Fabric, el nuevo renderizador, que unifica el árbol de componentes y permite actualizaciones síncronas. Codegen genera el código de enlace a partir de especificaciones tipadas, de modo que los errores de interfaz aparecen en compilación. En la práctica, la ganancia más visible que he medido es en el arranque, por la carga perezosa, y en la fluidez de las interacciones gestuales.

Flutter no usa los componentes de interfaz del sistema: dibuja cada píxel con su propio motor gráfico, antes Skia y ahora Impeller, sobre un lienzo. React Native, en cambio, construye la interfaz con vistas nativas reales de cada plataforma. Las consecuencias son directas. Con Flutter obtengo una consistencia visual total entre iOS y Android y control absoluto sobre animaciones complejas, pero pago con un tamaño base de la aplicación mayor y con el riesgo de que un cambio del sistema en accesibilidad, teclado o campos de texto tarde en reflejarse hasta que el framework lo replique. Con React Native heredo automáticamente el comportamiento nativo, incluidos los detalles de accesibilidad con VoiceOver y TalkBack, a cambio de depender de esa capa de vistas y de sus diferencias. Por eso elijo Flutter cuando el diseño es muy propio y con mucha animación, y React Native cuando la app debe sentirse indistinguible de una nativa y ya hay talento de React en el equipo.

En Android publico siempre Android App Bundle en lugar de un APK universal, para que Google Play entregue solo la arquitectura, la densidad y el idioma de cada dispositivo; activo R8 con ofuscación y eliminación de código muerto, y reviso las dependencias transitivas con el analizador de APK, que es donde suelen esconderse los megabytes. En iOS me apoyo en App Thinning y en los bitcode y recursos por variante, y controlo el tamaño de los frameworks embebidos. Común a ambas: imágenes en WebP o vectores, fuentes con solo los pesos que se usan, ninguna traducción huérfana y eliminación de librerías que se metieron para una pantalla y se quedaron. En una app llegué a 41 MB desde 78 MB en Android y a 62 MB desde 96 MB en iOS. Vigilo el tamaño en cada pull request porque, si no se mide, crece siempre.

La interfaz lee siempre de la base de datos local, nunca de la red, y la red es un proceso de sincronización que actualiza esa base. Uso WatermelonDB o Realm en React Native y Drift o sqflite en Flutter, con un esquema versionado y migraciones probadas. Toda escritura del usuario entra en una cola persistente de operaciones idempotentes con identificador propio, reintentos con retroceso exponencial y resolución de conflictos declarada por entidad, normalmente última escritura gana en campos independientes y fusión manual en los que no lo son. Muestro el estado de sincronización en la interfaz para que el usuario sepa qué está pendiente, porque el silencio genera duplicados. Con este planteamiento, 4.200 técnicos de campo trabajaron sin cobertura estable con un 0,3 % de conflictos y ninguna pérdida de datos en catorce meses.

Con CodePush o EAS Update puedo sustituir el paquete JavaScript y los recursos asociados, lo que cubre correcciones de errores, ajustes de interfaz y cambios de lógica de negocio de la capa compartida. No puedo cambiar nada que viva en el binario: dependencias nativas, permisos, versión mínima del sistema, extensiones o cualquier módulo nativo nuevo. Además hay un límite de política, no solo técnico: las condiciones del programa de desarrolladores de Apple admiten estas actualizaciones siempre que no alteren el propósito principal de la aplicación ni introduzcan funcionalidades no revisadas, así que no uso OTA para lanzar funcionalidades nuevas de calado. En mi flujo, el OTA es para el incidente urgente, con despliegue por fases y reversión inmediata, y todo lo demás va por release normal en ambas tiendas.

Unifico el envío en Firebase Cloud Messaging, que entrega en Android directamente y en iOS a través de APNs con la clave de autenticación configurada en la consola de Apple. En el cliente abstraigo en un único servicio el registro del token, su renovación y su envío al backend asociado al usuario y al dispositivo, y trato por separado los tres estados de recepción, con la app en primer plano, en segundo plano y cerrada, porque se comportan de forma distinta en cada sistema. Los permisos también difieren: en iOS hay que pedirlos explícitamente y elijo bien el momento, tras un primer valor entregado, y en Android son obligatorios desde la versión 13. Añado canales de notificación en Android para que el usuario module qué recibe, deep links con enlaces universales y App Links para abrir la pantalla correcta, y mido la tasa de entrega y de apertura para detectar problemas de token antes de que los reporte soporte.

En tres niveles, con la mayor parte del esfuerzo en la capa compartida, que es donde el retorno es mayor. Pruebas unitarias de la lógica de negocio y de los reductores con Jest o con el paquete de test de Dart, con cobertura exigida en la integración continua sobre los módulos críticos. Pruebas de componente con React Native Testing Library o widget tests en Flutter, escritas desde el comportamiento visible y no desde la implementación. Y pruebas E2E sobre los flujos que no pueden romperse, unos veinte o treinta, con Detox o Maestro, ejecutadas en cada pull request en un dispositivo virtual y una vez al día en dispositivos físicos, porque los fallos de permisos y de teclado solo aparecen ahí. Complemento con capturas automáticas comparadas para detectar regresiones visuales entre plataformas, que es un problema típico de estos proyectos.

Lo primero es leer el motivo exacto del rechazo y clasificarlo, porque no es lo mismo un problema de metadatos o de etiquetas de privacidad, que se corrige en una hora, que un problema de funcionalidad o de cumplimiento de una directriz, que puede exigir cambios de código. Después informo de inmediato a producto y a marketing con dos escenarios y sus plazos, para que decidan con información y no con optimismo. Si es corregible, envío la nueva versión y solicito la revisión acelerada explicando la fecha de campaña, que en mi experiencia se concede cuando la petición es razonable y no se abusa de ella. Y mientras tanto retengo la publicación en Google Play, porque lanzar solo en una plataforma en una campaña que promete la app en las dos genera valoraciones negativas y tickets de soporte que cuestan más que el retraso. Lo que sí hago siempre después es incorporar la causa del rechazo a la lista de comprobación previa a cada envío.

Lo traduzco a coste y a valor antes de discutir de tecnología. Estimo tres opciones: implementarlo nativo en las dos plataformas, implementarlo solo donde aporta más valor según los datos de uso, o buscar una alternativa dentro de la app que cubra la necesidad de negocio. Presento las tres con horas y con mantenimiento anual, y con el dato de reparto de usuarios entre iOS y Android, que en España suele inclinarse hacia Android en volumen y hacia iOS en gasto según el sector. En un caso real elegimos hacer el widget solo en iOS, donde estaba el 68 % de los usuarios de pago, y aplazamos Android un trimestre. Lo importante es dejar claro que la base compartida no es un dogma: es una decisión de eficiencia que admite excepciones justificadas.

Primero busco el patrón en los datos antes de tocar código: en Google Play Console y en Firebase segmento por modelo, versión de Android, memoria y país, y en Sentry miro las trazas de rendimiento de los inicios lentos. Casi siempre el problema se concentra en unos pocos modelos de gama de entrada y en una pantalla concreta. Después reproduzco en un dispositivo físico equivalente, nunca en un emulador, y perfilo con las herramientas de desarrollo del framework y con Android Studio para ver si el cuello está en el arranque, en el hilo de interfaz o en consultas a la base de datos local. Luego priorizo por impacto: normalmente arranque en frío y listas. Y por último cierro el círculo con una métrica y un umbral en la integración continua para que la mejora no se pierda en tres sprints. En un caso así, el 82 % de las quejas venía de dos modelos con 3 GB de RAM y de una pantalla que cargaba imágenes sin redimensionar.

Detener la propagación primero y diagnosticar después. Paro el despliegue por fases en Google Play y, si la versión de iOS ya está publicada, retiro la disponibilidad de la nueva versión. Si el fallo está en la capa JavaScript, revierto por OTA, que en minutos alcanza a los usuarios afectados. Con la hemorragia contenida, abro el crash en Crashlytics y en Sentry, identifico la traza y la versión del sistema o el modelo implicado, y reproduzco. Publico un aviso interno para soporte con el alcance y el mensaje que deben dar. Y cuando está resuelto, escribo un postmortem sin culpables con la causa raíz y con una acción concreta para que no vuelva a pasar, que en el último caso fue añadir a las pruebas E2E el flujo de sesión caducada, que era justo el que nadie ejecutaba antes de publicar.

Negocio una proporción, no una parada. Dedico las dos primeras semanas a levantar visibilidad, que es lo más barato y lo que más ahorra después: monitorización de errores, métricas de rendimiento y una batería mínima de pruebas E2E sobre los cinco flujos que dan dinero. Con eso ya puedo tocar el código sin ir a ciegas. Después propongo un reparto sostenido, del orden del 20 % de la capacidad de cada sprint para actualizar dependencias y reducir deuda, empezando por las que bloquean la subida a las tiendas, porque Apple y Google exigen periódicamente versiones mínimas del SDK y ese es un plazo que no se negocia. Ese argumento, el de que sin actualizar no se podrá publicar, es el que hace que producto entienda la deuda técnica sin necesidad de hablar de calidad en abstracto.