実機でアプリのアイコンをタップすると、ユーザーは白いフラッシュ、引き伸ばされたロゴ、または凍結した起動画面が一瞬で消え、ユーザーは何も役に立たないものが表示されるまで待つことになります。その時点で、React Nativeアプリは通常プロダクショングレードのものと感じられません。
React Nativeの良いSplash Screenは、ネイティブの起動と最初の意味のあるReactレンダリングフレームの間のギャップをカバーするだけでなく、起動順序、資産の準備、およびExpo Goという開発クライアントと実店舗ビルドの間の違いについても考えることを強制します。タイミングを間違えると、ユーザーはすぐに欠陥を認識します。
目次
- プロフェッショナルなスプラッシュスクリーンはなぜ重要か
- パーフェクトなスプラッシュスクリーンアセットを用意する
- Expo Goと開発クライアントワークフローの実装
- Bare React Native CLI プロジェクトの設定
- アニメーションとパフォーマンスの高いスプラッシュスクリーン用の高度なテクニック
- スプラッシュスクリーンの一般的な問題のトラブルシューティング
プロのスプラッシュスクリーンはなぜ重要か
Aユーザーがホーム画面からアプリをタップすると、起動シーケンスは最初のUIが表示される前に白いフレームが表示されます。生産環境では、これは不安定性として読み取られます。 React NativeがJavaScriptバンドルを読み込んでいる場合やバックグラウンドで状態を復元している場合でも、最初の印象は間違っています。
React Nativeでは、スプラッシュ画面はアプリが制御する最初のネイティブ表面です。プロセス開始と最初のReactでレンダリングされたフレームのハンドオフをカバーするため、スプラッシュ画面は起動ツールであり、単にブランドアセットではありません。タイミングが良ければ、ユーザーは安定した起動を感じます。スプラッシュ画面を早く隠すと、レイアウトのシフト、欠落したフォント、または認証、ナビゲーション、またはリモート設定が追いつくまで死んでいるように見える画面が表示されます。
スプラッシュ画面が実際に何をしているか
生産環境のスプラッシュ画面は通常、起動の4つの懸念事項を処理する必要があります。
- ネイティブからJSの起動作業をカバーする: フォントの読み込み、パーシステントセッションの復元、機能フラグの読み込み、初期ナビゲーション状態の競合が最初のフレームを争っています。
- 視覚的な不具合を防ぐ: システムの白いフレッシュ、未スタイリングのテキスト、または部分的にマウントされたルートビューを避けます。
- 起動を視覚的に一貫性を保つ: 背景色とロゴがアプリシェルと一致する場合、トランジションは制御されたように感じます。
- 起動の決定を強制する: チームは、ローンチ画面を削除する前に、「準備完了」という概念を定義する必要があります。
実践的なルール： 最初の実際の画面がきれいにレンダリングできるようになったら、ローンチ画面を非表示にします。ローンチ画面を非表示にするのは、任意の待機時間後に非表示にするのではなく、画面がきれいにレンダリングできるようになったときに非表示にする必要があります。
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.
実際のプロジェクトでは、このトレードオフは重要です。Expoは、設定が速く、環境間で一貫性が保たれるため、より速く設定できます。バーレーンのプロジェクトは、既存のカスタムネイティブモジュール、カスタムローンチ動作、起動パスの厳密な制御などが必要な場合に適しています。
ローンチを製品の品質の一部として扱うチームは、より広範なUXワークとともにローンチをレビューし、ローンチを孤立したネイティブタスクとして扱うのではなく、同じ考え方が__CAPGO_KEEP_0__のアプリユーザー体験ガイドでカバーされています。 Capgo’s guide to app user experienceReact NativeアプリのNerdifyソリューション は、生産性に焦点を当てた概要を提供します。 ローンチ画面のアセットを準備する
ローンチ画面のバグの多くは、設計ファイルに起因します。__CAPGO_KEEP_0__の基本アセットが間違っていると、Android XMLまたはiOSストーリーボードのクリーンアップでもローンチ画面の問題を解決することはできません。
Most splash screen bugs start in design files, not code. If the base asset is wrong, no amount of Android XML or iOS storyboard cleanup will save it.
The safest approach is to treat the splash as a レイアウトシステム、ではなく、単一のフルスクリーン画像ではありません。背景色と中央のロゴまたはイラストを使用してください。Androidデバイス、iPhone、タブレット、横向きのデバイスの幅の広いデバイスの高さのAndroidデバイスにわたって予測可能に拡大します。
コーディングする前に準備するもの
デザインからクリーンなソースファイルから始めましょう。ベクターは、ハンドオフのために理想的です。exportされた起動アセットはPNGである場合でも。
このチェックリストを使用してください。
- ソースアートワーク: マスター ロゴまたはマークをSVG、AI、または編集可能なソース形式で保持してください。エクスポートが一貫性を保つようにします。
- 背景色: スプラッシュ背景色を正確に定義し、最初の画面またはアプリシェル背景色と一致するようにしてください。
- セーフマージン: ロゴの周りに十分な空白を残して、不規則なアスペクト比で強制的に切り取られることなくデザインが切断されないようにします。
- プラットフォームバリアント: 必要なワークフローで使用する画像サイズをエクスポートするのではなく、1 つのファイルをすべて拡張してしまうのではなく。
- ダークモードレビュー: アプリがダークサーフェスをサポートしている場合、選択された背景に対してロゴがきれいに読み取れることを確認します。
Expo のガイドラインはここで役立ちます。ロゴはビルドパイプラインの一部になり、後悔の念のないものになりました。ドキュメントでは、 1024×1024 の正方形の PNG アプリアイコンとして推奨されており、EAS ビルドは npx create-expo-appプロジェクトを作成した場合に必要なサイズを生成できることを示しています。アセットの生成は、現代のツールに移行し、手動の繰り返しではなく、
共通のアセットのミス
最も予測可能な視覚的失敗は:
| 問題 | Likely cause | より良いアプローチ |
|---|---|---|
| ロゴがぼやけている | 低解像度のラスターからエクスポート | ベクターのソースから再エクスポート |
| カットされた辺 | アートワークが境界線に近すぎる | 安全なパディングを増やす |
| 拡張 | 多くのアスペクトレシオに強制されたフルスクリーン画像 | 背景色と中央の画像を使用 |
| トランジションが一致していない | 初期画面とスプラッシュ画面の背景が異なる | 起動画面とアプリシェル色を揃える |
スプラッシュ画像には密集したテキスト、細かい詳細、またはマーケティングコピーを含めるべきではない。起動画面は短時間しか表示されず、厳密なネイティブ制約下でレンダリングされる。
頻繁なビジュアル更新を実施するチームでは、スプラッシュ画像の制約は起動画面だけに留まらない。同様の習慣は、配信パッケージとバイナリサイズにも適用されるため、標準化されたアセットエクスポートの際に 更新用の画像を最適化する のガイドを参照する価値がある。
実用的なエクスポートワークフロー
実際のプロジェクトで機能する設定は次のようになる。
- デザインされた中心に配置された構成 背景が単色の場合。
- 透過可能なロゴPNGをエクスポートする ワークフローが背景色を分離できる場合。
- Keep naming consistent across platforms so asset swaps don’t become guesswork.
- Test on small and tall simulators early before wiring the splash lifecycle.
- Rebuild after asset changes because launch resources often sit in native caches.
That last point matters more than people expect. Many splash screen issues that look like configuration bugs are just stale native assets.
Implementing with the Expo Go and Development Client Workflow
If you’re using Expo, start with expo-splash-screen. It fits the managed workflow, keeps most configuration declarative, and gives you explicit control over when the splash should leave.
The key behavior to understand is simple. native splashを初期表示し続けるまでの待機時間が終わるまで待つ。 Expoの SplashScreen APIはそのパターンを完全にサポートしています。 preventAutoHideAsync() 起動時と hideAsync() ロードが完了した後、重要なロードが終わった後、ExpoはiOSおよびAndroidの両方のビルドで、すぐに表示を非表示にすることで、短時間の間白い画面が表示されることを警告しています。 Expo splash screen API.
native splashの表示を宣言的に設定する
Expoのプロジェクトでは、通常、視覚的な側面は app.json または app.config.js.
通常の app.json 設定は次のようになります。
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}プロジェクトの設定によってフィールドは異なるかもしれませんが、パターンは同じです。native launch appearanceをconfigで定義し、JavaScriptから表示の可視性を制御します。
いくつかの実用的な選択肢がここで重要です:
- 背景色を初期画面に近づけることで、連続的な移行感を得ることができます。 イメージはシンプルに保つ
- 起動面では、密集したアートワークは適していません。 「ブランドの遅延」は避ける
- アプリがすでに準備が整っているのに、ロゴにユーザーを留めないようにする 準備が整ったときにスプラッシュを非表示にする
多くのチュートリアルでは、間違った方法で進みます。
デモ用に簡単に実行できるものの、実際の運用では間違っているものを使用しています。 setTimeout起動状態を使用する。一般的なルートレベルパターンは次のようになります。
このパターンを信頼できるものにする2つの詳細があります。
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>
);
}Two details make this pattern reliable.
まず、 preventAutoHideAsync() アプリが意味のあるUIをレンダリングする前に呼び出される。2つ目は、root viewがレイアウトを準備できるようになるまで、hideは発生しない。これにより、native splashとReact treeの間のフラッシュの可能性が減る。
アシンクロナス作業が終了するのを待つのではなく、UIがその作業に依存している場合にのみ、hideする。
起動に認証の復元、リモートの設定、フォントのロードなどが含まれる場合、hideのタイミングは重要になる。
ホーム画面がカスタムフォントやサインイン済みの状態に依存している場合、splashはそのギャップをカバーするべきである。
より広いReact Nativeのランディングと起動のエコシステムについての有用なウォークスルーは以下にあります。
Expo Goとdevビルドで期待すること
Expoは1つの追加のジレンマを追加する。スタンドアローンビルドで期待するsplashの動作と、実際に見るものは一致しない。
多くのチームが混乱するのは、この不一致である。
- アセットやタイミングのロジックを変更し、Expo Goでテストし、実際の問題は開発環境がプロダクションバイナリと同じように動作しないことであると結論付ける。 このメンタルモデルを使う:
- Expo Goは、開発のための便利なツールであるが、native splashの動作の最終的な権威ではない。 は、生成されたネイティブプロジェクトを含むためです。
- 独立したビルドは、起動タイミング、テーマの動作、およびアセットの正しさの最終チェックです。 スプラッシュがまだフラッシュしている場合、またはそのまま残っている場合、通常、バグは3つのうちの1つです:
早すぎて非表示になる、 null 長すぎて非表示になる、
Configuring for Bare React Native CLI Projects
Bare React Nativeプロジェクトの設定
In CLI projects, I usually recommend react-native-bootsplash __CAPGO_KEEP_0__プロジェクトでは、通常、 react-native-splash-screen新しい作業に推奨します。
、なので、メンテナンス作業で遭遇する可能性がありますが、最新の設定では目標は同じです。ネイティブの起動表面をすぐに表示し、意味のあるUIが表示できるようになるまで非表示にします。
Android スプラッシュ設定は、テーマリソース、ドロワブル、 AndroidManifest.xmlのいくつかの場所に存在します:。 MainActivityその分割は、小さなミスが視覚的なフラッシュを生み出す理由です。
通常のフローは、以下のとおりです:
- Android リソースフォルダをサポートするものにスプラッシュアセットを生成します。
- 正しい背景色とスプラッシュドロワブルを持つ起動テーマを定義します。
- 起動アクティビティにそのテーマを適用します。
AndroidManifest.xml. - Initialize the splash screen in
MainActivity. - Hide it from JavaScript after startup tasks that block first render are done.
A simplified MainActivity.kt pattern often looks like this:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}スプラッシュスクリーンを初期化します。JavaScriptからスプラッシュスクリーンを非表示にします。初期化タスクがブロックする最初のレンダリングが完了した後です。
Androidの生産環境で表示される問題はこちらです:
- テーマの不一致: 起動テーマがアプリの最初の画面の背景色と異なる場合、ユーザーはハンドオフ時にフラッシュを確認します。
- アセットバケットの不正確さ: Androidは、期待される密度フォルダに欠落しているアセットを伸縮またはぼかします。
- Metroでのみテスト: ネイティブリソースの変更は通常、クリーンリビルドが必要です。ホットリロードは起動の動作を検証しません。
- Android 12の起動ルール: 新しいAndroidバージョンでは、カスタム設定はプラットフォームの制約を尊重する必要があります。
- JSの遅延: Reactがルートビューを描画する前にスプラッシュを非表示にすると、ユーザーはスムーズなトランジションの代わりに白いフレームを確認します。
最後の点は、画像自体よりも重要です。タイミングの問題は通常、パフォーマンスの問題として受け取られます。
iOSプロジェクトの初期設定
iOSでは、 LaunchScreen.storyboard plus a small native hook in AppDelegate. プラットフォームは、起動画面を静的で軽量のものと想定している。最初の画面の視覚構造のスナップショットとして扱う。
The reliable setup looks like this:
- Xcodeアセットカタログにアセットを追加する
- Configure
LaunchScreen.storyboardwith simple constraints. - 静的なレイアウトを維持する。背景色、ロゴ、セーフスペースは通常十分である。
- Add the library’s native bootstrap call in
AppDelegate. - JavaScriptからスプラッシュを非表示にするには、
iOSに慣れていないチームはストーリーボードを過度に拡張することが多い。通常は失敗する。複雑な制約、複数のネストされたビュー、または起動画面のアニメーションを試みることは、デバイスサイズによって維持が難しく、破損しやすくなる。
A plain launch screen is the safer choice.
CLI の基本的な設定は、起動時のハンドオフの制御をより多く受け取ることを意味します。
This is the key difference between Expo-managed and bare CLI. Expo gives you a faster path to a correct default. Bare gives you full responsibility for the native launch pipeline.
起動時の処理が複雑になる場合、起動時にバンドルを読み込む以外の処理が必要なアプリでは、この制御が必要になります。 例えば、認証の復元、暗号化されたストレージの読み取り、カスタムのネイティブ SDK の初期化、またはホワイトラベルブランドのルールなどが必要になります。 Bare プロジェクトでは、起動時のスプラッシュタイミングをアプリの他の処理と合わせることができます。
If you plan to add an animated transition after launch, keep the native splash static and move motion into the first React screen. The performance trade-offs are similar to what matters in any mobile startup path. Heavy work during the first paint is expensive. This Capacitor アプリのアニメーション性能のガイド このガイドは、別のスタックから同じ原理を紹介しています。 React Native にもこの原理が適用されます。
Expo-managed versus bare CLI
実際の比較は、画像の表示ではなく、起動時の複雑さの位置にあります。
| 決定点 | Expo-managed | CLI の基本的な設定 |
|---|---|---|
| セットアップスピード | 初期セットアップの高速化 | よりネイティブな作業 |
| ネイティブのカスタマイズ | より制約のある | フルコントロール |
| アセット生成フロー | より宣言的 | より手動 |
| デバッグの表面 | JSの設定プラス生成されたネイティブレイヤー | 直接AndroidとiOSファイル |
| 最適な選択 | 速度と一貫性を優先するチーム | ネイティブコントロールの深いチーム |
If the app is already in Expo and the launch requirements are standard, staying there usually saves time. If the startup path depends on native initialization order, custom themes, or platform-specific boot logic, bare CLI is often the cleaner long-term choice.
起動パスがネイティブの初期化順序、カスタムのテーマ、プラットフォーム固有のブートロジックに依存している場合、bare Capgoは長期的にはより綺麗な選択肢であることが多い
両方のワークフローは、綺麗なスプラッシュ画面を配信できる。違いは、フレームワークまたはチームが起動パイプラインを管理するかどうかである
アニメーションとパフォーマンスの高いスプラッシュ画面の高度なテクニック
アニメーションが起動パイプラインを尊重する場合、スプラッシュ画面は綺麗に見える。アニメーションが起動パイプラインを妨げる場合、安っぽく見える
アニメーションは実際の起動現実に従うべき
起動パイプラインを尊重するアニメーションは綺麗に見えるが、起動パイプラインを妨げるアニメーションは安っぽく見える
アプリが準備されていない場合、スプラッシュ画面は表示される。アプリが準備されている場合、最初の利用可能な画面に迅速に移行するようにする
- アニメーションは起動現実に従うべき
- Reactは最初の実際の画面または制御されたトランジション画面をマウントします。
- オプションのアニメーションは、必要以上にインタラクションをブロックしない限り、実行されません。
機能しないのは古い setTimeout(2000) パターンです。高速なデバイスでは、待ち時間が無駄になるため、アプリが待機します。低速なデバイスでは、よくはロード中の状態を置き換えるだけです。
起動をオーケストレーションとして扱う
より良いメンタルモデルは 起動オーケストレーションスプラッシュ画面は、意味のあるコンテンツを表示できるようになる前に完了する必要があるタスクを完全にカバーする必要があります。
これは、次の組み合わせのいずれかが含まれます。
- 認証の初期化 セッションの復元またはサインインにルーティングするかどうかを決定する
- 必須のストレージの読み取り テーマ、ロケール、オンボーディング状態、最後の知られているクリティカルな好み。
- フォントの準備: 特に、最初の画面がカスタムフォントのレイアウト安定性に依存している場合。
- リモート設定がUIを制限する: 最初の画面が安全にレンダリングできない場合のみ。
多くのチュートリアルがこのもう一つのニュアンスを省略している。起動画面の動作は環境によって異なる。Expo起動画面の処理についての議論は、開発と実行環境での起動画面の動作がExpo Goとスタンドアロンビルドで同じように見えなくなることを指摘し、自動的な表示管理が手動で制御を取るときに変化することを指摘している。自動表示管理の変更は、遅延ベースの例が古くなってしまう理由の1つである。 起動画面は、ユーザーが未完成のUIを見るのを防ぐために使用されるべきである。ユーザーが未完成のUIを見るのを防ぐために使用されるべきである。 Hybridスタックに動きを追加している場合や、より広範なレンダリングパフォーマンスを評価している場合、
この__CAPGO_KEEP_0__アプリのアニメーションパフォーマンスガイド
は、同じ規範が適用されるため、参考になる。起動作業を軽量に保ち、不要なブロッキングを避け、動きがレスポンス性をサポートするのではなく、それと競合するのではなく、レスポンス性をサポートするようにする。 this guide to animation performance in Capacitor apps 起動画面の動作は環境によって異なる。
One practical note for teams shipping visual fixes outside full binary releases: platforms such as Capgo JavaScript、CSS、コピー、設定、そしてアセットの更新は、CapacitorとElectronアプリ用に
トラブルシューティングのためのコモン スプラッシュ スクリーン イシュー
ほとんどのスプラッシュの問題は、繰り返し犯人に分類される。解決策は、問題を アセットの問題, タイミングの問題、そして ネイティブの統合の問題.
最近のReact Nativeのガイドのコミュニティパターンは、同じコアフローに収束している。ライブラリを追加し、ネイティブの起動アセットを設定し、 show 起動時に呼び出し、そしてアプリが準備されたら非表示にする。Androidのセットアップは、 MainActivity プラスXMLまたはdrawableリソースを含むことが多い。iOSは、 LaunchScreen.storyboard と同じ概要のノートは、Expoがアプリアイコンのために1024×1024のPNGを推奨していることを指摘しています。EAS BuildはCapacitorプロジェクトを作成した場合に必要なサイズを生成することができます。 AppDelegate1024×1024 PNG Capacitorプロジェクト このReact Nativeのスプラッシュスクリーンガイド npx create-expo-appスプラッシュ画像が引き伸ばされたりぼやかされたりしている 症状:.
ロゴが柔らかく、切り取られた、または奇妙にスケールされている
原因: 基本画像が正しくエクスポートされていなかった、またはフルスクリーンのラスターに依存しているレイアウト
対処法: The logo looks soft, cropped, or oddly scaled.
Cause: The base image wasn’t exported correctly, or the layout depends on a full-screen raster that doesn’t adapt well. ポスター風のアートワークを、平らな背景に中央に配置したロゴに置き換えます。元のデザインソースから再エクスポートし、密度に応じたアセットを再生成し、AndroidのドロワブルまたはiOSのアセットカタログに含まれるファイルが意図されたものであることを確認します。
スプラッシュ画面が白い画面に変わります
症状: ネイティブのスプラッシュが消え、ユーザーは最初の画面を見る前に白いフレームを表示します。
原因: アプリがスプラッシュを隠す前に、ルートUIが意味のあるコンテンツをレンダリングできるようになるまで待つ必要があります。
対処法: スプラッシュの消去を、時間経過ではなく、UIの準備度に基づいて行うようにします。Expoの場合、通常はルートビューがレイアウトできるまでスプラッシュを表示します。bareプロジェクトの場合、同様のパターンを使用し、最初のレンダリングされた画面がすぐにアシンクロニズドワークにブロックしないようにします。
プラットフォームの1つでスプラッシュ画面が見られない
症状: Androidでは表示されますが、iOSでは表示されない、またはその逆です。
原因: One native side wasn’t fully configured. Often it’s a forgotten storyboard reference, theme wiring issue, or asset not added to the correct target.
対処法: Android用のファイルを一つずつ確認してください。Androidでは、起動テーマとリソース参照を確認してください。iOSでは、Xcodeでアセットカタログのメンバーとアプリのターゲット設定を確認してください。 LaunchScreen.storyboardビルドが途中で途切れる
症状:
アプリがコンパイルされなくなったのは、ライブラリを追加したり、スプラッシュファイルを変更したためです。 原因:
ネイティブプロジェクトファイルと生成された設定が同期を失い、特にプラグインやアセットの変更後は、特別に気をつけてください。 対処法:
ビルドをクリーンアップし、必要に応じて依存関係を再インストールし、ネイティブプロジェクトを完全にビルドしてください。Expoで生成されたネイティブレイヤーにいる場合は、慎重に再生成し、プラグインの設定を確認してください。ベアアプリの場合は、リソース名やplistやmanifestの編集の小さなミスを確認してください。 __CAPGO_KEEP_0__ MainActivity, AppDelegate__CAPGO_KEEP_0__
最速のチームは、リリースエンジニアリングの一部として、スプラッシュスクリーンを視覚的なタスクとして一度だけ扱うのではなく、扱います。 これは、起動時点後にスピードでアセット、UIテキスト、またはアプリシェル動作を変更する必要がある場合に、さらに重要です。 Capgo gives Capacitor and Electron teams a way to ship JavaScript, CSS, copy, config, and asset fixes on the next launch with rollout controls and rollback support, which is useful when the problem is in the app layer rather than the native launch screen itself.
Splash Screen in React Native: A Complete Guide for 2026
Capgoを使用している場合 Splash Screen in React Native: A Complete Guide for 2026 を使用して、ネイティブメディアとインターフェイスの動作を計画し、@__CAPGO_KEEP_0__/__CAPGO_KEEP_1__-live-activities Using @capgo/capacitor-live-activities @capgo/capacitor-live-activities を使用して、@capgo/capacitor-live-activitiesのネイティブ機能を実装します。 @capgo/capacitor-live-activities を使用して、@capgo/capacitor-live-activitiesの実装詳細を実装します。 native能力を使用する@capgo/capacitor-video-playerの場合 @capgo/capacitor-video-player native能力を使用する@capgo/capacitor-video-playerの実装詳細については nativeナビゲーションを使用する@capgo/capacitor-native-navigation nativeナビゲーションを使用する@capgo/capacitor-native-navigationの場合
