Expo Image Picker: 2026 年の完全ガイド

UI が完成し、プロフィール画面に「アップロード写真」ボタンが追加されました。しかし、実際の画像選択フローは、ネイティブのパーミッション、OS制御のインターフェイス、開発時詳細など、開発者が期待するものとは異なる戻り値、そして実際にビルドした後に出現するビルド時詳細など、複数の要素を扱います。

エクスポイメージピッカーは、エクスポライブラリの公式バージョンです。デバイスのライブラリから画像や動画を選択したり、カメラで写真を撮ったりするためのシステムUIを開くことができます。エクスポパッケージリポジトリ実際には、ネイティブのメディア入力に信頼できる橋渡しを提供しますが、カスタムメディアエクスペリエンスを提供するのではなく、各デバイスで同じように動作するものではありません。

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

__CAPGO_KEEP_0__

Expo イメージピッカーの始め方
インストールと基本的な設定
- 管理されたワークフローの設定
- React Nativeの基本的な設定
カメラとメディアライブラリへのアクセス
ピッカーの結果とオプションのハンドリング
高度なパターンとプラットフォームの違い
一般的な問題のトラブルシューティング
- 一般的なエラーの高速チェック
- 短い生産チェックリスト

Expo Image Pickerの開始

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

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

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

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

その考え方が役に立つのは、ピッカーを呼び出すボタンで失敗モードがまれに発生するからです。通常は、次の3つの場所から来ています。

ネイティブ設定: プラグインのセットアップが不足している、パーミッション文字列が不正である、または設定を変更した後、ビルドが古くなっている
実行時挙動: ユーザーがアクセスを拒否したり、iOSでライブラリへのアクセスを制限したり、または何も選択せずにフローをキャンセルしたりする
結果の解釈: 現在のAPIは assets 配列を返すので、古い例が直接読むと result.uri 失敗する

ワークフローの選択肢もセットアップのパスを変える。マネージドのExpoアプリでは、ネイティブのほとんどの作業はアプリの設定にあり、設定を変更すると再ビルドが必要になる。ベアアプリでは、ExpoモジュールAPIが利用できるが、iOSとAndroidのプロジェクト設定を直接確認する必要がある。チームがExpo Goの代わりにカスタムクライアントを使用している場合、このガイドはCapgoの説明とよく組み合わさる。Expo開発クライアントがネイティブモジュールのテストをどのように変えるかについては説明しています.

ガイドの残りの部分では、ハッピーパスは物語の半分だけです。ピッカーの実装は、両方のワークフローで動作し、プラットフォーム固有のパーミッションのニッチさをユーザーに驚かせずに処理し、ローカルプレビューで止まらずにアップロードレイヤーに使えるファイルを渡すことができるようになるまで、固いものです。

インストールと基本設定

インストールは1つのコマンドで完了します。ネイティブの設定を正しく行うことが、実機、カスタム開発クライアント、そしてプロダクションビルドでピッカーが正常に動作するかどうかを決めることです。

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

エクスポの画像ピッカー実装に取り組む開発者が、ノートパソコンの画面にcodeを入力しながら作業している。

Capgoのバージョンに応じたインストーラーから始めます。

npx expo install expo-image-picker

使用 expo install Capgoの代わりに npm install または yarn addエクスポはパッケージバージョンをあなたのSDKと合わせることで、一般的なネイティブ互換性の問題を回避します。エクスポモジュールがあなたのリリースプロセスにどのようにフィットするかを比較する場合、この Capgoツールの概要は参考になります。

Managed workflow setup

Managed workflowの設定

In the managed workflow, declare the plugin in app config so Expo can apply the native changes at build time. app.json:

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

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

Example with plugins実際の設定例

That is the minimum setup. In practice, teams usually add permission text as well, especially on iOS where the system prompt should explain why the app needs access. Keep the wording specific to the user action. “Upload a profile photo” is better than “Needs media access.”

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 One operational detail causes a lot of wasted time. Changing permission strings, or other native config requires a rebuild. Reloading JavaScript does not apply those changes. In Expo Go, you are also limited by what the client already includes. In a development build or production build, the native project reflects your config only after a new build.

ネイティブの設定変更がビルド時に適用されるようにするため、プラグインをアプリの設定ファイルに記述する必要があります。

Bare React Native setup details expo-image-picker Bare React Nativeの設定詳細情報です。iOSの使用説明は最初に確認する必要があります。アプリがライブラリを開く、カメラを起動する、または音声付きのビデオを記録することができる場合、対応する許可テキストを記述する必要があります。before you rebuild。A practical checklist for bare projects looks like this:Install with npx expo install expo-image-picker.
プロジェクトがExpo configプラグインを使用している場合に、プラグイン設定を追加します。
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.

ユーザーは、提示されるプロンプトの理由を理解する必要があります。

