Preguntas de entrevista para Desarrollador iOS

Respuesta modelo

Llevo seis años en desarrollo iOS nativo, siempre en Swift, con dos productos principales. El último es la app de una entidad financiera con 1,9 millones de usuarios activos y soporte desde iOS 16: entré para migrar pantallas de UIKit a SwiftUI y acabé responsabilizándome del módulo de pagos y del proceso de publicación completo, desde la firma de código hasta la ficha en App Store Connect. Antes trabajé tres años en una app de movilidad, donde construí el widget de seguimiento de pedidos con WidgetKit y las Live Activities. En ambos casos era la persona que respondía cuando App Store Review rechazaba una versión, y eso me obligó a conocer las Human Interface Guidelines y las reglas de privacidad con bastante detalle.

Respuesta modelo

Porque el trabajo que me interesa está en la capa donde la plataforma manda: rendimiento de arranque, gestión de memoria, integración con StoreKit 2, extensiones, widgets y todo lo relacionado con privacidad y accesibilidad, que en la App Store se revisa de verdad. He trabajado con equipos que usaban React Native y entiendo su valor cuando hay que cubrir dos plataformas con poco presupuesto, pero en cuanto un producto necesita cámara, mapas en segundo plano o pagos, el coste del puente nativo termina igualando al del desarrollo nativo. También influye algo práctico: cuando Apple cambia las reglas, en un proyecto nativo se adapta uno mismo en una tarde y no se depende de que la librería intermedia lo soporte.

Respuesta modelo

Nos rechazaron una versión por la guía 5.1.1: pedíamos permiso de ubicación siempre activa en el arranque, antes de que el usuario entendiera para qué servía. En lugar de discutir, reescribí el flujo: moví la petición al momento en que se activa el seguimiento del pedido, añadí una pantalla previa explicando el uso concreto y ajusté el texto de la clave NSLocationAlwaysAndWhenInUseUsageDescription para que dijera exactamente qué hacíamos con el dato. Adjunté capturas y una nota para el revisor en App Store Connect y la versión se aprobó en menos de veinticuatro horas. Desde entonces mantengo una lista de comprobación previa a cada envío con los permisos, el privacy manifest y las capturas actualizadas.

Respuesta modelo

Cada junio veo las sesiones de la WWDC que afectan a nuestro producto y preparo una nota interna con lo que nos obliga a cambiar y lo que solo es interesante; después abro las tareas correspondientes en el backlog. Durante el año sigo las notas de versión de Xcode y de los SDK, y pruebo las betas de iOS en un dispositivo secundario en cuanto salen, sobre todo para detectar roturas en la interfaz y en los permisos. Además reservo un rato a la semana para leer las actualizaciones de las App Store Review Guidelines, porque los cambios de privacidad suelen llegar por ahí y no por el compilador.

Respuesta modelo

Primero pregunto qué problema de usuario intenta resolver el diseño, porque muchas veces la propuesta llega copiada de la versión web o de Android y la intención es razonable aunque la forma no encaje. Después llevo a la conversación datos, no opiniones: si un patrón rompe la navegación por gestos o deja fuera VoiceOver, lo enseño en el simulador con el lector de pantalla activado. Suelo proponer una alternativa nativa equivalente en la misma reunión para no quedarme en el «no». Cuando el equipo insiste y el riesgo es de rechazo en la revisión, lo dejo por escrito con la guía correspondiente y decidimos con producto asumiendo el riesgo de forma consciente.

Respuesta modelo

La app de banca tenía unas 180.000 líneas, con la mitad del módulo de sesión todavía en Objective-C y sin apenas pruebas. En vez de plantear una reescritura, acordamos una estrategia de migración por pantallas: cada nueva funcionalidad se hacía en SwiftUI dentro de un UIHostingController y, al tocar una pantalla antigua, se convertía. Añadí pruebas de caracterización antes de cada refactor para no romper comportamientos que nadie recordaba haber escrito. En dieciocho meses migramos 47 pantallas y extrajimos cuatro módulos a Swift Package Manager, sin congelar el roadmap ni un solo sprint.

