React Native Splash Screen: Setup Expo dan Bare (2026)

Jawaban cepat: Gunakan expo-splash-screen dengan plugin config di app.json atau app.config.js ketika aplikasi berjalan di Expo (termasuk dev clients dan EAS builds). Panggil SplashScreen.preventAutoHideAsync() di scope global, lalu SplashScreen.hideAsync() ketika font, auth, dan navigation siap. Pada React Native CLI polos, lebih baik react-native-bootsplash untuk proyek baru; rawat aplikasi legacy dengan react-native-splash-screen sampai Anda migrasi. Jaga agar splash native statis, sembunyikan saat layar pertama yang nyata bisa dirender, dan pindahkan splash animasi branding ke layar React pertama. Membangun dengan teknologi web? Capacitor menggunakan @capacitor/splash-screen dengan aturan kesiapan yang sama, dan Capgo mengirimkan live update lapisan web tanpa build store. Aset splash native tetap membutuhkan binary baru.

Anda mengetuk ikon aplikasi di perangkat asli, dan selama sekejap pengguna melihat kilatan putih, logo yang teregang, atau layar launch yang membeku sebelum konten siap. Jeda inilah yang react native splash screen setup ini dirancang untuk menutupi: UI launch native hingga JavaScript dapat menampilkan frame pertama yang stabil.

Table of Contents

• Mengapa Splash Screen Profesional Penting
  • Apa yang sebenarnya dilakukan splash screen
• Menyiapkan Aset Splash Screen yang Sempurna
  • Persiapan sebelum coding
  • Kesalahan aset umum
  • Workflow ekspor yang praktis
• Implementasi dengan Expo Go dan Development Client Workflow
  • Konfigurasi splash screen native secara deklaratif
  • Sembunyikan splash berdasarkan kesiapan, bukan waktu
  • Yang bisa Anda harapkan di Expo Go dan dev builds
• Konfigurasi untuk proyek Bare React Native CLI
  • Setup Android di bare project
  • Setup iOS di bare project
  • Bare CLI memberi Anda kontrol lebih atas handoff
  • Expo-managed vs bare CLI
• Teknik Lanjutan untuk Splash Screen Animasi dan Berperforma Tinggi
  • Animasi harus mengikuti realitas startup
  • Anggap startup sebagai orkestrasi
• React Native vs Capacitor: Splash Screen dan Perbaikan Rilis
  • Splash screen di Capacitor
  • Mengapa tim web memilih Capacitor dibanding React Native
• Troubleshooting Masalah Umum Splash Screen
  • Gambar splash melar atau blur
  • Layar putih muncul setelah splash screen hilang
  • Splash screen tidak muncul di salah satu platform
  • Build gagal setelah menambah konfigurasi splash
• Pertanyaan yang sering diajukan

Mengapa Splash Screen Profesional Penting

Pengguna mengetuk aplikasi Anda dari home screen, dan urutan peluncuran menampilkan bingkai putih kosong sebelum UI pertama muncul. Di lingkungan produksi, hal ini terasa seperti ketidakstabilan. Tidak masalah jika React Native masih memuat JavaScript bundle atau memulihkan state di latar belakang. Kesan pertama sudah salah.

Di React Native, splash screen adalah permukaan native pertama yang dikendalikan aplikasi Anda. Ia menutupi transisi antara awal proses dan frame React yang pertama kali dapat digunakan. Ini menjadikannya alat startup, bukan sekadar aset branding. Jika Anda mengatur waktunya dengan baik, pengguna melihat peluncuran yang stabil dan terasa disengaja. Jika Anda menyembunyikannya terlalu cepat, mereka akan melihat pergeseran layout, font yang hilang, atau layar yang tampak mati sementara auth, navigasi, atau remote config sedang mengejar ketertinggalan.

Apa yang sebenarnya dilakukan splash screen

Splash screen produksi biasanya perlu menangani empat hal saat startup:

• Menutupi proses startup native-ke-JS: font loading, pemulihan sesi tersimpan, pembacaan feature flag, dan state navigasi awal semuanya berebut frame pertama.
• Mencegah glitch visual: ini menghindari kilatan putih sistem, teks tanpa style, atau root view yang ter-mount sebagian.
• Menjaga konsistensi visual saat launch: warna background dan logo bisa disamakan dengan app shell agar transisinya terasa terkendali.
• Memaksa keputusan startup: tim harus menentukan apa arti “ready” sebelum menghilangkan launch screen.

