実機でアプリのアイコンをタップすると、ユーザーは白いフラッシュ、引き伸ばされたロゴ、または凍結した起動画面が一瞬で消え、ユーザーは何も役に立たないものが表示されるのを待つことになる。通常、React Nativeアプリはプロダクショングレードのものと感じられなくなるのがその時だ。
React Nativeのスプラッシュスクリーンは、ブランドの問題を解決するものだけではない。ネイティブの起動と最初の意味のあるReactレンダリングフレームの間のギャップをカバーする。開発クライアントのExpo Goと実際のストアビルドの間の違いについても考える必要がある。タイミングを間違えると、ユーザーはすぐに亀裂を感じることになる。
目次
- プロフェッショナルなスプラッシュスクリーンはなぜ重要か
- パーフェクトなスプラッシュスクリーンアセットを用意する
- エクスポーゴと開発クライアントワークフローで実装する
- バーレイアクトネイティブプロジェクトのCLIの設定
- アニメーションされたおよびパフォーマントなスプラッシュスクリーンの高度なテクニック
- 一般的なスプラッシュスクリーン問題のトラブルシューティング
プロフェッショナルなスプラッシュスクリーンはなぜ重要か
A user taps your app from the home screen, and the launch sequence shows a blank white frame before the first UI appears. In production, that reads as instability. It does not matter that React Native is still loading the JavaScript bundle or restoring state in the background. The first impression is already wrong.
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は、設定が速く、環境間で一貫性が保たれるため、より適切です。Bareプロジェクトは、既存のカスタムネイティブモジュール、カスタムローンチ動作、起動パスの厳格な制御など、依存しているアプリケーションに適しています。
ローンチを製品の品質の一部として扱うチームは、より広範なUXワークとともに、ローンチをレビューします。ローンチを孤立したネイティブタスクとして扱うのではなく、__CAPGO_KEEP_0__のアプリユーザー体験ガイドでカバーされている同じ考え方です。 Capgoのアプリユーザー体験ガイドを参照してください。React Nativeスタックのより広範な評価を行う場合、または新しいアプリまたは移行の評価を行う場合、NerdifyのReact Nativeアプリの製品フォーカスされた概要は、有用なものです。 ローンチ画面のパーフェクトなアセットを準備する ほとんどのローンチ画面のバグは、設計ファイルから始まります。__CAPGO_KEEP_0__の基礎アセットが間違っていると、Android XMLまたはiOSストーリーボードのクリーンアップでも救うことはできません。
__CAPGO_KEEP_1__
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.
最も安全なアプローチは、スプラッシュをレイアウトシステムとして扱うことです。 レイアウトシステム背景色と中央に配置されたロゴまたはイラストを使用することが推奨されています。
モバイル アプリのスプラッシュ スクリーン アセットを設計するための 4 つの基本要件を示すチェックリストです。
コードを書く前に準備するもの
デザインから始めて、クリーンなソース ファイルを使用します。ベクターはハンドオフに最適です。exported の起動アセットは PNG である場合でも。
- このチェックリストを使用してください。 ソース アートワーク:
- マスター ロゴまたはマークを SVG、AI、または編集可能なソース形式で保持して、exported の export が一貫性を保つようにします。 背景色:
- スプラッシュの背景色を最初に定義し、最初の画面またはアプリ シェル背景と一致するようにしてください。 ロゴの周りに十分な空間を残して、不規則なアスペクト比でアグレッシブなクロッピングがデザインに影響を与えないようにします。
- プラットフォームバリアント: 必要なワークフローで使用する画像サイズをエクスポートするのではなく、1 つのファイルをすべて拡張するのではなく、ファイルを伸ばさないようにします。
- ダークモードレビュー: アプリがダークサーフェスをサポートしている場合、選択した背景に対してロゴが読みやすく表示されることを確認します。
Expo のガイドラインはここで役立ちます。ロゴはビルドパイプラインの一部であるため、後悔の念を伴うものではなくなりました。ドキュメントでは、1024×1024 の正方形の PNG をアプリアイコンとして推奨しています。また、EAS ビルドは、Capacitor を使用してプロジェクトを作成した場合に必要なサイズを生成できることを示しています。これは、現代のツールでアセットの生成が手動の繰り返しから移行したことを示しています。 共通のアセットの誤り 最も予測可能な視覚的な失敗は: npx create-expo-app問題
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
| __CAPGO_KEEP_2__ | 原因の可能性 | より良いアプローチ |
|---|---|---|
| ぼやけたロゴ | 低解像度のラスターからエクスポートされた | ベクターのソースから再エクスポート |
| カットされたエッジ | アートワークが境界線に近すぎる | 安全なパディングを増やす |
| 引き伸ばし | フルスクリーン画像が多くのアスペクトレシオに強制される | 背景色と中央の画像を使用 |
| トランジションが一致していない | 背景画像と最初の画面の背景は異なる | 起動とアプリシェル色を揃える |
背景画像には密集したテキスト、小さな詳細、またはマーケティングコピーを含めるべきではない。起動画面は短時間しか表示されず、厳しいネイティブ制約の下でレンダリングされる。
頻繁なビジュアルアップデートを実施するチームにとって、画像の規律は起動画面のことだけに限られない。同様の習慣は、配信バンドルとバイナリサイズにも適用されるため、標準化されたアセットのエクスポートを規定する際に参考になるガイドは 更新用に画像を最適化する 実用的なエクスポートワークフロー
実際のプロジェクトで機能するように設定する
背景が明るい色の場合、中央に配置された単純な背景の構成を設計する
- 背景色が分離できる場合、透過可能なロゴPNGをエクスポートする __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
- 一貫性の命名を維持する プラットフォームをまたいだため、資産の交換が推測に頼ることになることはありません。
- 小さなシミュレータと高さのあるシミュレータでテストする スプラッシュライフサイクルを組み立てる前に
- 資産の変更後は再構築する 資産が古い場合、スプラッシュ画面の問題が設定の問題のように見えることがよくあります。
Expo Goと開発クライアントのワークフローで実装する
Expoを使用している場合、まず
を使用します。 expo-splash-screen管理されたワークフローに適合し、設定のほとんどが宣言的で、スプラッシュがどの時点で終了するかを明確に制御することができます。
理解する必要があるのは単純です。 native splash を表示し続け、最初の意味のある UI フレームが準備されるまで。 Expoの SplashScreen APIはそのパターンを完全にサポートしています。 preventAutoHideAsync() 起動時と hideAsync() クリティカルなロードが完了した後、ExpoはiOSとAndroidの両方のビルドで短時間の間、画面が空白になることを警告しています。これは、ドキュメントに記載されているExpoのスプラッシュスクリーン__CAPGO_KEEP_0__に記載されています。 Expo splash screen API.
Expo プロジェクトでは、視覚的な側面は通常、
または app.json 上記のコンテキスト: HTML テキスト フラグメント (親キー `alternatives_cta_questions`)。ページ/エリア: Capacitor ライブアップデートの代替比較ページ。役割: 長いマーケティングまたは法的文章。見つける場所: page alternatives.astro。Capgo の製品/ブランドと開発者用語を完全に保持する。メッセージキー `alternatives_cta_questions` (代替 CTA 問題)。 app.config.js.
上記のコンテキスト: HTML テキスト フラグメント (親キー `appflow_cta_questions`)。ページ/エリア: Appflow の比較/移行マーケティングコピー。役割: 長いマーケティングまたは法的文章。見つける場所: page ionic-appflow.astro。Capgo の製品/ブランドと開発者用語を完全に保持する。メッセージキー `appflow_cta_questions` (Appflow CTA 問題)。 app.json 上記のコンテキスト: HTML テキスト フラグメント (親キー `capwesome_cta_questions`)。ページ/エリア: Capawesome の比較ページ。役割: 長いマーケティングまたは法的文章。見つける場所: page capwesome.astro。Capgo の製品/ブランドと開発者用語を完全に保持する。メッセージキー `capwesome_cta_questions` (Capwesome CTA 問題)。
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}上記のコンテキスト: HTML テキスト フラグメント (親キー `consulting_faq_subtitle`)。ページ/エリア: コンサルティング サービス ページ。役割: セクションサブタイトルまたはタグライン。見つける場所: page consulting.astro。Capgo の製品/ブランドと開発者用語を完全に保持する。メッセージキー `consulting_faq_subtitle` (コンサルティング FAQ サブタイトル)。
実際的な選択肢が数点あるので、ここでは以下の点を考慮する必要があります。
- 背景色を初期画面に近い色に設定してください。 トランジションが連続的であるように感じる。
- イメージを単純に保つ launch surfaces では濃いアートワークは置いていない方がいい。
- 偽の「ブランド遅延」回避 ロゴを表示してユーザーを待たせる機能です。
Splash スクリーンは、準備が整ったときに非表示にするべきです。
React Nativeのチュートリアルはよく誤解を招くことがあります。 setTimeout、デモでは簡単ですが、実用には適していません。
起動状態を使用する。一般的なルートレベルパターンは次のようになります。
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 つの詳細からである。
最初は、意味のあるUIがレンダリングされる前に呼び出されます。2つ目は、root viewがレイアウトを準備できるようになるまで、native splashとReact treeの間のフラッシュの可能性を最小限に抑えるために、hideが発生するのはその後です。 preventAutoHideAsync() アシンクロナス作業が終了するのを待つのではなく、UIがその作業に依存する場合にのみ、splashを非表示にします。
起動に認証の復元、リモート設定、フォントの読み込みが含まれる場合、起動が最も重要なのはその時です。ホーム画面がカスタムフォントと署名済みの状態に依存している場合、splashはそのギャップをカバーする必要があります。
より広いReact Nativeのランディングと起動エコシステムの概要についての有用なウォークスルーは以下のとおりです。
Expo Goとdevビルドで期待されるもの
Expoは1つの追加のジレンマを追加します。スタンドアロンビルドで期待するsplashの動作と、実際に見られるものは一致しない場合があります。
これは多くのチームを混乱させます。アセットまたはタイミングロジックを変更し、Expo Goでテストし、実際の問題は開発環境がプロダクションバイナリと同じように動作しないことであると結論付けるのではなく、設定が壊れていると判断します。
このメンタルモデルを使用してください。
Expo Goは、開発のための便利なツールですが、native splashの動作について最終的な権威ではありません。
- 開発用クライアントは現実に近いです __CAPGO_KEEP_0__
- __CAPGO_KEEP_1__ nativeプロジェクトが生成されるためです。
- 独立したビルドは、リリース時点でのタイミング、テーマの動作、およびアセットの正しさの最終チェックです。 スプラッシュがまだフラッシュしている場合、またはリリース時点での動作を反映していない環境でテストしている場合、通常、バグは3つのうちの1つです: すでに非表示になっている、または非表示になっている後で長くレンダリングしている、またはテストしている環境がリリース時点の動作を反映していない。
バンドル型React Nativeプロジェクトの設定 null バンドル型React Nativeアプリは、スプラッシュ画面がロゴを表示する固定時間の代わりに実際の起動作業と一致するようにするために、起動の制御を直接持つことができます。これは、起動画面が実際の起動UIと最初のReact画面のハンドオフをテストする必要があるため、有用です。ただし、この制御はネイティブの責任を伴います。AndroidとiOSを正しく接続し、頻繁にビルドし、実際のデバイスでネイティブの起動UIと最初のReact画面のハンドオフをテストする必要があります。
CLIプロジェクトでは、通常、以下のことを推奨します。
__CAPGO_KEEP_0__プロジェクトでは、現在のReact Nativeプロジェクトに適合するため、古いスプラッシュライブラリよりも適切です。また、ネイティブのセットアップはアップグレード時にも簡単に推論できます。古いアプリはまだ__CAPGO_KEEP_0__を含んでいますが、メンテナンスワークで遭遇するかもしれませんが、最新の設定では目標は同じです。ネイティブの起動画面をすぐに表示し、表示できる意味のあるUIがレンダリングできるようになるまで、非表示にします。
スプラッシュ画面を設定するためのReact Native CLIのプロセスを示す4ステップのイラストです。 react-native-bootsplash Androidの設定 react-native-splash-screen__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
Android スプラッシュ設定は、テーマリソース、ドロワブルなど、いくつかの場所にまたがっています。 AndroidManifest.xml, MainActivity。 その分散は、小さなミスが可視的なフラッシュを生み出す理由です。
通常のフローは、次のとおりです。
- Android リソースフォルダをサポートするものにスプラッシュアセットを生成する。
- 正しい背景色とスプラッシュドロワブルを持つ起動テーマを定義する。
- ランチャー活動にそのテーマを適用する。
AndroidManifest.xml. - 初回レンダリングがブロックされるタスクが完了したら、JavaScript からスプラッシュスクリーンを非表示にする。
MainActivity. - 簡略化された
パターンは、次のようになります。 MainActivity.kt そのスニペットは、ライブラリによっては正確な呼び出しに依存するため、意図的に汎用性が高いものにしている。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}That snippet is intentionally generic because the exact call depends on the library. The native integration point is usually the easy part. The mistakes tend to come from resources and theme transitions.
Androidの生産環境で表示される問題はこちらです:
- テーマの不一致: 起動テーマがアプリの最初の画面の背景色と異なる場合、ユーザーはハンドオフ時にフラッシュが表示されます。
- 不正なアセットバケット: Androidは、期待される密度フォルダから欠落しているアセットを伸縮またはぼかします。
- Metroでのみテストする: ネイティブリソースの変更は通常、クリーンリビルドが必要です。ホットリロードでは起動の動作を検証しません。
- Android 12の起動ルール: 新しいAndroidバージョンでは、カスタム設定はプラットフォームの制約を尊重する必要があります。
- JSの遅延表示後: Reactがルートビューを描画する前にスプラッシュを非表示にすると、ユーザーはスムーズなトランジションではなく、白いフレームが表示されます。
最後の点は、画像自体よりもタイミングの問題が重要です。タイミングの問題は通常、パフォーマンスの問題として受け取られます。
iOSプロジェクトの設定
iOSでは、 LaunchScreen.storyboard plusという小さなネイティブのhook AppDelegate. このプラットフォームでは、
を静的で軽量なものとして期待しています。最初の画面の視覚的な構造のスナップショットとして扱ってください。オンボーディングフローのmini版ではありません。
- 信頼できる設定は次のようになります。
- Xcodeアセットカタログにアセットを追加します。
LaunchScreen.storyboardを簡単な制約で設定します。 - レイアウトを静的で保ちます。背景色、ロゴ、安全なスペーシングは通常十分です。
- のネイティブの起動呼び出しをライブラリに追加します。
AppDelegate. - JavaScriptからスプラッシュを非表示にするのは、
アプリが完全にレンダリングできる状態になるまで待ってください。
単純な起動画面はより安全な選択肢です。
Bare CLI は、ハンドオフの制御をより多く行えるようにします。
Expoが管理するものと、裸のCLIの間で、このは主な違いです。Expoは、正しいデフォルトへの迅速なパスを提供します。裸のものは、ネイティブの起動パイプラインの完全な責任を与えます。
起動プロセスがバンドルを読み込む以外の作業を実行している場合、そのトレードオフは有用になる。認証の復元、暗号化されたストレージの読み取り、カスタムネイティブのSDK初期化、またはホワイトラベルブランド規則を持つアプリは、追加の制御が必要になることが多い。ベアプロジェクトでは、起動タイミングをその作業と合わせることができる。高レベルの設定を通じてすべてを強制するのではなく。
起動後アニメーション遷移を追加する場合、ネイティブのスプラッシュ画面は静的で、最初のReact画面に動きを移すことができます。パフォーマンスのトレードオフは、モバイルアプリの起動パスにおける重要な要素と同様です。最初のレンダリング中に重い作業を行うことは高価です。 guide to animation performance in Capacitor apps 別のスタックから同じ原理をカバーし、レッスンはクリーンにReact Nativeに適用されます。
Expoが管理するものと、裸のCLI
実用的な比較は、画像の表示ではなく、起動の複雑さがどの所に存在するかということです。
| 判断ポイント | Expoが管理している | Bare 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スクリーンで軽量なブランドアニメーションを実行することです。これにより、起動パイプラインの真のネイティブ表面をアニメーション化する必要がなくなるため、より多くの柔軟性が得られます
ロティは、このようなハンドオフのための実用的選択肢です。最初のスクリーンで重いカスタムアニメーションスタックを構築する必要がなく、動きを提供できます。重要なのはシーケンスです
- ネイティブのスプラッシュスクリーンは、批判的な起動作業中は常に表示される
- Reactは最初の実際の画面または制御されたトランジション画面をマウントします。
- オプションのアニメーションは、必要以上にインタラクションをブロックしない限り、のみ再生されます。
機能しないのは古い setTimeout(2000) パターンです。高速なデバイスでは、アプリが待機する必要がなくなるため、待機せずにアプリが起動します。低速なデバイスでは、よくはるかにロード中の状態を置き換えるだけです。
起動をオーケストレーションとして扱う
より良いメンタルモデルは 起動オーケストレーションです。スプラッシュ画面は、アプリが意味のあるコンテンツを表示できるまで、完了する必要があるタスクを完全にカバーする必要があります。
通常は、次の組み合わせが含まれます。
- 認証ブートストラップ: セッションの復元またはサインインにルーティングするかどうかを決定する。
- 必須のストレージ読み取り: テーマ、ロケール、オンボーディング状態、最後の知られている重要な設定。
- フォントの読み込み状況： 特に、最初の画面がカスタムフォントを使用してレイアウトの安定性を確保する場合、
- リモート設定がUIを制御する: 最初の画面が安全にレンダリングできない場合にのみ。
多くのチュートリアルでは、環境に依存するスプラッシュスクリーンの動作のもう一つの微妙な点が省略されている。 Expoのスプラッシュスクリーン処理の議論は、開発とリリースの両方で動作が異なることを指摘しており、Expo Goとスタンドアロンビルドの両方で動作が異なる可能性があることを示唆している。 Expo Goとスタンドアロンビルドの両方で動作が異なる可能性があるため、自動的な可視性管理は、手動で制御を取り戻すと変更される。
そのため、遅延ベースの例は、実際の起動シーケンスを隠すのではなく、起動シーケンスに合わせることが重要であるため、古くなりやすい。
起動画面は、ユーザーが未完成のUIを表示しないようにするために使用するべきであり、スピードを偽装するために使用するべきではない。 this guide to animation performance in Capacitor apps このガイドは、__CAPGO_KEEP_0__ アプリのアニメーションパフォーマンスのガイドです。
React Nativeで使う場合、ビルドパイプラインの外でビジュアル修正を配信するチームには、次のような注意点があります。 Capgo JavaScript、CSS、コピー、設定、資産の更新をCapacitorとElectronアプリのために取り扱いますが、React Nativeのネイティブスプラッシュの変更はネイティブビルドパイプラインに属します。なぜなら、JavaScriptアプリが実行されていないときにスプラッシュ画面が現れるからです。
スプラッシュ画面の一般的な問題を解決する
ほとんどのスプラッシュ画面の問題は、繰り返し発生する小さなセットに分類できます。問題を分離することで、修正が簡単になります。 資産の問題, タイミングの問題ネイティブ統合の問題 最近のReact Nativeのガイドのコミュニティパターンは、同じ基本的なフローに収束しています。ライブラリを追加し、ネイティブの起動資産を設定し、起動時に呼び出し、そしてアプリが準備されているときに非表示にします。Androidの設定では、XMLまたはdrawableリソースを含めることがよくあります。一方、iOSでは.
__CAPGO_KEEP_0__ show __CAPGO_KEEP_0__ MainActivity __CAPGO_KEEP_0__ LaunchScreen.storyboard と AppDelegate。同様の概要では、Expoはアプリアイコンのために1024×1024のPNGを推奨している アプリアイコンのために1024×1024のPNG プロジェクトがCapacitorで作成されている場合に必要なサイズを生成できる npx create-expo-appこのReact Nativeのスプラッシュスクリーンガイド スプラッシュ画像が引き伸ばされているかぼやけている.
症状:
ロゴがぼやけている、切り取られている、または奇妙に拡大縮小されている 原因:
基本画像が正しくエクスポートされていなかった、またはフルスクリーンのラスターに依存しているレイアウト 対策:
対策: ロゴを背景に配置して、ポスター風のアートワークを置き換えます。元のデザインソースから再エクスポートし、density固有のアセットを再生成し、AndroidのドロワブルまたはiOSのアセットカタログに含まれるファイルが意図したものであることを確認します。
スプラッシュが隠れた後は白い画面が表示される
症状: スプラッシュが消え、最初の画面が表示される前にユーザーは白いフレームを見る
原因: アプリがスプラッシュを隠す前に、root UIが意味のあるコンテンツをレンダリングできるようになるまで待つ必要がある
対策: スプラッシュの消去をタイムアウトではなく、UIのレディー状態に紐付けます。Expoの場合、通常はrootビューがレイアウトできるまでスプラッシュを保持します。bareプロジェクトの場合は、同様のパターンを使用し、最初のレンダリングされた画面がすぐにアシンクロニスワークにブロックしないようにします。
1つのプラットフォームでスプラッシュが見えません
症状: Androidでは表示されますが、iOSでは表示されない、またはその逆
原因: native側の設定が完全にできていません。よくあるのは、忘れられたストーリーボードの参照、テーマのワイヤリングの問題、または正しいターゲットに追加されていないアセットです。
Fix: チェックするには、プラットフォームごとにファイルを一つずつ確認してください。Androidの場合は、起動テーマとリソース参照を調べます。iOSの場合は、Xcodeでアセットカタログのメンバーシップとアプリのターゲット設定を確認してください。 LaunchScreen.storyboardビルドが途中で途切れる
症状:
アプリがコンパイルできなくなったのは、ライブラリを追加したり、スプラッシュファイルを変更したりしたためです。 原因:
ネイティブプロジェクトファイルと生成された設定が同期が取れなくなり、特にプラグインやアセットの変更後はそうです。 Fix:
ビルドをクリーンし、必要に応じて依存関係を再インストールし、ネイティブプロジェクトを完全にビルドしてください。Expoの場合、生成されたネイティブレイヤーを慎重に再生成し、プラグインの設定を確認してください。バレアプリの場合は、リソース名、plist、またはマニフェストの編集を確認してください。 native側の設定が完全にできていません。よくあるのは、忘れられたストーリーボードの参照、テーマのワイヤリングの問題、または正しいターゲットに追加されていないアセットです。 MainActivity, AppDelegateFix:
最速のチームは、リリースエンジニアリングの一部として、スプラッシュスクリーンを視覚的なタスクとして一度だけ扱うのではなく、扱います。 それが、起動後すぐに起動アセット、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
あなたが使用している Splash Screen in React Native: A Complete Guide for 2026 @__CAPGO_KEEP_0__/__CAPGO_KEEP_1__-live-activities @capgo/capacitor-live-activities @capgo/capacitor-live-activities @capgo/capacitor-video-player']} for the implementation detail in @capgo/capacitor-live-activities, Using @capgo/capacitor-video-player for the native capability in Using @capgo/capacitor-video-player, @capgo/capacitor-video-player for the implementation detail in @capgo/capacitor-video-player, and Using @capgo/capacitor-native-navigation for the native capability in Using @capgo/capacitor-native-navigation.