Empiezo en SwiftUI por defecto: la velocidad de iteración y el soporte automático de Dynamic Type y modo oscuro compensan de sobra. Bajo a UIKit en tres casos concretos: listas muy largas con celdas heterogéneas donde necesito control fino del reciclado, transiciones y gestos personalizados que en SwiftUI aún cuestan más de lo que valen, y pantallas de cámara o de edición donde controlo el ciclo de vida al detalle. La convivencia la resuelvo con UIHostingController para meter SwiftUI en una jerarquía UIKit y con UIViewRepresentable en el sentido contrario. La versión mínima manda: con iOS 16 como suelo hay que asumir que ciertas APIs de navegación y de scroll no están disponibles.

Un struct es un tipo de valor, se copia al asignarse y vive normalmente en la pila; una class es un tipo de referencia, se gestiona con conteo de referencias y vive en el montón. En una lista de SwiftUI eso importa mucho: si el modelo de cada celda es un struct conforme a Identifiable y Equatable, el framework puede comparar valores y redibujar solo lo que cambió. Con clases se pierde esa comparación barata y aparecen redibujados innecesarios, además del riesgo de estados compartidos entre celdas. Uso clases cuando necesito identidad y estado compartido de verdad, por ejemplo en un modelo de vista observable, y struct para todo lo que sea datos de presentación.

Se produce cuando dos objetos se retienen mutuamente con referencias fuertes y ninguno llega a liberarse; el caso típico es un closure que captura self dentro de una propiedad del propio objeto, o un delegado declarado strong en lugar de weak. Lo prevengo con listas de captura [weak self] en closures que sobreviven al ámbito y con delegados siempre weak. Para detectarlos en una app en marcha uso el Memory Graph Debugger de Xcode: navego varias veces por la pantalla sospechosa, capturo el grafo y busco instancias que deberían ser únicas y aparecen repetidas. Si necesito más contexto, paso la plantilla Leaks y Allocations de Instruments y comparo generaciones de memoria entre dos ciclos de navegación.

async/await modela una operación asíncrona que devuelve un resultado una vez, con un flujo de control secuencial y manejo de errores mediante try. Combine modela flujos de valores en el tiempo con operadores de composición. Para llamadas de red, lectura de disco o cualquier cosa con principio y fin, uso async/await porque el código queda más legible y la cancelación funciona con la estructura de tareas. Mantengo Combine donde hay emisiones continuas y ya existe infraestructura montada: entradas de formularios con debounce, combinación de varios estados o los @Published de modelos de vista antiguos. En proyectos nuevos suelo cubrir esos casos con AsyncSequence y AsyncStream, pero no reescribo un módulo estable de Combine solo por moda.

Un actor es un tipo de referencia que serializa el acceso a su estado interno: solo una tarea entra cada vez, así que se eliminan por diseño las condiciones de carrera sobre ese estado, y el acceso desde fuera es asíncrono con await. @MainActor es el actor global asociado al hilo principal: al marcar con él un modelo de vista o una función, el compilador garantiza que la actualización de la interfaz ocurre en el hilo principal, sin sembrar el código de DispatchQueue.main.async. Con la comprobación estricta de concurrencia de Swift 6, esto deja de ser una recomendación y pasa a ser un error de compilación cuando se cruza un límite de aislamiento con un tipo que no es Sendable, lo que obliga a modelar bien qué datos viajan entre contextos.

Para el arranque mido primero con la plantilla App Launch de Instruments y separo el tiempo pre-main del posterior. En el pre-main lo que suele doler es el exceso de frameworks dinámicos y las inicializaciones estáticas; ahí consolido módulos y elimino trabajo del arranque de las dependencias. Después de main, saco del didFinishLaunching todo lo que no sea imprescindible para pintar la primera pantalla: analítica, SDK de terceros y precargas se inicializan de forma diferida. Para el tamaño reviso el catálogo de assets, apoyo el app thinning, muevo contenido pesado a On-Demand Resources y audito qué aportan realmente las dependencias, porque un SDK de atribución puede costar varios megabytes de binario. Después vigilo el resultado en campo con MetricKit, no solo en mi dispositivo.