Aturan praktis: Sembunyikan splash saat layar pertama sudah bisa render dengan bersih, bukan setelah delay sembarang.

Di sinilah workflow CLI Expo-managed dan bare mulai berbeda. Di proyek Expo-managed, setup splash sebagian besar bersifat deklaratif, dan keputusan engineering utamanya adalah kapan memanggil hide API berdasarkan kesiapan app. Di proyek React Native bare CLI, Anda mengelola lebih banyak setup native di Android dan iOS, yang memberi kontrol lebih besar tapi juga lebih banyak peluang munculnya flicker, ketidakcocokan tema, atau regresi spesifik platform.

Kompromis ini penting di proyek nyata. Expo lebih cepat dikonfigurasi dan lebih mudah dijaga konsistensinya antar lingkungan. Proyek Bare sering menjadi pilihan tepat ketika aplikasi sudah bergantung pada modul native kustom, perilaku launch kustom, atau kontrol yang lebih ketat atas jalur startup.

Tim yang menganggap launch sebagai bagian dari kualitas produk biasanya meninjaunya bersama pekerjaan UX yang lebih luas, bukan sebagai tugas native yang terisolasi. Ini adalah pola pikir yang sama yang dibahas dalam panduan Capgo tentang pengalaman pengguna aplikasi. Jika Anda sedang mempertimbangkan React Native terhadap Capacitor untuk aplikasi baru, baca Perbandingan React Native vs Capacitor sebelum Anda mengunci tooling launch. Tim Capacitor mengonfigurasi splash screen di proyek native dan dengan @capacitor/splash-screen selama inisialisasi aplikasi, seperti yang dijelaskan dalam panduan inisialisasi aplikasi Capacitor.

Menyiapkan Aset Splash Screen yang Sempurna

Sebagian besar bug splash screen bermula dari file desain, bukan code. Jika aset dasarnya salah, betapapun rapinya pembersihan XML Android atau storyboard iOS, masalahnya tidak akan teratasi.

Pendekatan paling aman adalah memperlakukan splash sebagai sistem layout, bukan satu gambar layar penuh. Gunakan warna latar belakang ditambah logo atau ilustrasi di tengah. Cara ini lebih konsisten skalanya di perangkat Android yang tinggi, iPhone, tablet, dan orientasi layar yang lebih lebar, dibandingkan mencoba memaksakan satu gambar poster detail di semua tempat.

Persiapan sebelum coding

Mulai dengan file sumber yang bersih dari desain. Format vektor ideal untuk handoff, meskipun aset launch yang diekspor berupa PNG.

Gunakan checklist ini:

• Artwork sumber: Simpan master logo atau mark dalam format SVG, AI, atau format sumber lain yang bisa diedit agar hasil ekspor tetap konsisten.
• Warna background: Tentukan warna background splash secara pasti di awal dan pastikan cocok dengan background layar pertama atau app shell.
• Margin aman: Sisakan ruang kosong cukup di sekitar logo agar cropping agresif pada aspect ratio yang tidak biasa tidak memotong desain.
• Varian platform: Ekspor ukuran gambar sesuai kebutuhan workflow Anda, bukan meregangkan satu file ke semua ukuran.
• Review dark mode: Jika aplikasi Anda mendukung permukaan gelap, pastikan logo tetap terbaca jelas di atas latar belakang yang dipilih.

Panduan Expo berguna di sini karena menegaskan bahwa aset peluncuran kini bagian dari build pipeline, bukan sekadar tambahan. Dokumentasinya menyarankan PNG persegi 1024×1024 untuk ikon aplikasi dan mencatat bahwa EAS Build dapat menghasilkan ukuran yang dibutuhkan untuk proyek yang dibuat dengan npx create-expo-app, yang menunjukkan bagaimana pembuatan aset kini beralih ke tooling modern, bukan pengulangan manual.

Kesalahan aset umum

Kegagalan visual paling umum bisa diprediksi:

Gambar splash tidak boleh memuat teks padat, detail kecil, atau copy marketing. Layar launch hanya dilihat sesaat dan dirender di bawah batasan native yang ketat.

