2026年版React Nativeのスプラッシュ画面の完全ガイド

実機でアプリのアイコンをタップすると、ユーザーは白いフラッシュ、引き伸ばされたロゴ、または凍結した起動画面が一瞬で表示され、ユーザーが何か有用なものが表示される前に消えます。通常、React Nativeアプリはプロダクショングレードのものと感じられなくなります。

React NativeのSplash Screenは、ブランドだけでなく、ネイティブの起動と最初の意味のあるReactレンダリングフレームの間のギャップをカバーする。ネイティブの起動順序、資産の準備、Expo Goという開発クライアントと実店舗ビルドの間の違いについても考慮する必要があります。タイミングを間違えると、ユーザーはすぐに欠陥を認識します。

プロフェッショナルなスプラッシュスクリーンはなぜ必要か
- 実際にスプラッシュスクリーンが何をしているか
パーフェクトなスプラッシュスクリーンアセットを用意する
エクスポーゴと開発クライアントワークフローで実装する
Configuring for Bare React Native CLI Projects
アニメーションとパフォーマンスの高いスプラッシュスクリーンの高度なテクニック
- アニメーションはスタートアップの現実に従うべき
- 起動をオーケストレーションとして扱う
一般的なスプラッシュスクリーンのトラブルシューティング

Why a Professional Splash Screen Matters

ユーザーがアプリをホーム画面からタップすると、起動シーケンスが白いフレームで始まり、最初のUIが表示されるまで待機します。生産環境では、これはinstabilityと読み取られます。 React NativeがJavaScriptバンドルを読み込んでいるか、バックグラウンドで状態を復元しているかは関係ありません。最初の印象は間違っています。

React Nativeでは、スプラッシュスクリーンはアプリが制御する最初のネイティブ表面です。プロセス起動と最初の使用可能なReactレンダリングフレームのハンドオフをカバーするため、スプラッシュスクリーンは起動ツールであり、ブランドアセットではありません。タイミングが良ければ、ユーザーは安定した起動を感じます。スプラッシュスクリーンを早く表示すると、レイアウトのシフト、欠落したフォント、または認証、ナビゲーション、リモート設定が追いつくまで死んでいるスクリーンが表示されます。

実際に何が起こっているのか

生産環境のスプラッシュスクリーンは通常、起動の4つの懸念事項を処理する必要があります。

ネイティブからJSの起動作業をカバーする フォントの読み込み、保存されたセッションの復元、機能フラグの読み取り、初期ナビゲーション状態はすべて最初のフレームを争っています。
視覚的な不具合を防ぐ システムの白いフレーム、未スタイリングのテキスト、または部分的にマウントされたルートビューのフラッシュを避けます。
起動を視覚的に一貫させる 背景色とロゴはアプリシェルと一致するように設定することで、トランジションが制御されたように感じます。
Force startup decisions: チームは、ロード画面を非表示にする前に、「起動準備完了」という概念を定義する必要があります。

実践的なルール: 最初の実際の画面がクリーンにレンダリングできるようになったら、ロード画面を非表示にすることです。ロード画面を非表示にするタイミングは、任意の待機時間ではなく、画面のレンダリング状況に基づいて決めます。

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ソリューションは、生産性に焦点を当てた概要を提供します。ロード画面アセットを完璧に準備するには

Preparing Perfect Splash Screen Assets

Most splash screen bugs start in 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 レイアウトシステム, not a single full-screen image. Use a background color plus a centered logo or illustration. That scales more predictably across tall Android devices, iPhones, tablets, and wider device orientations than trying to fit one detailed poster-style image everywhere.

, not a single full-screen image. Use a background color plus a centered logo or illustration. That scales more predictably across tall Android devices, iPhones, tablets, and wider device orientations than trying to fit one detailed poster-style image everywhere.

A checklist illustrating four essential requirements for designing perfect mobile app splash screen assets.

What to prepare before coding

Start with a clean source file from design. Vector is ideal for the handoff, even if the exported launch asset is a PNG.

Use this checklist: Source artwork:
Keep a master logo or mark in SVG, AI, or another editable source format so exports stay consistent. Background color:
安全マージン: ロゴの周りに余白を十分に確保して、不規則なアスペクト比でアグレッシブなクロッピングがデザインに影響を与えないようにします。
プラットフォームバリアント: 必要な画像サイズをエクスポートするのではなく、1 つのファイルをすべて拡張してみましょう。
ダークモードレビュー: アプリがダークサーフェスをサポートしている場合、選択した背景に対してロゴが読みやすく表示されることを確認してください。

