簡単に言うと: 使用する expo-splash-screen を使用して、 config プラグイン における app.json または app.config.js アプリが実行されるのは Expo (dev clients と EAS ビルドを含む)。呼び出す SplashScreen.preventAutoHideAsync() における グローバルスコープ、次に SplashScreen.hideAsync() フォント、認証、ナビゲーションの準備が整った時点で。オン 素の React Native CLIでは、優先的に react-native-bootsplash 新しい開発に使用し、レガシーアプリは react-native-splash-screen 移行するまで維持してください。 ネイティブスプラッシュは静的に保ち、最初の実際の画面がレンダリング可能になったら非表示にし、 アニメーション付きスプラッシュ のブランディングは最初の React 画面に移行させます。Web 技術で構築していますか？ Capacitor は @capacitor/splash-screen を使用し、同じ準備完了ルールに従い、 Capgo ストアのビルドなしでWebレイヤーのライブアップデートを提供します。ネイティブのスプラッシュアセットには新しいバイナリが必要です。
実機でアプリのアイコンをタップすると、一瞬だけ白いフラッシュ、引き伸ばされたロゴ、または有用なコンテンツが準備できる前に消えるフリーズした起動画面が表示されます。このギャップを埋めるのが react native splash screen セットアップの目的です：JavaScriptが安定した最初のフレームを表示できるまでのネイティブ起動UI。
目次
- プロフェッショナルなスプラッシュ画面が重要な理由
- 完璧なスプラッシュ画面用アセットの準備
- Expo GoとDevelopment Clientワークフローでの実装
- Bare React Native CLI プロジェクトの設定
- アニメーションとパフォーマンスを両立するスプラッシュ画面の応用テクニック
- React Native vs Capacitor: スプラッシュスクリーンと修正のリリース
- スプラッシュスクリーンの一般的な問題のトラブルシューティング
- よくある質問
プロフェッショナルなスプラッシュ画面が重要な理由
ユーザーがホーム画面からアプリをタップすると、最初のUIが表示される前に白いフレームがちらつくことがあります。本番環境では、これは不安定さとして受け取られます。React NativeがまだJavaScriptバンドルを読み込んでいたり、バックグラウンドで状態を復元していたりしても、関係ありません。第一印象はすでに誤ったものになっています。
React Nativeでは、スプラッシュスクリーンはアプリが制御する最初のネイティブサーフェスです。プロセスの開始から最初の利用可能なReactレンダリングフレームまでの引き継ぎをカバーします。そのため、これは単なるブランディング資産ではなく、起動ツールです。タイミングを適切に調整すれば、ユーザーは意図的な安定した起動を感じます。早すぎると、認証、ナビゲーション、リモート設定が追いつくまでのレイアウトシフト、フォントの欠落、または無反応に見える画面が表示されます。
スプラッシュ画面が実際にやっていること
本番環境のスプラッシュ画面では、通常、起動時の4つの課題に対処する必要があります：
- ネイティブからJSへの起動処理をカバー： フォントの読み込み、永続化されたセッションの復元、フィーチャーフラグの読み取り、初期ナビゲーション状態が、最初のフレームを巡って競合します。
- 視覚的なグリッチの防止： システムの白画面の点滅、スタイル未適用のテキスト、あるいはルートビューが中途半端にマウントされた状態を防ぎます。
- 起動時の見た目の一貫性を保つ： 背景色とロゴをアプリのシェルに合わせれば、遷移が制御されているように感じられます。
- 起動時の判断を明確にする： チームは、スプラッシュ画面を消す前に「準備完了」の定義を決める必要があります。
実践的なルール： 最初の実画面が問題なくレンダリングできたら、任意の遅延を待たずにスプラッシュを隠します。
ここから、Expo管理型とbare CLI のワークフローが分岐し始めます。Expo管理型プロジェクトでは、スプラッシュ設定は主に宣言的であり、主なエンジニアリング上の判断は、アプリの準備状況に基づいて API の非表示をいつ呼び出すかです。bare React Native CLI プロジェクトでは、AndroidとiOSのネイティブ設定をより多く自身で管理するため、制御は強化されますが、起動時のちらつき、テーマの不整合、プラットフォーム固有の回帰問題を引き起こす要因も増えます。
このトレードオフは実際のプロジェクトで重要です。Expoは設定が速く、環境間で一貫性を保ちやすいです。bareプロジェクトは、アプリがカスタムネイティブモジュール、カスタム起動動作、または起動パスに対するより厳格な制御に依存している場合、適切な選択であることが多いです。
起動をプロダクト品質の一部として捉えるチームは、それを孤立したネイティブタスクとしてではなく、より広範なUX作業と並んでレビューします。これは、で説明されているのと同じマインドセットです。 Capgo のアプリユーザー体験ガイド。もしあなたが React Native と Capacitor のどちらをグリーンフィールドアプリに採用するか検討しているなら、 React Native と Capacitor の比較 起動ツールを確定する前に、Capacitor チームはネイティブプロジェクトおよびでスプラッシュ画面を設定します。 @capacitor/splash-screen アプリ初期化時に、以下のガイドに示されているように Capacitor アプリ初期化ガイド.
完璧なスプラッシュ画面用アセットの準備
ほとんどのスプラッシュスクリーンのバグは、code ではなくデザインファイルから始まります。ベースアセットが間違っていれば、Android XML や iOS ストーリーボードをどれだけ整えても解決しません。
最も安全なアプローチは、スプラッシュを単一のフルスクリーン画像ではなく レイアウトシステムとして扱うことです。背景色と中央に配置されたロゴまたはイラストを使用してください。これは、細部まで描き込まれたポスター風の1枚の画像をどこにでも合わせるよりも、縦長のAndroidデバイス、iPhone、タブレット、および横長のデバイス方向でより予測可能にスケーリングされます。
コーディング前に準備すべきこと
デザインからクリーンなソースファイルを用意しましょう。書き出した起動アセットがPNGであっても、受け渡しにはベクター形式が理想的です。
以下のチェックリストを活用しましょう：
- ソースアートワーク: 書き出しの整合性を保つため、マスターロゴやマークはSVG、AI、またはその他の編集可能なソース形式で保持してください。
- 背景色: スプラッシュ画面の背景色を事前に正確に定義し、最初の画面やアプリシェルの背景色と一致させておきましょう。
- セーフマージン: ロゴの周囲に十分な余白を残し、特殊なアスペクト比で強くトリミングされてもデザインが欠けないようにしてください。
- プラットフォーム別のバリエーション: 一つのファイルを無理に引き伸ばすのではなく、ワークフローに必要な画像サイズをそれぞれ書き出しましょう。
- ダークモードの確認: アプリがダークモードに対応している場合、選択した背景に対してロゴが鮮明に読めるか確認してください。
Expo のガイドラインは、ローンチアセットが後付けではなく build pipeline の一部であることを強調しているため、ここで役立ちます。ドキュメントでは 正方形の 1024×1024 PNG をアプリアイコンに推奨し、EAS Build が必要なサイズを生成できることに触れています。 npx create-expo-app、アセット生成が手動の繰り返しからモダンなツールチェーンに移行したことを示しています。
よくあるアセットのミス
最も一般的なビジュアル上の失敗は予測可能です：
| 問題点 | 考えられる原因 | より良いアプローチ |
|---|---|---|
| ぼやけたロゴ | 低解像度のラスターから書き出されたもの | ベクターソースから再エクスポート |
| 端が切れる | アートワークが境界に近すぎる | セーフパディングを増やす |
| 引き伸ばし | フルスクリーン画像がさまざまなアスペクト比に無理やり合わせられる | 背景色と中央寄せの画像を使う |
| トランジションの不一致 | スプラッシュの背景が最初の画面と異なる | 起動画面とアプリ本体の色を合わせる |
スプラッシュ画像には、密度の高いテキストや細かいディテール、宣伝コピーを載せるべきではありません。起動画面は一瞬しか表示されず、ネイティブの厳しい制約下でレンダリングされるためです。
頻繁にビジュアルアップデートを配信するチームにとって、画像の管理は起動画面だけの話ではありません。同じ習慣は配信bundleやバイナリサイズにも当てはまります。だからこそ、次のようなガイドが役立ちます。 アップデート用画像の最適化 アセットのエクスポートを標準化する際に確認すべき点です。
実用的なエクスポートワークフロー
実際のプロジェクトでうまく機能するセットアップは次のようなものです：
- 中央に配置した構図を1つデザインし、 背景は無地にします。
- 透過PNG形式のロゴを書き出します。 ワークフローで背景色を別途指定できる場合。
- 命名規則を統一しましょう。 プラットフォーム間で名前を揃えることで、アセットの差し替えミスを防げます。
- 小型・縦長のシミュレーターで早めにテストする スプラッシュのライフサイクルを実装する前に。
- アセットを変更したら再ビルドする 起動時のリソースはネイティブキャッシュに保持されることが多いためです。
この最後の点は、予想以上に重要です。設定ミスに見えるスプラッシュ画面の問題の多くは、単にネイティブアセットが古いだけであることがよくあります。
Expoのスプラッシュ画面（expo-splash-screen)
を探しているなら expo splash screen または React Native Expo スプラッシュ画面から始めましょう。 expo-splash-screen このパッケージは、managed ワークフローと prebuild ワークフローの両方に適しており、起動アセットを config に保持し、ストアビルドで表示を制御するための JavaScript API を公開します。
理解すべき重要な動作はシンプルです。 最初の意味のある UI フレームが準備できるまで、ネイティブの splash を表示し続けます。 Expo は preventAutoHideAsync() をドキュメント化しており、設定された splash が呼び出されるまで表示され続けます。 hideAsync()。 preventAutoHideAsync() グローバルスコープで await なし、フック内ではなく、そうしないと code が実行される前にスプラッシュが自動的に非表示になる可能性があります。早すぎる非表示は、iOS と Android で一瞬だけ白画面を表示させる原因になります。
読み込み中にスプラッシュを維持 (Expo)
これは通常 React Native ローディング画面 パターンです: ネイティブスプラッシュがフォントの読み込み、永続化された認証、リモート設定をカバーし、React が返すまで null。 isReady が true になると、 hideAsync()を呼び出します。任意の SplashScreen.setOptions() は非表示時のフェード動作を調整します。スプラッシュアセットは 開発クライアント, プレビュー、または 本番 build; Expo はそれが Expo Go ネイティブスプラッシュ設定の権威ある環境ではないと明記しています。
ネイティブのスプラッシュ画面を宣言的に設定する
Expoプロジェクトでは、見た目の部分は通常 app.json, app.config.js、または app.config.ts の下の expo-splash-screen config pluginについては、 Expo のスプラッシュスクリーンとアプリアイコンガイド.
一般的な app.json セットアップは以下の通りです：
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}フィールドの詳細はプロジェクト構成によって異なりますが、パターンは同じです。configでネイティブの起動時の見た目を定義し、JavaScriptから表示を制御します。
ここでは、いくつかの実用的な選択肢が重要になります：
- 初期画面に近い背景色を使用する これにより、遷移がスムーズに感じられます。
- 画像はシンプルなものにする 起動画面は、細かいアートワークを詰め込む場所ではないからです。
- 不自然なブランディングによる遅延を防ぐ アプリの準備ができているのに、ロゴ表示でユーザーを待たせるような
時間ではなく、準備完了状態に基づいてスプラッシュ画面を隠す
多くのチュートリアルは、しばしば脱線します。それらは setTimeout、デモは簡単でも本番には不向きです。
代わりにstartup stateを使いましょう。よくあるルートレベルのパターンは次のとおりです：
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>
);
}このパターンを信頼できるものにするポイントは2つあります。
まず、 preventAutoHideAsync() は、アプリが意味のあるUIを描画し始める前に呼び出されます。2つ目に、非表示はルートビューがレイアウト可能になった後にのみ行われるため、ネイティブsplashとReactツリーの間でちらつきが起きる可能性を減らせます。
非同期処理が終わりかけているタイミングでsplashを隠さないでください。その処理に依存するUIが実際に描画できるようになってから隠しましょう。
この違いは、起動時に認証状態の復元、リモート設定、フォントの読み込みなどを行う場合に特に重要です。ホーム画面がカスタムフォントやサインイン状態に依存しているなら、splashはその間をカバーすべきです。
React Nativeの起動とスタートアップを取り巻く、より広いエコシステムの有用なウォークスルーは以下です：
Expo Goとdev buildsで期待できること
Expoにはもう1つ注意点があります。スタンドアロンビルドで期待するスプラッシュの挙動は、Expo Goで見えるものと一致しないことがあります。
この不一致は多くのチームを混乱させます。アセットやタイミングのロジックを変更してExpo Goでテストし、設定が壊れていると判断してしまいますが、実際の問題は開発環境が本番バイナリと同じ挙動をしないことにあります。
次のメンタルモデルで考えてください：
- Expo Goはイテレーションに便利です ただし、ネイティブのスプラッシュ挙動について最終的な判断基準ではありません。
- Development clientsの方が実態に近いです。 生成済みのネイティブプロジェクトが含まれているからです。
- Standalone buildsが最終確認です。 起動タイミング、テーマの挙動、アセットの正確性を確認するためです。
スプラッシュ画面がまだちらついたり、長く残ったりする場合、バグは通常次の3つのいずれかです：非表示にするのが早すぎる、レンダリング null 非表示にした後も長時間表示される、またはリリース時の挙動を反映していない環境でテストする
Bare React Native CLI スプラッシュスクリーン
Bare React Native アプリを使用すると、起動時の挙動を直接制御できます。また、 新しい Bare CLI プロジェクト, react-native-bootsplash は、メンテナンスされている選択肢です（2026年まで活発にリリースされ、現在の React Native サポートポリシーに沿っています）。多くのプロダクションアプリが今も出荷しています react-native-splash-screen；それとして扱う レガシー保守 すでに統合済みでない限り。
アニメーション付きスプラッシュ画面（React Native または Expo）： iOSと LaunchScreen.storyboard 静的なままです。Android 12 以降では、短い アニメーション付きベクターアイコン をシステムスプラッシュに表示できますが、 expo-splash-screen ほとんどの素の CLI セットアップではまだ 静的な PNG を使用し、動きを最初の React 画面（Lottie など）に移します。起動処理が完了したらネイティブスプラッシュを非表示にし、そこでアニメーションを実行します。参考： Capacitor アプリでのアニメーションパフォーマンス 別のスタックでも同じ起動規律を維持するために。
CLI プロジェクトでは、ネイティブ引き継ぎの目標は変わりません。起動UIを即座に表示し、意味のあるUIがレンダリング可能になった後にのみ非表示にします。
BareプロジェクトでのAndroidセットアップ
Androidのスプラッシュ設定は、テーマリソースやdrawableなど複数の場所に分散しています。 AndroidManifest.xmlや MainActivityこの分散構造が原因で、小さなミスが視覚的なフラッシュを引き起こします。
一般的なフローはシンプルです：
- サポートしているAndroidのリソースフォルダ向けに、スプラッシュ用アセットを生成します。
- 正しい背景色とスプラッシュ用のdrawableを指定して、起動テーマを定義します。
- そのテーマを以下のlauncher activityに適用します：
AndroidManifest.xml. - 以下の場所でスプラッシュ画面を初期化します：
MainActivity. - 初回レンダリングをブロックする起動タスクが完了した後、JavaScriptからスプラッシュを非表示にします。
簡略化された MainActivity.kt パターンは、通常以下のようになります：
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}呼び出し方法はライブラリによって異なるため、このスニペットはあえて汎用的にしています。ネイティブ側の統合はたいてい簡単な部分です。つまずきやすいのはリソースとテーマの遷移です。
本番環境で発生しやすいAndroidの問題は以下の通りです：
- テーマの不一致： 起動テーマの背景色がアプリの最初の画面と異なると、画面の切り替え時に一瞬チラつきが発生します。
- アセットのバケット指定ミス： Androidは、期待される密度フォルダに存在しないアセットをストレッチまたはぼかし処理します。
- Metroでのみテストする場合: ネイティブリソースの変更には通常、クリーンな再ビルドが必要です。ホットリロードでは起動時の動作を検証できません。
- Android 12の起動ルール: 新しいAndroidバージョンでは、まず独自のスプラッシュ動作が適用されるため、カスタム設定ではこれらのプラットフォーム制約を尊重する必要があります。
- hide後のJSが遅い: Reactがルートビューの描画前にスプラッシュを非表示にすると、スムーズな遷移の代わりに空白フレームが表示されます。
最後のポイントは、画像そのものよりも重要です。タイミングの問題は、通常、パフォーマンスの問題として認識されます。
iOSのセットアップ（ベアプロジェクト）
iOSでは、重心は LaunchScreen.storyboard に加えて、 AppDelegate内の小さなネイティブフックです。プラットフォームは、起動画面が静的で軽量であることを期待しています。ミニオントボーディングフローではなく、最初の画面のビジュアル構造のスナップショットとして扱ってください。
信頼できるセットアップは次のようになります:
- アセットをXcodeのアセットカタログに追加します。
- 設定
LaunchScreen.storyboardシンプルな制約付きで。 - レイアウトは静的に保ちましょう。背景色、ロゴ、適切な余白があれば十分です。
- ライブラリのネイティブブートストラップ呼び出しを
AppDelegate. - アプリが完全にレンダリングできる状態になってから、JavaScriptでスプラッシュを非表示にします。
iOSに慣れていないチームは、ストーリーボードを作り込みすぎる傾向があります。これはたいてい裏目に出ます。複雑な制約、ネストしたビュー、起動画面のアニメーションなどは、メンテナンスを難しくし、デバイスサイズごとに壊れやすくします。
シンプルな起動画面の方が安全な選択です。
Bare CLI なら、ハンドオフをより細かく制御できます
これがExpo管理型とBare CLIの主な違いです。Expoは正しいデフォルト設定に早く到達できます。Bareではネイティブ起動パイプラインのすべてを自分で管理する必要があります。
起動時にバンドルの読み込み以外の処理を行う場合、このトレードオフが活きます。認証の復元、暗号化ストレージの読み取り、カスタムネイティブSDKの初期化、ホワイトラベルのブランディングルールなどがあるアプリは、追加の制御が必要になることがよくあります。Bareプロジェクトなら、すべてを高レベルの設定に押し込めるのではなく、スプラッシュのタイミングをその処理に合わせられます。
起動後にアニメーションのトランジションを追加する予定なら、iOSではネイティブスプラッシュを静的に保ち、Androidでは意図的にAndroid 12のアニメーションアイコンを設定しない限り静的アセットを使いましょう。モーションは最初のReact画面に移してください。パフォーマンスのトレードオフは、モバイルの起動パス全般で重要な点と似ています。最初のペイント中の重い処理はコストがかかります。これは Capacitorアプリのアニメーションパフォーマンスガイド 別のスタックから同じ原則を扱い、その教訓はReact Nativeにもそのまま適用できます。
Expo管理型とBare CLI
実用的な比較は、画像表示よりも、起動時の複雑さがどこにあるかという点にあります。
| 判断ポイント | Expo管理型 | Bare CLI |
|---|---|---|
| セットアップ速度 | 初期セットアップが速い | ネイティブ作業が多い |
| ネイティブのカスタマイズ | より制約が多い | 完全な制御 |
| アセット生成フロー | より宣言的 | より手動 |
| デバッグ範囲 | JS設定 + 生成されたネイティブ層 | Android/iOSファイルを直接 |
| 最適 | スピードと一貫性を重視するチーム | ネイティブを深く制御する必要があるチーム |
アプリがすでにExpoにあり、起動要件が標準的な場合は、そのままExpoを使う方が通常は時間を節約できます。起動パスがネイティブの初期化順序、カスタムテーマ、プラットフォーム固有のブートロジックに依存する場合は、bare CLI の方が長期的にクリーンな選択となることが多いです。
どちらのワークフローでも、洗練されたスプラッシュ画面を実現できます。違いは、起動パイプラインをフレームワークが管理するか、チームが管理するかという点にあります。
アニメーションとパフォーマンスを両立するスプラッシュ画面の応用テクニック
アニメーション付きのスプラッシュ画面は、起動パイプラインに沿っていれば洗練されて見えます。邪魔になると安っぽく見えます。
だからこそ、私はアニメーションを基盤ではなく拡張レイヤーとして扱います。最初にやるべきことは、今もタイミングです。アプリの準備ができていなければスプラッシュは表示したままにし、準備ができたら最初に使える画面へ素早く遷移させるべきです。
アニメーションは起動の実態に合わせるべき
一般的なパターンは、ネイティブのスプラッシュはシンプルに保ち、起動後の最初のReact画面で軽量なブランドアニメーションを実行することです。これなら、ネイティブの起動画面そのものをアニメーションさせようとするよりも、柔軟性が高まります。
Lottieはこの種のハンドオフにおいて実用的な選択肢です。最初の画面で重いカスタムアニメーションスタックを構築することなく、動きを実現できるからです。重要なのは順序です：
- 重要な起動処理の間は、ネイティブのスプラッシュを表示し続ける。
- Reactが最初の実際の画面、または制御された遷移用の画面をマウントする。
- 任意のアニメーションは、必要以上に操作を妨げない場合にだけ再生する。
うまくいかないのは、従来のような setTimeout(2000) パターンです。高速なデバイスでは理由もなくアプリを待たせることになり、低速なデバイスではローディング状態が別のローディング状態に置き換わるだけになりがちです。
起動をオーケストレーションとして捉える
より良いメンタルモデルは 起動時のオーケストレーション。スプラッシュ画面は、アプリが意味のあるコンテンツを表示できるようになる前に完了すべきタスクを正確にカバーする必要があります。
通常は、次のような組み合わせが含まれます：
- 認証ブートストラップ： セッションの復元、またはサインインへルーティングするかどうかの判断。
- 必須ストレージの読み取り： テーマ、ロケール、オンボーディング状態、最後に確認された重要な設定。
- フォントの準備完了： 特に、最初の画面がレイアウトの安定性のためにカスタムタイポグラフィに依存している場合。
- UIの表示を制御するリモート設定： 最初の画面がそれなしで安全にレンダリングできない場合のみ。
多くのチュートリアルが見落としがちなもう一つのニュアンスがあります。スプラッシュ画面の動作は環境によって変わります。 Expoでの開発環境と本番環境におけるスプラッシュ画面処理について Expo Goとスタンドアロンビルドでは挙動が異なる場合があること、また手動制御に切り替えると自動表示管理が変わることを指摘しています。これが、遅延ベースのサンプルがすぐに陳腐化する理由の一つです。実際の起動シーケンスに合わせるのではなく、それを隠蔽してしまうためです。
スプラッシュ画面は速度を偽装するために使うべきではありません。未完成のUIをユーザーに見せないために使うべきです。
ハイブリッドスタックでモーションを追加する場合、またはより広いレンダリングパフォーマンスを評価する場合、 Capacitorアプリにおけるアニメーションパフォーマンスに関するこのガイド は有用な文脈です。同じ規律が適用されるためです。起動時の処理をスリムに保ち、不要なブロッキングを避け、アニメーションがレスポンシブネスと競合するのではなくそれを支えるようにしてください。
バイナリリリース以外でビジュアル修正をリリースするチーム向けの実際的な注意点として、 Capgo のようなプラットフォームはCapacitorおよびElectronアプリのJavaScript、CSS、コピー、設定、アセットの更新を処理しますが、React Nativeのネイティブスプラッシュ変更は、JavaScriptアプリの実行前に真のスプラッシュ画面が表示されるため、依然としてネイティブビルドパイプラインに属します。
React Native vs Capacitor: スプラッシュ画面と修正のリリース
新しいアプリを開始している、またはチームがすでにReact、Vue、Angular、SvelteのWebアプリを持っているためにこの記事を読んでいるなら、スプラッシュ画面がどのように動作するかを比較する価値があります。 Capacitor。ネイティブの起動画面の考え方は同じですが、Web チームの日々のワークフローはよりシンプルです。
Capacitor のスプラッシュ画面
Capacitor アプリは公式の @capacitor/splash-screen プラグインを使用します。設定は一度 capacitor.config.ts で行い、アプリの準備ができたら Web の code から非表示にします：
// 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()このガイドの準備完了のルールも同じです。ネイティブのスプラッシュは静的なままにし、最初の実際の画面が描画できるようになったら非表示にし、アニメーションはアプリの最初の画面で行います。ネイティブアセットについては、 @capacitor/assets がソースのアイコンとスプラッシュ画像から Android と iOS のアイコンとスプラッシュファイルを生成します icon-only.png と splash.png （例えば assets フォルダ内）。ステップごとの流れは Capacitor アプリの初期化.
Web チームが React Native ではなく Capacitor を選ぶ理由
- 既存のアプリを再利用: Capacitorは既存のWebアプリをネイティブシェルでラップするため、コンポーネント、CSS、ビルドツールがそのまま動作します。React NativeではUIをReact Nativeコンポーネントで書き直す必要があります。
- 任意のフレームワーク: React、Vue、Angular、Svelte、またはプレーンなJavaScriptがすべて動作します。Reactに縛られることはありません。
- 必要なときにネイティブアクセス: 公式およびコミュニティプラグインがカメラ、プッシュ、生体認証などをカバーし、独自のSwiftまたはKotlinプラグインも作成できます。
- アプリレイヤーのライブアップデート: を使用して Capgo、JavaScript、HTML、CSS、アセットの修正を次の起動時にユーザーに配信できます。チャネル、段階的ロールアウト、ワンクリックロールバックに対応し、Webレイヤーの各変更でストアレビューを待つ必要はありません。ネイティブ変更（ネイティブスプラッシュスクリーン自体を含む）は、引き続きストア経由で配信されます。詳細は Capgoライブアップデートのドキュメント.
パフォーマンス、ツール、チーム適合性の完全な比較については、こちらをお読みください React Native と Capacitor の比較。現在Expoを使っていて、移行を検討しているなら、 Expoの代替手段 選択肢を解説しています。
スプラッシュスクリーンのよくある問題のトラブルシューティング
スプラッシュの問題のほとんどは、いくつかの定番の原因に集約されます。切り分けて考えれば、修正は簡単になります。 アセットの問題, タイミングの問題や ネイティブ統合の問題.
最近のReact Nativeガイドで見られるコミュニティのパターンは、同じ基本的な流れに収束しています。ライブラリを追加し、ネイティブの起動アセットを設定し、呼び出し show を起動時に行い、アプリの準備が整ったら非表示にします。Androidのセットアップでは通常、 MainActivity に加えて XML や drawable リソース、一方 iOS は LaunchScreen.storyboard と AppDelegate。同じ概要では、Expo は正方形の 1024×1024 PNG をアプリアイコンに推奨し、EAS Build がプロジェクトに必要なサイズを生成できると述べています npx create-expo-appとしており、 このReact Nativeスプラッシュ画面ガイド.
スプラッシュ画像が引き伸ばされる・ぼやける
症状: ロゴがぼやけたり、切れたり、不自然なサイズで表示される。
原因: ベース画像が正しくエクスポートされていないか、全画面のラスタ画像に依存したレイアウトがうまく適応していない。
解決策: ポスターのようなアートワークではなく、フラットな背景の中央にロゴを置く形式に変更してください。元のデザインソースから再エクスポートし、密度ごとのアセットを再生成した上で、AndroidのdrawableやiOSのasset catalogに意図したファイルが含まれているか確認してください。
スプラッシュ画面が消えた後に白い画面が表示される
症状: ネイティブのスプラッシュ画面が消えた後、最初の画面が表示されるまでの間に空白のフレームが見えてしまう。
原因: ルートUIが意味のあるコンテンツを描画できる前に、アプリがスプラッシュを非表示にしています。
解決策: スプラッシュの非表示は経過時間ではなく、準備完了に紐付けましょう。Expoでは、ルートビューがレイアウト可能になるまでスプラッシュを保持するのが一般的です。bareプロジェクトでは同様のパターンを使用し、最初に表示される画面が即座に追加の非同期処理でブロックされないようにしてください。
あるプラットフォームでスプラッシュが表示されない
症状: Androidでは表示されるがiOSでは表示されない、またはその逆。
原因: ネイティブ側の設定が完全に終わっていなかったケースです。よくある原因は、storyboard の参照が抜け落ちていること、テーマの配線ミス、またはアセットが正しいターゲットに追加されていないことです。
解決策: プラットフォーム固有のファイルを1つずつ確認してください。Android では、起動テーマとリソース参照を調べます。iOS では、 LaunchScreen.storyboardアセットカタログのメンバーシップと Xcode でのアプリターゲット設定を確認します。
スプラッシュ設定の追加後にビルドが失敗する
症状: ライブラリを導入したりスプラッシュファイルを変更した後、アプリがコンパイルできなくなる。
原因: ネイティブプロジェクトのファイルと生成された設定は、特にプラグインやアセットの変更後に同期がずれることがあります。
解決策: クリーンビルドを行い、必要なら依存関係を再インストールして、ネイティブプロジェクトを完全にリビルドしてください。生成されたネイティブレイヤーを使うExpoの場合は、慎重に再生成してプラグイン設定を確認してください。bareアプリの場合は、 MainActivity, AppDelegateリソース名や plist・manifest の編集内容に小さな不整合がないか見直してください。
動きの速いチームは、スプラッシュ画面を一度きりのビジュアル作業ではなく、リリースエンジニアリングの一部として扱っています。リリース後に起動アセットやUIテキスト、アプリシェルの挙動を素早く変える必要があるなら、なおさらです。 Capgo により、Capacitor や Electron のチームは、ロールアウト制御とロールバック対応を備えた形で、JavaScript、CSS、コピー、設定、アセットの修正を次回起動時に配信できます。問題がネイティブの起動画面自体ではなくアプリレイヤーにある場合に有効です。
よくある質問
Expo (expo splash screen) にスプラッシュスクリーンを追加するには？
次を追加します： expo-splash-screen プラグインを app.json または app.config.js、設定する backgroundColor と image、ネイティブバイナリを再ビルドし、 preventAutoHideAsync() グローバルスコープで、かつ hideAsync() 最初の画面が準備できたタイミングです。Expo Go だけでなく、開発クライアントや本番ビルドで検証してください。
React Native アプリの読み込み中、スプラッシュスクリーンを表示し続けるには？
Expo では、 preventAutoHideAsync() および返却 null 非同期処理が完了するまで、その後 hideAsync()。 react-native-splash-screen、呼び出し SplashScreen.show(this) Android では MainActivity または [RNSplashScreen show] iOS では AppDelegate、次に SplashScreen.hide() 準備が整ったら JavaScript から。 react-native-bootsplash、プラットフォームごとにネイティブで初期化し、次に BootSplash.hide() を同じ準備完了ゲート後に呼び出します。
react-native-splash-screen と react-native-bootsplash の違いは何ですか？
Bootsplash はアクティブにメンテナンスされており、起動アセット用のジェネレーターを同梱しています。 react-native-splash-screen は古いリポジトリではまだ一般的ですが、メンテナンスは遅れています。新しい bare CLI アプリでは bootsplash を推奨します。
Expo を使わずに bare React Native でスプラッシュスクリーンを設定するには？
インストール react-native-bootsplashでアセットを生成し、 RNBootSplash.init(this, R.style.BootTheme) Android では、 RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) iOS では、 BootSplash.hide() 起動完了時に JS から表示します。レガシープロジェクトでは SplashScreen.show(this) / [RNSplashScreen show] を使用して SplashScreen.hide() を使用できます。ネイティブアセットを変更した後は再ビルドしてください。
React Native や Expo でアニメーション付きスプラッシュスクリーンは使えますか？
オンラインに iOSとでは、起動画面は静的に保ちます。 Android 12以降では、システムスプラッシュで短いアニメーションアイコンが使えますが、ほとんどのチームは expo-splash-screen や bootsplash アセットを静的にし、準備が整ったら非表示にしてから React でアニメーションさせます（例: Lottie）。 setTimeout ローディング時間を偽装するために。
React Native と Capacitor でスプラッシュスクリーンの設定はどのように異なりますか？
React Native は expo-splash-screen または JS 実行前にネイティブの CLI ライブラリを使用します。Capacitor はネイティブの起動画面に加えて @capacitor/splash-screen を WebView スタック内で使用します。詳細は React Native と Capacitor の比較 と Capacitor アプリの初期化.
Capgo で Capacitor アプリをより速くリリース
Capacitor で開発中、または Web アプリをモバイルに移行する予定ですか？ 無料の Capgo アカウントを作成 数分で最初の live update をプッシュできます。Capgo は、段階的なロールアウトと即時ロールバックを備え、次の起動時に JavaScript、CSS、アセットの修正をユーザーに配信します。アプリ層のバグでも、ストアのレビューを待つ必要はありません。
React Native スプラッシュスクリーン（Expo と bare CLI）から続けます
使用している場合 このガイド ネイティブメディアとインターフェースの挙動を計画するには、次と連携させてください @capgo/capacitor-live-activities の使用 @capgo/capacitor-live-activities の使用におけるネイティブ機能については、 @capgo/capacitor-live-activities @capgo/capacitor-live-activities の実装の詳細については、 @capgo/capacitor-video-playerの使用方法 @capgo/capacitor-video-player の使い方におけるネイティブ機能については、 @capgo/capacitor-video-player @capgo/capacitor-video-player の実装の詳細、および @capgo/capacitor-native-navigation の活用 @capgo/capacitor-native-navigation. の使い方におけるネイティブ機能については
