Splash Screen en React Native: configuración con Expo y Bare (2026)

Respuesta rápida: Usa expo-splash-screen con el plugin de configuración en app.json o app.config.js cuando la app se ejecuta en Expo (incluidos dev clients y builds de EAS). Llama a SplashScreen.preventAutoHideAsync() en ámbito global, luego SplashScreen.hideAsync() cuando las fuentes, la autenticación y la navegación estén listas. En React Native puro CLI, prefiere react-native-bootsplash para nuevo trabajo; mantén las aplicaciones legacy con react-native-splash-screen hasta que las migres. Mantén el splash nativo estático, ocúltalo cuando la primera pantalla real pueda renderizarse y mueve el splash animado branding en la primera pantalla de React. ¿Construyendo con tecnología web en su lugar? Capacitor usa @capacitor/splash-screen con la misma regla de preparación, y Capgo ships web-layer live updates without a store build. Native splash assets still need a new binary.

Tocas el icono de tu app en un dispositivo real y, durante un instante, el usuario ve un destello blanco, un logo estirado o una pantalla de inicio congelada que desaparece antes de que esté listo algo útil. Esa brecha es lo que react native splash screen La configuración debe cubrir: la interfaz de inicio nativa hasta que JavaScript pueda mostrar un primer cuadro estable.

Tabla de contenidos

• Por qué una splash screen profesional es clave
  • Qué hace realmente la splash screen
• Preparar assets perfectos para la pantalla de splash
  • Qué preparar antes de programar
  • Errores comunes en los assets
  • Un flujo de exportación práctico
• Implementación con el flujo de trabajo de Expo Go y Development Client
  • Configura el splash nativo de forma declarativa
  • Oculta el splash cuando esté lista, no por tiempo
  • Qué esperar en Expo Go y builds de desarrollo
• Configuración para proyectos de Bare React Native CLI
  • Configuración de Android en un proyecto bare
  • Configuración de iOS en un proyecto bare
  • El CLI bare te da más control sobre el handoff
  • Expo managed vs. CLI bare
• Técnicas avanzadas para splash screens animados y con buen rendimiento
  • La animación debe seguir la realidad del arranque
  • Trata el arranque como una orquestación
• React Native vs Capacitor: Splash screens y publicación de correcciones
  • Pantallas splash en Capacitor
  • Por qué los equipos web eligen Capacitor en vez de React Native
• Solución de problemas comunes con la splash screen
  • Imagen de splash estirada o borrosa
  • Pantalla blanca tras ocultar el splash
  • Falta la splash screen en una plataforma
  • El build falla al añadir la configuración de splash
• Preguntas frecuentes

Por qué una splash screen profesional es clave

Un usuario toca tu app desde la pantalla de inicio y la secuencia de arranque muestra un frame blanco vacío antes de que aparezca la primera UI. En producción, eso se percibe como inestabilidad. No importa que React Native siga cargando el JavaScript bundle o restaurando el estado en segundo plano. La primera impresión ya está mal.

En React Native, la splash screen es la primera superficie nativa que controla tu app. Cubre la transición entre el inicio del proceso y el primer frame usable renderizado por React. Eso la convierte en una herramienta de arranque, no solo en un activo de branding. Si ajustas bien el tiempo, los usuarios verán un arranque estable que parece intencionado. Si la ocultas demasiado pronto, verán saltos de layout, fuentes que faltan o una pantalla que parece muerta mientras la auth, la navegación o la remote config se ponen al día.

Qué hace realmente la splash screen

Una pantalla de inicio en producción suele tener que gestionar cuatro aspectos del arranque:

• Cubre el trabajo de inicio de nativo a JS: la carga de fuentes, la restauración de sesiones persistidas, la lectura de feature flags y el estado inicial de navegación compiten por el primer frame.
• Evitar glitches visuales: evita destellos de blanco del sistema, texto sin estilo o una vista raíz montada parcialmente.
• Mantener la coherencia visual del lanzamiento: el color de fondo y el logo pueden coincidir con la app para que la transición se sienta controlada.
• Forzar decisiones de arranque: los equipos deben definir qué significa “listo” antes de quitar la pantalla de inicio.

