Schermo di benvenuto in React Native: una guida completa per il 2026

Selezioni l'icona del tuo app su un dispositivo reale e, per un secondo, l'utente vede un flash bianco, un logo allungato o uno schermo di avvio congelato che scompare prima che qualcosa di utile sia pronto. È proprio in quel momento che un'app React Native smette di sentirsi di produzione.

Un buon schermo di avvio in React Native risolve più di una questione di branding. Copre la lacuna tra l'avvio nativo e il primo frame React significativo. Inoltre, ti costringe a pensare chiaramente all'ordine di avvio, alla preparazione degli asset e alla differenza tra cosa accade in Expo Go, un client di sviluppo, e una build reale. Se sbagli il timing, gli utenti vedono i crack immediatamente.

Elenco dei Contenuti

• Perché un Schermo di Avvio Professionale è Importante
  • Cosa sta effettivamente facendo lo schermo di avvio
• Preparare gli Asset dello Schermo di Avvio Perfetti
  • Cosa preparare prima di iniziare a codificare
  • Errori comuni sugli asset
  • Flusso di lavoro di esportazione pratico
• Implementare con il Flusso di Lavoro di Expo Go e Client di Sviluppo
  • Configura lo schermo di avvio nativo in modo dichiarativo
  • Nascondi lo splash in base alla prontezza, non al tempo
  • Cosa aspettarsi in Expo Go e build dev
• Configurazione per progetti React Native Bare CLI
  • Configurazione Android in un progetto Bare
  • Configurazione iOS in un progetto Bare
  • Bare CLI ti dà più controllo sulla gestione del passaggio
  • CLI gestito da Expo contro Bare CLI
• Tecniche avanzate per schermate di splash animate e performanti
  • L'animazione dovrebbe seguire la realtà di avvio
  • Trattare l'avvio come orchestratura
• Risoluzione dei problemi comuni per le schermate di splash
  • Immagine di splash allungata o sfocata
  • Schermo bianco dopo la schermata di benvenuto nasconde
  • Schermata di benvenuto mancante su una piattaforma
  • Il build si interrompe dopo l'aggiunta della configurazione della schermata di benvenuto

Perché una schermata di benvenuto professionale è importante

Un utente tocca la tua app dalla schermata principale e la sequenza di avvio mostra un riquadro bianco vuoto prima che la prima interfaccia utente venga visualizzata. In produzione, questo si legge come instabilità. Non importa che React Native stia ancora caricando il bundle JavaScript o ripristinando lo stato in background. L'impressione iniziale è già sbagliata.

In React Native, la schermata di benvenuto è la prima superficie nativa che il tuo app controlla. Copre il passaggio tra l'avvio del processo e la prima frame React visualizzata. Ciò la rende uno strumento di avvio, non solo un bene di marketing. Se la sincronizzi bene, gli utenti vedono un avvio stabile che sembra intenzionale. Se la nascondi troppo presto, vedono shift di layout, caratteri mancanti o uno schermo morto mentre l'autenticazione, la navigazione o la configurazione remota si aggiorna.

Cosa sta effettivamente facendo la schermata di benvenuto

Una schermata di benvenuto di produzione solitamente deve gestire quattro preoccupazioni di avvio:

• Coprire il lavoro di avvio nativo-JS: Caricamento di caratteri, ripristino della sessione persistente, lettura di flag di feature e stato di navigazione iniziale competono per la prima frame.
• Prevenire glitch visivi: evita flash di colore bianco del sistema, testo non stile, o una vista root parzialmente caricata.
• Mantieni l'aspetto di lancio coerente: il colore di sfondo e il logo possono corrispondere alla shell dell'app per rendere la transizione controllata.
• Forza le decisioni di avvio: le squadre devono definire cosa significa “pronto” prima di rimuovere lo schermo di lancio.

Regola pratica: Nascondi lo splash quando la prima schermata reale può renderizzare in modo pulito, non dopo un ritardo arbitrario.

This is also where the Expo-managed and bare CLI workflows start to diverge. In Expo-managed projects, splash setup is mostly declarative, and the main engineering decision is when to call the hide API based on app readiness. In bare React Native CLI projects, you own more native setup on Android and iOS, which gives you more control but also more ways to introduce launch flicker, theme mismatches, or platform-specific regressions.

Quel trade-off conta nei progetti reali. Expo è più veloce da configurare e più facile da mantenere coerente across ambienti. I progetti nudi sono spesso la scelta giusta quando l'app già dipende da moduli nativi personalizzati, comportamento di lancio personalizzato o controllo più stretto sulla via di avvio.

