Risposta rapida: Usa expo-splash-screen con il plugin di configurazione nella app.json o app.config.js quando l'app viene eseguita su Expo (inclusi dev client ed EAS build). Chiama SplashScreen.preventAutoHideAsync() nella scope globale, poi SplashScreen.hideAsync() quando font, auth e navigazione sono pronti. Su React Native bare CLI, preferisci react-native-bootsplash per i nuovi progetti; mantieni le app legacy con react-native-splash-screen finché non migri. Mantieni la splash screen nativa statica, nascondila quando la prima schermata reale è pronta, e sposta splash screen animata il branding nella prima schermata React. Vuoi usare tecnologie web? Capacitor usa @capacitor/splash-screen con la stessa regola di readiness, e Capgo distribuisce Live Update del web-layer senza un nuovo build dello store. Gli asset nativi della splash screen richiedono ancora un nuovo binario.
Tocchi l'icona dell'app su un dispositivo reale e, per una frazione di secondo, l'utente vede un flash bianco, un logo distorto o una splash screen bloccata che scompare prima che tutto sia pronto. Quel vuoto è ciò che react native splash screen la configurazione deve coprire: l'interfaccia di avvio nativa finché JavaScript non può mostrare il primo frame stabile.
Indice dei contenuti
- Perché uno splash screen professionale è fondamentale
- Preparare asset perfetti per lo splash screen
- Implementazione con il workflow Expo Go e Development Client
- Configurazione per progetti Bare React Native CLI
- Tecniche avanzate per splash screen animate e performanti
- React Native vs Capacitor: Splash Screen e rilascio di fix
- Risoluzione dei problemi comuni con la splash screen
- Frequently asked questions
Perché uno splash screen professionale è fondamentale
Un utente tocca la tua app dalla home screen e la sequenza di avvio mostra un frame bianco vuoto prima della prima UI. In produzione, questo trasmette instabilità. Non importa se React Native sta ancora caricando il bundle JavaScript o ripristinando lo stato in background. La prima impressione è già compromessa.
In React Native, la splash screen è la prima superficie nativa controllata dalla tua app. Copre il passaggio tra l'avvio del processo e il primo frame renderizzato da React. Questo la rende uno strumento di startup, non solo un elemento di branding. Se gestisci bene il timing, gli utenti vedranno un avvio stabile e fluido. Se la nascondi troppo presto, vedranno layout shift, font mancanti o uno schermo vuoto mentre l'auth, la navigazione o la remote config si caricano.
Cosa fa realmente lo splash screen
Una splash screen in produzione deve solitamente gestire quattro aspetti all'avvio:
- Coprire il passaggio da native a JS: caricamento font, ripristino sessione, feature flag e stato iniziale della navigazione competono per il primo frame.
- Prevenire glitch visivi: evita flash bianchi di sistema, testo senza stile o una root view montata solo parzialmente.
- Mantenere la coerenza visiva al lancio: colore di sfondo e logo possono coincidere con l'app shell per una transizione fluida.
- Definire le decisioni di startup: i team devono stabilire cosa significhi essere "ready" prima di rimuovere la splash screen.
Regola pratica: Nascondere la splash quando la prima schermata reale è pronta, non dopo un delay arbitrario.
È anche qui che i workflow CLI gestiti con Expo e quelli bare iniziano a divergere. Nei progetti Expo-managed, la configurazione della splash screen è quasi tutta dichiarativa, e la decisione tecnica principale riguarda quando chiamare il comando hide API in base alla prontezza dell'app. Nei progetti bare React Native CLI, gestisci direttamente il setup nativo su Android e iOS, il che ti offre più controllo ma anche più rischi di flicker all'avvio, mismatch dei temi o regressioni specifiche della piattaforma.
Questo compromesso è fondamentale nei progetti reali. Expo è più veloce da configurare e più facile da mantenere coerente tra i vari ambienti. I progetti bare sono spesso la scelta giusta quando l'app dipende già da moduli nativi custom, comportamenti di avvio personalizzati o richiede un controllo più stretto sul percorso di startup.
I team che considerano l'avvio come parte della qualità del prodotto solitamente lo analizzano insieme al lavoro sulla UX, non come un compito nativo isolato. È lo stesso approccio descritto nella guida di Capgo all'esperienza utente delle app. Se stai valutando React Native rispetto a Capacitor per un nuovo progetto, leggi React Native vs Capacitor: il confronto prima di bloccare i tool di lancio. I team Capacitor configurano le splash screen nei progetti nativi e con @capacitor/splash-screen durante l'inizializzazione dell'app, come descritto nella guida all'inizializzazione dell'app Capacitor.
Preparare asset perfetti per lo splash screen
La maggior parte dei bug della splash screen nasce nei file di design, non in code. Se l'asset di base è errato, nessuna pulizia di Android XML o storyboard iOS potrà salvarlo.
L'approccio più sicuro è trattare la splash come un sistema di layout, e non come una singola immagine a tutto schermo. Usa un colore di sfondo con un logo o un'illustrazione centrata. Questo scala in modo più prevedibile su dispositivi Android lunghi, iPhone, tablet e orientamenti più ampi rispetto al tentativo di adattare un'unica immagine dettagliata in stile poster ovunque.
Cosa preparare prima di scrivere il codice
Parti da un file sorgente pulito derivato dal design. Il formato vettoriale è l'ideale per l'handoff, anche se l'asset di lancio esportato sarà un PNG.
Usa questa checklist:
- Grafica sorgente: Conserva un logo o un simbolo master in SVG, AI o un altro formato editabile per garantire la coerenza degli export.
- Colore di sfondo: Definisci subito l'esatto colore di sfondo della splash screen e assicurati che corrisponda alla prima schermata o allo sfondo dell'app shell.
- Margini di sicurezza: Lascia abbastanza spazio vuoto attorno al logo, così un eventuale cropping aggressivo su aspect ratio insoliti non rovinerà il design.
- Varianti per piattaforma: Esporta le dimensioni delle immagini richieste dal tuo workflow, invece di stirare un unico file ovunque.
- Revisione dark mode: Se la tua app supporta la dark mode, verifica che il logo sia ben leggibile sullo sfondo scelto.
La guida di Expo è utile in questo caso, perché sottolinea che gli asset di avvio fanno parte della build pipeline e non sono un elemento secondario. La sua documentazione consiglia un PNG quadrato 1024×1024 per le icone dell'app e specifica che EAS Build può generare le dimensioni richieste per i progetti creati con npx create-expo-app, che dimostra come la generazione di asset sia passata a tool moderni invece che alla ripetizione manuale.
Errori comuni con gli asset
I fallimenti visivi più comuni sono prevedibili:
| Problema | Causa probabile | Approccio migliore |
|---|---|---|
| Logo sfocato | Esportato da un raster a bassa risoluzione | Re-esportazione da sorgente vettoriale |
| Bordi tagliati | Grafica troppo vicina ai bordi | Aumentare il safe padding |
| Stretching | Immagine a tutto schermo forzata in vari aspect ratio | Usa un colore di sfondo e un'immagine centrata |
| Transizione incoerente | Lo sfondo della splash differisce dalla prima schermata | Allinea i colori della splash e dell'app shell |
Una splash image non dovrebbe contenere testi densi, dettagli minuscoli o copy di marketing. Le launch screen vengono visualizzate brevemente e renderizzate con vincoli nativi stringenti.
Per i team che rilasciano frequenti aggiornamenti visivi, la disciplina nelle immagini è fondamentale. Le stesse abitudini si applicano ai bundle e alla dimensione del binario, ecco perché guide come ottimizzare le immagini per gli update meritano una revisione quando standardizzi l'export degli asset.
Un workflow pratico per l'export
Una configurazione che funziona bene nei progetti reali è questa:
- Crea una composizione centrata su uno sfondo uniforme.
- Esporta un logo PNG trasparente se il tuo workflow supporta un colore di sfondo separato.
- Mantieni una nomenclatura coerente tra le piattaforme per evitare errori nel cambio degli asset.
- Testa subito su simulatori piccoli e lunghi before wiring the splash lifecycle.
- Ricostruisci dopo ogni modifica agli asset perché le risorse di avvio spesso risiedono in cache native.
L'ultimo punto è più importante di quanto si pensi. Molti problemi della splash screen che sembrano bug di configurazione sono solo asset nativi obsoleti.
Splash screen di Expo (expo-splash-screen)
If you are searching for splash screen di expo o splash screen in react native expo, inizia con il expo-splash-screen package. È ideale per workflow managed e prebuild, mantiene gli asset di lancio nel config ed espone API JavaScript per controllarne la visibilità nelle build store.
Il comportamento chiave è molto semplice. Mantieni la splash screen nativa visibile finché il primo frame UI significativo non è pronto. La documentazione di Expo preventAutoHideAsync() così la splash configurata resta attiva finché non chiami hideAsync(). Chiama preventAutoHideAsync() nello scope globale senza usare await, non dentro un hook, altrimenti la splash potrebbe nascondersi prima dell'esecuzione di code. Nasconderla troppo presto può mostrare brevemente uno schermo bianco su iOS e Android.
Mantenere la splash attiva durante il caricamento (Expo)
Questo è il classico schermata di caricamento in React Native : la splash nativa copre il caricamento dei font, l'autenticazione persistente e la remote config mentre React ritorna null. Quando isReady diventa true, chiama hideAsync(). Opzionalmente, SplashScreen.setOptions() adjusts fade behavior on hide. Test splash assets in a client di sviluppo, Anteprima, o produzione build; la documentazione di Expo che Expo Go non è l'ambiente di riferimento per la configurazione della splash screen nativa.
Configura la splash screen nativa in modo dichiarativo
In un progetto Expo, la parte visiva di solito si trova in app.json, app.config.js, o app.config.ts sotto il expo-splash-screen configura il plugin, come descritto nella guida di Expo su splash screen e app icon.
Un tipico app.json il setup è questo:
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}I campi esatti possono variare in base al progetto, ma lo schema è lo stesso. Definisci l'aspetto del lancio nativo nella config, poi controlli la visibilità da JavaScript.
Alcune scelte pratiche sono fondamentali:
- Usa un colore di sfondo simile alla prima schermata per rendere la transizione fluida.
- Mantieni l'immagine semplice perché le schermate di avvio non sono il posto per artwork complessi.
- Evita ritardi di branding artificiali che bloccano l'utente sul logo quando l'app è già pronta.
Nascondi la splash in base alla prontezza, non al tempo
Molti tutorial spesso sbagliano strada. Usano setTimeout, che è facile da testare ma sbagliato per la produzione.
Usa invece lo stato di avvio. Un pattern comune a livello di root è questo:
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>
);
}Due dettagli rendono questo pattern affidabile.
Primo, preventAutoHideAsync() viene chiamato prima che l'app inizi a renderizzare la UI. Secondo, la scomparsa avviene solo quando la root view è pronta per il layout, riducendo il rischio di flash tra la splash nativa e l'albero React.
Non nascondere la splash quando i tuoi task async stanno finendo. Nascondila quando la UI che dipende da quei task può effettivamente renderizzare.
Questa distinzione è fondamentale quando l'avvio include il ripristino dell'auth, la configurazione remota o il caricamento dei font. Se la home dipende da font custom e dallo stato di login, la splash deve coprire questo intervallo.
Qui sotto trovi una guida utile sull'ecosistema di landing e startup di React Native:
Cosa aspettarsi in Expo Go e nei dev builds
Expo aggiunge un ulteriore complicazione. Il comportamento della splash che ti aspetti in una build standalone potrebbe non corrispondere a quello che vedi in Expo Go.
Questa discrepanza confonde molti team. Modifichi l'asset o la logica temporale, testi in Expo Go e concludi che la configurazione è errata, quando il problema reale è che l'ambiente di sviluppo non si comporta come un binario di produzione.
Usa questo modello mentale:
- Expo Go è comodo per iterare ma non è il riferimento per il comportamento della splash screen nativa.
- I development client sono più vicini alla realtà perché includono il tuo progetto nativo generato.
- Le standalone build sono il controllo finale per i tempi di avvio, il tema e la correttezza degli asset.
Se la splash screen lampeggia o resta troppo a lungo, il bug è solitamente uno di questi tre: si nasconde troppo presto, viene renderizzata null per troppo tempo dopo la chiusura, o testando in un ambiente che non rispecchia il comportamento della release.
Splash screen CLI in React Native bare
Un'app React Native bare ti dà il controllo diretto sul comportamento di avvio. Per nuovi progetti bare CLI, react-native-bootsplash è l'opzione supportata (release attive fino al 2026 e in linea con la policy di supporto di React Native). Molte app in produzione usano ancora react-native-splash-screen; consideralo come manutenzione legacy a meno che tu non sia già integrato.
Splash screen animato (React Native o Expo): iOS LaunchScreen.storyboard rimane statico. Android 12+ può mostrare una breve icona vettoriale animata nello splash di sistema, ma expo-splash-screen e la maggior parte dei setup CLI base usa ancora un PNG statico e sposta l'animazione nella prima schermata React (es. Lottie). Nascondi lo splash nativo al termine dell'avvio, poi anima lì. Vedi le performance delle animazioni nelle app Capacitor per mantenere la stessa disciplina di startup su un altro stack.
Nei progetti CLI, l'obiettivo del passaggio al nativo non cambia: mostrare subito la UI di lancio e nasconderla solo quando la UI principale è pronta.
Configurazione Android in un progetto bare
La configurazione della splash su Android si trova in più punti: risorse del tema, drawable, AndroidManifest.xml, e MainActivity. Questa frammentazione è il motivo per cui piccoli errori causano flash visibili.
Il flusso standard è piuttosto semplice:
- Genera gli asset della splash per le cartelle delle risorse Android che supporti.
- Definisci un tema di avvio con il colore di sfondo e lo splash drawable corretti.
- Applica quel tema alla launcher activity in
AndroidManifest.xml. - Inizializza la splash screen in
MainActivity. - Nascondila tramite JavaScript una volta completate le task di avvio che bloccano il primo render.
Un pattern MainActivity.kt semplificato spesso è questo:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}Lo snippet è volutamente generico perché la chiamata esatta dipende dalla libreria. L'integrazione nativa è solitamente la parte facile. Gli errori derivano spesso dalla gestione delle risorse e delle transizioni del tema.
Ecco i problemi Android che emergono in produzione:
- Mismatch del tema: Se il tema di lancio usa un colore di sfondo diverso dalla prima schermata dell'app, l'utente vedrà un flash durante il passaggio.
- Asset bucket errati: Android distorce o sfoca gli asset mancanti nelle cartelle di densità previste.
- Testare solo con Metro: Le modifiche alle risorse native richiedono solitamente un rebuild pulito. L'hot reload non valida il comportamento al lancio.
- Regole di lancio di Android 12: Le version più recenti di Android applicano il proprio comportamento splash, quindi le configurazioni custom devono rispettare tali vincoli della piattaforma.
- JS lento dopo l'hide: Se React nasconde lo splash prima che la root view possa renderizzare, gli utenti vedranno un frame vuoto invece di una transizione fluida.
L'ultimo punto è più importante dell'immagine stessa. I problemi di timing vengono solitamente percepiti come problemi di performance.
Configurazione iOS in un bare project
Su iOS, il centro di gravità è LaunchScreen.storyboard più un piccolo hook nativo in AppDelegate. La piattaforma si aspetta che la launch screen sia statica e leggera. Trattala come un'istantanea della struttura visiva della prima schermata, non come un mini onboarding flow.
Una configurazione affidabile è questa:
- Aggiungi gli asset all'asset catalog di Xcode.
- Configura
LaunchScreen.storyboardcon semplici constraints. - Mantieni il layout statico. Colore di sfondo, logo e margini di sicurezza di solito bastano.
- Aggiungi la chiamata nativa di bootstrap della libreria in
AppDelegate. - Nascondi la splash screen da JavaScript solo quando l'app è pronta per il rendering.
I team alle prime armi con iOS tendono a sovraccaricare lo storyboard. Spesso è un errore. Vincoli complessi, viste nidificate o tentativi di animare la launch screen rendono il setup difficile da mantenere e fragile su diversi dispositivi.
Una launch screen semplice è la scelta più sicura.
Un CLI bare ti offre più controllo sul passaggio di consegne
Questa è la differenza chiave tra Expo-managed e CLI bare. Expo offre un percorso più rapido verso un default corretto. Il bare ti dà la piena responsabilità della pipeline nativa di avvio.
Questo compromesso diventa utile quando l'avvio fa più del semplice caricamento di un bundle. App con ripristino auth, letture da storage criptato, inizializzazione nativa SDK custom o regole di white-labeling spesso richiedono quel controllo extra. I progetti bare ti permettono di sincronizzare il timing della splash con quel lavoro, invece di forzare tutto tramite configurazioni di alto livello.
Se prevedi una transizione animata dopo il lancio, mantieni la splash nativa statica su iOS e preferisci un asset statico su Android, a meno che non configuri intenzionalmente l'icona animata di Android 12. Sposta il movimento nella prima schermata React. I compromessi sulle performance sono simili a quelli di ogni startup mobile. Carichi pesanti durante il primo paint sono costosi. Questo guida alle performance delle animazioni nelle app Capacitor copre lo stesso principio con un altro stack, e la lezione si applica bene anche a React Native.
Expo-managed vs bare CLI
Il confronto pratico riguarda meno la visualizzazione delle immagini e più dove risiede la complessità dell'avvio.
| Criterio di decisione | Gestito con Expo | Solo CLI |
|---|---|---|
| Velocità di setup | Setup iniziale più rapido | Più lavoro nativo |
| Personalizzazione nativa | Più limitato | Controllo totale |
| Flusso di generazione asset | Più dichiarativo | Più manuale |
| Superficie di debugging | Config JS più layer nativo generato | File Android e iOS diretti |
| Consigliato | Team che puntano a velocità e coerenza | Team che necessitano di controllo nativo profondo |
Se l'app è già in Expo e i requisiti di avvio sono standard, restare lì solitamente fa risparmiare tempo. Se il percorso di startup dipende dall'ordine di inizializzazione nativa, temi custom o logica di boot specifica per piattaforma, un approccio bare CLI è spesso la scelta più pulita a lungo termine.
Entrambi i workflow permettono di rilasciare una splash screen rifinita. La differenza sta in chi gestisce la pipeline di avvio: il tuo framework o il tuo team.
Tecniche avanzate per splash screen animate e performanti
Le splash screen animate risultano curate quando rispettano la pipeline di avvio. Sembrano scadenti quando distolgono l'attenzione da essa.
Per questo tratto l'animazione come uno strato di miglioramento, non come la base. Il compito principale resta il timing. Se l'app non è pronta, la splash resta. Se l'app è pronta, la transizione deve passare rapidamente alla prima schermata utilizzabile.
L'animazione deve seguire la realtà della startup
Un pattern comune è mantenere semplice la splash nativa, per poi eseguire un'animazione brandizzata leggera nella prima schermata React dopo il lancio. Questo offre più flessibilità rispetto al tentativo di animare direttamente la superficie di lancio nativa.
Lottie è una scelta pratica per questo tipo di handoff, perché permette di gestire il movimento senza dover costruire uno stack di animazione custom pesante nella prima schermata. La parte importante è il sequencing:
- La splash nativa resta visibile durante le operazioni critiche di startup.
- React monta la prima schermata reale o una schermata di transizione controllata.
- L'animazione opzionale viene riprodotta solo se non blocca l'interazione più del necessario.
Quello che non funziona è il vecchio setTimeout(2000) pattern. Su un dispositivo veloce, costringe l'app ad attendere senza motivo. Su un dispositivo lento, spesso sostituisce solo uno stato di caricamento con un altro.
Considera l'avvio come un'orchestrazione
Un modello mentale migliore è l'orchestrazione dell'avvio. La splash screen dovrebbe coprire esattamente i task che devono completarsi prima che l'app mostri contenuti rilevanti.
Di solito questo include un mix di:
- Bootstrap dell'auth: Ripristino di una sessione o scelta se reindirizzare al sign-in.
- Letture essenziali dallo storage: Tema, locale, stato dell'onboarding e preferenze critiche note più recenti.
- Disponibilità dei font: Soprattutto se la prima schermata dipende da una tipografia custom per la stabilità del layout.
- Remote config che condiziona la UI: Solo se la prima schermata non può essere renderizzata in sicurezza senza di essa.
C'è un'altra sfumatura che molti tutorial trascurano. Il comportamento della splash screen cambia a seconda dell'ambiente. Il discussione sulla gestione della splash screen in Expo in sviluppo e produzione evidenzia come il comportamento possa differire tra Expo Go e le build standalone, e come la gestione automatica della visibilità cambi quando si prende il controllo manuale. È per questo che gli esempi basati su delay invecchiano male: nascondono la reale sequenza di avvio invece di allinearsi ad essa.
Una splash screen non dovrebbe servire a simulare velocità. Dovrebbe servire a evitare che gli utenti vedano interfacce incomplete.
Se stai aggiungendo animazioni in uno stack ibrido o valutando le prestazioni di rendering generali, questa guida alle performance delle animazioni nelle app Capacitor fornisce un contesto utile, perché la disciplina è la stessa. Mantieni l'avvio leggero, evita blocchi non necessari e lascia che le animazioni supportino la reattività invece di competere con essa.
Una nota pratica per i team che rilasciano fix visivi senza nuove release binarie: piattaforme come Capgo gestiscono aggiornamenti di JavaScript, CSS, copy, config e asset per app Capacitor ed Electron, ma le modifiche alla splash screen nativa in React Native passano ancora dalla pipeline di build nativa, perché la vera splash screen appare prima che l'app JavaScript sia in esecuzione.
React Native vs Capacitor: Splash Screen e rilascio dei fix
Se stai leggendo questo perché stai iniziando una nuova app, o perché il tuo team ha già una web app in React, Vue, Angular o Svelte, vale la pena confrontare come funzionano le splash screen in Capacitor. Il concetto di splash screen nativo è lo stesso, ma il workflow quotidiano è più semplice per i team web.
Splash screen in Capacitor
Le app Capacitor usano l'ufficiale @capacitor/splash-screen plugin. Lo configuri una volta in capacitor.config.ts e lo nascondi dal tuo code web quando l'app è pronta:
// 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 regola di prontezza di questa guida è identica: mantieni la splash nativa statica, nascondila quando la prima schermata reale può essere renderizzata ed esegui ogni animazione nella prima schermata della tua app. Per gli asset nativi, @capacitor/assets genera i file icon e splash per Android e iOS dalle tue immagini sorgente (ad esempio icon-only.png e splash.png in un assets ). Il flusso passo dopo passo è trattato in inizializzazione dell'app Capacitor.
Perché i team web scelgono Capacitor rispetto a React Native
- Riutilizza l'app che già possiedi: Capacitor avvolge la tua web app esistente in una shell nativa, così i tuoi componenti, CSS e build tooling continuano a funzionare. React Native richiede invece di riscrivere la UI con componenti React Native.
- Qualsiasi framework: React, Vue, Angular, Svelte o semplice JavaScript: funzionano tutti. Non sei vincolato a React.
- Accesso nativo quando serve: i plugin ufficiali e della community coprono fotocamera, push, biometria e altro; puoi anche scrivere il tuo plugin in Swift o Kotlin.
- Live updates per lo strato app: con Capgopubblichi fix di JavaScript, HTML, CSS e asset agli utenti al prossimo avvio, con canali, rollout graduali e rollback con un click, senza attendere la revisione degli store per ogni modifica al web layer. Le modifiche native, incluso lo splash screen nativo, passano comunque tramite gli store. Vedi la documentazione live updates di Capgo.
Per un confronto completo su performance, tooling e adeguatezza del team, leggi React Native vs Capacitor: il confronto. Se oggi usi Expo e stai valutando un passaggio, Alternative a Expo esamina le varie opzioni.
Risoluzione dei problemi comuni con la Splash Screen
La maggior parte dei problemi con la splash screen rientra in poche categorie ricorrenti. Risolvere diventa più semplice se separi i problemi di asset, i problemi di timing, e i problemi di integrazione nativa.
I pattern della community nelle recenti guide di React Native convergono sullo stesso flusso principale: aggiungi la libreria, configura gli asset nativi di avvio, chiama show durante l'avvio, e nascondila quando l'app è pronta. Le configurazioni Android solitamente prevedono MainActivity anche risorse XML o drawable, mentre iOS si concentra su LaunchScreen.storyboard e AppDelegate. La stessa panoramica fa notare che Expo raccomanda un'immagine quadrata in PNG 1024×1024 per le icone dell'app e che EAS Build può generare le dimensioni richieste per i progetti creati con npx create-expo-app, come sintetizzato in questa guida alla splash screen in React Native.
Immagine splash distorta o sfocata
Sintomo: Il logo appare sfuocato, ritagliato o ridimensionato in modo strano.
Causa: L'immagine di base non è stata esportata correttamente, oppure il layout dipende da un raster a tutto schermo che non si adatta bene.
Soluzione: Sostituisci la grafica in stile poster con un logo centrato su uno sfondo uniforme. Riesporta dal file di design originale, rigenera gli asset specifici per densità e verifica che i drawable di Android o l'asset catalog di iOS contengano i file corretti.
Schermata bianca dopo che la splash screen scompare
Sintomo: La splash nativa scompare, poi gli utenti vedono un frame vuoto prima della prima schermata.
Causa: L'app nasconde la splash screen prima che la UI principale possa renderizzare contenuti significativi.
Soluzione: Collega la chiusura della splash alla prontezza dell'app, non al tempo trascorso. In Expo, di solito significa mantenere la splash finché la root view non è pronta per il layout. Nei progetti bare, usa un pattern equivalente e assicurati che la prima schermata renderizzata non rimanga bloccata da ulteriori operazioni async.
Splash screen mancante su una piattaforma
Sintomo: Android la mostra, iOS no, o viceversa.
Causa: Una parte nativa non era configurata correttamente. Spesso si tratta di un riferimento a un storyboard dimenticato, un problema di collegamento del tema o un asset non aggiunto al target corretto.
Soluzione: Controlla i file specifici per piattaforma uno per uno. Su Android, ispeziona il launch theme e i riferimenti alle risorse. Su iOS, conferma LaunchScreen.storyboard, l'appartenenza all'asset catalog e le impostazioni del target dell'app in Xcode.
Il build fallisce dopo l'aggiunta della configurazione splash
Sintomo: L'app ha smesso di compilare dopo aver introdotto una libreria o modificato i file splash.
Causa: I file del progetto nativo e la configurazione generata possono andare fuori sincrono, specialmente dopo modifiche a plugin o asset.
Soluzione: Pulisci la build, reinstalla le dipendenze se necessario e ricostruisci completamente il progetto nativo. Se usi Expo con layer nativi generati, rigenerali con attenzione e verifica la config dei plugin. Se hai un'app bare, controlla MainActivity, AppDelegate, i nomi delle risorse e ogni modifica a plist o manifest per eventuali piccoli mismatch.
I team più veloci trattano la splash screen come parte della release engineering, non come un semplice compito visivo una tantum. Questo conta ancora di più quando asset di startup, testi UI o il comportamento dell'app-shell devono cambiare rapidamente dopo il lancio. Capgo permette ai team Capacitor ed Electron di distribuire fix a JavaScript, CSS, testi, config e asset al prossimo avvio, con controlli di rollout e supporto al rollback, utile quando il problema è nel layer app piuttosto che nella splash screen nativa.
Frequently asked questions
Come aggiungo una splash screen in Expo (expo splash screen)?
Aggiungi la expo-splash-screen plugin per app.json o app.config.js, imposta backgroundColor e image, ricostruire un binario nativo, chiamare preventAutoHideAsync() nello scope globale, e hideAsync() quando la prima schermata è pronta. Verifica in un dev client o in una Native Build, non solo con Expo Go.
Come posso mantenere visibile la splash screen mentre la mia app React Native si carica?
In Expo, preventAutoHideAsync() oltre a restituire null fino al completamento dei task async, quindi hideAsync(). Con react-native-splash-screen, chiama SplashScreen.show(this) su Android MainActivity o [RNSplashScreen show] su iOS AppDelegate, poi SplashScreen.hide() da JavaScript quando è pronto. Con react-native-bootsplash, inizializza nativamente per piattaforma, poi chiama BootSplash.hide() dopo lo stesso controllo di disponibilità.
Qual è la differenza tra react-native-splash-screen e react-native-bootsplash?
Bootsplash è attivamente mantenuto e include un generatore per gli asset di avvio. react-native-splash-screen è ancora comune nei vecchi repo ma ha un mantenimento più lento; preferisci bootsplash per nuove app CLI bare.
Come configuro una splash screen su React Native bare senza Expo?
Installa react-native-bootsplash, genera gli asset e chiama RNBootSplash.init(this, R.style.BootTheme) su Android o RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) su iOS, quindi BootSplash.hide() da JS al termine dell'avvio. I progetti legacy potrebbero usare SplashScreen.show(this) / [RNSplashScreen show] con SplashScreen.hide() invece. Ricompila dopo modifiche agli asset nativi.
Posso usare una splash screen animata in React Native o Expo?
Su iOS, mantieni la launch screen statica. Su Android 12+, la splash di sistema può usare un'icona animata breve, ma la maggior parte dei team preferisce expo-splash-screen o gli asset bootsplash statici, li nasconde quando è pronto e poi anima in React (es. Lottie). Non affidarti a setTimeout per simulare il tempo di caricamento.
In cosa differisce la configurazione della splash screen tra React Native e Capacitor?
React Native utilizza expo-splash-screen o librerie CLI bare prima dell'esecuzione di JS. Capacitor usa le native launch screens più @capacitor/splash-screen nello stack WebView. Vedi React Native vs Capacitor: il confronto e l'inizializzazione dell'app Capacitor.
Pubblica la tua app Capacitor più velocemente con Capgo
Stai sviluppando con Capacitor o vuoi portare un'app web su mobile? Crea un account Capgo gratuito e pubblica il tuo primo live update in pochi minuti. Capgo porta correzioni JavaScript, CSS e asset ai tuoi utenti al prossimo avvio, con rollout graduali e rollback istantaneo, così un bug nel layer dell'app non deve mai aspettare la revisione degli store.
Continua la lettura: React Native Splash Screen (Expo e CLI bare)
Se stai usando questa guida per pianificare il comportamento dei media nativi e dell'interfaccia, collegalo a Uso di @capgo/capacitor-live-activities per la funzionalità nativa nella pagina Uso di @capgo/capacitor-live-activities, @capgo/capacitor-live-activities per il dettaglio implementativo in @capgo/capacitor-live-activities, Uso di @capgo/capacitor-video-player per la funzionalità nativa in Utilizzo di @capgo/capacitor-video-player, @capgo/capacitor-video-player per i dettagli di implementazione in @capgo/capacitor-video-player, e Usando @capgo/capacitor-native-navigation per la funzionalità nativa in Usando @capgo/capacitor-native-navigation.