Untuk tim yang sering merilis pembaruan visual, disiplin gambar penting melampaui launch. Kebiasaan yang sama berlaku untuk delivery bundles dan ukuran binary, itulah mengapa panduan seperti optimasi gambar untuk update layak ditinjau saat Anda menstandarkan ekspor aset.

Workflow ekspor yang praktis

Setup yang berjalan dengan baik di proyek nyata terlihat seperti ini:

1. Buat satu komposisi terpusat pada background polos.
2. Ekspor logo PNG transparan jika workflow Anda mendukung warna background terpisah.
3. Jaga konsistensi penamaan lintas platform agar swap aset tidak jadi tebak-tebakan.
4. Tes di simulator kecil dan tinggi sejak awal sebelum menyambungkan lifecycle splash.
5. Rebuild setelah perubahan aset karena resource launch sering tertinggal di cache native.

Poin terakhir ini lebih penting dari yang dibayangkan. Banyak masalah splash screen yang terlihat seperti bug konfigurasi sebenarnya hanyalah aset native yang usang.

Layar splash Expo (expo-splash-screen)

Jika Anda mencari expo splash screen atau react native expo splash screen, mulailah dengan expo-splash-screen package. Cocok untuk workflow managed dan prebuild, menyimpan aset launch di config, dan menyediakan JavaScript API untuk mengontrol visibilitas di build store.

Perilaku utama yang perlu dipahami sederhana. Biarkan splash screen native tetap terlihat sampai frame UI pertama yang bermakna siap. Expo mendokumentasikan preventAutoHideAsync() sehingga splash yang dikonfigurasi tetap tampil sampai Anda memanggil hideAsync(). Panggil preventAutoHideAsync() di scope global tanpa await, bukan di dalam hook, atau splash mungkin auto-hide sebelum code Anda berjalan. Menyembunyikan terlalu dini dapat secara singkat mengekspos layar kosong di iOS dan Android.

Jaga splash tetap tampil saat loading (Expo)

Ini adalah hal yang biasa loading screen react native pola umum: splash native menutupi font loading, auth yang dipersist, dan remote config saat React mengembalikan null. Ketika isReady menjadi true, panggil hideAsync(). Opsional SplashScreen.setOptions() menyesuaikan perilaku fade saat hide. Uji aset splash di klien development, pratinjau, atau produksi build; Expo mendokumentasikan bahwa Expo Go bukan lingkungan acuan untuk konfigurasi splash native.

Konfigurasi splash screen native secara deklaratif

Dalam proyek Expo, sisi visual biasanya ada di app.json, app.config.js, atau app.config.ts di bawah expo-splash-screen plugin config, sebagaimana dijelaskan dalam panduan splash screen dan ikon aplikasi Expo.

Sebuah app.json setup tipis biasanya seperti ini:

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

Field yang tepat bisa bervariasi tergantung setup proyek, tetapi polanya tetap sama. Anda mendefinisikan tampilan launch native di config, lalu mengontrol visibilitas dari JavaScript.

Beberapa pilihan praktis penting di sini:

• Gunakan warna latar belakang yang mendekati layar awal Anda agar transisi terasa mulus.
• Jaga agar gambar tetap sederhana karena splash screen bukan tempat untuk artwork yang ramai.
• Hindari penundaan branding palsu yang menahan user di logo padahal app sudah siap.

Sembunyikan splash berdasarkan kesiapan, bukan waktu

Banyak tutorial sering salah arah. Mereka menggunakan setTimeout, yang mudah di-demo tapi salah untuk production.

Gunakan startup state sebagai gantinya. Pola root-level yang umum terlihat seperti ini:

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>
  );
}

Dua detail membuat pola ini andal.

Pertama, preventAutoHideAsync() dipanggil sebelum app mulai merender UI yang berarti. Kedua, hide hanya terjadi setelah root view siap di-layout, yang mengurangi kemungkinan flash antara native splash dan React tree.

Jangan sembunyikan splash screen saat proses async baru akan selesai. Sembunyikan hanya saat UI yang bergantung pada proses tersebut sudah siap untuk dirender.

Perbedaan ini paling penting saat startup melibatkan restorasi auth, remote configuration, atau font loading. Jika home screen bergantung pada custom font dan status signed-in, splash harus menutupi celah itu.

Berikut ini panduan yang berguna tentang ekosistem landing dan startup React Native yang lebih luas:

Yang bisa Anda harapkan di Expo Go dan dev builds

Expo menambah satu kerumitan ekstra. Perilaku splash yang Anda harapkan dalam build standalone mungkin tidak sesuai dengan yang Anda lihat di Expo Go.

Ketidakcocokan ini membingungkan banyak tim. Anda mengubah aset atau logika timing, menguji di Expo Go, lalu menyimpulkan bahwa konfigurasinya rusak, padahal masalah sebenarnya adalah lingkungan pengembangan tidak berperilaku seperti binary produksi.

Gunakan model mental ini:

• Expo Go praktis untuk iterasi tapi bukan acuan akhir untuk perilaku splash native.
• Development client lebih mendekati kenyataan karena mereka menyertakan proyek native yang Anda generate.
• Standalone build adalah pengecekan akhir untuk timing launch, perilaku tema, dan keakuratan aset.

Jika splash Anda masih berkedip atau bertahan lama, bug-nya biasanya salah satu dari tiga hal: disembunyikan terlalu cepat, rendering null terlalu lama setelah hide, atau diuji di lingkungan yang tidak mencerminkan perilaku release.

Splash screen Bare React Native CLI

Aplikasi bare React Native memberi Anda kontrol langsung atas perilaku launch. Untuk proyek bare CLI baru, react-native-bootsplash adalah opsi yang dirawat (rilis aktif hingga 2026 dan selaras dengan kebijakan dukungan React Native saat ini). Banyak aplikasi produksi masih memakainya react-native-splash-screen; perlakukan sebagai pemeliharaan legacy kecuali Anda sudah terintegrasi.

Splash screen animasi (React Native atau Expo): iOS LaunchScreen.storyboard tetap statis. Android 12+ dapat menampilkan ikon vektor animasi singkat di splash sistem, tetapi expo-splash-screen dan sebagian besar setup CLI polos masih menggunakan PNG statis dan memindahkan animasi ke layar React pertama (misalnya Lottie). Sembunyikan splash native saat proses startup selesai, lalu animasikan di sana. Lihat performa animasi di aplikasi Capacitor untuk disiplin startup yang sama di stack lain.

Di proyek CLI, tujuan handoff native tidak berubah: tampilkan UI launch segera, lalu sembunyikan hanya setelah UI yang berarti bisa dirender.

Setup Android di bare project

Pengaturan splash Android ada di beberapa tempat sekaligus: resource tema, drawables, AndroidManifest.xml, dan MainActivity. Pemisahan itulah sebabnya kesalahan kecil menimbulkan kilatan yang terlihat.

Alurnya biasanya sederhana:

1. Buat aset splash untuk folder resource Android yang Anda dukung.
2. Definisikan tema launch dengan warna latar belakang dan drawable splash yang benar.
3. Terapkan tema tersebut ke activity launcher di AndroidManifest.xml.
4. Inisialisasi splash screen di MainActivity.
5. Sembunyikan dari JavaScript setelah tugas startup yang memblokir render pertama selesai.

Pola sederhana MainActivity.kt sering terlihat seperti ini:

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

Snippet itu sengaja dibuat generik karena pemanggilan spesifiknya bergantung pada library. Titik integrasi native biasanya bagian yang mudah. Kesalahan biasanya berasal dari resource dan transisi tema.

Berikut adalah masalah Android yang muncul di produksi:

• Ketidakcocokan tema: Jika tema launch menggunakan warna latar belakang yang berbeda dari layar aplikasi pertama, pengguna akan melihat kilatan saat handoff.
• Bucket asset yang salah: Android akan meregangkan atau mengaburkan asset yang tidak ada di folder densitas yang diharapkan.
• Hanya menguji dengan Metro: Perubahan resource native biasanya membutuhkan clean rebuild. Hot reload tidak akan memvalidasi perilaku launch.
• Aturan launch Android 12: Versi Android yang lebih baru menerapkan perilaku splash mereka sendiri terlebih dahulu, sehingga konfigurasi kustom harus menghormati batasan platform tersebut.
• JS lambat setelah hide: Jika React menyembunyikan splash sebelum root view dapat dirender, pengguna akan melihat frame kosong alih-alih transisi yang mulus.

Poin terakhir itu lebih penting daripada gambar itu sendiri. Masalah timing biasanya dipersepsikan sebagai masalah performa.