Le squadre che trattano il lancio come parte della qualità del prodotto lo valutano insieme al lavoro di UX più ampio, non come un compito nativo isolato. È lo stesso mindset coperto nella guida di Capgo all'esperienza dell'utente dell'app. Se si sta anche valutando la pila React Native più ampia per un nuovo progetto o migrazione, Soluzioni Nerdify per app React Native fornisce un'utile panoramica focalizzata sulla produzione.

Preparazione di Asset di Splash Screen Perfetti

La maggior parte dei bug di splash screen iniziano nei file di progettazione, non code. Se l'asset base è sbagliato, nessuna quantità di pulizia di Android XML o iOS storyboard può salvarlo.

L'approccio più sicuro è trattare lo splash come un sistema di layout, non un'unica immagine a schermo intero. Utilizzare un colore di sfondo più un logo o un'illustrazione centrati. Ciò si scalda in modo più prevedibile su dispositivi Android alti, iPhone, tablet e orientamenti di dispositivo più ampi rispetto a provare a inserire un'unica immagine poster-stile dettagliata in ogni posto.

Cosa preparare prima di codificare

Inizia con un file di origine pulito dalla progettazione. Il vettore è ideale per il passaggio, anche se l'asset di lancio esportato è un PNG.

Utilizza questo elenco di controllo:

• Artefatto di origine: Conserva un logo o marchio master in SVG, AI o un altro formato di origine modificabile per garantire che le esportazioni rimangano coerenti.
• Colore di sfondo: Definisci il colore di sfondo esatto della schermata di avvio in anticipo e assicurati che corrisponda al colore di sfondo della prima schermata o della shell dell'app.
• Marginali sicuri: Lascia abbastanza spazio vuoto intorno al logo per evitare che la riduzione aggressiva su rapporti di aspetto insoliti tagli nel disegno.
• Varianti di piattaforma: Esporta le dimensioni dell'immagine che il tuo workflow richiede, piuttosto che allungare un file in ogni dove.
• Recensione del dark mode: Se il tuo app supporta superfici scure, conferma che il logo legge ancora chiaramente contro il background scelto.

La guida di Expo è utile qui perché rafforza il fatto che gli asset di lancio sono ora parte della pipeline di costruzione, non un dopo pensiero. I suoi documenti raccomandano un immagine quadrata 1024×1024 PNG per gli iconi dell'app e notano che EAS Build può generare le dimensioni richieste per i progetti creati con npx create-expo-appche mostra come la generazione degli asset si è spostata in strumenti moderni piuttosto che nella ripetizione manuale.

Errori comuni degli asset

I fallimenti visivi più comuni sono prevedibili:

Una immagine di splash non dovrebbe contenere testo denso, dettagli minimi o copia di marketing. Le schermate di lancio vengono visualizzate brevemente e vengono renderizzate sotto stretti vincoli nativi.

Per le squadre che inviano aggiornamenti visivi frequenti, la disciplina delle immagini è importante al di là del lancio. Le stesse abitudini si applicano ai pacchetti di consegna e al peso binario, il che spiega perché guide come ottimizzare le immagini per gli aggiornamenti siano da considerare quando si standardizzano le esportazioni di asset.

Un flusso di lavoro di esportazione pratico

Un setup che funziona bene nei progetti reali assomiglia a questo:

1. Progettare una composizione centrata su un fondo piano.
2. Esportare un logo PNG trasparente se il tuo workflow supporta un colore di sfondo separato.
3. Mantieni coerente il nome all'interno delle piattaforme per evitare che le sostituzioni degli asset diventino un problema da risolvere.
4. Testare sui simulatori piccoli e alti fin da subito prima di collegare il ciclo di vita dello splash.
5. Riavviare dopo le modifiche agli asset perché i risorse di lancio spesso si trovano in cache native.

Quel punto è più importante di quanto le persone si aspettino. Molti problemi di schermo di avvio che sembrano essere bug di configurazione sono solo asset native invecchiati.

Implementare con il workflow di Expo Go e del Client di sviluppo

If sei stai utilizzando Expo, inizia con expo-splash-screenE si adatta alla gestione del workflow, mantiene la maggior parte della configurazione dichiarativa e ti dà un controllo esplicito sul momento in cui il splash dovrebbe lasciare.

