Comprender cómo nace, vive y muere una aplicación es fundamental para cualquier desarrollador móvil. En el ecosistema de Apple, el ciclo de vida de la aplicación determina qué sucede cuando el usuario recibe una llamada, cambia de pantalla o cierra la app por completo. Saber intervenir en cada uno de esos estados te permite guardar datos, recuperar información y ofrecer una experiencia fluida, como si nada hubiera pasado.
¿Qué es el ciclo de vida de una aplicación y por qué importa?
El ciclo de vida abarca todos los estados por los que transita una app: desde su creación, pasando por el momento en que se muestra en pantalla, cuando el usuario interactúa con ella, cuando pasa a background (segundo plano) y hasta que se elimina de la memoria RAM [0:25]. Cada transición representa una oportunidad para ejecutar lógica específica.
Por ejemplo, si al usuario le llaman por teléfono, la aplicación deja de ser visible. El programador tiene la responsabilidad de guardar instancias o datos que el usuario estaba utilizando, para que al regresar pueda continuar sin interrupciones [0:40]. En versiones anteriores de iOS, esta tarea se delegaba a una clase llamada delegado, que requería implementar múltiples métodos activados automáticamente ante eventos del sistema [1:30]. Afortunadamente, SwiftUI simplifica este proceso con pocos métodos bien definidos.
¿Cómo funciona el punto de partida en SwiftUI?
Todo comienza en el archivo principal de la aplicación. En el ejemplo práctico se trabaja con GameStreamApp, donde se define qué pantalla se mostrará primero [2:10].
¿Qué hace cada línea de código en la estructura principal?
import SwiftUI: importa las librerías necesarias para utilizar los componentes del framework sin reinventar la rueda [2:30].
@main: esta anotación le indica al sistema que la estructura contiene el método principal de ejecución, similar al main en lenguajes como C y C++ [2:40]. Le otorga a la estructura la habilidad de ser el punto de inicio.
Protocolo App: la estructura debe conformar este protocolo, lo que exige una variable body que retorne una escena [3:10].
WindowGroup: es el contenedor de escena que agrupa las ventanas de tu aplicación. Dentro de él defines qué vistas se presentarán [3:30].
Esta jerarquía funciona de forma análoga al protocolo View, donde también necesitas un body que conforme con ciertas reglas. La diferencia es que aquí conformas con el protocolo de App y el body devuelve una escena en lugar de una vista.
¿Puedes tener múltiples vistas dentro de un WindowGroup?
Sí. Un WindowGroup puede contener varias instancias de vistas [4:00]. En la demostración se colocan dos instancias de ContentView dentro del grupo, e incluso se embeben en un HStack para mostrarlas de forma horizontal [4:50]. Cada instancia es completamente independiente: puedes iniciar sesión en una y reproducir contenido diferente en la otra [5:50]. En iPadOS, esta capacidad es especialmente poderosa, ya que el sistema soporta múltiples instancias corriendo de manera simultánea [6:10].
¿Cómo ejecutar código antes de mostrar la primera pantalla?
Antes de que la vista principal aparezca, puedes utilizar un inicializador (init) dentro de la estructura de la app [5:10]. Este método se ejecuta primero que cualquier vista y es ideal para:
Inicializar bases de datos.
Cargar datos del usuario, como credenciales o preferencias.
Realizar peticiones al servidor.
swift
@main
struct GameStreamApp: App {
init(){print("Punto de partida de mi app")// Inicializar bases de datos, datos de usuario, etc.}varbody: some Scene{WindowGroup{ContentView()}}
}
Al igual que cualquier estructura o clase en Swift, puedes definir un método init para preparar todo lo necesario antes de la presentación visual [5:20].
El punto de inicio es solo el primer estado del ciclo de vida. Los siguientes estados, como cuando la app está en uso activo o pasa a background, permiten ejecutar lógica adicional para proteger la experiencia del usuario. Si quieres dominar cada transición, ¿qué estado del ciclo de vida consideras más crítico para tu proyecto?