Regla práctica: Ocultar la splash cuando la primera pantalla real pueda renderizarse limpiamente, no después de un retardo arbitrario.

Aquí es donde los flujos de trabajo gestionados por Expo y los CLI bare empiezan a divergir. En los proyectos gestionados por Expo, la configuración del splash es mayoritariamente declarativa, y la principal decisión de ingeniería es cuándo llamar a hide API según el estado de preparación de la app. En los proyectos CLI bare de React Native, tú asumes más de la configuración nativa en Android e iOS, lo que te da más control, pero también más formas de introducir parpadeos al inicio, desajustes de tema o regresiones específicas de la plataforma.

Ese equilibrio importa en proyectos reales. Expo es más rápido de configurar y más fácil de mantener consistente entre entornos. Los proyectos bare suelen ser la opción correcta cuando la app ya depende de módulos nativos personalizados, comportamiento de inicio personalizado o un control más estricto sobre la ruta de arranque.

Los equipos que tratan el lanzamiento como parte de la calidad del producto suelen revisarlo junto con el trabajo de UX más amplio, no como una tarea nativa aislada. Ese es el mismo enfoque que se cubre en Capgo’s guide to app user experience. Si estás sopesando React Native contra Capacitor para una app desde cero, lee Comparativa: React Native vs Capacitor antes de fijar las herramientas de lanzamiento. Los equipos de Capacitor configuran pantallas de inicio en proyectos nativos y con @capacitor/splash-screen durante la inicialización de la app, como se detalla en Guía de inicialización de la app Capacitor.

Preparar los assets perfectos para la splash screen

La mayoría de los bugs de la splash screen empiezan en los archivos de diseño, no en code. Si el asset base está mal, ninguna cantidad de limpieza en XML de Android o storyboard de iOS lo arreglará.

El enfoque más seguro es tratar la splash como un sistema de layout, no como una sola imagen a pantalla completa. Usa un color de fondo más un logo o ilustración centrado. Eso escala de forma más predecible en dispositivos Android altos, iPhones, tablets y orientaciones más anchas que intentar encajar una imagen detallada estilo póster en todas partes.

Qué preparar antes de programar

Empieza con un archivo de diseño limpio. El formato vectorial es ideal para el handoff, aunque el asset de lanzamiento exportado sea un PNG.

Usa esta checklist:

• Arte original: Mantén un logo o isotipo maestro en SVG, AI u otro formato editable para que las exportaciones sean consistentes.
• Color de fondo: Define el color exacto del fondo del splash desde el inicio y asegúrate de que coincida con la primera pantalla o el fondo del app shell.
• Márgenes de seguridad: Deja suficiente espacio vacío alrededor del logo para que un recorte agresivo en aspect ratios inusuales no afecte al diseño.
• Variantes de plataforma: Exporta los tamaños de imagen que necesite tu workflow en lugar de estirar un solo archivo en todas partes.
• Revisión de dark mode: Si tu app soporta temas oscuros, asegúrate de que el logo se lea bien sobre el fondo elegido.

La guía de Expo es útil aquí porque refuerza que los assets de lanzamiento son parte del build pipeline, no un detalle posterior. Su documentación recomienda un PNG cuadrado de 1024×1024 para los iconos de la app y señala que EAS Build puede generar los tamaños necesarios para proyectos creados con npx create-expo-app, lo que muestra cómo la generación de assets ha pasado a las herramientas modernas en lugar de la repetición manual.

Errores comunes con assets

Los fallos visuales más comunes son predecibles:

Una imagen de splash no debe incluir texto denso, detalles diminutos ni copy de marketing. Las pantallas de inicio se ven brevemente y se renderizan bajo restricciones nativas estrictas.

Para equipos que lanzan actualizaciones visuales frecuentes, la disciplina con las imágenes importa más allá del lanzamiento. Los mismos hábitos se aplican a los bundles de entrega y al tamaño del binario, por eso guías como optimizar imágenes para actualizaciones valen la pena revisar al estandarizar las exportaciones de assets.

Un flujo de exportación práctico

Una configuración que funciona bien en proyectos reales se ve así:

1. Diseña una composición centrada sobre un fondo liso.
2. Exporta un PNG de logo transparente si tu flujo de trabajo admite un color de fondo separado.
3. Mantén la nomenclatura consistente entre plataformas para que cambiar assets no sea adivinar.
4. Prueba en simuladores pequeños y altos temprano antes de configurar el ciclo de vida del splash.
5. Recompila tras cambios en assets porque los recursos de lanzamiento suelen estar en cachés nativas.

Ese último punto importa más de lo que la gente cree. Muchos problemas de splash screen que parecen fallos de configuración son solo assets nativos obsoletos.

Splash screen de Expo (expo-splash-screen)

Si estás buscando expo splash screen o pantalla de inicio de react native expo, empieza por el expo-splash-screen paquete. Se adapta a flujos gestionados y prebuild, mantiene los assets de lanzamiento en la configuración y expone APIs de JavaScript para controlar la visibilidad en builds de la tienda.

El comportamiento clave que debes entender es simple. Mantén el splash nativo visible hasta que el primer frame de UI significativo esté listo. Expo documenta preventAutoHideAsync() para que el splash configurado permanezca hasta que llames a hideAsync(). Llama a preventAutoHideAsync() en el ámbito global sin await, no dentro de un hook, o el splash podría ocultarse automáticamente antes de que se ejecute tu code. Ocultarlo demasiado pronto puede exponer brevemente una pantalla en blanco en iOS y Android.

Mantén el splash mientras carga (Expo)

Esta es la forma habitual pantalla de carga en React Native patrón: el splash nativo cubre la carga de fuentes, la autenticación persistida y la configuración remota mientras React regresa null. Cuando isReady se vuelve true, llama a hideAsync(). Opcional SplashScreen.setOptions() adjusts fade behavior on hide. Test splash assets in a cliente de desarrollo, Vista previa, o producción build; Expo documenta que Expo Go no es el entorno autoritativo para la configuración nativa del splash.

Configura el splash nativo de forma declarativa

En un proyecto de Expo, la parte visual suele estar en app.json, app.config.js, o app.config.ts dentro de la expo-splash-screen plugin de configuración, como se describe en la guía de splash screen e icono de app de Expo.

Un app.json setup típico se ve así:

{
  "expo": {
    "plugins": [
      [
        "expo-splash-screen",
        {
          "backgroundColor": "#111111",
          "image": "./assets/splash-icon.png",
          "imageWidth": 200
        }
      ]
    ]
  }
}

Los campos exactos pueden variar según el setup del proyecto, pero el patrón se mantiene. Definas la apariencia nativa de inicio en la config y luego controlas la visibilidad desde JavaScript.

Algunas decisiones prácticas importan aquí:

• Usa un color de fondo cercano al de tu pantalla inicial para que la transición se sienta continua.
• Mantén la imagen simple porque las pantallas de lanzamiento no son el lugar para gráficos recargados.
• Evita retrasos de branding falsos que mantienen al usuario viendo un logo cuando la app ya está lista.

Oculta el splash cuando esté lista, no por tiempo

Muchos tutoriales suelen desviarse. Usan setTimeout, que es fácil de demostrar pero incorrecto para producción.

Usa mejor el estado de inicio. Un patrón común a nivel de raíz es este:

import { useCallback, useEffect, useState } from 'react';
import { View } from 'react-native';
import * as SplashScreen from 'expo-splash-screen';

SplashScreen.preventAutoHideAsync();

export default function App() {
  const [isReady, setIsReady] = useState(false);

  useEffect(() => {
    async function prepare() {
      try {
        // Load fonts
        // Restore auth state
        // Read persisted settings
      } finally {
        setIsReady(true);
      }
    }

    prepare();
  }, []);

  const onLayoutRootView = useCallback(async () => {
    if (isReady) {
      await SplashScreen.hideAsync();
    }
  }, [isReady]);

  if (!isReady) {
    return null;
  }

  return (
    <View style={{ flex: 1 }} onLayout={onLayoutRootView}>
      {/* Your real app UI */}
    </View>
  );
}

Dos detalles hacen que este patrón sea fiable.

