Expo イメージピッカー: 2026 年の完全ガイド

2026年のためのExpoイメージピッカー: 完全ガイド

UIが完成し、プロフィール画面に「アップロード写真」ボタンが追加されましたが、簡単な部分が突然簡単ではなくなりました。実際の画像選択フローは、ネイティブパーミッション、OSコントロールされたインターフェイス、開発時詳細など、開発者が期待するよりも多くの形態を取ります。 Expo Image Pickerは、公式のExpoライブラリで、Expoパッケージリポジトリに記載されているように、デバイスライブラリから画像や動画を選択したり、カメラで写真を撮ったりするためのシステムUIを開くものです。. Expo の実際の実装では、信頼性の高いネイティブメディア入力へのブリッジが得られますが、すべてのデバイスで同じように動作するカスタムメディアエクスペリエンスは得られません。

このガイドは、デモではなく最初の実装用に書かれています。生産環境で重要な決定に焦点を当て、管理されたワークフロー設定、後で驚かないようにするパーミッションハンドリング、安全な結果のパース、ユーザーがファイルを選択した後、実用的アップロードパターンなど、プロダクションで重要な決定に焦点を当てています。 Expo 開発クライアントワークフロー.

Expo イメージピッカーの使い方

インストールと基本的な設定
管理されたワークフロー設定
- Bare React Native セットアップの詳細
- カメラとメディアライブラリへのアクセス
最小限の安全なコンポーネント
結果とオプションの処理
高度なパターンとプラットフォームの差異
一般的な問題のトラブルシューティング
- 一般的なエラーの高速チェック
- 短い生産チェックリスト

エクスポで始めるイメージピッカー

プロフィール写真の要求が来ます。1週間後、同じ機能が受領のアップロード、事故報告のカメラキャプチャ、ユーザーが最初の許可を拒否したときのリトライも必要になります。画像入力は、ネイティブのパーミッション、OS所有のUI、テンポラリファイルの処理、バックエンドのアップロードフローに触れるため、速く拡大します。

expo-image-picker エクスポのSDKモジュールはその仕事に適しています。プラットフォームピッカーまたはカメラUIを開き、選択されたメディアをReact Nativeのcodeが扱える形で返します。JavaScriptのAPIは小さく、主な課題は、両方のマネージドとバーレスプロジェクトでネイティブのセットアップ、パーミッションフロー、結果の処理を正しく行うことです。

主なトレードオフは簡単です。iOSとAndroidが独自のメディアUIを提示するのを許可するのです。通常、カスタムピッカーを構築するのではなく、システムスクリーンを使用すると、結果は良くなります:ユーザーはシステムスクリーンをすでに理解しているため、パーミッションプロンプトはOSの期待どおりに動作し、チームはJavaScriptでギャラリーアイテムを維持する必要がありません。

この機能をネイティブの統合機能とReactインターフェイスとみなしてください。

この考え方は役立ちます。失敗モードは、ピッカーを呼び出すボタンではなく、ほとんどの場合、次の3つの場所から来ます:

ネイティブの設定: プラグインのセットアップが欠落している、パーミッション文字列が不正、または構成を変更した後、古いビルドが残っている
実行時挙動: ユーザーが許可を拒否したり、iOSでライブラリへの制限付きの許可を付けたり、選択なしでフローをキャンセルしたりします。
結果の解析: 現在のAPIは assets 配列なので、古い例が直接読めなくなる result.uri 失敗する

Workflow choice also changes the setup path. In a managed Expo app, most of the native work lives in app config and requires a rebuild when that config changes. In a bare app, you still get the Expo module API, but you need to verify the underlying iOS and Android project settings more directly. If your team is using a custom client instead of Expo Go, this guide pairs well with Capgo’s explanation of マネージドのExpoアプリでは、ほとんどのネイティブの作業はアプリの設定にあり、設定が変更されたら再ビルドが必要になる.

バレアプリでは、Expoモジュール__CAPGO_KEEP_0__が利用できるが、iOSとAndroidのプロジェクト設定を直接確認する必要がある

チームがカスタムクライアントを使用している場合、このガイドは__CAPGO_KEEP_1__の説明と組み合わせて、Expo開発クライアントがネイティブモジュールのテストをどのように変えるかを理解するのに役立つ