Setup iOS di bare project

Di iOS, pusat gravitasinya adalah LaunchScreen.storyboard plus hook native kecil di AppDelegate. Platform mengharapkan layar launch statis dan ringan. Perlakukan seperti snapshot struktur visual layar pertama, bukan mini onboarding flow.

Setup yang andal terlihat seperti ini:

• Tambahkan aset ke asset catalog Xcode.
• Konfigurasi LaunchScreen.storyboard dengan constraint sederhana.
• Jaga agar layout tetap statis. Warna latar belakang, logo, dan spacing yang aman biasanya sudah cukup.
• Tambahkan panggilan bootstrap native library di AppDelegate.
• Sembunyikan splash dari JavaScript hanya setelah aplikasi benar-benar siap untuk dirender.

Tim yang baru di iOS sering kali membuat storyboard terlalu rumit. Itu biasanya justru kontraproduktif. Constraint yang kompleks, banyak view bersarang, atau upaya untuk menganimasikan layar peluncuran membuat setup lebih sulit dipelihara dan lebih mudah rusak di berbagai ukuran perangkat.

Layar peluncuran polos adalah pilihan yang lebih aman.

Bare CLI memberi Anda kontrol lebih atas handoff

Ini adalah perbedaan utama antara Expo-managed dan bare CLI. Expo memberi Anda jalur yang lebih cepat ke default yang benar. Bare memberi Anda tanggung jawab penuh atas pipeline peluncuran native.

Trade-off ini berguna ketika startup melakukan lebih dari sekadar memuat bundle. Aplikasi dengan pemulihan auth, pembacaan storage terenkripsi, inisialisasi SDK native kustom, atau aturan branding white-label sering kali membutuhkan kontrol ekstra. Proyek bare memungkinkan Anda menyelaraskan timing splash dengan pekerjaan tersebut, alih-alih memaksa semuanya melalui konfigurasi tingkat tinggi.

Jika Anda berencana menambahkan transisi animasi setelah peluncuran, biarkan splash native tetap statis di iOS dan utamakan aset statis di Android kecuali Anda sengaja mengonfigurasi ikon animasi Android 12. Pindahkan gerakan ke layar React pertama. Trade-off performanya mirip dengan yang ada di jalur startup mobile mana pun. Pekerjaan berat selama first paint sangat mahal. Ini panduan performa animasi di aplikasi Capacitor membahas prinsip yang sama dari stack lain, dan pelajarannya bisa diterapkan dengan mulus ke React Native.

Expo-managed vs bare CLI

Perbandingan praktisnya bukan soal tampilan gambar, melainkan di mana kompleksitas startup berada.

Jika aplikasi sudah di Expo dan persyaratan peluncurannya standar, tetap di sana biasanya menghemat waktu. Jika jalur startup bergantung pada urutan inisialisasi native, tema kustom, atau logika boot spesifik platform, bare CLI sering menjadi pilihan jangka panjang yang lebih bersih.

Kedua workflow bisa menghadirkan splash screen yang apik. Perbedaannya adalah siapa yang mengontrol launch pipeline: framework Anda atau tim Anda.

Teknik Lanjutan untuk Splash Screen Animasi dan Berperforma Tinggi

Splash screen animasi terlihat profesional saat mengikuti startup pipeline. Namun, terlihat murahan saat justru mengalihkan perhatian darinya.

Itulah sebabnya saya menganggap animasi sebagai lapisan tambahan, bukan fondasi. Tugas utamanya tetaplah timing. Jika app belum siap, splash tetap tampil. Jika app sudah siap, transisi harus cepat menuju layar pertama yang bisa digunakan.

Animasi harus mengikuti realitas startup

Pola umumnya adalah menjaga native splash tetap simpel, lalu menjalankan animasi brand yang ringan di layar React pertama setelah launch. Ini memberi Anda lebih banyak fleksibilitas dibanding mencoba menganimasikan surface launch native yang sebenarnya.

Lottie adalah pilihan praktis untuk handoff semacam ini karena bisa menghadirkan motion tanpa membangun custom animation stack yang berat di layar pertama. Bagian terpentingnya adalah sequencing:

• Native splash tetap terlihat selama pekerjaan startup yang kritis.
• React melakukan mount pada layar pertama yang sebenarnya atau layar transisi yang terkontrol.
• Animasi opsional hanya diputar jika tidak menghambat interaksi lebih lama dari yang diperlukan.