Primero, preventAutoHideAsync() se llama antes de que la app empiece a renderizar UI relevante. Segundo, la ocultación ocurre solo cuando la root view está lista para el layout, lo que reduce la probabilidad de un flash entre el splash nativo y el árbol de React.

No ocultes el splash cuando tu trabajo async empiece a terminar. Ocúltalo cuando la UI que depende de ese trabajo pueda renderizarse de verdad.

Esa distinción es clave cuando el inicio incluye restauración de auth, configuración remota o carga de fuentes. Si tu home depende de fuentes custom y del estado de sesión iniciada, el splash debe cubrir ese hueco.

A continuación, un recorrido útil por el ecosistema más amplio de inicio y arranque de React Native:

Qué esperar en Expo Go y builds de desarrollo

Expo añade una complicación extra. El comportamiento del splash que esperas en un build standalone puede no coincidir con el que ves en Expo Go.

Esa discrepancia confunde a muchos equipos. Cambias el asset o la lógica de timing, pruebas en Expo Go y concluyes que la configuración está rota, cuando el problema real es que el entorno de desarrollo no se comporta como un binario de producción.

Usa este modelo mental:

• Expo Go es práctico para iterar pero no es la autoridad final sobre el comportamiento del splash nativo.
• Los clientes de desarrollo se acercan más a la realidad porque incluyen tu proyecto nativo generado.
• Las builds standalone son la verificación final del timing de lanzamiento, el comportamiento del tema y la corrección de los assets.

Si tu splash aún parpadea o se queda, el bug suele ser uno de tres: ocultarlo demasiado pronto, renderizar null durante demasiado tiempo después de ocultarse, o al probar en un entorno que no refleja el comportamiento de release.

Pantalla de splash en React Native puro CLI

Una app de React Native puro te da control directo sobre el comportamiento de lanzamiento. Para nuevos proyectos de CLI puro, react-native-bootsplash es la opción mantenida (releases activas hasta 2026 y alineada con la política de soporte actual de React Native). Muchas apps de producción aún lanzan react-native-splash-screen; trátalo como mantenimiento legacy a menos que ya estés integrado.

Splash screen animada (React Native o Expo): iOS LaunchScreen.storyboard se mantiene estática. Android 12+ puede mostrar un breve icono vectorial animado en la splash del sistema, pero expo-splash-screen and most bare CLI setups still use a PNG estática y mueve la animación a la primera pantalla de React (por ejemplo, Lottie). Oculta el splash nativo cuando termine el trabajo de arranque y luego anima allí. Ver rendimiento de animaciones en apps de Capacitor para aplicar la misma disciplina de arranque en otro stack.

En proyectos de CLI, el objetivo del handoff nativo no cambia: mostrar la UI de inicio de inmediato y ocultarla solo cuando la UI significativa pueda renderizarse.

Configuración de Android en un proyecto bare

La configuración de la splash screen en Android se encuentra en varios lugares: recursos de tema, drawables, AndroidManifest.xml, y MainActivity. Esa separación explica por qué pequeños errores provocan destellos visibles.

El flujo habitual es sencillo:

1. Genera los assets de splash para las carpetas de recursos de Android que soportes.
2. Define un launch theme con el color de fondo y el splash drawable correctos.
3. Aplica ese theme a la actividad launcher en AndroidManifest.xml.
4. Inicializa la splash screen en MainActivity.
5. Ocúltala desde JavaScript cuando terminen las tareas de inicio que bloquean el primer render.

Un patrón simplificado MainActivity.kt el patrón suele verse así:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // initialize splash handling here depending on the library
}

Ese snippet es genérico a propósito porque la llamada exacta depende de la librería. El punto de integración nativa suele ser lo fácil; los errores suelen venir de los resources y las transiciones de theme.

Estos son los problemas de Android que aparecen en producción:

• Mismatch de theme: Si el launch theme usa un color de fondo distinto al de tu primera pantalla, los usuarios verán un flash durante la transición.
• Buckets de assets incorrectos: Android estirará o desenfocará los assets que falten en las carpetas de densidad esperadas.
• Pruebas solo con Metro: Los cambios en recursos nativos suelen requerir un rebuild limpio. El hot reload no valida el comportamiento de inicio.
• Reglas de inicio de Android 12: Newer Android versions apply their own splash behavior first, so custom setups need to respect those platform constraints.
• JS lento tras ocultar: Si React oculta el splash antes de que la vista raíz pueda renderizarse, los usuarios ven un fotograma en blanco en lugar de una transición fluida.

Ese último punto importa más que la imagen en sí. Los problemas de timing suelen percibirse como problemas de rendimiento.

Configuración de iOS en un proyecto bare

En iOS, el centro de gravedad es LaunchScreen.storyboard más un pequeño hook nativo en AppDelegate. La plataforma espera que la pantalla de inicio sea estática y ligera. Trátala como una instantánea de la estructura visual de la primera pantalla, no como un flujo de onboarding mini.

La configuración fiable se ve así:

• Añade los assets al asset catalog de Xcode.
• Configurar LaunchScreen.storyboard con restricciones simples.
• Mantén el diseño estático. El color de fondo, el logo y los márgenes seguros suelen ser suficientes.
• Añade la llamada nativa de bootstrap de la librería en AppDelegate.
• Oculta el splash desde JavaScript solo cuando la app esté completamente lista para renderizar.

Los equipos nuevos en iOS suelen sobrecomplicar el storyboard. Eso normalmente sale mal. Restricciones complejas, múltiples vistas anidadas o intentos de animar la pantalla de inicio hacen que la configuración sea más difícil de mantener y más propensa a romperse en distintos tamaños de dispositivo.

Una pantalla de inicio simple es la opción más segura.

El CLI bare te da más control sobre el handoff

Esta es la diferencia clave entre Expo-managed y bare CLI. Expo te ofrece un camino más rápido hacia un valor predeterminado correcto. Bare te da la responsabilidad total del pipeline nativo de inicio.

Ese intercambio resulta útil cuando el arranque hace más que cargar un bundle. Las apps con restauración de autenticación, lecturas de almacenamiento cifrado, inicialización nativa personalizada de SDK o reglas de marca blanca a menudo necesitan ese control extra. Los proyectos bare te permiten alinear el timing del splash con ese trabajo, en lugar de forzar todo a través de configuraciones de alto nivel.

Si planeas añadir una transición animada tras el arranque, mantén el splash nativo estático en iOS y prefiere un asset estático en Android, a menos que configures deliberadamente el icono animado de Android 12. Mueve el movimiento a la primera pantalla de React. Los trade-offs de rendimiento son similares a los que importan en cualquier ruta de arranque móvil. El trabajo pesado durante el primer paint es costoso. Este guía sobre rendimiento de animaciones en apps de Capacitor cubre el mismo principio desde otro stack, y la lección se aplica sin problemas a React Native.

Expo managed vs. CLI bare

La comparación práctica tiene menos que ver con la visualización de imágenes y más con dónde reside la complejidad de inicio.

Si la app ya está en Expo y los requisitos de lanzamiento son estándar, quedarse ahí suele ahorrar tiempo. Si la ruta de arranque depende del orden de inicialización nativa, temas personalizados o lógica de arranque específica de la plataforma, bare CLI suele ser la opción más limpia a largo plazo.

Ambos flujos pueden entregar una splash screen pulida. La diferencia es quién controla el pipeline de lanzamiento: tu framework o tu equipo.

Técnicas avanzadas para splash screens animados y con buen rendimiento

Las pantallas de inicio animadas parecen pulidas cuando respetan el pipeline de arranque. Parecen baratas cuando lo distraen.

Por eso trato la animación como una capa de mejora, no como la base. La primera tarea sigue siendo el timing. Si la app no está lista, la splash se queda. Si está lista, la transición debe avanzar rápido hacia la primera pantalla utilizable.

La animación debe seguir la realidad del arranque

Un patrón común es mantener la splash nativa simple y luego ejecutar una animación ligera con marca en la primera pantalla de React tras el lanzamiento. Eso te da más flexibilidad que intentar animar la superficie nativa de lanzamiento real.

Lottie es una opción práctica para este tipo de handoff porque puede entregar movimiento sin construir un stack de animación personalizado pesado en la primera pantalla. La parte importante es el secuencia:

• La splash nativa permanece visible durante el trabajo crítico de arranque.
• React monta la primera pantalla real o una pantalla de transición controlada.
• La animación opcional se reproduce solo si no bloquea la interacción más de lo necesario.

Lo que no funciona es el viejo setTimeout(2000) patrón. En un dispositivo rápido, eso hace que la app espere sin razón. En uno lento, a menudo solo reemplaza un estado de carga con otro.

Trata el arranque como una orquestación

Un mejor modelo mental es la orquestación del arranque. La splash screen debe cubrir las tareas exactas que deben completarse antes de que la app pueda mostrar contenido útil.

Eso suele incluir una mezcla de:

• Bootstrap de auth: Restaurar una sesión o decidir si redirigir al sign-in.
• Lecturas de storage esenciales: Tema, locale, estado de onboarding y preferencias críticas conocidas.
• Disponibilidad de fuentes: Especialmente si la primera pantalla depende de tipografía personalizada para la estabilidad del layout.
• Configuración remota que condiciona la UI: Solo si la primera pantalla no puede renderizarse de forma segura sin ella.

Hay otro matiz que muchos tutoriales pasan por alto. El comportamiento de la splash screen cambia según el entorno. El análisis del manejo de splash en Expo en desarrollo y producción señala que el comportamiento puede no ser igual en Expo Go que en builds independientes, y que la gestión automática de visibilidad cambia al tomar el control manual. Por eso los ejemplos basados en delays envejecen mal: ocultan la secuencia de inicio real en lugar de alinearse con ella.

Una launch screen no debería usarse para fingir velocidad. Debe usarse para evitar que los usuarios vean una UI incompleta.

Si estás añadiendo movimiento en un stack híbrido o evaluando el rendimiento de renderizado general, esta guía sobre el rendimiento de animaciones en apps de Capacitor es un contexto útil porque se aplica la misma disciplina. Mantén el trabajo de inicio ligero, evita bloqueos innecesarios y deja que la animación apoye la capacidad de respuesta en lugar de competir con ella.

Una nota práctica para equipos que lanzan correcciones visuales fuera de releases binarios completos: plataformas como Capgo gestionan actualizaciones de JavaScript, CSS, copy, config y assets para apps de Capacitor y Electron, pero los cambios de splash nativa en React Native siguen siendo parte del pipeline de build nativo, ya que la splash screen real aparece antes de que la app de JavaScript esté en ejecución.

React Native vs Capacitor: Splash screens y publicación de correcciones

Si estás leyendo esto porque estás iniciando una nueva app, o porque tu equipo ya tiene una web app en React, Vue, Angular o Svelte, vale la pena comparar cómo funcionan los splash screens en Capacitor. El concepto de pantalla de inicio nativa es el mismo, pero el flujo de trabajo diario es más sencillo para los equipos web.

Pantallas splash en Capacitor

Las apps de Capacitor usan el plugin oficial @capacitor/splash-screen . Lo configuras una vez en capacitor.config.ts y lo ocultas de tu code web cuando la app está lista:

// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli'

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example',
  webDir: 'dist',
  plugins: {
    SplashScreen: {
      launchAutoHide: false,
      backgroundColor: '#ffffff',
    },
  },
}

export default config

// main.ts, after your router, fonts, and auth are ready
import { SplashScreen } from '@capacitor/splash-screen'

await SplashScreen.hide()

La regla de preparación de esta guía es idéntica: mantén el splash nativo estático, ocúltalo cuando la primera pantalla real pueda renderizarse y ejecuta cualquier animación en la primera pantalla de tu app. Para los recursos nativos, @capacitor/assets genera los archivos de iconos y splash para Android e iOS a partir de tus imágenes de icono y splash (por ejemplo icon-only.png y splash.png en un assets ). El flujo paso a paso se detalla en inicialización de la app Capacitor.

Por qué los equipos web eligen Capacitor en vez de React Native