ワークフローの分割は、このガイドの残りの部分で重要な点である。ハッピーパスは、実際のデバイスで、カスタムデバッグクライアントで、生産ビルドですべて動作するピッカー実装を確実にする

expo-image-picker gives a React-facing API over the platform pickers for photos, videos, and camera capture. The JavaScript call is simple. The setup is not, because photo access and camera access are controlled by iOS and Android, not by React Native.

A developer working on Expo image picker implementation by typing code on a laptop computer screen.

ネイティブの設定を正しく行うことが、ピッカーが実際のデバイスで、カスタムデバッグクライアントで、生産ビルドで動作するかどうかを決定する

npx expo install expo-image-picker

Expoのバージョンに合わせたインストーラーから始め expo install photo accessとcamera accessはiOSとAndroidによって制御されるため、React Nativeでは設定できない npm install または yarn addExpoはパッケージバージョンをあなたのSDKに合わせることで、一般的なネイティブ互換性の問題を回避します。Expoモジュールがあなたのリリースプロセスにどのようにフィットするかを比較する場合、この Expoツールの概要管理されたワークフロー設定

管理されたワークフローでは、App Configでプラグインを宣言することで、Expoがビルド時に出力するネイティブの変更を適用することができます。

例

最小限の設定です。実際には、iOSではシステムのプロンプトがアクセスが必要な理由を説明する必要があるため、iOSでは特に許可テキストを追加することが多いです。ユーザーが実行するアクションに合わせて、テキストを具体的に設定することが重要です。 app.json:

{
  "expo": {
    "plugins": ["expo-image-picker"]
  }
}

「プロフィール写真をアップロードする」は「メディアアクセスが必要」よりも良いです。

ワークフロー上の1つの操作上の詳細が多くの時間を浪費しています。ネイティブの設定、許可テキスト、またはその他のネイティブの設定を変更すると、再ビルドが必要になります。JavaScriptを再読み込みしても、変更が適用されません。Expo Goでは、クライアントがすでに含まれているものに制限されています。開発ビルドまたはリリースビルドの場合、ネイティブのプロジェクトはあなたの設定を反映するのは、ビルドを再実行した後のみです。 pluginsバーレスReactNativeの設定詳細

バーレスアプリでは、パッケージ__CAPGO_KEEP_0__は同じですが、ネイティブのプロジェクトを自分で確認する必要があります。iOSの使用説明は最初に確認するべきです。ライブラリを開く、カメラを起動する、または音声付きのビデオを記録することができるフローであれば、アプリには対応する許可テキストが必要です。

In a bare app, the package API is the same, but you need to verify more of the native project yourself. iOS usage descriptions are the first thing to check. If your flow can open the library, launch the camera, or record video with audio, your app needs the corresponding permission strings in Info.plist 再構築する前に。

バーレプロジェクトの実用的なチェックリストは次のようになります。

インストール expo-image-picker と npx expo install expo-image-picker.
プロジェクトがExpoの設定プラグインを使用している場合に、プラグインの設定を追加します。
iOSの使用説明が機能を公開しているものと一致していることを確認します。
iOSとAndroidアプリの再構築を行う必要がある場合、ネイティブの設定が変更されたら。

Missing permission text often looks like a runtime bug because the UI code is fine and the button handler runs. The failure is lower in the stack. I usually check Info.plist, the app config, and whether the current build includes the latest native changes before I touch the component code.

設定をより予測可能にするために、習慣的な習慣があります:

実際のアクションの許可のテキストを書きます: ユーザーは、提示されるプロンプトの理由を理解する必要があります。
カメラとライブラリを個別に設定します: 一方が機能しない場合もう一方が機能することがあります。
ネイティブの変更後は再構築します: ホットリロードと高速リフレッシュはネイティブの権限を更新しません。
デバイスでテストします: シミュレータの動作は権限やカメラの問題を隠すことができます。

開発中は正常に動作するが、テストフライトまたはプレイストアのビルドで機能しない場合、まずは設定問題とみなしてください。ほとんどの場合、それは事実です。

カメラとメディアライブラリのアクセス