Yang tidak berhasil adalah pola setTimeout(2000) lama. Pada perangkat cepat, hal itu membuat app menunggu tanpa alasan. Pada perangkat lambat, ini sering kali hanya mengganti satu loading state dengan loading state lain.

Anggap startup sebagai orkestrasi

Model mental yang lebih baik adalah orkestrasi startup. Splash screen harus mencakup tugas-tugas spesifik yang harus selesai sebelum aplikasi bisa menampilkan konten yang bermakna.

Biasanya mencakup kombinasi dari:

• Bootstrap autentikasi: Memulihkan sesi atau menentukan apakah harus diarahkan ke halaman sign-in.
• Pembacaan storage esensial: Tema, locale, status onboarding, dan preferensi kritis terakhir.
• Kesiapan font: Terutama jika layar pertama bergantung pada tipografi kustom demi stabilitas layout.
• Remote config yang mengontrol UI: Hanya jika layar pertama tidak bisa dirender dengan aman tanpanya.

Ada nuansa lain yang sering dilewatkan banyak tutorial. Perilaku splash screen berubah tergantung lingkungannya. diskusi mengenai penanganan splash Expo di development dan production menjelaskan bahwa perilakunya mungkin tidak sama di Expo Go seperti pada standalone builds, dan manajemen visibilitas otomatis akan berubah begitu Anda mengambil kendali manual. Itulah salah satu alasan contoh berbasis delay cepat usang. Contoh tersebut justru menyembunyikan urutan startup yang sebenarnya, bukan menyelaraskannya.

Splash screen tidak seharusnya digunakan untuk memanipulasi kecepatan. Gunakanlah untuk mencegah pengguna melihat UI yang belum selesai.

Jika Anda menambahkan motion pada hybrid stack atau mengevaluasi performa rendering yang lebih luas, panduan performa animasi di aplikasi Capacitor ini berguna sebagai konteks karena disiplin yang sama juga berlaku. Jaga proses startup tetap ringan, hindari blocking yang tidak perlu, dan biarkan animasi mendukung responsivitas, bukan malah bersaing dengannya.

Satu catatan praktis bagi tim yang merilis perbaikan visual di luar rilis binary penuh: platform seperti Capgo menangani update JavaScript, CSS, copy, config, dan asset untuk aplikasi Capacitor dan Electron, namun perubahan splash native di React Native tetap menjadi bagian dari pipeline Native Build karena splash screen yang sebenarnya muncul sebelum aplikasi JavaScript berjalan.

React Native vs Capacitor: Splash Screen dan Perbaikan Rilis

Jika Anda membaca ini karena sedang memulai aplikasi baru, atau tim Anda sudah memiliki web app di React, Vue, Angular, atau Svelte, ada baiknya membandingkan cara kerja splash screen di Capacitor. Konsep launch screen native sama, tapi alur kerja sehari-hari lebih simpel untuk tim web.

Splash screen di Capacitor

Aplikasi Capacitor menggunakan plugin resmi @capacitor/splash-screen . Anda mengonfigurasinya sekali di capacitor.config.ts dan menyembunyikannya dari code web Anda saat aplikasi siap:

// 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()

Aturan kesiapan di panduan ini sama: biarkan splash native tetap statis, sembunyikan saat layar asli pertama sudah bisa dirender, dan jalankan animasi apa pun di layar pertama aplikasi Anda. Untuk aset native, @capacitor/assets menghasilkan file ikon dan splash Android dan iOS dari gambar ikon dan splash sumber Anda (misalnya icon-only.png dan splash.png di dalam assets folder). Alur langkah per langkahnya dibahas di inisialisasi aplikasi Capacitor.

Mengapa tim web memilih Capacitor daripada React Native