Expo のガイドラインはここで役立ちます。ロゴはビルドパイプラインの一部であることを強調しています。ドキュメントでは、 1024×1024 の正方形の PNG アプリアイコンとして推奨しています。また、EAS Build は、 npx create-expo-appでプロジェクトを作成した場合に必要なサイズを自動で生成できることを示しています。アセットの生成は、古い手法の繰り返しではなく、現代のツールに移行していることを示しています。

共通のアセットのミス:

最も予測可能な視覚的な失敗は、

問題	起こりやすい原因	より良いアプローチ
ロゴがぼやけている	低解像度のラスターから出力された	ベクターソースから再エクスポート
カットされた辺	アートワークが境界線に近すぎる	安全なパディングを増やす
拡大	多くのアスペクトレシオに強制されたフルスクリーン画像	背景色と中央の画像を使用
不一致のトランジション	初期画面とスプラッシュ背景が異なる	起動とアプリシェル色を揃える

スプラッシュ画像には密集したテキスト、小さな詳細、またはマーケティングコピーを含めるべきではない。起動画面は短時間しか表示されず、厳密なネイティブ制約下でレンダリングされる。

頻繁なビジュアル更新を実施するチームにとって、イメージの規範は起動画面に留まらない。同様の習慣は、配信パッケージやバイナリサイズにも適用されるため、標準化されたアセットのエクスポートの際にイメージを更新用に最適化するなどのガイドを参照する価値がある。

実用的なエクスポートワークフロー

実用的なプロジェクトで機能するセットアップは次のようになる。

中心に配置された構成をデザインする 背景が単色の場合。
透明のロゴPNGをエクスポートする __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

CapacitorとExpo Goと開発クライアントワークフローを実装する

Expoを使用している場合、まずは expo-splash-screen。マネージドワークフローに適しており、スプラッシュが離れるタイミングを明示的に制御できるためです。

__CAPGO_KEEP_0__

The key behavior to understand is simple. Native splash screenを表示するまでの最初の意味のあるUIフレームが準備されるまで表示し続けることです。 Expoの SplashScreen APIは、起動時と preventAutoHideAsync() critical loadingが完了した後、ExpoはiOSおよびAndroidの両方のビルドで、早すぎると短時間の白い画面を表示する可能性があることを警告しています。 hideAsync() Expo splash screen __CAPGO_KEEP_0__ Expo splash screen API.

Expoプロジェクトでは、視覚的な側面は通常

または app.json 通常の app.config.js.

設定は次のようになります: app.json Capgoの

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

プロジェクト設定によってフィールドの詳細は異なるかもしれませんが、パターンは同じです。

native起動の外観を定義するにはconfigを使用し、JavaScriptから可視性を制御します。

実際には、以下のいくつかの選択肢が重要です。 初期画面と同じような背景色を使用すると、トランジションが連続的であるように感じます。
起動面では、密集したアートワークは適していません。 ロゴにユーザーを待たせる「ブランドの遅延」は避けるべきです。
アプリがすでに準備されているのにユーザーを待たせるのは間違いです。 起動画面を表示するのは、準備ができたときにのみ行うべきです。

多くのチュートリアルでは、間違った方法で進みます。

デモ用に簡単に実行できるが、実際のプロダクションでは間違っている方法です。 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の間のフラッシュの可能性が減る。

アシンクロニスワークが終了し始めたときにスプラッシュを隠さないでください。UIがそのワークに依存している場合にのみ、スプラッシュを隠してください。

スタートアップが認証の復元、リモートの設定、フォントのロードなどを含む場合、スプラッシュの表示タイミングは重要です。ホーム画面がカスタムフォントと署名済みの状態に依存している場合、スプラッシュはそのギャップをカバーするべきです。

React Nativeのより広いランディングとスタートアップエコシステムの概要についての有用なウォークスルーは以下にあります。

Expo Goとdevビルドで期待すること

Expoは1 つの追加のジレンマを追加する。スタンドアローンビルドで期待するスプラッシュの動作と、実際に見られるものは一致しないことがある。

これは多くのチームを混乱させる。アセットまたはタイミングのロジックを変更し、Expo Goでテストし、実際の問題は開発環境がプロダクションバイナリと同じように動作しないことであると結論付ける。

この考え方を使用してください。

