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

UIはほぼ完成しているはずで、プロフィール画面には「写真をアップロード」ボタンが表示されていますが、実際の画像選択フローは、ネイティブのパーミッション、OS管理のインターフェイス、開発者が期待するよりも多くの戻り値、そして実際にビルドした後に出現するビルド時詳細など、複雑な部分です。

Expo Image Pickerはそのようなポイントで役立ちます。Expo公式ライブラリで、デバイスのライブラリから画像や動画を選択したり、カメラで写真を撮ったりするためのシステムUIを開くことができます。実際には、Expoパッケージリポジトリで説明されているように、デバイスのライブラリから画像や動画を選択したり、カメラで写真を撮ったりするためのシステムUIを開くことができます。

このガイドは、デモではなく最初の実装を対象としています。生産環境で重要な決定に焦点を当てています。マネージドワークフロー設定、パーミッションのハンドリング、安全な結果の解析、ユーザーがファイルを選択した後の上書きパターンなどです。カスタムネイティブ設定で作業している場合、このガイドはExpo開発クライアントワークフローの違いを理解するのに役立ちます。.

Expo Image Pickerの初期設定
インストールと基本設定
- マネージドワークフロー設定
- Bare React Native設定の詳細
カメラとメディアライブラリへのアクセス
ピッカー結果とオプションの処理
高度なパターンとプラットフォームの差異
トラブルシューティングの一般的な問題
- 一般的なエラーの高速チェック
- 短い生産チェックリスト

Expo Image Pickerの導入

製品マネージャーがプロフィール写真を要求します。1週間後、同じ機能も受け取る必要があります。レシートのアップロード、インシデントレポートのカメラキャプチャ、ユーザーが最初に許可を拒否したときにリトライ

expo-image-picker Expo Image Pickerは、SDKモジュールです。プラットフォームピッカーまたはカメラUIを開き、選択されたメディアをReact Native codeが扱える形で返します。JavaScript APIは小さく、主な課題は、両方のマネージドとベアプロジェクトでネイティブのセットアップ、許可フロー、結果のハンドリングを正しく行うことです。

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

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

この考え方が役立ちます。失敗モードは、ピッカーを呼び出すボタンにほとんどありません。通常、次の3つの場所から来ます:

ネイティブの設定: プラグインのセットアップが不足している、許可文字列が不正、または構成を変更した後、古いビルドが残っている
実行時挙動: ユーザーはアクセスを拒否したり、iOSでライブラリへの制限付きアクセスを許可したり、選択なしでフローをキャンセルしたりできます。
結果の解析: 現在のAPIは assets 配列を返します。したがって、直接読み取る古い例は失敗します。 result.uri ワークフローの選択もセットアップパスを変更します。マネージドのExpoアプリでは、ほとんどのネイティブの作業はアプリの構成にあり、構成が変更されたときに再構築が必要です。ネイティブアプリでは、Expoモジュール__CAPGO_KEEP_0__が利用できますが、iOSとAndroidのプロジェクト設定を直接確認する必要があります。チームがExpo Goの代わりにカスタムクライアントを使用している場合、このガイドは__CAPGO_KEEP_1__の説明と組み合わせて、Expo開発クライアントがネイティブモジュールのテストを変更する方法についての説明と組み合わせて使用できます。

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 実装には1つのコマンドが必要です。ネイティブの構成を正しく設定することが、実機、カスタムデバッグクライアント、またはプロダクションビルドでピッカーが機能するかどうかを決定します。.

写真、動画、カメラキャプチャのプラットフォームピッカーにReact向け__CAPGO_KEEP_0__を提供します。JavaScriptの呼び出しは簡単ですが、写真へのアクセスとカメラへのアクセスはiOSとAndroidによって制御されるため、セットアップは簡単ではありません。

結果の解析:

ネイティブの構成

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.

エクスポイメージピッカー実装を実施している開発者が、ノートパソコンの画面にcodeを入力している。