ユーザーが「写真をアップロード」ボタンをタップすると、カメラまたはライブラリが開くことを期待し、ユーザーはその時点でアプリの1つの仕事しかありません。正しいシステムUIを開き、拒否またはキャンセルを処理することなく画面を破壊せずに、プレビューまたはアップロード用に利用可能なローカルファイル参照を返します。

That sounds simple until you test both managed and bare builds across iOS and Android. The JavaScript API stays compact, but the runtime behavior still depends on OS prompts, device hardware, and how your native permissions were configured earlier.

最小限の安全なコンポーネント

__CAPGO_KEEP_0__

Expo管理とバレーウォークフロー両方のプロジェクトで、コアフローは一貫している。許可された権限を要求し、ピッカーを起動し、ユーザーがキャンセルしたかどうかを確認し、最初のアセットを読み取る。 result.assets.

A基本コンポーネントは次のようになっている。

import { useState } from 'react';
import { View, Button, Image, Alert } from 'react-native';
import * as ImagePicker from 'expo-image-picker';

export default function PhotoInput() {
  const [imageUri, setImageUri] = useState<string | null>(null);

  const pickFromLibrary = async () => {
    const permission = await ImagePicker.requestMediaLibraryPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow photo library access.');
      return;
    }

    const result = await ImagePicker.launchImageLibraryAsync({
      mediaTypes: ['images'],
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  const takePhoto = async () => {
    const permission = await ImagePicker.requestCameraPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow camera access.');
      return;
    }

    const result = await ImagePicker.launchCameraAsync({
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  return (
    <View>
      <Button title="Choose from library" onPress={pickFromLibrary} />
      <Button title="Take photo" onPress={takePhoto} />
      {imageUri ? (
        <Image
          source={{ uri: imageUri }}
          style={{ width: 200, height: 200 }}
        />
      ) : null}
    </View>
  );
}

3つの重要な点がここにあります。

ライブラリとカメラのパーミッションを個別に要求する。独立して失敗する。
キャンセルを正常なユーザーアクションとして扱う。エラーステートとして扱うのではなく。
から読み取る。ピッカーはアセット配列を返すのではなく、トップレベルの assets[0]ライブラリとカメラのフロー uri.

ライブラリフローから始めて、機能が動作する最速のパスを得たい場合は、カメラサポートを追加するのを後回しにしてください。テストが容易で、シミュレーターのセットアップが多く、カメラハードウェアのエッジケースを回避できます。

カメラパスは開発で失敗する方法が多くあります。iOSシミュレーターのサポートは限られています。Androidエミュレータでは、実機と同じカメラの動作を表現することができません。バレーコンポーネントでは、実際の問題はネイティブの設定またはテスト環境にある場合でも、コンポーネントを確認することになります。

The camera path has more ways to fail in development. iOS Simulator support is limited. Android emulators may not expose camera behavior that matches a real device. In bare projects, those gaps can send you looking at component code even though the actual issue is native config or test environment.

A clean UI pattern is to ask the user for the source before calling the picker API:

const showPickerOptions = () => {
  Alert.alert('Upload image', 'Choose a source', [
    { text: 'Camera', onPress: takePhoto },
    { text: 'Photo Library', onPress: pickFromLibrary },
    { text: 'Cancel', style: 'cancel' },
  ]);
};

ライブラリとカメラのパーミッションを個別に要求する。独立して失敗する。

あなたのアプリがエクスポ以外のファイルアクセスパターンをサポートしている場合、またはネイティブスタック間のコンベンションを比較している場合、この Capacitor 写真ライブラリの参照

は便利なコンテキストです。

短いデモは、チームメンバーまたはQAにこのフローを示すときに役立ちます。

expo-image-picker システムUIの期待事項

プラットフォームピッカーまたはカメラUIを開きます。アプリはそのフローの全ての画面を制御していません。その区別は重要です。 “私のデバイスで動作する”ということはよくありますが、 “テストしたパスがOSによって許可された”ということです。

iOSでは、ユーザーは完全なアクセス権限の代わりに制限されたライブラリアクセスを許可することができます。Androidでは、ピッカーの動作はOSバージョンとベンダースキンによって異なります。マネージドワークフロープロジェクトでは、エクスポはネイティブのワイヤリングの多くを取り扱います。バーレスワークフロープロジェクトでは、ネイティブの許可変更が含まれるビルドされたアプリを確認する必要があります。JavaScriptの呼び出しサイトは両方のケースで同じままですが、実行時結果は異なります。

私は通常、次のケースをテストする前に機能を完了します。
最初の許可要求
許可が拒否された
ユーザーのキャンセル
物理デバイスでのカメラキャプチャの成功
返されたローカルURIの即時プレビュー

実際の生産動作に直接対応するケースもあります。必要に応じてファイルをサーバー、モデレーションパイプライン、または公開エンドポイント（例：インスタグラムのメディアパブリッシング__CAPGO_KEEP_0__）に送信するための次のステップをきちんと設定します。インスタグラムのメディアパブリッシングAPI.

ピッカー結果とオプションのハンドリング

ピッカー結果は、通常、実際の生産ロジックが必要です。システムUIは構造化されたオブジェクトを返しますが、ファイルパスだけではありません。ここで小さな間違いが原因で、プレビューが破損したり、キャンセルしたときにアプリがクラッシュしたりします。

結果オブジェクトを正しく読み取る

現在のExpoアプリでは重要な結果の形状は result.assets[0].uri、トップレベル result.uri。この詳細は、管理されたワークフローとベアワークフロープロジェクトに影響を与えます。JavaScriptAPIは同じですが、ネイティブのセットアップは下部にあるため異なります。

guard-firstパターンを使用します:

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 1,
});

if (result.canceled) {
  return;
}

const asset = result.assets?.[0];
if (!asset) {
  return;
}

const { uri } = asset;
setImageUri(uri);

これは、キャンセルしたピッカーがアセットを読み取ることができない場合と、codeが仮定している場合の2つの失敗ケースを取り扱います。 result.assets[0] 常に存在する場合、実行時には失敗します。

URIが得られたら、プレビューをレンダリングすることは簡単です:

<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />

アップロードする場合に後で使用する場合は、URIだけではなく、オブジェクト全体を保存しておくことをお勧めします。 asset 実際には、 fileName, mimeType, width, height、 fileSize は、検証、ログ出力、またはクリーンな多部品要求の作成に便利です。

選択画面以外の下流動作を変更するオプション

一部のピッカーのオプションは、ファイルサイズ、編集動作、バックエンドが受け入れる必要があるものに影響を与えます。

オプション	タイプ	変更されること	一般的な使用法
`mediaTypes`	配列	ユーザーが選択できるものを制限します	API が画像のみを受け入れる場合に限り、画像のみを選択できるようにします
`allowsEditing`	ブール値	OS がサポートしている場合に、カットや編集の UI を提供します	アバター、正方形のカバー、領収書のキャプチャ
`quality`	数値	サポートしている画像出力を圧縮します	モバイルネットワークのアップロードサイズを削減します
`base64`	ブール値	結果にエンコードされた画像データを追加します	inline 画像データを含む必要がある統合のみに使用してください

A few trade-offs are easy to miss:

allowsEditing は、画像スロットが固定形状またはサイズを持つ場合に便利です。サーバーが独自のクロップパイプラインを実行し、元のファイルを取得したい場合は、有用ではありません。
quality アップロード時間、メモリ圧力、サーバーストレージに影響します。 quality: 1 自動的に正解ではありません。
mediaTypes バックエンドのルールと一致するようにしてください。サーバーが動画を拒否する場合、ピッカーが動画を返さないようにしてください。
base64 メモリ内でのペイロードサイズを増加します。受信サービスがそれを必要とする場合にのみ使用してください。

最後の点は、メモリが少ないデバイスでは重要です。ローカルファイルURIは、プレビューとマルチパートアップロードのためのよりよいハンドオフです。Base64は有効な使用例がありますが、ファイル参照を渡すことと比較して高価です。

URI versus base64

ほとんどのアプリでは、ルールは簡単です:

使用してください URI プレビュー用に
使用 URI ファイルアップロード用
使用 base64 受信システムがエンコードされたコンテンツを要求している場合にのみ使用してください。

このパターンは、ピッカーをcode小さくテストしやすくするのに役立ちます。また、多くのバックエンドメディアフローが構築されていることにも一致しています。これには、最終的に外部プラットフォームに公開するサービスも含まれます。 Instagram メディア出版API.

チームが頻繁にOTA更新を実行したり、画像重いアセットをアプリ配信で移動したりする場合、ここでのファイルサイズの決定はパイプラインの残りの部分に影響を与える可能性があります。このガイドアプリ更新用の画像最適化は、ピッカーの構成とともに役立つ便利な相談相手です。

実用的なアプリ用の安全な結果パターン

デモ用途ではcodeを保存するだけで imageUri プロダクションでは、次のステップであるプレビュー、検証、アップロード、またはリトライのために、元のピッカーのレスポンスを再解釈する必要がなくなるように、正規化されたオブジェクトを保存することが推奨されます。

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 0.8,
});