Il comportamento chiave da comprendere è semplice. Tieni il splash nativo visibile fino a quando non è pronto il primo frame UI significativo. Expo's SplashScreen API supporta esattamente quel modello con preventAutoHideAsync() a partenza e hideAsync() una volta terminata la carica critica, e Expo avverte che nascondere troppo presto può esporre brevemente uno schermo vuoto in entrambe le build iOS e Android, come documentato nel schermo di splash Expo API.

Configura il splash nativo dichiarativamente

In un progetto Expo, la parte visiva vive di solito in app.json o app.config.js.

Un setup tipico app.json Il setup esatto può variare a seconda della configurazione del progetto, ma il pattern rimane lo stesso. Definisci l'aspetto di lancio nativo nella configurazione, quindi controlla la visibilità dal JavaScript.

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

Un paio di scelte pratiche contano qui:

Utilizza un colore di sfondo vicino allo schermo iniziale

• affinché la transizione si senta continua. Tieni l'immagine semplice
• perché le superfici di lancio non sono il posto per l'arte densa. Evita i ritardi "di branding fittizi"
• che tengono gli utenti su un logo quando l'app è già pronta. Nascondi lo splash in base alla prontezza, non al tempo

__CAPGO_KEEP_0__

Molti tutorial spesso si allontanano dal percorso. Utilizzano setTimeout, che è facile da dimostrare e sbagliato per la produzione.

Usa lo stato di avvio invece. Un modello di base comune assomiglia a 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 modello affidabile.

Innanzitutto preventAutoHideAsync() viene chiamato prima che l'app inizi a renderizzare l'interfaccia utente significativa. In secondo luogo, il nascondimento avviene solo dopo che la vista radice è pronta per disporre gli elementi, il che riduce la possibilità di un flash tra lo schermo di benvenuto nativo e l'albero React.

Non nascondere lo schermo di benvenuto quando il tuo lavoro asincrono inizia a completarsi. Nascondilo quando l'interfaccia utente che dipende da quel lavoro può effettivamente renderizzarsi.

Questa distinzione è più importante quando lo stato di avvio include la restaurazione dell'autenticazione, la configurazione remota o il caricamento di font. Se la schermata iniziale dipende da font personalizzati e uno stato di accesso firmato, lo schermo di benvenuto dovrebbe coprire quel divario.

Un utile walkthrough dell'ecosistema React Native più ampio e di avvio è riportato di seguito:

Cosa aspettarsi in Expo Go e build di sviluppo

Expo aggiunge un ulteriore intreccio. Il comportamento dello schermo di benvenuto che si aspetta in un build autonomo potrebbe non corrispondere a quello che si vede in Expo Go.

Questa dissonanza confonde molti team. Cambi l'asset o la logica di timing, testa in Expo Go e conclude che la configurazione è rotta 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 l'iterazione ma non è l'autorità finale sul comportamento dello splash nativo.
• I client di sviluppo sono più vicini alla realtà perché includono il tuo progetto nativo generato.
• I build standalone sono il controllo finale per il timing di lancio, il comportamento del tema e la correttezza degli asset.

Se il tuo splash ancora lampeggia o persiste, il bug è di solito uno dei tre cose: nascondere troppo presto, rendere null per troppo tempo dopo nascondere, o testare in un ambiente che non riflette il comportamento di rilascio.

Configurazione per Progetti React Native Bare CLI

Un'app React Native bare ti dà il controllo diretto sul comportamento di lancio, che è utile una volta che lo splash screen deve corrispondere al lavoro di avvio reale invece di mostrare un logo per un ritardo fissato. Quel controllo comporta la responsabilità nativa. Devi collegare Android e iOS correttamente, ricostruire spesso e testare il passaggio tra l'interfaccia di lancio nativa e la prima schermata React su dispositivi reali.

In CLI progetti, raccomando di solito react-native-bootsplash For nuove attività. Si adatta meglio ai progetti React Native correnti rispetto alle librerie splash più vecchie, e la configurazione nativa è più facile da ragionare durante gli aggiornamenti. Gli app più vecchi ancora inviano con react-native-splash-screen, quindi incontrerai questo durante il lavoro di manutenzione, ma per una configurazione fresca lo scopo rimane lo stesso. Mostra una superficie di avvio nativa immediatamente, poi nascondila solo dopo che l'app può renderizzare l'UI significativa.

Configurazione Android in un progetto nudo

La configurazione della schermata di avvio Android vive in più posti allo stesso tempo: risorse di tema, disegni, e AndroidManifest.xml, e MainActivity. Quel divario è il motivo per cui piccoli errori creano lampi visibili.

