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

UIが完成し、プロフィール画面に「アップロード写真」ボタンが追加されました。ここで、簡単な部分が突然簡単ではなくなりました。実際のイメージ選択フローは、ネイティブパーミッション、OS制御インターフェイス、開発者が期待するよりも多くの戻り値、そして実際にビルドした後だけに現れるビルド時詳細など、複数の要素を含みます。

Expo Image Pickerは、実際のイメージ選択フローを簡素化する公式Expoライブラリです。これは、デバイスライブラリから画像や動画を選択したり、カメラで写真を撮ったりするためのシステムUIを開くものです。 Expoパッケージリポジトリ. 本実装では、信頼性の高いネイティブメディア入力へのブリッジを提供しますが、デバイスごとに同じように動作するカスタムメディアエクスペリエンスは提供されません。

このガイドは、デモではなく最初の実装向けに書かれています。生産環境で重要な決定に焦点を当て、管理されたワークフロー設定、後で驚かないようにするパーミッションハンドリング、安全な結果のパース、ユーザーがファイルを選択した後、実際のアップロードパターンを含みます。カスタムネイティブ設定で作業している場合、Expo開発クライアントワークフローの違いを理解することも役立ちます。概要.

Expo Image Pickerの使用開始

インストールと基本的な設定
管理されたワークフロー設定
- 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 ワークフロー選択もセットアップパスを変更します。マネージドのExpoアプリでは、ほとんどのネイティブの作業はアプリの設定とそれが変更されたときに再構築が必要です。バレアアプリでは、Expoモジュール__CAPGO_KEEP_0__が得られますが、iOSとAndroidのプロジェクト設定を直接確認する必要があります。チームがカスタムクライアントを使用している場合、このガイドは__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つのコマンドが必要です。ネイティブの設定が正しく設定されていれば、実機、カスタムデベロッパークライアント、そしてプロダクションビルドでピッカーが動作するかどうかが決まります。

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

Expoの画像ピッカー実装を実行している開発者がタイプする__CAPGO_KEEP_0__のスクリーンショットです。

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

__CAPGO_KEEP_0__は、写真、動画、カメラキャプチャのプラットフォームピッカーにReact向けの__CAPGO_KEEP_0__を提供します。JavaScriptの呼び出しは簡単ですが、セットアップは簡単ではありません。写真へのアクセスとカメラへのアクセスはiOSとAndroidによって制御され、React Nativeによって制御されません。 expo install Expoの画像ピッカー実装を実行している開発者がタイプする__CAPGO_KEEP_0__のスクリーンショットです。 npm install または yarn add. Expo はパッケージのバージョンをあなたの SDK と合わせることで、ネイティブの互換性の問題を回避することができます。 Expo モジュールがリリースプロセスにどのように組み込まれるかを比較する場合、この Expo のツールの概要は参考になります。

管理されたワークフローの設定

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

例 app.json:

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

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

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

バーレスアプリでは、パッケージの __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アプリを再構築します。

codeのUIは正常ですが、ボタンハンドラーが実行されると、許可の欠如は下部のスタックで発生します。私は通常、 Info.plistアプリの設定と、現在のビルドが最新のネイティブの変更を含んでいるかどうかを確認し、コンポーネントcodeに触る前に

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

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

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

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

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

それが簡単そうに見えるが、iOSとAndroidの両方でマネージドとベアのビルドをテストすると、JavaScriptのAPIはコンパクトに残るが、実行時にはOSのプロンプト、デバイスハードウェア、そして先ほどネイティブの権限を設定した影響に依存する。

モバイルアプリの画像ピッカーのフローchart:カメラまたはメディアライブラリのソースを選択するプロセスを示す。

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

両方の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 つの詳細な点がここで重要です。

ライブラリとカメラの許可を別々に要求する必要があります。独立して失敗します。
キャンセルを正常なユーザーアクションとして扱い、エラー状態としては扱いません。
から読み取ります、 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' },
  ]);
};