Expoのバージョンに合わせたインストーラーから始めます。

npx expo install expo-image-picker

Use expo install の代わりに npm install または yarn add. Expo matches the package version to your SDK, which avoids a common class of native compatibility problems. If you are comparing how Expo modules fit into your release process, this Expoのツールの概要管理されたワークフローの設定

アプリの設定ファイルでプラグインを宣言し、Expoがビルド時にネイティブの変更を適用するようにします。

例えば

最小限の設定です。実際には、iOSではシステムのプロンプトがアプリがメディアアクセスを必要とする理由を説明する必要があるため、チームは通常、許可のテキストを追加します。ユーザーが実行するアクションに合わせて、言葉を具体的にします。 "プロフィール写真をアップロードする" は "メディアアクセスが必要" よりも良いでしょう。 app.json:

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

Managed workflow setup is a useful reference.

1 つの運用上の詳細が多くの時間を浪費しています。変更 plugins許可文字列、または他のネイティブの構成には、再構築が必要です。JavaScript の再読み込みは、その変更を適用しません。Expo Go では、クライアントがすでに含まれているものに制限されます。開発用ビルドまたはプロダクション用ビルドの場合、ネイティブのプロジェクトは、構成が反映されるのは、新しいビルド後にのみです。

バーレス React Native の設定詳細

バーレスアプリでは、パッケージ API は同じですが、ネイティブのプロジェクトを自分で検証する必要があります。iOS の使用説明は、最初に確認するべきものです。ライブラリを開く、カメラを起動する、または音声付きのビデオを記録するフローがあれば、アプリには対応する許可文字列が必要です。 Info.plist 再構築する前に、次のようになります。

インストール

に expo-image-picker with npx expo install expo-image-picker.
iOS の使用説明が機能に一致していることを確認します。
iOS と Android アプリを再構築する必要があります。ネイティブの構成が変更された場合。
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.plistcodeを触る前に、最新のネイティブ変更が含まれているかどうか、そしてアプリの設定が正しくされているかを確認する必要があります。

設定をより予測可能にする習慣がいくつかあります。

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

開発中でピッカーが機能するが、テストフライトまたはGoogle Playストアのビルドで機能しない場合、まずは設定問題とみなします。ほとんどの場合、それは事実です。

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

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

それが簡単そうに見えるまでに、iOSとAndroidの両方のマネージドとベアビルドをテストするまでの間、JavaScript APIはコンパクトに残りますが、OSのプロンプト、デバイスハードウェア、およびユーザーが前に設定したネイティブパーミッションの設定に依存するランタイムの動作は依然として依存します。

モバイルアプリケーション画像ピッカーのプロセスを選択するためのカメラまたはメディアライブラリソースのフローを示すフローチャート。

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

両方のExpoマネージドとベアワークフロープロジェクトでコアフローは一貫しています。関連するパーミッションを要求し、ピッカーを起動し、ユーザーがキャンセルしたかどうかを確認し、最初のアセットを読み取るだけです。 result.assets.

ベースラインコンポーネントは次のようになります。

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つの重要な点があります。

ライブラリとカメラのパーミッションを個別に要求することが重要です。独立して失敗します。
キャンセルを正常なユーザーアクションとして扱うことが重要です。エラー状態ではありません。
Read from assets[0]ライブラリとカメラのフロー uri.

ライブラリとカメラフロー

ライブラリフローから始めて、機能を実装する最速のパスを得たい場合は、より簡単にテストできます。シミュレーターの設定が多く、カメラハードウェアのエッジケースを回避できます。結果の処理パスが安定したら、カメラサポートを追加してください。

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.

ユーザーから画像の元のソースを確認するUIパターンは、クリアで使いやすいです。まずユーザーにソースを確認してもらうように API を呼びます。

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

各機能を集中させることができ、分析、機能フラグ、バックエンド固有のルールを追加することも容易になります。たとえば、プロフィール画像のライブラリアップロードを許可するチームもありますが、身元確認のために新しいカメラキャプチャを要求するチームもあります。