Expo Goは、開発のための便利なツールですが、nativeのスプラッシュの動作の最終的な権威ではありません。 but it isn’t the final authority on native splash behavior.
開発用クライアントは現実に近いです 生成されたネイティブプロジェクトを含むためです。
スタンドアロンビルドは、リリースタイミング、テーマの動作、資産の正しさの最終チェックです。 スプラッシュがまだフラッシュしている場合、またはリリースの動作を反映していない環境でテストしている場合、通常、バグは3つのうちの1つです:

早すぎて非表示、非表示後で長すぎるレンダリング、またはテスト環境がリリースの動作を反映していない場合です。 null Bare React Native __CAPGO_KEEP_0__ プロジェクトの設定

Configuring for Bare React Native CLI Projects

しかし、この制御はネイティブの責任も伴います。

In CLI projects, I usually recommend react-native-bootsplash __CAPGO_KEEP_0__ プロジェクトでは、通常、 react-native-splash-screen新しいプロジェクトの場合に推奨します。

A four-step infographic illustrating the process for setting up a splash screen in React Native CLI.

Android のセットアップは、基本プロジェクトで行います

Android のスプラッシュ設定は、テーマリソース、ドロワブル、 AndroidManifest.xml. その分割は、小さなミスが目立つフラッシュを生み出します。 MainActivity通常のフローは、以下のようになります:

Android リソースフォルダをサポートするものにスプラッシュアセットを生成します。

正しい背景色とスプラッシュドロワブルを持つ起動テーマを定義します。
起動アクティビティにそのテーマを適用します。
Apply that theme to the launcher activity in 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
}

そのスニペットは、ライブラリの具体的な呼び出しに依存しているため、一般的なものにしている。ネイティブの統合ポイントは、通常、簡単な部分です。エラーは、リソースとテーマのトランジションから来ています。

Androidの生産環境で表示される問題は次のとおりです。

テーマの不一致: 起動テーマがアプリの最初の画面の背景色と異なる場合、ユーザーはハンドオフ時にフラッシュを表示します。
アセットバケットの不正: Androidは、期待される密度フォルダから欠落しているアセットを伸縮またはぼかすことがあります。
Metroのみでテストする: ネイティブのリソース変更は、通常、クリーンリビルドが必要です。ホットリロードは、起動の動作を検証しません。
Android 12の起動ルール: 新しいAndroidバージョンでは、カスタム設定はプラットフォームの制約を尊重する必要があります。
JSの遅延: Reactがルートビューを描画する前にスプラッシュを非表示にすると、ユーザーはスムーズなトランジションの代わりに空のフレームを表示します。

__CAPGO_KEEP_0__は、画像そのものよりも重要です。タイミングの問題は通常、パフォーマンスの問題として受け取られます。

iOSプロジェクトのベアセットアップ

iOSでは、重心は LaunchScreen.storyboard プラス、小さなネイティブのハックが AppDelegateプラットフォームは、起動画面を静的で軽量であると想定しています。起動画面の視覚的構造のスナップショットとして扱ってください。ミニオンボードングローカルはありません。

信頼できるセットアップは次のようになります。

Xcodeアセットカタログにアセットを追加します。
Configure LaunchScreen.storyboard 制約が単純な場合、レイアウトを静的でください。背景色、ロゴ、安全なスペーシングは通常十分です。
ライブラリのネイティブのブートストラップコールを追加します。
JavaScriptからスプラッシュを非表示にするのは、完全にレンダリングできるようになったアプリが完全に準備されているときにのみ行ってください。 AppDelegate.
__CAPGO_KEEP_1__

iOSの新しいチームは、ストーリーボードをオーバービルドすることがよくあります。しかし、それは通常失敗します。複雑な制約、複数のネストされたビュー、または起動画面のアニメーションを試みることは、デバイスサイズによってはセットアップが維持しにくく、簡単に破損する可能性があります。

単純な起動画面が安全な選択肢です。

CLIの基本的な設定は、ハンドオフの制御をより多く持つようにします。

Expo管理型とCLIの基本的な設定の主な違いは、Expoは正しいデフォルトまでの迅速なパスを提供し、CLIは完全な責任を与えることです。

起動時にバンドルを読み込む以外の作業を行うアプリでは、この制御が必要になります。例えば、認証の復元、暗号化されたストレージの読み取り、カスタムのSDKの初期化、またはホワイトラベルブランドの規則などが含まれます。これらの作業を合わせるには、SDKのプロジェクトを使用して、スプラッシュタイミングを合わせることができます。