if (result.canceled || !result.assets?.length) {
  return;
}

const asset = result.assets[0];

setSelectedImage({
  uri: asset.uri,
  fileName: asset.fileName ?? 'upload.jpg',
  mimeType: asset.mimeType ?? 'image/jpeg',
  width: asset.width,
  height: asset.height,
  fileSize: asset.fileSize ?? null,
});

これにより、内部のアプリケーション内では、予測可能な形状が得られます。また、管理型と裸のプロジェクトを同期することが容易になります。なぜなら、アプリケーションcodeが安定しているからです。

最後のチェックも役立ちます。追加の結果フィールドを有効にするのではなく、必要なデータを要求し、ピッカーを選択に集中させてください。

高度なパターンとプラットフォームの差異

ピッカー機能は、最初の選択された画像がリトライ、認証ヘッダー、ネイティブの許可差異、実際のアップロードエンドポイントと遭遇するときに、単純なものから簡単に複雑になることがあります。 expo-image-picker 選択をうまく処理することはできます。残りの機能はあなたのアプリケーションに任せます。

サーバーストレージの利点と欠点を比較検討したグラフィック

実用的なアップロードパターン

APIがファイルアップロードを期待している場合 FormData __CAPGO_KEEP_0__は、パスが機能することを証明するのに十分ですが、実稼動アプリでは通常、1層追加が必要です。