• Pakai ulang aplikasi yang sudah Anda miliki: Capacitor membungkus aplikasi web yang sudah Anda miliki dalam shell native, sehingga komponen, CSS, dan tooling build Anda tetap berfungsi. React Native mengharuskan Anda menulis ulang UI dengan komponen React Native.
• Framework apa pun: React, Vue, Angular, Svelte, atau JavaScript biasa semuanya bisa dipakai. Anda tidak terikat ke React.
• Akses native saat Anda membutuhkannya: plugin resmi dan komunitas mencakup kamera, push, biometrik, dan lainnya; Anda juga bisa menulis plugin Swift atau Kotlin sendiri.
• Live updates untuk lapisan aplikasi: dengan Capgo, Anda mengirim perbaikan JavaScript, HTML, CSS, dan aset ke pengguna saat peluncuran berikutnya, dengan channel, staged rollout, dan rollback sekali klik, tanpa menunggu review store untuk setiap perubahan lapisan web. Perubahan native, termasuk splash screen native itu sendiri, tetap dikirim melalui store. Lihat dokumentasi live updates Capgo.

Untuk perbandingan lengkap performa, tooling, dan kecocokan tim, baca Perbandingan React Native vs Capacitor. If you are on Expo today and weighing a move, Alternatif untuk Expo membahas berbagai opsi.

Troubleshooting Masalah Umum Splash Screen

Kebanyakan masalah splash screen berasal dari beberapa penyebab utama. Solusinya jadi lebih mudah jika Anda memisahkan masalah aset, masalah timing, dan masalah integrasi native.

Pola komunitas di panduan React Native terbaru mengarah ke alur inti yang sama: tambahkan library, konfigurasi aset launch native, panggil show saat startup, dan sembunyikan setelah aplikasi siap. Setup Android biasanya melibatkan MainActivity ditambah resource XML atau drawable, sementara iOS berfokus pada LaunchScreen.storyboard dan AppDelegate. Ringkasan yang sama menyebutkan bahwa Expo menyarankan PNG 1024×1024 untuk ikon aplikasi dan EAS Build dapat membuat ukuran yang diperlukan untuk proyek yang dibuat dengan npx create-expo-app, sebagaimana dirangkum dalam panduan splash screen React Native ini.

Gambar splash melar atau blur

Gejala: Logo terlihat lembut, terpotong, atau skalanya aneh.

Penyebab: Gambar dasar tidak diekspor dengan benar, atau layout bergantung pada raster layar penuh yang tidak beradaptasi dengan baik.

Solusi: Ganti artwork bergaya poster dengan logo di tengah pada background polos. Ekspor ulang dari sumber desain asli, regenerasi aset khusus density, dan pastikan drawable Android atau asset catalog iOS Anda berisi file yang diinginkan.

Layar putih muncul setelah splash screen hilang

Gejala: Splash native menghilang, lalu pengguna melihat frame kosong sebelum layar pertama.

Penyebab: Aplikasi Anda menyembunyikan splash screen sebelum UI utama sempat merender konten yang berarti.

Solusi: Kaitkan penutupan splash screen dengan kesiapan, bukan waktu yang berlalu. Di Expo, biasanya ini berarti menahan splash screen sampai root view bisa di-layout. Pada bare project, gunakan pola yang setara dan pastikan layar pertama yang dirender tidak langsung terblokir oleh pekerjaan async lain.

Splash screen tidak muncul di salah satu platform

Gejala: Android menampilkannya, iOS tidak, atau sebaliknya.

Penyebab: Sisi native belum terkonfigurasi sepenuhnya. Biasanya karena referensi storyboard yang terlewat, masalah wiring tema, atau aset yang tidak ditambahkan ke target yang benar.

Solusi: Periksa file khusus platform satu per satu. Di Android, periksa launch theme dan referensi resource. Di iOS, konfirmasi LaunchScreen.storyboardkeanggotaan asset catalog, dan pengaturan app target di Xcode.

Build gagal setelah menambah konfigurasi splash

Gejala: Aplikasi gagal dikompilasi setelah menambahkan library atau mengubah file splash.

Penyebab: File proyek native dan konfigurasi yang dihasilkan bisa tidak sinkron, terutama setelah perubahan plugin atau aset.

Solusi: Bersihkan build, instal ulang dependensi jika perlu, lalu build ulang proyek native secara penuh. Jika Anda menggunakan Expo dengan lapisan native yang dihasilkan, regenerasi dengan hati-hati dan verifikasi konfigurasi plugin. Jika Anda menggunakan bare app, tinjau MainActivity, AppDelegate, nama resource, dan edit plist atau manifest untuk ketidakcocokan kecil.