El privacy manifest, el archivo PrivacyInfo.xcprivacy, declara qué datos recoge la app, con qué finalidad, si se usan para seguimiento y qué APIs de motivo obligatorio utiliza, como acceso a UserDefaults o a marcas de tiempo de archivos. Apple exige que la app y los SDK de terceros incluidos lo aporten, y con esa información compone la etiqueta de privacidad de la ficha. App Tracking Transparency es otra cosa complementaria: es el permiso en tiempo de ejecución que hay que solicitar antes de acceder al IDFA o de cruzar datos del usuario con los de otras empresas. Un manifiesto que declara seguimiento sin pedir el permiso ATT es motivo de rechazo, y en España hay que encajarlo además con el consentimiento del RGPD, que no se cubre con la ventana de Apple.

El token va siempre en el Keychain, nunca en UserDefaults ni en un archivo del contenedor, y con el nivel de accesibilidad adecuado: normalmente kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly para que no viaje en la copia de seguridad ni a otro dispositivo. Si hay operaciones sensibles, protejo la entrada con LocalAuthentication y control de acceso biométrico, de modo que un cambio en las huellas registradas invalide el acceso. Para la red uso HTTPS con ATS activado y certificate pinning contra la clave pública, con un plan de rotación para no dejar la app inservible cuando caduque el certificado. Y evito registrar en los logs cualquier dato personal, porque acaban en herramientas de terceros.

Lo primero es contener, no diagnosticar. Miro Crashlytics para ver si el fallo se concentra en una versión de iOS, en un modelo concreto o en un porcentaje de usuarios, y en paralelo activo la reducción de despliegue por fases en App Store Connect para que deje de llegar a más gente. Si la app tiene banderas de funcionalidad, apago la que introdujo el cambio, porque es la única vía rápida: en iOS no existe la reversión de una versión ya publicada y la corrección tiene que pasar por revisión. Con la hipótesis clara preparo una versión de corrección mínima, la subo pidiendo revisión acelerada y aviso a soporte del texto que deben dar a los usuarios. El lunes escribimos el postmortem y añadimos la prueba que faltaba.

Explico que la fecha de revisión no la controlamos y propongo desacoplar el lanzamiento del despliegue. Lo habitual es subir la versión con antelación, aprobarla y dejarla con publicación manual, de modo que el martes solo haya que pulsar un botón; si el contenido depende de la campaña, lo dejo detrás de una bandera remota para no atarlo al binario. Si el calendario ya está comprometido, pido la revisión acelerada justificando la campaña, pero aviso de que no está garantizada y acordamos un plan alternativo. Lo que no hago es prometer una fecha que depende de un tercero.

No lo rechazo en bloque ni lo reescribo yo. Empiezo preguntando en el propio PR qué le llevó a resolverlo así, porque a veces hay una urgencia detrás que no conozco. Después señalo dos problemas concretos y verificables: la vista no se puede probar sin red y cualquier cambio de estado obliga a recalcular todo el cuerpo. Propongo un cambio acotado, extraer la llamada a un modelo de vista con @MainActor y dividir la vista en tres subvistas, y ofrezco hacerlo juntos en media hora. Si el PR es urgente, acuerdo que entre con una tarea de deuda técnica ya creada y con fecha, no con un comentario suelto.

Compruebo cuatro cosas antes de tocar el proyecto. Primero, si el SDK aporta su propio privacy manifest firmado y qué Required Reason API declara, porque sin eso la app puede ser rechazada. Segundo, qué datos recoge realmente y si eso obliga a actualizar la etiqueta de privacidad de la ficha y el registro de tratamiento del RGPD, para lo que hablo con la persona responsable de protección de datos. Tercero, el coste técnico: cuánto suma al binario y cuánto retrasa el arranque, midiéndolo con una rama de prueba. Y cuarto, el flujo de consentimiento, porque el permiso ATT no sustituye a la base legal del RGPD y el orden de las pantallas afecta tanto a la conversión como al cumplimiento. Con esos datos, la decisión ya no es técnica ni mía en solitario.