ライブラリとカメラの許可を別々に要求する必要があります。独立して失敗します。

If your broader app also supports file access patterns outside Expo or you are comparing conventions across native stacks, this Capacitor の写真ライブラリのリファレンスは、

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

システムUIの期待事項

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

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

私は、機能が完了する前に、これらのケースをテストすることが多いです。

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

これらのケースは、実際の生産動作に直接対応する。必要に応じてファイルをサーバー、モデレーションパイプライン、またはInstagramメディアパブリッシング__CAPGO_KEEP_0__などの公開エンドポイントに送信するための次のステップをきちんと設定する。 Instagram media publishing API.

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

結果オブジェクトの正しい読み取り

現在のExpoアプリケーションで重要な結果の形状は

トップレベル result.assets[0].uri。この詳細は、管理されたワークフローとバレワークフロープロジェクト両方に影響を与えます。JavaScript__CAPGO_KEEP_0__は同じですが、ネイティブのセットアップは下部にあるため異なります。 result.uri. That detail affects both managed and bare workflow projects because the JavaScript API is the same even though native setup differs underneath.

これは、キャンセルされたピッカーがアセットを読み取ることができないことと、__CAPGO_KEEP_0__が想定していることの2つの失敗ケースを処理します。

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 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 画像データを含む必要がある統合のみに使用してください

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

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

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

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 media publishing API.

アプリ更新用の画像最適化のガイドは、ピッカーの構成とともに便利な相談相手です。実用的なアプリ用の安全な結果パターン

__CAPGO_KEEP_0__

デモ用途では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 がファイルアップロードを期待している場合、

は依然として最も安全なデフォルトです。Rails、Node、Laravel、Django、Go の共通バックエンドで動作し、ピッカーをトランスポートの懸念から分離します。 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はメモリのコストが安く、モバイル上で推論が容易なので、より推奨される方法です。

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

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

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.

Bare React Nativeアプリでは、これらの差異を直接感じることができます。Nativeのセットアップをより多く所有しているからです。ただし、管理されたExpoアプリでも、ピッカーをプラットフォームに合わせたものとして扱う必要があります。

実用的なルールは簡単です。検証できるフィールドに依存しましょう。デバイス間でUIやメタデータが同一である必要はありません。

実際のアプリでは、以下の例が重要です。 編集とトリミング:
iOSとAndroidのUIとトリミングの動作は同一ではありません。 fileName, mimeType返されたメタデータ: fileSize 、および
が欠落しているか一貫性がなくなることがあります。代替値を追加してください。 許可:
iOSの写真アクセスは選択されたアイテムに制限されることがあります。Androidの動作はOSバージョンとシステムピッカーのサポートに依存します。 カメラ出力:

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

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

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

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

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

ExpoとCapacitorを交互に切り替えるチームは、抽象化レイヤー間の違いを過小評価する傾向があります。Capgoは、Capacitorがプラットフォームの違いをどのように扱うかについての便利な説明があり、どの程度ネイティブのセットアップをチームが所有したいのか決定する際の比較点として役立ちます。私の好みは両方のワークフローで一貫しています。ピッカーの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__

Expo Image Picker の多くのバグは、特定のカテゴリに分類できます。最速の修正方法は、失敗しているレイヤーを特定することです: config、許可、結果の処理、またはレンダリング。

Expo-image-picker ライブラリを使用する際に発生する一般的な問題をトラブルシューティングするためのチェックリストです。

一般的な失敗のための高速チェック

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

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

許可が拒否されたエラー:

アプリの設定とネイティブの許可文字列を確認し、再構築してください。 イメージ URI:
undefined 読み取り , result.assets?.[0]?.uri読み取り result.uri.
キャンセルすると何も起こらない キャンセルが正しいかもしれません。キャンセルを無視する状態として扱ってください。
画像が表示されない __CAPGO_KEEP_0__のURIが状態に保存され、__CAPGO_KEEP_0__に渡されていることを確認してください。 <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 Capgo

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