Pantalla de lanzamiento en SwiftUI: qué es, cómo configurarla y cuándo usar una presentación animada

Arturo Rivas Arias

🚀 La pantalla de lanzamiento es lo primero que vemos al abrir una aplicación en iOS. Aparece de inmediato, antes incluso de que la interfaz esté preparada, y desaparece en cuanto SwiftUI puede mostrar la primera vista. Es un instante muy breve, pero influye bastante en la sensación de fluidez que transmite la aplicación.

Aquí está el detalle que suele provocar confusión: aunque el proyecto esté creado por completo con SwiftUI, la pantalla de lanzamiento no es una vista SwiftUI. La dibuja el propio sistema a partir de una configuración estática incluida en la aplicación. En ese momento nuestro código todavía no controla la interfaz.

Por esa razón, en la pantalla de lanzamiento no podemos ejecutar tareas, consultar un servicio web, leer preferencias, reproducir animaciones ni decidir qué contenido mostrar. Su trabajo es mucho más sencillo: cubrir el pequeño intervalo que existe entre la pulsación sobre el icono y la aparición de la primera pantalla interactiva.

Pantalla de lanzamiento, presentación y primera vista

Antes de entrar en Xcode conviene separar tres conceptos que a menudo terminan mezclados:

  • La pantalla de lanzamiento (launch screen) la muestra iOS mientras pone en marcha la aplicación. Es estática y no depende de SwiftUI.
  • La pantalla de presentación (splash screen) ya forma parte de la aplicación. Puede incluir animaciones, contenido de marca o una transición, porque en realidad es una vista SwiftUI normal.
  • La primera vista es la interfaz funcional en la que el usuario ya puede empezar a interactuar.

💡 Esta distinción no es solo una cuestión de nombres. Si necesitamos animar un logotipo, esperar a que termine una operación o enseñar un mensaje de bienvenida, tendremos que hacerlo después del lanzamiento, dentro de una vista real. Intentar convertir la pantalla que administra iOS en una introducción animada parte de una idea equivocada sobre su función.

Apple aconseja que la pantalla de lanzamiento se parezca todo lo posible a la primera vista. Si una utiliza un fondo oscuro con una imagen centrada y la otra aparece de repente con un fondo claro y una barra de navegación, el cambio se percibe como un destello. La aplicación no tarda más, pero sí lo parece.

También es recomendable evitar los textos. Como el contenido es estático, no se localiza igual que el resto de la interfaz y puede dejar de encajar cuando cambie el idioma o el diseño. Los logotipos solo deberían aparecer cuando también formen parte estable de la primera pantalla. No estamos ante un anuncio ni ante un flujo de bienvenida, sino ante una transición que debería pasar casi desapercibida.

Dos formas de configurarla en Xcode

Xcode ofrece dos caminos para definir la pantalla de lanzamiento: la lista de propiedades de la aplicación (Info.plist) y un archivo de interfaz .storyboard.

Para un diseño sencillo, Info.plist suele ser la opción más cómoda. En la pestaña Info del destino de compilación —el target en Xcode— podemos añadir la clave Launch Screen (UILaunchScreen) y asociarle un color de fondo, una imagen o algunos elementos básicos del sistema.

La representación equivalente dentro de la lista de propiedades tiene este aspecto:

<key>UILaunchScreen</key>
<dict>
    <key>UIColorName</key>
    <string>LaunchBackground</string>
    <key>UIImageName</key>
    <string>LaunchIllustration</string>
    <key>UIImageRespectsSafeAreaInsets</key>
    <true/>
</dict>

LaunchBackground y LaunchIllustration son nombres de recursos guardados en el catálogo de la aplicación. El primero corresponde a un conjunto de colores y el segundo a un conjunto de imágenes. Si el color incluye variantes para los modos claro y oscuro, iOS podrá utilizar la apariencia adecuada desde el primer fotograma.

🎨 En una aplicación sencilla, un color bien elegido suele ser suficiente. Añadir una ilustración solo tiene sentido cuando esa misma imagen continúa presente al entrar en la interfaz. Cuantos más elementos intentemos reproducir, más fácil será que la pantalla estática y la vista real dejen de coincidir con el paso del tiempo.

