Expo Image Picker: 2026年版

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

Expo Image Pickerはそのような場所で役立ちます。それは、デバイスライブラリから画像や動画を選択したり、カメラで写真を撮ったりするためのシステムUIを開くための公式Expoライブラリです。 Expoパッケージリポジトリ. native メディア入力に信頼できるブリッジを提供しますが、デバイスごとに同じように動作するカスタムメディアエクスペリエンスは提供されません。

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

Expo Image Pickerの使用を始める

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

Expo 画像ピッカーの利用開始

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

expo-image-picker Expo 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__の説明とよく組み合わされます。

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 Goを使用しているチームがいる場合、このガイドは__CAPGO_KEEP_1__の説明とよく組み合わされます。.

ハッピーパスはストーリーの半分だけです。ピッカー実装は、両方のワークフローで動作し、プラットフォーム固有のパーミッションの奇妙さをユーザーに驚かせずに、そしてアップロードレイヤーに使えるファイルを渡すことができるかどうかで評価されます。

インストールと基本的な設定

インストールには1つのコマンドが必要です。ネイティブの設定が正しく設定されていれば、実機、カスタム開発クライアント、そしてプロダクションビルドでもピッカーが動作するかどうかが決まります。

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.

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

npx expo install expo-image-picker

Expoのバージョンに応じたインストーラーから始めます。 expo install 使用する代わりに 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は正常ですが、ボタンハンドラーが実行されると、許可のテキストが欠けていることが実行時エラーとして表示されます。失敗はスタックの下の方にあります。私は通常、コンポーネントcodeを触る前に、 Info.plist, the app config, and whether the current build includes the latest native changes before I touch the component code.

設定が予測可能になる習慣は数つきます。

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

開発中はピッカーが動作するが、テストフライトまたはGoogle Playストアのビルドで機能しない場合、まずは構成問題として扱ってください。ほとんどの場合、それはそうです。

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

ユーザーが「写真をアップロード」ボタンをタップすると、カメラまたはライブラリが開き、ユーザーはその時点でアプリの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 photo library reference は有用なコンテキストです。

A short demo helps when you’re showing this flow to teammates or QA:

システムUIの期待値

expo-image-picker プラットフォームピッカーまたはカメラUIを開きます。アプリはそのフローの全画面を制御していません。その区別は重要です。 “works on my device” は “OS がテストしたパスを許可した” と意味します。

iOS の場合、ユーザーは完全なライブラリへのアクセスを許可するのではなく、制限されたライブラリへのアクセスを許可する場合があります。Android の場合、ピッカーの動作は OS のバージョンとベンダースキンによって異なります。マネージドワークフロープロジェクトの場合、Expo はより多くのネイティブのワイヤリングを処理します。 Bare ワークフロープロジェクトの場合、ビルドされたアプリが変更したネイティブの許可変更を含むことを確認する必要があります。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.

これは、よく見る2つの失敗ケースを処理します。キャンセルしたピッカーにはアセットを読むことができず、__CAPGO_KEEP_0__が仮定しているもの

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] 実行時には失敗する。

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

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

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

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

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

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

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

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

最後の点は、メモリが少ないデバイスでは重要です。予め表示およびマルチパートアップロードのために、ローカルファイルURIは通常、より良いハンドオフです。 Base64は有効な使用法がありますが、ファイル参照を渡すことと比較して、コストが高くなります。

URIとBase64

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

プレビューの場合に使用します。 URI URI
使用 URI ファイルアップロード用に使用します。
受信システムがエンコードされたコンテンツを要求していない限り、base64を使用してください。ピッカーのサイズを小さくし、テストが容易になるパターンを維持します。また、多くのバックエンドメディアフローが構築されていることにも一致しています。これには、最終的に外部プラットフォームに公開するサービスも含まれます。 Instagram メディアパブリッシング

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__ __CAPGO_KEEP_0__

https://capgo.com/docs/guides/optimizing-images-for-app-updates

デモ用途の場合は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.

アプリケーション__CAPGO_KEEP_0__は安定しているため、ネイティブの差異を他の場所で処理しながらも、管理型と裸のプロジェクトを同期しやすくなります。

最後のチェックは、必要なデータを要求し、ピッカーを選択に焦点を当てるのではなく、一般的なファイル処理ステップに変えるのではなく、ピッカーが選択をうまく処理するようにします。

通常、ピッカー機能は、最初に選択された画像がリトライ、認証ヘッダ、ネイティブの許可差異、実際のアップロードエンドポイントなどを乗り越える必要があるとすると、単純ではなくなります。 expo-image-picker ネイティブの差異を他の場所で処理しながらも、管理型と裸のプロジェクトを同期しやすくします。

ピッカーは選択をうまく処理することができれば十分です。

残りの機能はアプリケーションに任せます。

サーバーストレージの利点と欠点を比較したインフォグラフィックのタイトル「ローカル vs サーバーストレージの考慮事項」 FormData 実用的なアップロードパターン

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.

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

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

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

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

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

マネージド vs. Bareワークフローの違い

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

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

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

Teams that switch between Expo and Capacitor often underestimate how different these abstraction layers are. Capgo has a useful explanation of how Capacitor handles platform differences両方のワークフローで、私の好みは一貫しています。ピッカーを__CAPGO_KEEP_0__に狭くし、結果を一度に正規化し、専用の__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.

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

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

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

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

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

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

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

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

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