起動後にアニメーションを追加する計画がある場合は、起動画面を静的で、最初のReact画面に動きを移行してください。これは、モバイルの起動パスにおけるパフォーマンスのトレードオフと似ています。最初の描画で重い作業を行うことは高価です。 Capacitorアプリのアニメーションパフォーマンスのガイド同じ原理を別のスタックから学び、React Nativeに適用することができます。

Expo管理型とCLI

実用的な比較は、画像の表示ではなく、起動の複雑さがどのくらいのレベルにあるかということです。

決定点	Expo管理型	裸のCLI
セットアップスピード	初期セットアップの高速化	よりネイティブな作業
ネイティブのカスタマイズ	より制限された	アセット生成フロー
より宣言的	より手動	デバッグの表面
JSの設定プラス生成されたネイティブレイヤー	__CAPGO_KEEP_0__	AndroidおよびiOSファイルを直接
最適な選択	速度と一貫性を優先するチーム	ネイティブコントロールの深い制御を必要とするチーム

アプリがすでにExpoにあり、起動要件が標準的な場合、そこに留まることが通常時間を節約する。起動パスがネイティブの初期化順序、カスタムのテーマ、プラットフォーム固有のブートロジックに依存している場合、bareCLIは長期的なクリーンな選択肢であることが多い

両方のワークフローは、磨かれたスプラッシュスクリーンを配信できます。違いは、フレームワークまたはチームが起動パイプラインを所有するかどうかです

アニメーションとパフォーマントなスプラッシュスクリーンの高度なテクニック

アニメーションが起動パイプラインを尊重する場合、スプラッシュスクリーンはきれいに見えます。アニメーションが起動パイプラインを妨げる場合、安っぽく見えます

だから私はアニメーションを強化層として扱います。最初の仕事はまだタイミングです。アプリが準備されていない場合、スプラッシュスクリーンは残ります。アプリが準備されている場合、最初の利用可能な画面に迅速に移行するトランジションが必要です

アニメーションは起動の現実に従うべきです

一般的なパターンは、ネイティブのスプラッシュスクリーンを単純に保ち、起動後に最初のReact画面で軽量なブランドアニメーションを実行することです。その方法で、起動の真のネイティブサーフェイス自体をアニメーション化する必要がなくなります。

Lottieは、このようなハンドオフのための実用的選択肢です。Lottieは、最初の画面で重いカスタムアニメーションスタックを構築することなく、動きを提供できます。重要なのはシーケンスです:

Native splash が起動中の重要な作業の際に常に表示されます。
React は最初の実際の画面または制御されたトランジション画面をマウントします。
オプションのアニメーションは、必要以上にインタラクションをブロックしない限り、のみ再生されます。

古い setTimeout(2000) パターンが機能しないことは明らかです。高速のデバイスでは、アプリが無駄に待つことになります。低速のデバイスでは、よくはロード中の状態を置き換えるだけです。

起動をオーケストレーションとして扱う

起動オーケストレーションというより良いメンタルモデルがあります。 Splash screen は、意味のあるコンテンツを表示できるようになる前に完了する必要があるタスクを完全にカバーする必要があります。通常、次の組み合わせが含まれます。

認証の初期化:

セッションの復元またはサインインにルーティングするかどうかを決定する。 __CAPGO_KEEP_0__
Essential storage reads: テーマ、ロケール、オンボーディング状態、最後の知られている重要な設定。
フォントの読み込み状況: 特に、カスタムフォントがレイアウトの安定性に依存する最初の画面の場合。
リモート設定がUIを制御する: 最初の画面が安全にレンダリングできない場合のみ。

多くのチュートリアルがこのもう一つのニュアンスを省略している。起動画面の動作は環境によって異なる。Expo起動画面の処理についての議論は、開発と実行環境での動作がExpo Goとスタンドアローンビルドで異なる可能性があることを指摘し、自動的な表示管理が手動で制御を取るときに変化することを示している。 Expo起動画面の処理についての議論は、開発と実行環境での動作がExpo Goとスタンドアローンビルドで異なる可能性があることを指摘し、自動的な表示管理が手動で制御を取るときに変化することを示している。起動画面はユーザーが未完成のUIを表示しないようにするために使用されるべきであり、速度を偽装するために使用されるべきではない。

ハイブリッドスタックに動きを追加する場合や、より広範なレンダリングパフォーマンスを評価する場合、

この__CAPGO_KEEP_0__アプリのアニメーションパフォーマンスのガイド Capacitor は有用なコンテキストです。同じ規範が適用されるからです。起動作業をスリムに保ち、不要なブロッキングを避け、動画のサポートはレスポンス性を優先するのではなく、それと競合するのではなく、