async function uploadImage(imageUri: string) {
  const formData = new FormData();

  formData.append('file', {
    uri: imageUri,
    name: 'upload.jpg',
    type: 'image/jpeg',
  } as any);

  const response = await fetch('https://your-api.example.com/uploads', {
    method: 'POST',
    body: formData,
    headers: {
      Accept: 'application/json',
    },
  });

  if (!response.ok) {
    throw new Error('Upload failed');
  }

  return response.json();
}

That code is enough to prove the path works, but production apps usually need one more layer. Derive name そして type 選択したアセットから可能な限り、認証をピッカー関数外に追加し、アップロード状態をピッカー状態と分離して、失敗した要求がユーザーにライブラリを開くことを強制しないようにします。

レビューでよく見る一般的なエラーを防ぐために、いくつかのチェックが実行されます。

確認 uri ローカル
存在することを確認して、リクエストを構築する前に
アップロードする前にプレビューを表示する
リクエストが飛行中の間、ユーザーがリピートタップを防ぐ
キャンセルまたはパーミッションエラーとは別にネットワークエラーを処理する

バックエンド検証は大きいファイル、非対応のMIMEタイプ、または認証の欠如を拒否することを期待する

バックエンドがbase64代わりにmultipartを要求する場合、それは通常サーバー制約であり、ピッカーの要件ではありません。Multipartはメモリのコストが安く、モバイルで推論しやすいです。

The picker UI is native, so it inherits native behavior. That affects both what users see and what your code should assume.

On iOS, editing flows and permission prompts follow Apple’s conventions. Limited Photos access can return a narrower set of assets than your test account saw on a fully granted device. On Android, picker behavior varies more by OS version and manufacturer skin, especially around albums, file names, and how camera captures are returned. Bare React Native apps feel these differences more directly because you own more of the native setup, but managed Expo apps still need code that treats the picker as platform-shaped rather than perfectly uniform.