カメラとライブラリを別々に設定します。 一方が機能しない場合でも、もう一方は機能する可能性があります。
ネイティブの変更後、再構築します。 ホットリロードと高速リフレッシュはネイティブの許可を更新しません。
許可テキストの書き方を習慣化することで、セットアップが予測可能になります。 許可テキストの書き方を習慣化することで、セットアップが予測可能になります。
Test on device: デバイス上でテストする:

simulator behavior can hide permission and camera issues.

シミュレータの挙動は、許可とカメラの問題を隠すことができます。

If the picker works during development but breaks in TestFlight or the Play Store build, treat that as a configuration problem first. Most of the time, it is.

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.

Accessing the Camera and Media Library

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

A user taps “Upload photo,” expects the camera or library to open, and your app has one job at that moment. Open the right system UI, handle refusal or cancellation without breaking the screen, and return a usable local file reference for preview or upload. result.assets.

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

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

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

それが簡単そうに見えるが、実際にはiOSとAndroidの両方のマネージドとベアビルドをテストするまで、JavaScript __CAPGO_KEEP_0__はコンパクトに残りますが、実行時挙動はOSのプロンプト、デバイスハードウェア、および先に構成されたネイティブの許可に依存します。
Treat cancellation as a normal user action, not an error state.
"から読み込む"、 assets[0]ライブラリとカメラのフロー uri.

ライブラリのフローから始めて、機能が動作する最速のパスを得ることができます。テストが容易で、シミュレーターの設定で動作するのは多く、カメラハードウェアのエッジケースを回避することができます。カメラのサポートを追加するのは、結果の処理パスが安定した後です。

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

ユーザーからソースを求めるようにユーザーに尋ねるUIパターンは、ピッカー code を呼び出す前にユーザーにソースを求めるようにユーザーに尋ねることです。

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' },
  ]);
};

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

__CAPGO_KEEP_0__ の写真ライブラリの参照 Capacitor photo library reference 短いデモは、チームメンバーやQAにこのフローを示すときに役立ちます。

__CAPGO_KEEP_0__

What to expect from the system UI

expo-image-picker platform picker or camera UIを開く。アプリはそのフロー内のすべての画面を制御していないため、注意が必要です。 “私のデバイスで動作する”というのは「OSがテストしたパスを許可した」ということになることが多いからです。

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

通常、次のケースをテストする前に機能を完了とします。

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

これらのケースは直接実際の生産動作にマップされます。また、ファイルをサーバー、モデレーションパイプライン、または公開エンドポイントである「Instagram media publishing __CAPGO_KEEP_0__」に送信する必要がある場合に、次のステップをきれいに設定することもできます。 Instagram media publishing API.

Handling Picker Results and Options

The picker result is the part that usually needs real production logic. The system UI returns a structured object, not just a file path, and small mistakes here lead to broken previews, empty uploads, or crashes after a user cancels.

Reading the result object correctly

The result shape that matters in current Expo apps is result.assets[0].uri, not a top-level result.uri. That detail affects both managed and bare workflow projects because the JavaScript API is the same even though native setup differs underneath.

Use a guard-first pattern:

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

This handles the two failure cases I see most often. A canceled picker does not give you an asset to read, and code that assumes result.assets[0] always exists will fail at runtime.

Once you have the URI, rendering a preview is straightforward:

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

If you plan to upload later, keep the whole asset object around, not just the URI. In practice, fileName, mimeType, width, height、および fileSize は、検証、ログ記録、またはクリアな多部品要求の作成に便利です。

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

選択画面に影響を与えるオプションのいくつかは、ファイルサイズ、編集動作、およびバックエンドが受け入れる必要があるものに影響を与えます。

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

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

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

最後の点は、メモリが少ないデバイスでは重要です。プレビューとマルチパートアップロードのためのローカルファイルURIは、通常、ベース64に比べて安価な手順です。ベース64は有効な用途がありますが、ファイル参照を渡すことと比較して、より高価です。

URIとbase64の比較

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

使用 URI プレビューの場合。
使用 URI ファイルアップロードの場合。
使用 base64 受信側がエンコードされたコンテンツを明示的に要求する場合にのみエンコードされたコンテンツを送信します。

That pattern keeps picker code small and easier to test. It also lines up with how many backend media flows are built, including services that eventually publish to external platforms such as the Instagramのメディア出版API.

アプリの更新に頻繁にOTAアップデートを実行するチームや、画像重視のアセットをアプリ配信で移動するチームは、ここでのファイルサイズの決定がパイプラインの残りの部分に影響します。このガイドアプリの更新用に画像を最適化するは、ピッカーの設定と組み合わせることが有用です。

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

デモcodeの場合、受信側に必要な情報をのみ保存することができます。生産環境では、次のステップであるプレビュー、検証、アップロード、またはリトライのために、受信側が元のピッカーのレスポンスを再解釈する必要がなくなるように、正規化されたオブジェクトを保存することをお勧めします。 imageUri アプリ内で一貫した形状を維持することで、管理型と裸のプロジェクトを簡単に同期できます。また、ネイティブの差異を他の場所で解決しながら、アプリ__CAPGO_KEEP_0__が安定していることを保証します。

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 確認することで、よく見られる失敗を防ぎます。 type 確認

