実機でアプリのアイコンをタップすると、ユーザーは白いフラッシュ、引き伸ばされたロゴ、または凍結した起動画面が一瞬で表示され、すぐに何か有益なものが表示される前に消えます。通常、React Nativeアプリはプロダクショングレードの感覚を失うその瞬間です。
React Nativeの良質なSplash Screenは、ブランドだけをカバーするのではなく、より多くの問題を解決します。Native起動と最初の意味のあるReactレンダリングフレームの間のギャップをカバーするのです。また、起動順序、資産の準備、Expo Goという開発クライアントと実際のストアビルドの間の違いについて、明確に考えさせるのです。タイミングを間違えると、ユーザーはすぐに欠陥を認識します。
目次
- プロフェッショナルなSplash Screenの重要性
- パーフェクトなSplash Screen資産の準備
- Expo Goと開発クライアントワークフローの実装
- CLI Bare React Nativeプロジェクトの設定
- アニメーションされたおよびパフォーマンスの高いスプラッシュスクリーンの高度なテクニック
- 一般的なスプラッシュスクリーン問題のトラブルシューティング
なぜプロのスプラッシュ画面が重要なのか
ユーザーがホーム画面からアプリをタップし、起動シーケンスが白い画面のフレームを表示し、最初のUIが表示される前に、React NativeはJavaScriptバンドルを読み込んで背景で状態を復元しています。生産環境では、それはinstabilityと読み取られます。React NativeがまだJavaScriptバンドルを読み込んで背景で状態を復元していることとは関係ありません。最初の印象は間違っています。
React Nativeでは、スプラッシュ画面はアプリが制御する最初のネイティブ表面です。プロセス開始と最初のReactでレンダリングされたフレームのハンドオフをカバーします。つまり、それは起動ツールであり、ブランドアセットだけではありません。タイミングが良ければ、ユーザーは安定した起動を感じます。スプラッシュを早く隠すと、レイアウトのシフト、見えにくいフォント、または認証、ナビゲーション、リモート設定が追いつくまで死んでいるように見える画面が表示されます。
実際に何がスプラッシュ画面が行っているのか
生産環境のスプラッシュ画面は通常、4つの起動関心事を処理する必要があります。
- ネイティブからJSの起動作業をカバーする フォントの読み込み、保存されたセッションの復元、機能フラグの読み取り、初期ナビゲーション状態はすべて最初のフレームを争っています。
- 視覚的な不具合を防ぐ システムの白い画面、未スタイリングのテキスト、または部分的にマウントされたルートビューを避けることで、
- 起動を視覚的に一貫性を持たせる: 背景色とロゴがアプリのシェルと一致することで、移行が制御された感じになる。
- 起動の決定を強制する: チームは「起動可能」という概念を定義する必要があるため、起動画面を削除する前に準備が整っているかどうかを判断する必要がある。
実践的なルール: 最初の実際の画面がきれいにレンダリングできるようになったら、スプラッシュを非表示にする。
この時点で、Expo管理型とバレCLIワークフローの差異が現れ始める。Expo管理型のプロジェクトでは、スプラッシュの設定は主に宣言的であり、主なエンジニアリングの決定は、APIを非表示にするタイミングを決定することである。バレReact NativeCLIプロジェクトでは、AndroidとiOSのネイティブ設定を自社で管理することができるため、より制御が可能であるが、スプラッシュのフリッカー、テーマの不一致、プラットフォーム固有のバグなどを引き起こす可能性も高くなる。
実際のプロジェクトでは、このトレードオフは重要な考慮事項となる。Expoは設定が速く、環境間で一貫性を保つのが容易であるが、バレプロジェクトでは、既存のカスタムネイティブモジュール、カスタムの起動動作、起動パスの制御が必要な場合など、特定の状況では適切な選択肢となる。
起動を品質管理の一部として扱うチームは、より広範なUXワークとともに起動をレビューすることが一般的であり、起動を孤立したネイティブタスクとして扱うのではなく、__CAPGO_KEEP_0__のアプリユーザー体験ガイドでカバーされている同じ意識を持つ。 Capgo’s guide to app user experience__CAPGO_KEEP_0__ React Native アプリ用の Nerdify ソリューション 実用的なプロダクション フォーカス オーバービューを提供します。
パーフェクト スプラッシュ スクリーン アセットの準備
ほとんどのスプラッシュ スクリーン バグは、設計ファイルではなく code で始まります。ベース アセットが間違っていると、Android XML または iOS ストーリーボードのクリーンアップでも救うことはできません。
最も安全なアプローチは、スプラッシュを "レイアウト システム" と見なすことです。単一のフルスクリーン イメージではなく、背景色と中央のロゴまたはイラストを使用します。高さのある Android デバイス、iPhone、タブレット、幅の広いデバイス オリエンテーションで予測可能にスケールすることは、詳細なポスター スタイルのイメージをすべての場所に収めることよりも簡単です。 モバイル アプリ スプラッシュ スクリーン アセットの設計に必要な 4 つの要件を示すチェックリスト。コードを書く前に準備するもの
このチェックリストを使用してください。
ソース アートワーク:
__CAPGO_KEEP_0__
- __CAPGO_KEEP_0__ マスター ロゴまたはマークをSVG、AI、または編集可能なソース形式で保存して、エクスポートが一貫性を保つようにします。
- 背景色: 正確なスプラッシュ背景色を事前に定義し、最初の画面またはアプリシェル背景と一致するようにしてください。
- 安全なマージン: ロゴ周囲に十分な空間を残して、不規則なアスペクト比で激しく切り取られることによるデザインの損傷を防ぎましょう。
- プラットフォームバリアント: 必要なワークフローで使用する画像サイズをエクスポートし、1 つのファイルをすべて拡張するのではなくしてください。
- ダークモードレビュー: アプリがダークサーフェスをサポートしている場合、選択された背景に対してロゴが読みやすく表示されることを確認してください。
Expo のガイドラインはここで役立ちます。ロゴはビルド パイプラインの一部であるため、後思いついてはならないものとします。ドキュメントでは、 1024×1024 の正方形の PNG アプリ アイコンとして推奨しており、EAS Build はプロジェクトを作成した場合に必要なサイズを生成できることを示しています。 npx create-expo-app、アセット生成は現代のツールに移行し、手動の繰り返しから脱却しました。
一般的なアセットの間違い
最も予測可能な視覚的失敗は次のとおりです。
| 問題 | 起こり得る原因 | より良いアプローチ |
|---|---|---|
| ぼやけたロゴ | 低解像度のラスターからエクスポート | ベクターソースから再エクスポート |
| カットされたエッジ | アートワークが境界線に近すぎます。 | 安全なパディングを増やす |
| Stretching | Full-screen image を多くのアスペクト比に強制する | 背景色と中央に配置された画像を使用 |
| 不一致のトランジション | スプラッシュ背景は最初の画面と異なる | 起動とアプリシェル色を揃える |
スプラッシュ画像には密集したテキスト、小さな詳細、またはマーケティングコピーを含めるべきではない。起動画面は短時間しか表示されず、厳密なネイティブ制約下でレンダリングされる。
頻繁なビジュアル更新を実施するチームにとって、画像の規律は起動画面のことだけに限られない。同様の習慣は、配信パッケージとバイナリサイズにも適用されるため、標準化されたアセットエクスポートの際に 画像の更新に最適化する などのガイドを参照する価値がある。
実用的なエクスポートワークフロー
実際のプロジェクトでうまく機能するセットアップは次のようになる。
- 1つの中心的な構成を設計する 平らな背景に。
- 透明なロゴPNGをエクスポートする あなたのワークフローが別の背景色をサポートする場合。
- 名前を一貫してつけ プラットフォームをまたいで、資産の交換が推測に頼ることになるのを防ぐ。
- 小さなと高いシミュレータでテストする スプラッシュライフサイクルにワイヤする前に。
- 資産の変更後は再構築する リリースリソースはしばしばネイティブキャッシュ内にあります。
その最後の点は、多くの人が想像するよりも多く影響を与える。スプラッシュスクリーン問題の多くは、構成のバグのように見えるが、実際は古いネイティブアセットの問題である。
Expo Goと開発クライアントワークフローを使用して実装する
Expoを使用している場合、まず expo-splash-screenは管理されたワークフローに適合し、ほとんどの設定を宣言的に保持し、スプラッシュが画面から出るタイミングを明示的に制御することができます。
理解するべき重要な動作は単純です。 最初の意味のあるUIフレームが準備されるまで、ネイティブのスプラッシュを表示します。 の SplashScreen APIは、起動時に preventAutoHideAsync() と hideAsync() の初期化が完了した後、 Expo splash screen API.
Expoのスプラッシュスクリーン__CAPGO_KEEP_0__
ネイティブのスプラッシュを宣言的に設定します。 app.json __CAPGO_KEEP_0__ app.config.js.
__CAPGO_KEEP_1__ app.json __CAPGO_KEEP_2__
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}__CAPGO_KEEP_3__
__CAPGO_KEEP_4__
- __CAPGO_KEEP_5__ __CAPGO_KEEP_6__
- __CAPGO_KEEP_7__ __CAPGO_KEEP_8__
- __CAPGO_KEEP_9__ __CAPGO_KEEP_10__
__CAPGO_KEEP_11__
Many tutorials often go off course. They use 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つの点による。
最初に preventAutoHideAsync() アプリが意味のあるUIをレンダリングする前に呼ばれる。2番目に
root viewがレイアウトを準備できるようになったあとにhideが発生する。native splashとReact treeの間のフラッシュの可能性を最小限に抑える。
アプリの起動時にはasync workが終了した時点でsplashを非表示にしない。UIがそのworkに依存している場合に非表示にする。
その区別は、起動時には認証の復元、リモートの設定、フォントのロードなどが含まれる場合に最も重要になる。ホーム画面がカスタムフォントと署名済みの状態に依存している場合、splashはそのギャップをカバーするべきだ。
React Nativeの起動とスタートアップのより広いエコシステムのウォークスルーは以下のようになる。
Expo Goとdevビルドで期待すること
Expoは1つの追加のジレンマを追加する。スタンドアローンビルドで期待するsplashの挙動と実際の挙動が一致しないことが多い。アセットやタイミングのロジックを変更し、Expo Goでテストし、実際の問題は開発環境が実行可能なバイナリと同じ挙動をしないことであるのに結論として設定が壊れていると判断するチームが多い。
Use this mental model:
- Expo Goは便利ですが、ネイティブのスプラッシュビューの最終的な決定権はありません。 開発用クライアントは現実に近いです
- なぜなら、生成されたネイティブプロジェクトを含むからです。 スタンドアロンベuildは、リリース時における起動タイミング、テーマの動作、資産の正しさの最終チェックです。
- スプラッシュがまだフラッシュしている場合、または残っている場合、通常、問題は3つのうちの1つです: 早すぎて非表示になる、
ネイティブプロジェクトの生成後、非表示になるまでに長すぎる時間になる、 null または、リリース時とは異なる環境でテストしていることです。
Bare React Native CLI プロジェクトの設定
Bare React Nativeアプリは、スプラッシュ画面がロゴを表示する固定時間の待ち時間ではなく、実際の起動作業と一致するようにする必要があるため、起動の動作を直接制御できます。これにはネイティブの責任が伴います。
In CLI projects, I usually recommend react-native-bootsplash 新しい作業用に適したものです。現在のReact Nativeプロジェクトに比べて古いスプラッシュライブラリよりも、ネイティブのセットアップはアップグレードの際に推論することが容易です。古いアプリはまだ__CAPGO_KEEP_0__で配信されますが、メンテナンス作業で遭遇する可能性がありますが、最新のセットアップの目標は同じです。 react-native-splash-screen新しいアプリを起動するとすぐにネイティブの起動表面を表示し、意味のあるUIが表示できるようになるまでにのみ非表示にします。
Androidプロジェクトの設定
Androidのスプラッシュ設定は、テーマリソース、ドロワブル、 AndroidManifest.xmlのいくつかの場所にまたがっています。 MainActivityこの分割は、小さなミスが視覚的なフラッシュを引き起こす原因です。
通常のフローは、次のとおりです。
- Androidのリソースフォルダをサポートするためにスプラッシュアセットを生成します。
- 正しい背景色とスプラッシュドロワブルを持つ起動テーマを定義します。
- Apply that theme to the launcher activity in
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の新しいバージョンでは、独自のスプラッシュ動作を適用するため、カスタム設定ではそれらのプラットフォーム制約を尊重する必要があります。
- 遅いJS後 Reactがルートビューを描画する前にスプラッシュを非表示にすると、ユーザーは滑らかなトランジションの代わりに白いフレームが表示されます。
最後の点は、画像自体よりも重要です。タイミングの問題は通常、パフォーマンスの問題として認識されます。
iOSの設定は、bareプロジェクト
iOSでは、重心は LaunchScreen.storyboard plus a small native hook in AppDelegateプラットフォームは、起動画面を静的で軽量のものと想定しています。最初の画面の視覚構造のスナップショットとして扱うのではなく、ミニオンボードングローカルフローとして扱うのではなく。
信頼できる設定は次のようになります。
- Xcodeアセットカタログにアセットを追加します。
- Configure
LaunchScreen.storyboard単純な制約とともに。 - レイアウトを静的で保つ。背景色、ロゴ、安全なスペースは通常十分です。
- ライブラリのネイティブのブートストラップコールを追加します。
AppDelegate. - JavaScriptのみで、画面が完全にレンダリングできるようになるまで、スプラッシュを非表示にします。
iOSに新しくなったチームは、ストーリーボードをオーバービルドすることがよくあります。それは通常失敗します。複雑な制約、複数のネストされたビュー、または起動画面のアニメーションを試みることは、デバイスサイズによってはメンテナンスが難しく、破損しやすくなります。
シンプルな起動画面はより安全な選択です。
CLIのバーレス版は、ハンドオフの制御をより多く提供します。
Expoが管理するものとCLIのバーレス版の主な違いは、この点です。Expoは、正しいデフォルトを得るためのより速いパスを提供します。バーレス版は、ネイティブの起動パイプラインの完全な責任を与えます。
このトレードオフは、起動時にバンドルを読み込む以外の作業を行うアプリに有益です。認証の復元、暗号化されたストレージの読み取り、カスタムのネイティブSDKの初期化、またはホワイトラベルブランドの規則など、追加の制御が必要なアプリは、起動時のスプラッシュタイミングをその作業と同期させることができます。バーレスプロジェクトは、より高いレベルの構成を通じてすべてを強制するのではなく、ネイティブのスプラッシュを静的で保ち、初期のReact画面に動作を移すことができます。
アニメーションを追加する計画がある場合は、起動後にアニメーションを実行するには、ネイティブのスプラッシュを静的で保ち、初期のReact画面に動作を移すことができます。パフォーマンスのトレードオフは、モバイルの起動パスにおけるどの要素よりも重要です。初期の描画中に重い作業を行うことは、コストが高いです。 Capacitorアプリのアニメーションパフォーマンスのガイド 同じ原則は別のスタックから学べます。このレッスンは、React Nativeに適用できます。
Expoが管理するversus bare CLI
実用的な比較は、画像表示ではなく、起動の複雑さがどの場所に住んでいるかについてです。
| 決定点 | Expoが管理する | bare CLI |
|---|---|---|
| セットアップ速度 | 初期セットアップが速い | ネイティブの作業が多い |
| ネイティブのカスタマイズ | 制約が多い | アセット生成フロー |
| 全体的な制御 | より宣言的 | より手動 |
| デバッグ用表面 | JS設定と生成されたネイティブレイヤー | 直接AndroidとiOSファイル |
| 最適な選択 | 速度と一貫性を優先するチーム | ネイティブコントロールを深く必要とするチーム |
アプリがすでにExpoにあり、起動要件が標準であれば、そこに残ることが通常時間を節約する。起動パスがネイティブ初期化順序に依存している場合、カスタムテーマ、またはプラットフォーム固有のブートロジックに依存している場合は、bare CLIが長期的には清潔な選択肢となることが多い。
両方のワークフローは、磨き上げられたスプラッシュスクリーンを配信できる。違いは、フレームワークが起動パイプラインを管理するか、チームが管理するかである。
アニメーションされたスプラッシュスクリーンは、起動パイプラインを尊重する場合、綺麗に見える。起動パイプラインから視線を引き離す場合、安っぽく見える。
アニメーションされたスプラッシュスクリーンは、起動パイプラインを尊重する場合、綺麗に見える。起動パイプラインから視線を引き離す場合、安っぽく見える。
それはなぜ、動きを強調するレイヤーとしてではなく、基本となるものとして扱うのか。最初の仕事はまだタイミングです。アプリが準備されていない場合、スプラッシュ画面が表示されます。アプリが準備されている場合、トランジションは迅速に最初の利用可能な画面に進むべきです。
アニメーションは起動実際性に従うべきです
共通のパターンは、ネイティブのスプラッシュ画面を簡素化し、起動後に軽量のブランドアニメーションを最初のReact画面で実行することです。これにより、真のネイティブ起動面自体をアニメーション化する必要がなくなるため、より多くの柔軟性が得られます。
Lottieは、このようなハンドオフのための実用的選択肢です。最初の画面で重いカスタムアニメーションスタックを構築する必要がなく、動きを提供できるからです。重要なのはシーケンスです。
- ネイティブのスプラッシュ画面は、重要な起動作業中は表示され続けます。
- Reactは最初の実際の画面または制御されたトランジション画面をマウントします。
- オプションのアニメーションは、必要以上にインタラクションをブロックしない限り、実行されません。
古いパターンは機能しません。高速なデバイスでは、アプリは無駄のために待機することになります。低速なデバイスでは、よくあるのは、ロード中の状態を置き換えることだけです。 setTimeout(2000) 起動をオーケストレーションとして扱う
より良いメンタルモデルは、起動オーケストレーションです
__CAPGO_KEEP_0__ __CAPGO_KEEP_1__. アプリが意味のあるコンテンツを表示できるようになる前に完了する必要があるタスクを完全にカバーするように、スプラッシュ画面が表示されるべきです。
通常、次のいくつかのタスクが含まれます:
- Auth bootstrap: セッションの復元またはサインインにルーティングするかどうかを決定する
- 必須のストレージ読み取り: テーマ、ロケール、オンボーディング状態、および最後の知的好み
- フォントの準備: 特に、最初の画面がカスタムフォントのレイアウト安定性に依存している場合
- リモート設定がUIを制御する: 最初の画面が安全にレンダリングできない場合のみ
スプラッシュ画面の動作は環境によって変わります。開発と生産のExpoスプラッシュハンドリングについての議論は 開発と生産のExpoスプラッシュハンドリングについての議論は Expo Go では、スタンドアロン ビルドと同じように動作しない可能性がある動作が指摘され、自動的な可視性管理は、手動でコントロールを取り始めたときに変更される。 その一つの理由は、遅延ベースの例が古くなってしまうことである。 実際の起動シーケンスを隠すのではなく、起動シーケンスに合わせるようにする必要があるからである。
起動画面は、ユーザーが未完成のUIを見るのを防ぐために使用するべきであり、速度を偽るために使用するべきではない。
ハイブリッドスタックに動きを追加している場合や、より広範なレンダリングパフォーマンスを評価している場合、 この Capacitor アプリのアニメーションパフォーマンスガイド は、同じ規範が適用されるため、有用なコンテキストである。 起動作業をスリムに保ち、不要なブロッキングを避け、動きがレスポンス性をサポートするのではなく、それと競合するのではなく、動きをサポートするようにする。
チームがフルバイナリーリリースの外で視覚的な修正を配信している場合の実用的な注意点: Capgo handle JavaScript, CSS, copy, config, and asset updates for Capacitor and Electron apps, but native splash changes in React Native still belong to the native build pipeline because the true splash screen appears before the JavaScript app is running.
__CAPGO_KEEP_0__
および Electron アプリの場合に、 しかし、React Native のネイティブ スプラッシュ チェンジは、ネイティブ ビルド パイプラインに属することに注意する必要がある。 実際のスプラッシュ スクリーンは、JavaScript アプリが実行されていないときに表示されるからである。, スプラッシュ スクリーンに関する一般的なトラブルシューティングの問題点は、少数の繰り返し犯人に分類されることが多い。 その解決策は、資産問題とタイミング問題を分離することで簡単になる。、 ネイティブ統合問題.
最近のReact Nativeガイドのコミュニティパターンは、同じコアフローに収束しています：ライブラリを追加、ネイティブ起動アセットを構成、起動時呼び出し、起動後は非表示にします。Androidのセットアップでは、XMLまたはdrawableリソースを含むことがよくあります。一方、iOSは show 、 MainActivity 。同様の概要では、Expoはアプリアイコンとして正方形の1024×1024 PNGを推奨しており、EAS Buildは LaunchScreen.storyboard プロジェクトを作成した場合に必要なサイズを生成できることがまとめられている AppDelegateこのReact Nativeのスプラッシュスクリーンガイド 引き伸ばされたまたはぼやけたスプラッシュ画像 __CAPGO_KEEP_0__ npx create-expo-app__CAPGO_KEEP_0__ __CAPGO_KEEP_0__.
__CAPGO_KEEP_0__
症状： ロゴがぼやけ、切り取れ、または奇妙に拡大縮小されている。
原因： 元の画像が正しくエクスポートされていなかったり、レイアウトがフルスクリーンラスタに依存していないか?
対処法： ポスター風のアートワークを置き換え、中央にロゴを配置した平面の背景にします。元のデザインソースから再エクスポートし、density固有のアセットを再生成し、AndroidのドロワブルまたはiOSのアセットカタログに意図されたファイルが含まれていることを確認します。
スプラッシュが隠れた後、白い画面が表示される
症状： ネイティブのスプラッシュが消え、ユーザーは最初の画面の前に白いフレームを表示します。
原因： アプリがルートUIが意味のあるコンテンツをレンダリングできる前にスプラッシュを隠しています。
対処法： __CAPGO_KEEP_0__を準備状態と経過時間と結びつけるのではなく、タイムアウトを設定してください。Expoでは、ルートビューがレイアウトできるまでスプラッシュを表示することを意味します。バーレスプロジェクトでは、同様のパターンを使用し、最初にレンダリングされる画面が即座にアシンクロニズムの作業にブロックされないようにしてください。
プラットフォームの1つでスプラッシュ画面が見えません
症状: Androidでは表示されますが、iOSでは表示されません、またはその逆です。
原因: ネイティブ側の1つが完全に設定されていませんでした。よくあるのは、ストーリーボードの参照を忘れたり、テーマの設定が不正だったり、アセットが正しいターゲットに追加されていなかったりします。
対処法: プラットフォームごとにファイルを確認してください。Androidの場合は、起動テーマとリソース参照を確認し、iOSの場合はXcodeでアセットカタログのメンバーシップとアプリのターゲット設定を確認してください。 LaunchScreen.storyboardスプラッシュ設定を追加した後、ビルドが途中で止まります
症状:
ライブラリを追加したり、スプラッシュファイルを変更したりした後、ビルドが途中で止まりました。 対処法:
原因: ネイティブプロジェクトファイルと生成された構成が同期を失うことがあり、特にプラグインまたはアセットの変更後です。
対処法: ビルドをクリーンし、必要に応じて依存関係を再インストールし、ネイティブプロジェクトを完全に再構築してください。 Expoで生成されたネイティブレイヤーにいる場合、慎重に再生成し、プラグイン設定を確認してください。 Bareアプリにいる場合、リソース名、plist、manifestの編集など、小さな不一致を確認してください。 MainActivity, AppDelegate最速のチームは、スプラッシュスクリーンをリリースエンジニアリングの一部として扱い、1回限りの視覚的なタスクではありません。起動アセット、UIテキスト、またはアプリシェル動作が急に変更される必要がある場合、さらに重要になります。
__CAPGO_KEEP_0__ CapgoとElectronチームにJavaScript、CSS、コピー、構成、またはアセットの修正を次の起動時に実行する方法を提供します。ロールアウト制御とロールバックサポートがあり、これは問題がネイティブ起動スクリーン自体ではなくアプリ層にある場合に便利です。 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.
「React Native: 2026年版のスプラッシュスクリーンに関する完全ガイド」を使用している場合
「React Native: 2026年版のスプラッシュスクリーンに関する完全ガイド」を使用してネイティブメディアとインターフェイスの動作を計画し、接続してください。 「React Native: 2026年版のスプラッシュスクリーンに関する完全ガイド」 を使用しています Using @capgo/capacitor-live-activities for the native capability in Using @capgo/capacitor-live-activities @capgo/capacitor-live-activities 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