• Reutiliza la app que ya tienes: Capacitor envuelve tu app web existente en una shell nativa, por lo que tus componentes, CSS y herramientas de build siguen funcionando. React Native requiere reescribir la UI en componentes de React Native.
• Cualquier framework: React, Vue, Angular, Svelte o JavaScript plano funcionan. No estás atado a React.
• Acceso nativo cuando lo necesites: los plugins oficiales y de la comunidad cubren cámara, push, biometría y más, y puedes escribir tu propio plugin en Swift o Kotlin.
• Live updates para la capa de la app: con Capgo, envías correcciones de JavaScript, HTML, CSS y assets a los usuarios en el siguiente lanzamiento, con canales, despliegues progresivos y rollback con un clic, sin esperar a la revisión de la tienda en cada cambio de la capa web. Los cambios nativos, incluida la propia pantalla de splash nativa, se publican a través de las tiendas. Consulta la documentación de live updates de Capgo.

Para una comparación completa de rendimiento, herramientas y ajuste de equipo, lee Comparativa: React Native vs Capacitor. Si hoy usas Expo y estás valorando un cambio, Alternativa a Expo analiza las opciones.

Solución de problemas comunes con la splash screen

La mayoría de los problemas de splash se repiten en un pequeño grupo de causas. La solución es más fácil una vez que separas problemas de assets, problemas de timing, y problemas de integración nativa.

Los patrones de la comunidad en las guías recientes de React Native convergen en el mismo flujo central: añadir la librería, configurar los assets nativos de inicio y llamar show durante el arranque y ocultarlo cuando la app esté lista. Las configuraciones de Android suelen implicar MainActivity además de recursos XML o drawable, mientras que iOS se centra en LaunchScreen.storyboard y AppDelegate. El mismo resumen señala que Expo recomienda un PNG cuadrado de 1024×1024 para los iconos de la app y que EAS Build puede generar los tamaños necesarios para proyectos creados con npx create-expo-app, según el resumen de esta guía de splash screen en React Native.

Imagen de splash estirada o borrosa

Síntoma: El logo se ve difuso, recortado o con un escalado extraño.

Causa: La imagen base no se exportó correctamente o el layout depende de un raster a pantalla completa que no se adapta bien.

Solución: Cambia el arte tipo póster por un logo centrado sobre un fondo plano. Re-exporta desde el diseño original, regenera los assets por densidad y verifica que tus drawables de Android o el asset catalog de iOS tengan los archivos correctos.

Pantalla blanca tras ocultar el splash

Síntoma: El splash nativo desaparece y los usuarios ven un frame en blanco antes de la primera pantalla.

Causa: Tu app oculta la splash screen antes de que la UI raíz pueda renderizar contenido útil.

Solución: Vincula el cierre de la splash a que la app esté lista, no al tiempo transcurrido. En Expo, normalmente significa mantener la splash hasta que la vista raíz pueda hacer layout. En proyectos bare, usa el patrón equivalente y asegúrate de que la primera pantalla renderizada no se bloquee de inmediato con más trabajo asíncrono.

Falta la splash screen en una plataforma

Síntoma: Se muestra en Android pero no en iOS, o al revés.

Causa: Faltaba configurar algo en el lado nativo. Suele ser una referencia de storyboard olvidada, un problema con el tema o un asset que no se añadió al target correcto.

Solución: Revisa los archivos específicos de cada plataforma uno por uno. En Android, inspecciona el launch theme y las referencias de recursos. En iOS, confirma LaunchScreen.storyboardla pertenencia al asset catalog y los ajustes del target de la app en Xcode.

El build falla al añadir la configuración de splash

Síntoma: La app dejó de compilar tras introducir una librería o cambiar los archivos de splash.

Causa: Los archivos del proyecto nativo y la configuración generada pueden desincronizarse, especialmente tras cambios en plugins o assets.

Solución: Limpia el build, reinstala las dependencias si es necesario y reconstruye el proyecto nativo por completo. Si usas Expo con capas nativas generadas, regenera con cuidado y verifica la configuración de plugins. Si tienes una app bare, revisa MainActivity, AppDelegate, nombres de recursos y cualquier edición de plist o manifest para pequeñas discrepancias.