Cuando necesitamos una composición algo más elaborada, podemos utilizar LaunchScreen.storyboard. El archivo admite componentes básicos de UIKit, clases de tamaño (las famosas size classes) y restricciones de Auto Layout, de modo que el diseño se adapte a diferentes dispositivos y orientaciones. Su nombre se registra mediante UILaunchStoryboardName, sin escribir la extensión:

<key>UILaunchStoryboardName</key>
<string>LaunchScreen</string>

No hace falta mantener las dos configuraciones a la vez. UILaunchScreen encaja muy bien con un fondo y una imagen centrada. El archivo .storyboard ofrece más control cuando hay varios elementos estáticos que deben conservar una posición concreta.

Qué significa realmente «en SwiftUI»

La declaración principal de una aplicación SwiftUI comienza después de la pantalla administrada por el sistema en el punto anterior:

import SwiftUI

@main
struct ReadingJournalApp: App {
    var body: some Scene {
        WindowGroup {
            LibraryView()
        }
    }
}

iOS muestra primero la pantalla de lanzamiento. Cuando SwiftUI está en condiciones de presentar LibraryView, el sistema retira la imagen estática y entrega el control a la aplicación. Por eso no existe un modificador .launchScreen ni podemos colocar directamente una vista SwiftUI en ese momento del arranque.

La transición funciona mejor cuando ambas pantallas comparten los elementos visuales esenciales. Si hemos configurado LaunchBackground como color inicial, podemos reutilizar exactamente el mismo recurso en la vista de la biblioteca:

import SwiftUI

struct LibraryView: View {
    var body: some View {
        NavigationStack {
            ContentUnavailableView(
                "Aún no hay lecturas",
                systemImage: "books.vertical",
                description: Text("Añade un libro para comenzar tu diario.")
            )
            .navigationTitle("Biblioteca")
            .background(Color("LaunchBackground"))
        }
    }
}

El texto, la barra de navegación y los controles aparecen cuando la aplicación ya está activa. La pantalla inicial solo necesita conservar el fondo y, si forma parte permanente del diseño, una ilustración común. Así evitamos duplicar una interfaz completa en un formato que nunca podrá reaccionar al contenido ni al estado de la aplicación.

Cómo añadir una presentación animada

✨ Si el diseño necesita una animación de entrada, esta debe vivir en una vista SwiftUI real. Eso nos permite utilizar transiciones, respetar los ajustes de accesibilidad y decidir cuándo tiene sentido mostrarla.

Una buena opción es reservarla para el primer uso, como parte de una bienvenida breve. En el siguiente ejemplo, @AppStorage recuerda si el usuario ya ha completado esa presentación:

import SwiftUI

struct RootView: View {
    @AppStorage("didCompleteWelcome") private var didCompleteWelcome = false

    var body: some View {
        Group {
            if didCompleteWelcome {
                LibraryView()
            } else {
                WelcomeView {
                    withAnimation(.smooth) {
                        didCompleteWelcome = true
                    }
                }
            }
        }
    }
}

struct WelcomeView: View {
    let continueAction: () -> Void

    var body: some View {
        VStack(spacing: 24) {
            Image(systemName: "bookmark.square.fill")
                .font(.system(size: 72))
                .foregroundStyle(.tint)

            Text("Tu biblioteca, siempre a mano")
                .font(.title.bold())
                .multilineTextAlignment(.center)

            Button("Continuar", action: continueAction)
                .buttonStyle(.borderedProminent)
        }
        .padding()
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .background(Color("LaunchBackground"))
    }
}

Al tratarse de una vista normal, el mensaje se puede traducir, VoiceOver puede interpretarlo y el botón responde a la interacción. Además, es el usuario quien decide cuándo avanzar. No necesitamos mantener un logotipo en pantalla durante dos segundos mediante un temporizador que solo retrasa la llegada al contenido.

⚠️ Una presentación animada tampoco debería aparecer en cada apertura por pura decoración. Puede resultar atractiva la primera vez, pero termina siendo una barrera cuando el usuario abre la aplicación varias veces al día. La prioridad sigue siendo permitir la interacción cuanto antes.

Cargar datos sin alargar el arranque

La pantalla de lanzamiento tampoco debe servir para esconder una petición de red o una migración larga. Si los datos tardan en llegar, lo más natural es mostrar primero la estructura de la interfaz y representar la carga dentro de la propia aplicación.

import SwiftUI

struct RecommendationsView: View {
    @State private var titles: [String] = []
    @State private var isLoading = true