Expo外のファイルアクセスパターンをサポートするより広いアプリがあれば、またはネイティブスタック間でコンベンションを比較する場合は、この Capacitor 写真ライブラリのリファレンスは参考になります。

デモは、チームメイトやQAにこのフローを示すときに役立ちます。

システムUIの期待事項

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

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

通常、機能を完了する前に、これらのケースをテストします:

最初の許可要求
許可が拒否された
ユーザーのキャンセル
ライブラリの成功的な選択
物理デバイス上のカメラの成功的なキャプチャ
返されたローカルURIの即時プレビュー

これらのケースは直接実際の生産動作にマップされます。また、ファイルをサーバー、モデレーションパイプライン、または公開エンドポイントである Instagramメディア出版API.

ピッカー結果とオプションの処理

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

結果オブジェクトを正しく読む

現在のExpoアプリでは重要なのは結果の形状 result.assets[0].uri、トップレベル result.uri. That detail affects both managed and bare workflow projects because the JavaScript API is the same even though native setup differs underneath.

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を取得したら、プレビューをレンダリングすることは簡単です:

アップロードする予定の場合、URIだけでなく、結果オブジェクト全体を保持しておくことをお勧めします。実際には、

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

、 asset は、検証、ログ出力、またはクリーンな多部品要求の作成に役立ちます。 fileName, mimeType, width, height, and fileSize _CAPGO_KEEP_0__

下流の動作を変更するオプション

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

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

いくつかの取引は簡単に見落とされる:

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

低メモリデバイスでは、上記の点が重要です。

ローカルファイルURIは、プレビューとマルチパートアップロードのハンドオフでは通常、より良い選択です。

Base64は有効な使用例がありますが、ファイル参照を渡すことと比較して高価です。

Use URI プレビューの場合、
Use URI ファイルアップロードの場合、
Use base64 URI

パターンはピッカーを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,
});

This gives you one predictable shape inside the app. It also makes managed and bare projects easier to keep aligned because the app code stays stable while you work through native differences elsewhere.

最終的なチェックも役立ちます。追加の結果フィールドを有効にするのではなく、必要なデータを要求し、ピッカーを選択に集中させて、一般的なファイル処理ステップに変えるのを避けます。

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

ピッカーの機能は、最初の選択された画像が再試行、認証ヘッダー、ネイティブの許可差異、そして実際のアップロードエンドポイントを乗り越えるまで、単純ではありません。 expo-image-picker 選択をうまく処理します。機能の残りはあなたのアプリにあります。

サーバーストレージの利点と欠点を比較するグラフィックのタイトル「ローカル vs サーバーストレージの考慮事項」

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

ファイルアップロードを期待する API に対して FormData 安全なデフォルトです。Rails、Node、Laravel、Django、Go の共通バックエンドで動作し、ピッカーをトランスポートの懸念から分離します。

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();
}

code がパスが機能することを証明するのに十分ですが、生産的なアプリでは通常、さらに 1 つのレイヤーが必要です。派生 name and type 選択されたアセットから可能な限り派生し、認証をピッカー関数外に付与し、アップロード状態をピッカー状態から分離して、失敗した要求がユーザーにライブラリを開くことを強制しないようにします。

レビューでよく見る一般的なエラーを防ぐ数少ないチェックがあります。

ローカル uri 存在することを確認してリクエストを構築します。
アップロードする前にプレビューを表示して、ユーザーが間違ったファイルを早期に検出できるようにします。
リクエスト中のタップを防止する
ネットワークエラーとピッカーのキャンセルまたはパーミッションエラーを別々に処理する
バックエンド検証で大きなファイル、非対応のMIMEタイプ、または認証情報の欠如を拒否することを期待する

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

プラットフォームの違いが実際に重要な場合

ピッカーUIはネイティブなので、ネイティブの動作を継承します。それがユーザーが見るものと、codeが仮定するものに影響します。