Il flusso usuale è lineare:

1. Genera asset di schermata di avvio per i cartelle di risorse Android che supporti.
2. Definisci un tema di avvio con il colore di sfondo corretto e il disegno di schermata.
3. Applica quel tema all'attività di lancio in AndroidManifest.xml.
4. Inizializza la schermata di avvio in MainActivity.
5. Nascondilo dopo le attività di avvio che bloccano la prima renderizzazione.

Un modello semplificato MainActivity.kt spesso assomiglia a questo:

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

Quel frammento è intenzionalmente generico perché la chiamata esatta dipende dalla libreria. Il punto di integrazione nativo è di solito la parte facile. Gli errori tendono a venire dai risorse e dalle transizioni di tema.

Ecco gli errori Android che si verificano in produzione:

• Mancanza di tema: Se il tema di lancio utilizza un colore di sfondo diverso dalla prima schermata dell'app, gli utenti vedono un lampo durante il passaggio di consegne.
• Buste di asset errate: Android allungherà o sfocerà gli asset che mancano dalle cartelle di densità previste.
• Testare con Metro solo: Le modifiche alle risorse native richiedono di solito una ricostruzione pulita. La ricarica calda non valuterà il comportamento di lancio.
• Regole di lancio Android 12: Le versioni Android più recenti applicano il loro comportamento di schermo di benvenuto prima, quindi i settaggi personalizzati devono rispettare quelle restrizioni della piattaforma.
• JS lento dopo nascondere: Se React nasconde lo schermo di benvenuto prima che la vista radice possa dipingere, gli utenti ottengono un riquadro vuoto invece di una transizione liscia.

Quel punto conta più dell'immagine stessa. I problemi di timing sono solitamente percepiti come problemi di prestazioni.

Configurazione iOS in un progetto nudo

Sul iOS, il centro di gravità è LaunchScreen.storyboard più un piccolo hook nativo in AppDelegateLa piattaforma aspetta che lo schermo di benvenuto sia statico e leggero. Trattalo come una snapshot della struttura visiva della prima schermata, non come un mini flusso di onboarding.

La configurazione affidabile assomiglia a questo:

• Aggiungi risorse al catalogo di asset di Xcode.
• Configura LaunchScreen.storyboard con vincoli semplici.
• Conserva la struttura statica. Il colore di sfondo, il logo e lo spazio sicuro sono abbastanza sufficienti.
• Aggiungi il chiamata di avvio nativo della libreria in AppDelegate.
• Nascondi lo splash solo dal JavaScript dopo che l'app è completamente pronta per renderizzare.

I team nuovi a iOS spesso sovraccaricano la storyboard. Ciò di solito ha conseguenze negative. Le vincoli complessi, le viste multiple annidate o gli sforzi per animare lo schermo di lancio rendono la configurazione più difficile da mantenere e più facile da rompere su dimensioni di dispositivo.

Una schermata di lancio semplice è la scelta più sicura.

Un CLI nudo ti dà più controllo sulla consegna della mano.

Questa è la differenza chiave tra Expo-gestito e CLI nudo. Expo ti offre una via più veloce per un default corretto. CLI nudo ti dà la piena responsabilità del pipeline di avvio nativo.

Questo trade-off diventa utile quando l'avvio fa più che caricare un bundle. Le app con la restaurazione dell'autenticazione, le letture di archiviazione crittografata, l'inizializzazione nativa personalizzata di SDK o le regole di branding bianco-etichetta spesso hanno bisogno del controllo aggiuntivo. I progetti SDK consentono di allineare la sincronizzazione dello splash con questo lavoro anziché forzarlo attraverso una configurazione di livello superiore.

Se hai in programma di aggiungere una transizione animata dopo il lancio, conserva lo splash nativo statico e sposta la movimento nella prima schermata React. I trade-off di prestazioni sono simili a quelli che contano in qualsiasi percorso di avvio mobile. Lavoro pesante durante la prima pittura è costoso. Questa guida alle prestazioni dell'animazione nelle app Capacitor copre lo stesso principio da un'altra pila, e la lezione si applica pulitamente a React Native.

Esposizione gestita da Expo rispetto a CLI

La comparazione pratica è meno legata alla visualizzazione delle immagini e più alla complessità di avvio.

Se l'app è già in Expo e i requisiti di avvio sono standard, rimanere lì salva spesso tempo. Se il percorso di avvio dipende dall'ordine di inizializzazione nativa, temi personalizzati o logica di avvio specifica per piattaforma, il CLI nudo è spesso la scelta più pulita a lungo termine.