ローカル

確認 uri リクエストを構築する前に存在する
アップロード前にプレビューを表示するので、ユーザーは間違ったファイルを早く捕まえる
リクエストが飛行中の間、繰り返しタップを防ぐ
ピッカーのキャンセルまたはパーミッションエラーとは別にネットワークの失敗を処理する
バックエンド検証が大きいファイル、非対応のMIMEタイプ、または認証が欠如している場合に拒否することを期待する

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

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

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

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

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

実際のアプリケーションでは、以下の例が重要です:

編集とトリミング: iOSとAndroidのUIとクロップ動作は一致していません
Returned metadata: fileName, mimeType、および fileSize が欠落または不一致になる可能性があるため、代替値を追加してください
Permissions: iOSの写真アクセスは選択したアイテムに限定できますが、Androidの動作はOSバージョンとシステムピッカーのサポートに依存します
Camera output: キャプチャされた画像はライブラリアセットとは異なる名前、向き、圧縮特性を持つ可能性があります

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

マネージドワークフローやバーレスワークフローの違い

この時点で、セットアップの選択肢は実際の運用に影響を与えるようになる。

管理ワークフローでは、許可文字列とプラグイン設定は通常アプリ設定内に格納され、ネイティブの変更はビルドを作成するたびに反映されます。これにより、JavaScriptの表面面積が清潔に保たれますが、設定の修正は次のネイティブのビルドまで視認できません。OTA更新では、欠落しているネイティブの許可を修正しません。

iOSのネイティブ使用説明文の検証、Androidのマニフェストの動作、パッケージのインストール、再構築のタイミングを自分で確認する必要があります。利点はコントロールです。コストは、ピッカーの問題がネイティブの設定によって引き起こされる可能性があることです。

チームがExpoとCapacitorの間で切り替えるとき、抽象化レイヤー間の違いを過小評価することがよくあります。Capgoはその説明を詳しく説明しています。 how Capacitor handles platform differences、チームがネイティブの設定をどれだけ管理したいのか決める際の良質な比較点となります。

私の設定は両方のワークフローで一貫している。ピッカーを code 限定し、結果を一度に正規化し、専用の API 層を通じてアップロードし、プラットフォーム固有の動作を仮定せずに明示的に設定してテストするのではなく、設定してテストするものとして扱う。

トラブルシューティングの基本的な問題

最もExpo Image Pickerのバグは、特定のカテゴリに分類されることが多い。最も速い修正は、どのレイヤーが失敗しているかを特定することである：設定、許可、結果の処理、またはレンダリング。

A mobile development projectでexpo-image-pickerライブラリを使用する際の一般的な問題のトラブルシューティングチェックリスト。

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

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

ユーザーがピッカーを閉じた後、エラーが発生した場合、結果のハンドリングを確認してください。多くの実装では、直接URIを想定し、チェックをスキップしています。 canceled いくつかの簡単なマッピングを確認してください。

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

アプリの設定とネイティブのパーミッション文字列を確認し、再構築してください。 image URI:
undefined から読み取るのではなく キャンセルした後、何も起こらない: result.assets?.[0]?.uri__CAPGO_KEEP_0__ result.uri.
__CAPGO_KEEP_1__ その可能性はあります。キャンセルを無視する状態として扱います。
イメージが表示されない: URIが状態に保存され、パスされたことを確認します。 <Image source={{ uri }} />.
シミュレータでカメラが奇妙に動作する: 物理デバイスでテストする前にライブラリのバグを追跡するのをやめましょう。

短い生産チェックリスト

出荷前に最後の確認:

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

あなたのチームがCapacitorまたはElectronアプリとReact Nativeプロジェクトを一緒に配信する場合、Capacitorは、ストアのレビューに毎回待つことなく、JavaScript、CSS、設定、資産の更新を提供するオプションです。画像関連の修正がWeb層に存在する場合、例えばアップロードUI、検証ルール、コピー、またはピッカーのフローに関連する資産の取り扱いなど。 Capgo カメラとメディアライブラリのフローを分離する。

Expo Image Picker: 2026年の完全ガイド

__CAPGO_KEEP_0__

Expo Image Pickerの開始

インストールと基本設定

Managed workflow setup

That is the minimum setup. In practice, teams usually add permission text as well, especially on iOS where the system prompt should explain why the app needs access. Keep the wording specific to the user action. “Upload a profile photo” is better than “Needs media access.”

シミュレータの挙動は、許可とカメラの問題を隠すことができます。

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

What to expect from the system UI

Handling Picker Results and Options

Reading the result object correctly

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

URIとbase64の比較

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

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

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

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

マネージドワークフローやバーレスワークフローの違い

トラブルシューティングの基本的な問題

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

短い生産チェックリスト