チームがビジュアル修正をフルバイナリーリリースの外で配信する際の実用的な注意点： Capgo JavaScript、CSS、コピー、設定、資産の更新を取り扱うプラットフォームはCapacitorとElectronアプリに対しては、しかし、React Nativeのネイティブスプラッシュの変更はネイティブビルドパイプラインに属する必要があります。なぜなら、JavaScriptアプリが実行されていないときに真のスプラッシュ画面が表示されるからです。

Splashスクリーンの一般的な問題のトラブルシューティング

大半のスプラッシュスクリーンの問題は、繰り返し犯人に分類される小さなセットに属します。 アセットの問題, タイミングの問題, and ネイティブ統合の問題.

最近のReact Nativeのガイドで共通化されたコミュニティパターンは、同じコアフローに収束しています： show ライブラリを追加し、ネイティブの起動資産を設定し、起動時には呼び出し、そしてアプリが準備されているときに非表示にする。Androidのセットアップはよく、 MainActivity plus XMLまたはdrawableリソース、iOSは LaunchScreen.storyboard と AppDelegateExpoは、正方形の 1024×1024 PNG アプリアイコンのために推奨しています。EAS Buildは、Capacitorプロジェクトで作成されたプロジェクトのために必要なサイズを生成できます。 npx create-expo-appこのReact Nativeのスプラッシュスクリーンガイドスプラッシュ画像が引き伸ばされたりぼやかされたりしている.

症状：

ロゴが柔らかく、切り取られたり、奇妙に拡大縮小されている 原因：

基本画像が正しくエクスポートされていなかったり、フルスクリーンラスタが適応しないレイアウトに依存していたりする __CAPGO_KEEP_0__

Fix: ロゴを中心に配置した背景のflat背景に置き換え、元のデザインソースから再エクスポート、density固有のアセットを再生成し、AndroidのドロワブルまたはiOSのアセットカタログに意図したファイルが含まれていることを確認する。

White screen after the splash hides

症状: ネイティブのスプラッシュが消え、ユーザーは最初の画面を見る前に白いフレームを見る。

Cause: アプリがスプラッシュを隠す前に、root UIが意味のあるコンテンツをレンダリングできるようにすることができないためです。

Fix: スプラッシュの非表示を、タイムアウトではなく、UIのレディー状態にタイムを合わせる。Expoでは、rootビューがレイアウトできるまでスプラッシュを保持すること、bareプロジェクトでは同等のパターンを使用し、最初のレンダリングされた画面が即座にさらに非同期の作業にブロックしないようにすることです。

Splash screen missing on one platform

症状: Androidでは表示され、iOSでは表示されない、またはその逆です。

原因: よくあるのは、忘れられたストーリーボードの参照、テーマのワイヤリングの問題、または正しいターゲットに追加されていないアセットです。

対処法: プラットフォーム固有のファイルを一つずつ確認してください。Androidの場合、起動テーマとリソース参照を調べます。iOSの場合、Xcodeでアセットカタログのメンバーとアプリのターゲット設定を確認します。 LaunchScreen.storyboardSplash設定を追加した後、ビルドが途中で止まる

症状:

Splashファイルを追加したり変更した後に、ビルドが途中で止まりました。 原因:

ネイティブプロジェクトファイルと生成された設定が同期を失い、特にプラグインやアセットの変更後はそうです。 対処法:

ビルドをクリーンし、必要に応じて依存関係を再インストールし、ネイティブプロジェクトを完全にビルドしてください。Expoの場合、生成されたネイティブレイヤーを慎重に再生成し、プラグインの設定を確認してください。ベアアプリの場合、プラグインの設定を確認してください。対処法: MainActivity, AppDelegateリソース名、plist、またはマニフェストの編集で小さな不一致が発生する場合。

最速のチームは、リリースエンジニアリングとしてスプラッシュスクリーンを扱い、1回限りの視覚的なタスクではありません。それが起動後すぐに起動アセット、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.

React NativeのSplash Screenから続けて: 2026年版完全ガイド

あなたが使用している React NativeのSplash Screenから続けて: 2026年版完全ガイド ネイティブメディアとインターフェイスの動作を計画する場合、接続する @capgo/capacitor-live-activities for the native capability in Using @capgo/capacitor-live-activities, @capgo/capacitor-live-activities @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

React NativeでSplash Screenを実装する完全ガイド 2026年

目次