Entrambi i flussi di lavoro possono distribuire uno schermo di benvenuto liscio. La differenza è chi possiede la pipeline di avvio, il tuo framework o il tuo team.

Tecniche avanzate per schermi di benvenuto animati e performanti

Gli schermi di benvenuto animati sembrano lisci quando rispettano la pipeline di avvio. Sembrano a buon mercato quando distrae da essa.

That’s why I consider l’animazione come un layer di miglioramento, non la base. Il primo compito è ancora il timing. Se l'app non è pronta, il splash rimane. Se l'app è pronta, la transizione dovrebbe muoversi velocemente nella prima schermata utilizzabile.

L'animazione dovrebbe seguire la realtà di avvio

Un modello comune è mantenere lo splash nativo semplice, quindi eseguire un'animazione leggera personalizzata nella prima schermata React dopo l'avvio. Ciò ti dà più flessibilità rispetto a cercare di animare la vera superficie di avvio nativa stessa.

Lottie è una scelta pratica per questo tipo di handoff perché può fornire il movimento senza costruire un stack di animazione personalizzata pesante nella prima schermata. La parte importante è la sequenziazione:

• Lo splash nativo rimane visibile durante il lavoro critico di avvio.
• React monta la prima schermata reale o una schermata di transizione controllata.
• L'animazione facoltativa gioca solo se non blocca l'interazione per più tempo del necessario.

Cosa non funziona è il vecchio setTimeout(2000) modello. Su un dispositivo veloce, ciò fa attendere l'app senza motivo. Su un dispositivo lento, spesso sostituisce uno stato di caricamento con un altro.

Trovare l'avvio come orchestrazione

Un modello mentale migliore è l'orchestrazione di avvio. La schermata di benvenuto dovrebbe coprire le esatte attività che devono completarsi prima che l'app possa mostrare contenuti significativi.

Di solito ciò include una combinazione di:

• Auth bootstrap: Ripristino di una sessione o decisione di reindirizzare al login.
• Lettura di archivi di storage essenziali: Tema, localizzazione, stato di onboarding e preferenze critiche note.
• Prontezza delle fonti: Soprattutto se la prima schermata dipende da una tipografia personalizzata per la stabilità della disposizione.
• Configurazione remota che blocca l'interfaccia utente: Solo se la prima schermata non può renderizzarsi in modo sicuro senza di essa.

Ci sono un'altra sfumatura che molti tutorial trascurano. Il comportamento della schermata di benvenuto cambia a seconda dell'ambiente. La discussione del trattamento di Expo della schermata di benvenuto in fase di sviluppo e produzione rileva che il comportamento potrebbe non apparire lo stesso in Expo Go rispetto a quanto avviene nei build standalone, e che la gestione automatica della visibilità cambia non appena prendi il controllo manuale. È una delle ragioni per cui gli esempi basati sulla ritardata età male. Nascondono la sequenza di avvio reale anziché allinearsi con essa.

La schermata di lancio non dovrebbe essere utilizzata per simulare la velocità. Dovrebbe essere utilizzata per impedire agli utenti di vedere l'interfaccia utente non completata.

Se si sta aggiungendo movimento in una pila ibrida o si sta valutando la prestazione di rendering più ampia, questa guida alla prestazione dell'animazione negli app Capacitor è un contesto utile perché la stessa disciplina si applica. Mantieni il lavoro di avvio sottile, evita bloccaggi non necessari e lascia che l'animazione supporti la risposta dei sistemi anziché competere con essa.

Un nota pratica per i team che stanno inviando correzioni visive fuori dai rilasci binari completi: le piattaforme come Capgo gestiscono aggiornamenti JavaScript, CSS, copia, configurazione e asset per Capacitor e app Electron, ma le modifiche alla schermata di lancio native in React Native ancora appartengono al flusso di compilazione nativo perché la schermata di lancio vera appare prima dell'app JavaScript è in esecuzione.

I Problemi Comuni della Schermata di Lancio

La maggior parte dei problemi di schermata si inserisce in un piccolo insieme di trasgressori ripetuti. La soluzione diventa più facile non appena separi i problemi di asset, i problemi di timing, e problemi di integrazione native protetti.