実用的なルールは簡単です。検証できるフィールドに依存してください。デバイス間で同じUIまたは同じメタデータに頼るのではなく。

実際のアプリでは、以下の例が重要です:

編集とトリミング: iOSとAndroidのUIとトリミングの動作は同じではありません。
返されたメタデータ: fileName, mimeType、 fileSize 存在しないか、不一致になる可能性があるため、代替値を追加してください。
許可: iOSの写真アクセスは選択されたアイテムに制限される場合があり、Androidの動作はOSバージョンとシステムピッカーのサポートに依存します。
カメラ出力: キャプチャされた画像はライブラリアセットと同じ名前、向き、圧縮特性を持つ可能性がありません。

チームがExpo以外でも作業している場合、この DesignStackアプリ開発ガイド Androidのメディアハンドリングの決定に現れるAndroidのコンテキストを提供します。

マネージドワークフローとベアワークフローの違い

この時点で、セットアップの選択肢は実行上の意味を持ちます。

マネージドワークフローでは、許可文字列とプラグインの設定は通常アプリの設定内にあり、ネイティブの変更はビルドを作成するたびに適用されます。これにより、JavaScriptの表面面積がきれいになりますが、設定の修正は次のネイティブのビルドまで表示されません。OTAの更新は欠落しているネイティブの許可を修正しません。

ベアワークフローでは、同じ機能にはより多くの要素が含まれます。iOSのネイティブの使用説明、Androidのマニフェストの動作、パッケージのインストール、ビルドのタイミングを自分で確認する必要があります。利点はコントロールです。コストは、JavaScriptの呼び出しサイトではなくネイティブの設定によって問題が発生する可能性があることです。

Teams that switch between Expo and Capacitor often underestimate how different these abstraction layers are. Capgo has a useful explanation of 両方のワークフローで私の好みは一貫しています。ピッカーをCapacitorに狭くし、結果を一度に正規化し、専用の__CAPGO_KEEP_1__レイヤーを通じてアップロードし、プラットフォーム固有の動作を仮定せずに設定してテストするのではなく、明示的に設定してテストするのを優先します。一般的な問題のトラブルシューティング

My preference is consistent across both workflows. Keep picker code narrow, normalize the result once, upload through a dedicated API layer, and treat platform-specific behavior as something to configure and test explicitly rather than smooth over with assumptions.

__CAPGO_KEEP_1__はCapgoのアップロードレイヤーです。

Expo イメージピッカーの一般的な問題のトラブルシューティングチェックリスト

Expo イメージピッカーの一般的な問題の迅速なチェック

Expo イメージピッカーが開かない場合やパーミッションが失敗した場合、まずネイティブの設定を確認してください。特にバーレスアプリでは、iOS の使用説明文が欠けていることが一般的な原因です。

ユーザーがピッカーを閉じた後、エラーが発生した場合、結果の処理を確認してください。多くの実装では、直接 URI を読み込むことを前提としているため、チェックを省略しています。 canceled 以下の簡単なマッピングを確認してください:

パーミッションが拒否されたエラー:

アプリの設定とネイティブのパーミッション文字列を確認し、再構築してください。 画像 URI:
undefined から読み込む ではなく result.assets?.[0]?.uri から result.uri.
キャンセルを押しても何も起こらない: それが正しいかもしれません。キャンセルを無視してください。
画像が表示されない: URIが保存されたステートと渡されたことを確認してください。 <Image source={{ uri }} />.
シミュレータでカメラが奇妙に動作する: 物理デバイスでテストしてください。ライブラリのバグを追いかける前に。

短い本番チェックリスト

本番前に最後のチェックとして使用してください:

Expoツールを使用してインストール: 使用 npx expo install expo-image-picker.
ネイティブの部分を設定: プラグインと必要なパーミッションの説明を追加してください。
許可を意図的に要求する: カメラとメディアライブラリのフローを分離する。
結果をすべて保護する: チェック result.canceled 安全に読む assets[0].
URIベースのアップロードを優先する: base64を特別なケースのみに保つ。
実機をテストする: 特にカメラキャプチャと許可のポップアップの場合。

If your team ships Capacitor or Electron apps alongside React Native projects, Capgo Capgo