Las entrevistas de iOS testean el sistema de tipos de Swift, cómo ARC maneja la memoria, y si puedes razonar sobre el estado de la UI — más al menos una pregunta donde un retain cycle se esconde a plena vista. Aquí están las preguntas hechas más a menudo, cada una con una respuesta modelo. Senior: arquitectura, trade-offs, mentoría y toma de decisiones.
Por lo que realmente es la complejidad de la app. El MVC de Apple está bien para una pantalla que muestra y edita una cosa; MVVM se gana su lugar cuando el estado de la vista es lo bastante complejo como para testearse por separado; una arquitectura unidireccional rinde cuando el estado se comparte entre muchas pantallas y los bugs son sobre estado que se desincroniza. Elegir la más pesada primero cuesta velocidad por años.
Mide primero — el resumen de timing del build te dice qué archivos dominan, y usualmente son un puñado con inferencia de tipos pesada. Luego: tipos explícitos donde la inferencia es costosa, modularización para que un cambio recompile un módulo, y menos optimizaciones de whole-module en debug. El consejo general sin medición usualmente no mueve nada.
Empieza desde la frecuencia y agrupación del reporte de crash — qué versiones de OS, qué dispositivos, qué versión de app, y qué estaba haciendo el usuario. Agrega logging de breadcrumbs alrededor del camino sospechoso y lánzalo, porque la forma más rápida de reproducir algo raro es instrumentar a la población que lo golpea. Adivinar un fix y lanzarlo no te enseña nada si la tasa no cambia.
La migration liviana maneja cambios aditivos automáticamente; cualquier cosa que transforme datos necesita un mapping model y un camino testeado desde cada versión que todavía anda por ahí. La restricción que la gente olvida es que los usuarios se saltan versiones — alguien actualiza desde un release de dos años atrás, así que la cadena de migration debe funcionar desde cada una de ellas, no solo la última.
Asumiendo que las versiones viejas viven indefinidamente: la API debe mantenerse retrocompatible, las features que requieren un cambio de cliente necesitan una flag del lado del servidor, y cualquier cosa removida tiene que ser tolerada por clientes que todavía la llaman. Vale la pena tener un kill switch antes del release que lo necesite. El rollout por fases limita el radio de impacto del error que todavía no encontraste.
Lógica de negocio y cualquier cosa con una regla — precios, validación, máquinas de estado — como unit tests, porque son rápidos y estables. Un pequeño número de tests de UI sobre los caminos críticos que nunca deben romperse, aceptando que son lentos y ocasionalmente flaky. Testear que un botón es azul es donde las suites van a convertirse en mantenimiento.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Senior iOS (Swift) →