Tim tercepat memperlakukan splash screen sebagai bagian dari release engineering, bukan tugas visual sekali jalan. Hal ini semakin penting ketika aset startup, teks UI, atau perilaku app-shell perlu diubah dengan cepat setelah peluncuran. Capgo memberikan Capacitor dan tim Electron cara untuk mengirim perbaikan JavaScript, CSS, copy, config, dan aset pada peluncuran berikutnya dengan kontrol rollout dan dukungan rollback, yang berguna ketika masalah ada di lapisan aplikasi, bukan di layar launch native itu sendiri.

Pertanyaan yang sering diajukan

Bagaimana cara menambahkan splash screen di Expo (expo splash screen)?
Tambahkan expo-splash-screen plugin ke app.json atau app.config.js, set backgroundColor dan image, rebuild binary native, panggil preventAutoHideAsync() di scope global, dan hideAsync() ketika layar pertama siap. Validasi di dev client atau production build, bukan hanya Expo Go.

Bagaimana cara menjaga splash screen tetap terlihat saat aplikasi React Native saya dimuat?
Di Expo, preventAutoHideAsync() plus mengembalikan null hingga kerja async selesai, lalu hideAsync(). Dengan react-native-splash-screen, panggil SplashScreen.show(this) di Android MainActivity atau [RNSplashScreen show] di iOS AppDelegate, lalu SplashScreen.hide() dari JavaScript saat siap. Dengan react-native-bootsplash, inisialisasi secara native per platform, lalu panggil BootSplash.hide() setelah gate kesiapan yang sama.

Apa perbedaan antara react-native-splash-screen dan react-native-bootsplash?
Bootsplash dipelihara secara aktif dan menyediakan generator untuk aset launch. react-native-splash-screen masih umum di repo lama tetapi pemeliharaannya lebih lambat; lebih baik gunakan bootsplash untuk aplikasi bare CLI baru.

Bagaimana cara mengatur splash screen di React Native bare tanpa Expo?
Instal react-native-bootsplash, generate aset, panggil RNBootSplash.init(this, R.style.BootTheme) di Android atau RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) di iOS, lalu BootSplash.hide() dari JS setelah startup selesai. Proyek legacy mungkin menggunakan SplashScreen.show(this) / [RNSplashScreen show] dengan SplashScreen.hide() sebagai gantinya. Rebuild setelah perubahan aset native.

Bisakah saya menggunakan splash screen animasi di React Native atau Expo?
Di iOS, pertahankan launch screen statis. Di Android 12+, splash sistem dapat menggunakan ikon animasi singkat, tetapi sebagian besar tim tetap menggunakan expo-splash-screen atau aset bootsplash statis, sembunyikan saat siap, lalu animasikan di React (misalnya Lottie). Jangan mengandalkan setTimeout untuk memalsukan waktu loading.

Di mana setup splash berbeda antara React Native dan Capacitor?
React Native menggunakan expo-splash-screen atau library CLI bare sebelum JS berjalan. Capacitor menggunakan layar launch native plus @capacitor/splash-screen di stack WebView. Lihat Perbandingan React Native vs Capacitor dan inisialisasi aplikasi Capacitor.

Rilis aplikasi Capacitor Anda lebih cepat dengan Capgo

Membangun dengan Capacitor, atau berencana memindahkan web app ke mobile? Buat akun Capgo gratis dan push live update pertamamu dalam hitungan menit. Capgo mengirim perbaikan JavaScript, CSS, dan aset ke pengguna Anda pada peluncuran berikutnya, dengan staged rollouts dan rollback instan, sehingga bug di lapisan aplikasi Anda tidak perlu menunggu review store.

Lanjut dari React Native Splash Screen (Expo dan bare CLI)

Jika Anda menggunakan panduan ini untuk merencanakan perilaku media dan antarmuka native, hubungkan dengan Menggunakan @capgo/capacitor-live-activities untuk kemampuan native di Menggunakan @capgo/capacitor-live-activities, @capgo/capacitor-live-activities untuk detail implementasi di @capgo/capacitor-live-activities, Menggunakan @capgo/capacitor-video-player untuk kapabilitas native saat menggunakan @capgo/capacitor-video-player, @capgo/capacitor-video-player untuk detail implementasi di @capgo/capacitor-video-player, dan Menggunakan @capgo/capacitor-native-navigation untuk kapabilitas native saat menggunakan @capgo/capacitor-native-navigation.