    var body: some View {
        List {
            if isLoading {
                ProgressView("Actualizando recomendaciones…")
            } else {
                ForEach(titles, id: \.self) { title in
                    Label(title, systemImage: "book.closed")
                }
            }
        }
        .task {
            titles = await loadRecommendations()
            isLoading = false
        }
    }

    private func loadRecommendations() async -> [String] {
        // Aquí llamaríamos al servicio o al repositorio de datos.
        ["El lenguaje de las máquinas", "Interfaces que perduran"]
    }
}

El modificador .task asocia el trabajo asíncrono al ciclo de vida de la vista. Si la pantalla desaparece, SwiftUI puede cancelar la tarea automáticamente. Mientras llegan los datos, el usuario ya ve una interfaz reconocible y un indicador de progreso en lugar de quedarse delante de una imagen congelada.

Esta separación también mejora el mantenimiento. La pantalla de lanzamiento se ocupa únicamente de la transición inicial; la vista SwiftUI controla la carga, los errores y los estados vacíos. Cada pieza resuelve el problema que realmente le corresponde.

El nuevo requisito de iOS 27

📦 A partir de iOS 27 y iPadOS 27, App Store Connect exige que las aplicaciones compiladas con el SDK correspondiente incluyan una configuración de pantalla de lanzamiento. La validación admite cualquiera de estas claves en Info.plist: UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen o UILaunchScreens.

Si el paquete no contiene ninguna de ellas, la subida se rechaza con el error ITMS-90870. Una aplicación que ya dispone de pantalla de lanzamiento no necesita cambiar su diseño, pero los proyectos antiguos deberían comprobar su configuración antes de actualizar el SDK de compilación.

Los proyectos SwiftUI nuevos pueden generar automáticamente la entrada UILaunchScreen cuando están activados los ajustes Generate Info.plist File y Launch Screen (Generation). Aun así, merece la pena revisar el Info.plist incluido en el producto final, sobre todo en proyectos con varios targets de compilación o con configuraciones heredadas.

El requisito no significa que iOS 27 permita crear esta pantalla con SwiftUI. Continúa siendo una definición estática administrada por el sistema. Lo que busca Apple es que la aplicación incluya una configuración moderna, compatible con la multitarea y con el cambio dinámico de tamaño de las ventanas.

Cuando los cambios no aparecen

🧹 iOS guarda en caché una representación de la pantalla de lanzamiento. Por eso es bastante común cambiar un color o una imagen, ejecutar de nuevo el proyecto y seguir viendo la versión anterior. No siempre hemos configurado algo mal; en ocasiones el sistema simplemente está reutilizando la copia almacenada.

La solución habitual consiste en limpiar la carpeta de compilación, eliminar la aplicación del dispositivo o del simulador y volver a instalarla. Para comprobar el requisito de iOS 27 también conviene inspeccionar el producto compilado, ya que la generación automática puede hacer que el Info.plist visible en el proyecto no sea idéntico al que termina dentro del paquete.

Otros problemas frecuentes son utilizar una imagen que no pertenece al catálogo de recursos, olvidar la variante para el modo oscuro, añadir texto que después no se puede localizar o diseñar pensando en una sola orientación. La pantalla debe adaptarse a todos los tamaños, orientaciones y modos de apariencia que admite la aplicación.

Una receta que suele funcionar

Para la mayoría de proyectos SwiftUI, el proceso puede resumirse en seis pasos:

  1. Definir UILaunchScreen con un color del catálogo de recursos y añadir una imagen únicamente cuando sea necesaria.
  2. Reutilizar ese color y la estructura visual básica en la primera vista SwiftUI.
  3. Mostrar el progreso, los errores y los estados vacíos dentro de la interfaz real.
  4. Reservar las animaciones y los mensajes de tu marca para una bienvenida opcional.
  5. Probar una instalación limpia en diferentes tamaños, orientaciones y apariencias.
  6. Verificar que el paquete compilado contiene una de las claves aceptadas por App Store Connect.

🎯 Una buena pantalla de lanzamiento funciona precisamente porque apenas se nota. No necesita impresionar ni entretener: debe unir el icono de la aplicación con una primera vista disponible cuanto antes. Mantenerla sencilla, estática y alineada con la interfaz SwiftUI evita saltos visuales, mejora la percepción de velocidad y deja el contenido interactivo en el lugar que le corresponde.