Explica el ciclo de vida de una app iOS: AppDelegate/SceneDelegate frente al protocolo App de SwiftUI

Esta pregunta filtra si un candidato entiende de verdad por qué el ciclo de vida tiene la forma que tiene, no solo qué método se dispara cuándo. iOS ha pasado por tres eras: un único AppDelegate dueño de toda la app, un SceneDelegate que repartió esa propiedad por ventana cuando llegó el soporte multi-ventana de iPad en iOS 13, y el protocolo App de SwiftUI, que envuelve a los dos anteriores bajo una superficie mucho más pequeña. Una respuesta senior conecta las tres eras en vez de recitar la que aprendió primero.

#La era de un único AppDelegate

Antes de que existieran las scenes, un solo objeto AppDelegate representaba la máquina de estados de toda la aplicación, y sus métodos mapeaban directamente sobre lo que el usuario le hacía a la app como un todo: application(_:didFinishLaunchingWithOptions:) se disparaba una vez, en el arranque en frío, para montar ventanas y dependencias; applicationWillResignActive(_:) y applicationDidBecomeActive(_:) enmarcaban cualquier cosa que sacara a la app del primer plano sin llevarla realmente a segundo plano — una llamada entrante, deslizar el centro de notificaciones, la aparición del selector de apps; applicationDidEnterBackground(_:) y applicationWillEnterForeground(_:) enmarcaban la transición real a segundo plano, que es donde guardabas el estado y tenías un número limitado de segundos para terminar trabajo pendiente; y applicationWillTerminate(_:) era una llamada de mejor esfuerzo, no garantizada, para el caso raro de que el sistema matara una app en primer plano directamente.

#Las scenes reparten esa propiedad

iOS 13 introdujo UIScene para que una sola app pudiera ser dueña de varias ventanas — piensa en una app de iPad con dos documentos abiertos lado a lado, cada uno con su propio ciclo de vida independiente. AppDelegate conservó los eventos a nivel de app: el lanzamiento inicial, ofrecer una UISceneConfiguration para cada scene nueva, registrarse para notificaciones remotas, gestionar la finalización de una URLSession en segundo plano. Todo lo relativo al estado de primer/segundo plano de una ventana concreta se movió a UISceneDelegate, una instancia por scene: scene(_:willConnectTo:options:) sustituye al antiguo método de lanzamiento para esa scene, y sceneWillEnterForeground, sceneDidBecomeActive, sceneWillResignActive y sceneDidEnterBackground reflejan los antiguos callbacks a nivel de app pero limitados a una sola ventana. Una llamada telefónica ya no manda "la app" a segundo plano en ningún sentido real: solo resigna actividad en la scene que en ese momento es la "key".

#El protocolo App de SwiftUI colapsa toda esa ceremonia

Una app de SwiftUI declara @main struct MyApp: App, cuyo body devuelve una Scene — normalmente un WindowGroup — y esa única declaración sustituye a los dos objetos delegate para el caso común. En lugar de seis o más callbacks granulares, SwiftUI expone exactamente una señal a través del entorno: scenePhase, con exactamente tres casos — .active, .inactive y .background. Una vista (o el propio App) lee @Environment(\.scenePhase) y reacciona con .onChange(of: scenePhase), y eso normalmente basta para cubrir "guardar estado al ir a segundo plano" o "refrescar datos al volver a primer plano."

Ese colapso es deliberado, pero tiene pérdidas: scenePhase no puede decirte por qué estás en .inactive — una llamada, el selector de apps y una alerta del sistema reportan .inactive de forma idéntica, mientras que los callbacks más finos de UIKit al menos te daban puntos de entrada distintos. Cuando una app necesita de verdad los métodos delegate de notificaciones push (UNUserNotificationCenterDelegate), manejo completo de esquemas de URL personalizados o universal links, o callbacks de URLSession en segundo plano, SwiftUI sigue permitiendo tender un puente al modelo antiguo con @UIApplicationDelegateAdaptor, adjuntando una clase AppDelegate convencional a un App de SwiftUI sin renunciar al WindowGroup.