Los equipos más rápidos tratan el splash screen como parte de la ingeniería de releases, no como una tarea visual puntual. Eso importa aún más cuando los assets de arranque, los textos de la UI o el comportamiento del app shell tienen que cambiar rápido después del lanzamiento. Capgo permite a los equipos de Capacitor y Electron publicar correcciones de JavaScript, CSS, textos, configuración y assets en el siguiente arranque, con controles de rollout y soporte de rollback, lo que resulta útil cuando el problema está en la capa de la app y no en el splash screen nativo en sí.

Preguntas frecuentes

¿Cómo añado un splash screen en Expo (expo splash screen)?
Añade la expo-splash-screen plugin para app.json o app.config.js, establece backgroundColor y image, recompilar un binario nativo, llamar a preventAutoHideAsync() en el ámbito global, y hideAsync() cuando la primera pantalla esté lista. Valida en un cliente de desarrollo o en un build de producción, no solo en Expo Go.

¿Cómo mantengo la splash screen visible mientras mi app de React Native carga?
En Expo, preventAutoHideAsync() más devolver null hasta que el trabajo asíncrono se complete, luego hideAsync(). Con react-native-splash-screen, llama a SplashScreen.show(this) en Android MainActivity o [RNSplashScreen show] en iOS AppDelegate, luego SplashScreen.hide() desde JavaScript cuando esté listo. Con react-native-bootsplash, inicializar de forma nativa por plataforma y luego llamar BootSplash.hide() después de la misma puerta de preparación.

¿Cuál es la diferencia entre react-native-splash-screen y react-native-bootsplash?
Bootsplash se mantiene activamente e incluye un generador para los assets de lanzamiento. react-native-splash-screen sigue siendo común en repositorios antiguos, pero su mantenimiento es más lento; prefiere bootsplash para nuevas apps bare CLI.

¿Cómo configuro una splash screen en React Native bare sin Expo?
Instalar react-native-bootsplash, genera los assets y llama a RNBootSplash.init(this, R.style.BootTheme) en Android o RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) en iOS, luego BootSplash.hide() desde JS cuando termina el arranque. Los proyectos legacy pueden usar SplashScreen.show(this) / [RNSplashScreen show] con SplashScreen.hide() en su lugar. Reconstruye tras cambios en assets nativos.

¿Puedo usar una splash screen animada en React Native o Expo?
En iOS, mantén la pantalla de lanzamiento estática. En Android 12+, la splash del sistema puede usar un icono animado breve, pero la mayoría de equipos mantienen expo-splash-screen o los assets de bootsplash estáticos, los ocultan cuando están listos y luego animan en React (por ejemplo, Lottie). No dependas de setTimeout para simular el tiempo de carga.

¿En qué se diferencia la configuración del splash entre React Native y Capacitor?
React Native usa expo-splash-screen o bibliotecas CLI antes de que se ejecute JS. Capacitor usa pantallas de inicio nativas más @capacitor/splash-screen en la pila del WebView. Consulta Comparativa: React Native vs Capacitor y inicialización de la app de Capacitor.

Lanza tu app de Capacitor más rápido con Capgo

¿Estás construyendo con Capacitor o planeas llevar una app web a móvil? Crea una cuenta gratuita de Capgo y publica tu primer live update en minutos. Capgo entrega correcciones de JavaScript, CSS y assets a tus usuarios en el siguiente lanzamiento, con despliegues progresivos y rollback instantáneo, para que un bug en tu capa de app nunca tenga que esperar a la revisión de la tienda.

Sigue con React Native Splash Screen (Expo y CLI bare)

Si estás usando esta guía para planificar el comportamiento de los medios nativos y la interfaz, conéctalo con Uso de @capgo/capacitor-live-activities para la capacidad nativa en Uso de @capgo/capacitor-live-activities, @capgo/capacitor-live-activities para los detalles de implementación en @capgo/capacitor-live-activities, Uso de @capgo/capacitor-video-player para la capacidad nativa en Uso de @capgo/capacitor-video-player, @capgo/capacitor-video-player por el detalle de implementación en @capgo/capacitor-video-player, y Uso de @capgo/capacitor-native-navigation para la capacidad nativa al usar @capgo/capacitor-native-navigation.