I modelli di comunità nei recenti guide di React Native si sono concentrati sulla stessa sequenza di base: aggiungere la libreria, configurare gli asset di avvio nativi, chiamare show durante l'avvio, e nascondere una volta che l'app è pronta. Le impostazioni Android sono comuni e coinvolgono MainActivity o risorse XML o drawable, mentre iOS si concentra su LaunchScreen.storyboard e AppDelegate. Lo stesso riassunto nota che Expo raccomanda un quadrato 1024×1024 PNG per icone dell'app e che EAS Build può generare le dimensioni richieste per i progetti creati con npx create-expo-app, come riportato in questa guida di schermo di avvio di React Native.

Immagine di schermo di avvio allungata o sfocata

Sintomo: Il logo sembra morbido, tagliato o scalato in modo strano.

Causa: L'immagine base non è stata esportata correttamente, o la disposizione dipende da un raster a schermo intero che non si adatta bene.

Soluzione: Sostituisci l'arte di poster con un logo centrato su un fondo piatto. Esporta nuovamente dalla fonte di design originale, rigenera gli asset specifici per la densità e verifica che i tuoi disegni Android o il catalogo di asset iOS contengano i file desiderati.

Scherzo bianco dopo che il splash si nasconde

Sintomo: Il splash nativo scompare, poi gli utenti vedono una finestra vuota prima della prima schermata.

Causa: Il tuo app nasconde il splash prima che la UI di base possa renderizzare contenuto significativo.

Soluzione: Leggi la schermata di avvio alla disponibilità, non al tempo trascorso. In Expo, ciò significa spesso tenere la schermata di avvio fino a quando la tua vista radice non può disporre gli elementi. In progetti bare, utilizza il pattern equivalente e assicurati che la prima schermata visualizzata non blocchi immediatamente su più lavoro asincrono.

Schermata di avvio mancante su un piattaforma

Sintomo: L'Android la mostra, l'iOS no, o viceversa.

Causa: Una parte nativa non era stata configurata completamente. Spesso si tratta di una riferimento alla storia non ricordata, di un problema di connessione al tema o di un'asset non aggiunta al target corretto.

Soluzione: Controlla i file specifici per piattaforma uno per uno. Sull'Android, ispeziona il tema di avvio e le riferenze alle risorse. Sull'iOS, conferma la partecipazione all'elenco dei cataloghi di asset e le impostazioni del target dell'app in Xcode. LaunchScreen.storyboardIl build si interrompe dopo l'aggiunta della configurazione della schermata di avvio

Sintomo:

L'app non si è più compilata dopo l'introduzione di una libreria o la modifica dei file della schermata di avvio. __CAPGO_KEEP_0__

Causa: I file del progetto nativo e la configurazione generata possono diventare disallineati, soprattutto dopo modifiche di plugin o asset.

Soluzione: Pulisci la build, reinstalla le dipendenze se necessario e ricostruisci il progetto nativo in modo completo. Se sei in Expo con layer nativi generati, rigenera con cura e verifica la configurazione dei plugin. Se sei in un'app bare, revisiona MainActivity, AppDelegate, i nomi delle risorse e qualsiasi modifica ai file plist o manifest per piccole incoerenze.

Le squadre più veloci trattano lo schermo di benvenuto come parte dell'ingegneria di rilascio, non come un compito visivo occasionale. Ciò è ancora più importante quando gli asset di avvio, il testo dell'interfaccia utente o il comportamento dell'app-shell devono cambiare rapidamente dopo il lancio. Capgo dà alle squadre di Electron e Capacitor una possibilità di inviare modifiche JavaScript, CSS, copia, configurazione e asset con il prossimo lancio con controlli di rollout e supporto per il rollback, il che è utile quando il problema è nella layer dell'app piuttosto che nello schermo di avvio nativo stesso.

Continua da Splash Screen in React Native: Una Guida Completa per il 2026

Se stai utilizzando Splash Screen in React Native: Una Guida Completa per il 2026 per pianificare il comportamento dei media nativi e dell'interfaccia, connettilo con Utilizzando @capgo/capacitor-live-attività per la capacità nativa in Utilizzando @capgo/capacitor-live-attività @capgo/capacitor-live-attività per il dettaglio di implementazione in @capgo/capacitor-live-attività Utilizzando @capgo/capacitor-player-video per la capacità nativa in Utilizzando @capgo/capacitor-player-video @capgo/capacitor-player-video per il dettaglio di implementazione in @capgo/capacitor-player-video e Utilizzando @capgo/capacitor-navigazione-nativa per la capacità nativa in Utilizzando @capgo/capacitor-navigazione-nativa