iOSでは、編集フローとパーミッションプロンプトはAppleの規約に従います。 Photosに制限されたアクセスでは、完全に許可されたデバイスでテストアカウントが見たアセットよりも狭いセットのアセットが返されます。 Androidでは、ピッカーの動作はOSバージョンとメーカースキンの影響を受けます、特にアルバム、ファイル名、カメラキャプチャが返される方法について。 Bare React Nativeアプリでは、これらの差異を直接感じることができますが、管理されたExpoアプリでも、ピッカーをプラットフォームに依存したものとして扱うcodeが必要です。

実用的ルールは簡単です。依存するのは、検証できるフィールドだけではなく、UIやメタデータがデバイス間で一致しないことを認識すること。

実際のアプリケーションでは、いくつかの例が重要です。

実用的なルールは簡単です。依存するのは、検証できるフィールドだけではなく、UIやメタデータがデバイス間で一致しないことを認識すること。 実用的なルールは簡単です。依存するのは、検証できるフィールドだけではなく、UIやメタデータがデバイス間で一致しないことを認識すること。
実用的なルールは簡単です。依存するのは、検証できるフィールドだけではなく、UIやメタデータがデバイス間で一致しないことを認識すること。 fileName, mimeType、 fileSize が欠如または不一致であるため、フォールバックを追加します。
許可: iOSの写真アクセスは選択されたアイテムに制限できますが、Androidの動作はOSバージョンとシステムピッカーのサポートに依存します。
カメラ出力: キャプチャされた画像はライブラリアセットと異なる名前、向き、圧縮特性を持つ可能性があります。

チームがExpo外で作業する場合も、このデザインスタックアプリ開発ガイドは、単一のライブラリの外で現れるメディアハンドリングの決定に役立つAndroidの有用なコンテキストを提供します。

管理されたワークフローと裸のワークフローの違い

この時点で、セットアップオプションは実行上の意味を持ちます。

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

In bare workflow, same feature has more moving parts. You need to verify native iOS usage descriptions, Android manifest behavior, package installation, and rebuild timing yourself. The upside is control. The cost is that a picker issue may be caused by native configuration, not by the JavaScript call site.

チームは、ExpoとCapacitorの間で切り替わることが多く、抽象化レイヤー間の違いを過小評価することが多い。Capgoは、この差異について便利な説明をしている。 how Capacitor handles platform differences、そして、どれだけのネイティブ設定をチームが所有したいのかを決定する際の比較対象としてはよいものです。

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.

トラブルシューティングのためのチェックリスト

Expo Image Pickerのバグは、カテゴリが限られている小さなセットに分類できます。最速の修正は、どのレイヤーが失敗しているかを特定することです: config、permission、result handling、またはrendering。

Expo Image Pickerを使用するモバイル開発プロジェクトで一般的な問題をトラブルシューティングするためのチェックリスト。

一般的なエラーのための高速チェック

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

アプリがピッカーを閉じた後でクラッシュする場合は、結果の処理を確認してください。多くの実装では、直接URIを想定し、チェックをスキップしています。 canceled チェック.

簡単なマッピングが役立ちます:

許可が拒否されたエラー: アプリの設定とネイティブの許可文字列を確認し、再構築してください。
undefined 画像URI: 読み取り result.assets?.[0]?.uri, result.uri.
キャンセルを押しても何も起こらない: それが正しい場合もあります。キャンセルを無視してください。
画像が表示されない: URIが保存された状態とパスされたことを確認してください。 <Image source={{ uri }} />.
シミュレータでカメラが奇妙に動作する場合: 実機でテストする前にライブラリのバグを追跡するのをやめましょう。

短いプロダクションチェックリスト

実稼働前に最後の確認として使用してください:

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

チームがReact Nativeプロジェクトと並行してCapacitorまたはElectronアプリをリリースする場合、 Capgo マーティン・ドナディュー

エクスポ画像ピッカー: 2026年の完全ガイド

目次