Expo Image Picker : le guide complet pour 2026

Vous en êtes probablement au stade où l'UI est prête, où l'écran de profil a un bouton « Upload photo », et où la partie facile ne l'est soudainement plus. Le flux de sélection d'image implique des permissions natives, des interfaces contrôlées par l'OS, des structures de retour différentes de ce que beaucoup de développeurs attendent, et une poignée de détails de build qui n'apparaissent qu'une fois un vrai build livré.

C'est là qu'intervient Expo Image Picker. C'est la bibliothèque officielle d'Expo pour ouvrir l'UI système afin de choisir des images et des vidéos dans la bibliothèque de l'appareil ou de prendre une photo avec la caméra, comme décrit dans la Dépôt de packages Expo. En pratique, cela signifie que vous obtenez un pont fiable vers l’entrée média native, mais pas une expérience média personnalisée qui se comporte de manière identique sur chaque appareil.

Ce guide est conçu pour la première implémentation, pas pour la démo. Il se concentre sur les décisions qui comptent en production : configuration du workflow managé ou bare, gestion des permissions qui ne vous surprendra pas plus tard, analyse sûre des résultats, et un pattern d’upload concret une fois que l’utilisateur a sélectionné un fichier. Si vous travaillez dans une configuration native personnalisée, il est également utile de comprendre en quoi cela diffère du Options d’update Expo EAS : Capgo les compare dans son guide des alternatives.

Table des matières

• Bien démarrer avec Expo Image Picker
• Installation et configuration essentielle
  • Configuration du managed workflow
  • Détails de configuration Bare React Native
• Accéder à la caméra et à la bibliothèque multimédia
  • Un composant minimal mais sûr
  • Flux bibliothèque et caméra
  • À quoi s’attendre avec l’interface système
• Gérer les résultats et les options du picker
  • Lire correctement l'objet résultat
  • Options qui modifient le comportement en aval
  • URI vs base64
  • Un pattern de résultat plus sûr pour les vraies apps
• Patterns avancés et différences entre plateformes
  • Un pattern d'upload pratique
  • Là où les différences de plateforme comptent réellement
  • Différences entre workflow managed et bare
• Dépannage des problèmes courants
  • Vérifications rapides pour les erreurs courantes
  • Une courte checklist de production

Bien démarrer avec Expo Image Picker

Un product manager demande des photos de profil. Une semaine plus tard, la même fonctionnalité doit aussi gérer l'upload de reçus, la capture via l'appareil photo pour les rapports d'incidents, et les nouvelles tentatives quand l'utilisateur refuse la permission la première fois. La saisie d'images prend vite de l'ampleur, car elle touche aux permissions natives, aux UI gérées par l'OS, à la gestion des fichiers temporaires et aux flux d'upload vers le backend.

expo-image-picker est le module Expo SDK pour cette tâche. Il ouvre le sélecteur de la plateforme ou l'interface caméra et renvoie le média sélectionné dans un format que votre code React Native peut traiter. L’API JavaScript est léger. Le principal défi consiste à bien configurer le setup natif, le flux de permissions et la gestion des résultats, que ce soit sur des projets managed ou bare.

Le compromis principal est simple. Vous laissez iOS et Android afficher leur propre UI média au lieu de développer un sélecteur personnalisé. Le résultat est généralement meilleur : les utilisateurs connaissent déjà les écrans du système, les prompts de permission se comportent comme l'OS l'attend, et votre équipe évite de maintenir une implémentation de galerie en JavaScript.

Considérez cela comme une fonctionnalité d'intégration native avec une interface React.

Cet état d'esprit aide, car les causes d'échec se trouvent rarement dans le bouton qui appelle le sélecteur. Elles viennent généralement de l'un de ces trois endroits :

• Configuration native : configuration de plugin manquante, chaînes de permission incorrectes ou build obsolète après modification de la config
• Comportement au runtime : les utilisateurs peuvent refuser l'accès, accorder un accès limité à la photothèque sur iOS ou annuler le flux sans rien sélectionner
• Analyse du résultat : l’API actuel renvoie un assets tableau, donc les anciens exemples qui lisent result.uri échouent directement

Le choix du workflow modifie aussi le processus de configuration. Dans une application Expo gérée, la majeure partie du travail natif se trouve dans la config de l'app et nécessite un rebuild quand cette config change. Dans une application bare, vous bénéficiez toujours du module Expo API, mais vous devez vérifier plus directement les paramètres des projets iOS et Android sous-jacents. Si votre équipe utilise un client personnalisé plutôt qu'Expo Go, ce guide complète bien l'Capgo de alternative à Expo EAS pour les équipes qui ont besoin de tester des modules natifs au-delà d'Expo Go.

Cette distinction compte pour la suite du guide, car le happy path ne raconte que la moitié de l'histoire. Une implémentation de sélecteur est solide quand elle fonctionne dans les deux workflows, gère les particularités de permissions propres à chaque plateforme sans surprendre l'utilisateur, et transmet un fichier exploitable à votre couche d'upload au lieu de s'arrêter à un aperçu local.

Installation et configuration essentielle

L'installation ne prend qu'une commande. C'est la configuration native qui détermine si le sélecteur fonctionne sur un appareil réel, dans un dev client personnalisé et dans votre build de production.

expo-image-picker offre une API côté React par-dessus les sélecteurs natifs pour les photos, les vidéos et la capture caméra. L'appel JavaScript est simple. La configuration ne l'est pas, car l'accès aux photos et à la caméra est contrôlé par iOS et Android, pas par React Native.

Commencez par l'installeur Expo qui tient compte des versions :

npx expo install expo-image-picker

Utiliser expo install au lieu de npm install ou yarn add. Expo fait correspondre la version du package à votre SDK, ce qui évite une classe courante de problèmes de compatibilité native. Si vous comparez la manière dont les modules Expo s'intègrent à votre processus de release, ceci Aperçu des outils Expo est une référence utile.

Configuration du managed workflow

Dans le managed workflow, déclarez le plugin dans la config de l'app pour qu'Expo puisse appliquer les modifications natives au moment du build.

Exemple avec app.json:

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

C'est la configuration minimale. En pratique, les équipes ajoutent généralement aussi les textes de permission, surtout sur iOS où le prompt système doit expliquer pourquoi l'app a besoin de cet accès. Restez spécifique à l'action de l'utilisateur. « Envoyer une photo de profil » est préférable à « Nécessite l'accès aux médias ».

Un détail opérationnel fait perdre beaucoup de temps. Modifier plugins, les textes de permission ou d'autres configurations natives nécessitent un nouveau build. Recharger le JavaScript n'applique pas ces changements. Dans Expo Go, vous êtes aussi limité par ce que le client inclut déjà. Dans un development build ou un production build, le projet natif ne reflète votre config qu'après un nouveau build.

Détails de configuration Bare React Native

Dans une app bare, le package API est le même, mais vous devez vérifier vous-même davantage de choses dans le projet natif. Les descriptions d'usage iOS sont la première chose à contrôler. Si votre flux peut ouvrir la photothèque, lancer la caméra ou enregistrer une vidéo avec audio, votre app a besoin des textes de permission correspondants dans Info.plist avant de relancer un build.

Voici une checklist pratique pour les projets bare :

1. Installer expo-image-picker par npx expo install expo-image-picker.
2. Ajoutez la config du plugin si votre projet utilise les config plugins d'Expo.
3. Vérifiez que les descriptions d'utilisation iOS correspondent aux fonctionnalités exposées.
4. Recompilez les apps iOS et Android après toute modification de la config native.

Un texte de permission manquant ressemble souvent à un bug au runtime, car l'UI code est correcte et le handler du bouton s'exécute. L'échec se situe plus bas dans la stack. Je vérifie généralement Info.plist, la config de l'app, et si le build actuel inclut les dernières modifications natives avant de toucher au composant code.

Quelques habitudes rendent la configuration plus prévisible :

• Rédigez le texte de permission pour l’action réelle : les utilisateurs doivent comprendre pourquoi ils voient ce prompt.
• Configurez la caméra et la bibliothèque séparément : l’un peut fonctionner alors que l’autre échoue encore.
• Recompilez après des modifications natives : le hot reload et le fast refresh ne mettent pas à jour les permissions natives.
• Testez sur un appareil réel : le comportement du simulateur peut masquer les problèmes de permissions et de caméra.

Si le picker fonctionne en développement mais ne fonctionne plus dans le build TestFlight ou Play Store, cherchez d’abord un problème de configuration. La plupart du temps, c’en est un.

Accéder à la caméra et à la bibliothèque multimédia

Un utilisateur tape sur « Upload photo », s’attend à ce que la caméra ou la bibliothèque s’ouvre, et votre application n’a qu’un seul rôl’à ce moment-là. Ouvrir la bonne interface système, gérer le refus ou l’annulation sans casser l’écran, et renvoyer une référence de fichier locale utilisable pour l’aperçu ou l’upload.

Ça semble simple jusqu’à ce que vous testiez les builds managed et bare sur iOS et Android. Le JavaScript API reste compact, mais le comportement au runtime dépend toujours des prompts du système, du matériel de l’appareil et de la façon dont vos permissions natives ont été configurées en amont.

Un composant minimal mais sûr

Le flux principal est identique dans les projets Expo managed et bare workflow. Demandez l’autorisation requise, lancez le sélecteur, vérifiez si l’utilisateur a annulé, puis lisez le premier asset depuis result.assets.

Un composant de base ressemble à ceci :

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

Trois détails sont importants ici.

• Demandez les permissions de la bibliothèque et de la caméra séparément. Elles échouent indépendamment.
• Traitez l'annulation comme une action utilisateur normale, et non comme un état d'erreur.
• Lire depuis assets[0], car le sélecteur renvoie un tableau d'assets plutôt qu'un élément de premier niveau uri.

Flux bibliothèque et caméra

Commencez par le flux de la bibliothèque si vous voulez le chemin le plus rapide vers une fonctionnalité opérationnelle. C'est plus facile à tester, cela fonctionne dans plus de configurations de simulateur et cela évite les cas limites du matériel caméra. Ajoutez le support de la caméra une fois que le chemin de gestion des résultats est stable.

Le chemin de la caméra présente plus de risques d'échec en développement. Le support de l'iOS Simulator est limité. Les émulateurs Android peuvent ne pas exposer un comportement caméra identique à un appareil réel. Dans les projets bare, ces écarts peuvent vous amener à examiner le composant code alors que le problème réel vient de la config native ou de l'environnement de test.

Un pattern UI propre consiste à demander la source à l'utilisateur avant d'appeler le sélecteur API :

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

Cette séparation permet de garder chaque fonction ciblée. Cela facilite aussi l'ajout ultérieur d'analytics, de feature flags ou de règles spécifiques au backend. Par exemple, certaines équipes autorisent l'upload depuis la bibliothèque pour les photos de profil, mais exigent des captures caméra récentes pour la vérification d'identité.

Si votre application supporte également l'accès aux fichiers en dehors d'Expo ou si vous comparez les conventions entre différentes stacks natives, ceci référence sur la bibliothèque photo Capacitor est un contexte utile.

Une courte démo est utile pour présenter ce flux à vos collègues ou à l’équipe QA :

À quoi s’attendre avec l’interface système

expo-image-picker ouvre le sélecteur de plateforme ou l’interface de l’appareil photo. Votre application ne contrôle pas chaque écran de ce flux. Cette distinction est importante, car « ça marche sur mon appareil » signifie souvent « le système d’exploitation a autorisé le chemin que j’ai testé ».

Sur iOS, les utilisateurs peuvent accorder un accès limité à la bibliothèque au lieu d’un accès complet. Sur Android, le comportement du sélecteur peut varier selon la version du système et la surcouche constructeur. Dans les projets en workflow managé, Expo gère une grande partie de la configuration native pour vous. Dans les projets en workflow bare, vous devez vous assurer que votre application compilée inclut les modifications de permissions natives que vous avez effectuées. L’appel JavaScript peut être identique dans les deux cas, mais le résultat à l’exécution diffère.

Je teste généralement ces cas avant de considérer la fonctionnalité comme terminée :

• première demande de permission
• permission refusée
• annulation par l’utilisateur
• sélection réussie dans la bibliothèque
• capture photo réussie sur un appareil physique
• aperçu immédiat de l’URI locale retournée

Ces cas correspondent directement au comportement réel en production. Ils préparent aussi proprement l’étape suivante si vous devez envoyer le fichier vers un serveur, un pipeline de modération ou un endpoint de publication tel que le Publication de médias Instagram avec API.

Gérer les résultats et les options du picker

Le résultat du picker est la partie qui demande généralement une vraie logique de production. L'interface système renvoie un objet structuré, pas seulement un chemin de fichier, et de petites erreurs ici entraînent des aperçus cassés, des uploads vides ou des crashs après une annulation par l'utilisateur.

Lire correctement l'objet résultat

La structure du résultat qui importe dans les apps Expo actuelles est result.assets[0].uri, pas un élément de premier niveau result.uriCe détail affecte aussi bien les projets en workflow managed qu'en bare, car l’API JavaScript est identique, même si la configuration native diffère en arrière-plan.

Utilisez un pattern 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);

Cela gère les deux cas d'échec que je vois le plus souvent. Un picker annulé ne vous fournit pas d'asset à lire, et code qui suppose que l'objet result.assets[0] existe toujours échouera au runtime.

Une fois que vous avez l'URI, afficher un aperçu est simple :

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

Si vous prévoyez un upload plus tard, conservez l'intégralité du asset l’objet complet, pas seulement l’URI. En pratique, fileName, mimeType, width, height, et fileSize sont souvent utiles pour la validation, les logs ou la construction d’une requête multipart plus propre.

Options qui modifient le comportement en aval

Certaines options du picker influencent plus que l’écran de sélection. Elles déterminent la taille des fichiers, le comportement d’édition et ce que votre backend doit accepter.

Quelques compromis passent facilement inaperçus :

• allowsEditing est utile lorsque l’emplacement de l’image a une forme ou une taille fixe. Il l’est moins si votre serveur gère son propre pipeline de recadrage et que vous souhaitez le fichier original.
• quality affecte le temps d’upload, la pression mémoire et le stockage serveur. quality: 1 n'est pas forcément le bon choix.
• mediaTypes doit correspondre aux règles du backend. Si le serveur rejette les vidéos, ne laissez pas le picker les renvoyer.
• base64 augmente la taille de la charge utile en mémoire. Évitez cela, sauf si le service destinataire l'exige.

Ce dernier point est crucial sur les appareils à faible mémoire. Un URI de fichier local est généralement une meilleure option pour l'aperçu et l'upload multipart. Le Base64 a des usages valides, mais il est coûteux par rapport au passage d'une référence de fichier.

URI vs base64

Pour la plupart des apps, la règle est simple :

• Utiliser URI pour les aperçus.
• Utiliser URI pour les uploads de fichiers.
• Utiliser base64 uniquement lorsque le système récepteur demande explicitement un contenu encodé.

Ce schéma permet de garder le code du picker petit et plus facile à tester. Il correspond aussi à la façon dont beaucoup de flux média backend sont conçus, y compris les services qui finissent par publier sur des plateformes externes comme le Publication de médias Instagram avec API.

Si votre équipe déploie fréquemment des mises à jour OTA ou fait transiter des assets riches en images dans la livraison de l'app, les choix de taille de fichier faits ici se répercutent sur le reste du pipeline. Ce guide sur l' optimiser les images pour les mises à jour d’app est un complément utile à la configuration du picker.

Un pattern de résultat plus sûr pour les vraies apps

Pour les démos code, stocker uniquement imageUri C’est acceptable. En production, stockez un objet normalisé afin que l’étape suivante (aperçu, validation, upload ou nouvelle tentative) n’ait pas à réinterpréter la réponse brute du picker à chaque fois.

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

Cela vous offre une structure prévisible au sein de l’application. Cela facilite également l’alignement entre les projets gérés et les projets bare, car l’application code reste stable pendant que vous gérez les différences natives ailleurs.

Une dernière vérification est utile. N'activez pas de champs de résultat supplémentaires au cas où. Ne demandez que les données dont vous savez avoir besoin, et gardez le picker centré sur la sélection plutôt que d'en faire une étape générale de traitement de fichiers.

Patterns avancés et différences entre plateformes

Une fonctionnalité de picker cesse généralement d'être simple dès que la première image sélectionnée doit résister aux retries, aux headers d'auth, aux différences de permissions natives et à un véritable endpoint d'upload. expo-image-picker gère bien la sélection. Le reste de la fonctionnalité dépend de votre application.

Un pattern d'upload pratique

Pour les API qui attendent un upload de fichier, FormData reste l'option par défaut la plus sûre. Il fonctionne avec les backends courants Rails, Node, Laravel, Django et Go, et garde le picker séparé des problématiques de transport.

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

Ce code suffit à prouver que le chemin fonctionne, mais les applications en production ont généralement besoin d'une couche supplémentaire. Dérivez name et type l'asset sélectionné quand c'est possible, attachez l'auth en dehors de la fonction du picker, et gardez l'état d'upload séparé de l'état du picker pour qu'une requête échouée n'oblige pas l'utilisateur à rouvrir la bibliothèque.

Quelques vérifications évitent les erreurs courantes que je vois en review :

• Confirmer que le fichier local uri existe avant de construire la requête
• Afficher un aperçu avant l'upload pour que les utilisateurs repèrent vite le mauvais fichier
• Empêcher les clics répétés pendant que la requête est en cours
• Gérer les échecs réseau séparément de l'annulation du picker ou des erreurs de permission
• Prévoir que la validation backend rejette les fichiers volumineux, les types MIME non supportés ou l'absence d'auth

Si votre backend nécessite du base64 au lieu du multipart, il s'agit généralement d'une contrainte serveur et non d'une exigence du picker. Le multipart est moins gourmand en mémoire et plus simple à gérer sur mobile.

Là où les différences de plateforme comptent réellement

L'UI du picker est native, elle hérite donc du comportement natif. Cela affecte à la fois ce que voient les utilisateurs et ce que votre code doit supposer.

Sur iOS, les flux d'édition et les prompts de permission suivent les conventions d'Apple. Un accès limité aux photos peut renvoyer un ensemble d'assets plus restreint que ce que votre compte de test a vu sur un appareil avec accès complet. Sur Android, le comportement du picker varie davantage selon la version de l'OS et la surcouche du fabricant, notamment pour les albums, les noms de fichiers et la manière dont les captures caméra sont renvoyées. Les apps React Native bare ressentent ces différences plus directement parce que vous gérez davantage la configuration native, mais les apps Expo managed ont toujours besoin de code qui traite le picker comme façonné par la plateforme plutôt que parfaitement uniforme.

La règle pratique est simple. Fiez-vous aux champs que vous pouvez valider, pas à une UI ou des métadonnées identiques d'un appareil à l'autre.

Quelques exemples concrets dans de vraies apps :

• Édition et recadrage : L'interface et le comportement du recadrage diffèrent entre iOS et Android
• Métadonnées retournées : fileName, mimeType, et fileSize peuvent être absentes ou incohérentes, prévoyez des valeurs par défaut
• Permissions : Sur iOS, l’accès aux photos peut être limité à une sélection ; sur Android, cela dépend surtout de la version d’OS et de la prise en charge du sélecteur système.
• Sortie caméra : Les images capturées peuvent présenter un nom, une orientation ou une compression différents des assets de la bibliothèque.

Si votre équipe travaille aussi en dehors d'Expo, ceci Guide de développement d'app DesignStack fournit un contexte Android utile pour les décisions de gestion des médias qui dépassent le cadre d'une seule bibliothèque.

Différences entre workflow managed et bare

À ce stade, les choix de configuration commencent à avoir un impact opérationnel.

Dans le workflow managed, les chaînes de permission et la config des plugins se trouvent généralement dans la config de l'app, et les changements natifs sont appliqués quand vous créez un nouveau build. Cela garde la surface JavaScript propre, mais implique aussi qu'une correction de config n'est visible qu'au prochain build natif. Les mises à jour OTA ne corrigent pas des permissions natives manquantes.

Dans le workflow bare, la même fonctionnalité comporte plus d'éléments à gérer. Vous devez vérifier vous-même les descriptions d'usage iOS, le comportement du manifest Android, l'installation des packages et le timing du rebuild. L'avantage, c'est le contrôle. Le coût, c'est qu'un problème de picker peut venir de la configuration native, et non de l'appel JavaScript.

Les équipes qui passent d'Expo à Capacitor sous-estiment souvent à quel point ces couches d'abstraction sont différentes. Capgo propose une explication utile sur comment Capacitor gère les différences entre les plateformes, et c'est un bon point de comparaison si vous évaluez la part de configuration native que votre équipe veut prendre en charge.

Ma préférence reste la même pour les deux workflows. Gardez le picker code restreint, normalisez le résultat une seule fois, effectuez l'upload via une couche API dédiée, et traitez le comportement spécifique à chaque plateforme comme un élément à configurer et tester explicitement plutôt que de le masquer derrière des suppositions.

Dépannage des problèmes courants

La plupart des bugs d'Expo Image Picker se classent dans quelques catégories. La solution la plus rapide consiste généralement à identifier quelle couche échoue : la config, les permissions, la gestion du résultat ou le rendu.

Vérifications rapides pour les erreurs courantes

Si le sélecteur ne s'ouvre pas ou si les permissions échouent, vérifiez d'abord la configuration native. Dans les apps bare, l'absence de descriptions d'utilisation iOS est une cause fréquente.

Si l'app crash après la fermeture du sélecteur, inspectez la gestion de vos résultats. Beaucoup d'implémentations supposent encore une URI directe et sautent l'étape de canceled vérification.

Quelques correspondances rapides :

• Erreurs de permission refusée : Vérifiez la config de votre app et les chaînes de permission natives, puis relancez un build.
• undefined URI de l'image : Lire depuis result.assets?.[0]?.uri, et non result.uri.
• Rien ne se passe après l'annulation : Cela peut être correct. Gérez l’annulation comme un état sans effet.
• L’image ne s’affiche pas : Vérifiez que l’URI a été stockée dans l’état et transmise à <Image source={{ uri }} />.
• Camera acts strangely in simulator: Testez sur un appareil physique avant de chercher un bug dans la bibliothèque.

Une courte checklist de production

Utilisez ceci comme dernière passe avant de déployer :

• Installez avec les outils Expo : Utiliser npx expo install expo-image-picker.
• Configurez les éléments natifs : Ajoutez le plugin et les descriptions de permissions requises.
• Demandez les permissions au bon moment : Séparez les flux caméra et bibliothèque multimédia.
• Vérifiez chaque résultat : Vérifier result.canceled et lisez en toute sécurité assets[0].
• Privilégiez les uploads basés sur URI : Réservez le base64 aux cas particuliers.
• Testez sur de vrais appareils : Surtout pour la capture caméra et les prompts de permission.

Si votre équipe déploie des applications Capacitor ou Electron en parallèle de projets React Native, Capgo est une option pour livrer des mises à jour JavaScript, CSS, de configuration et d’assets sans attendre la revue du store à chaque modification. C’est pertinent lorsque les correctifs liés aux images se trouvent dans votre couche web, comme l’interface d’upload, les règles de validation, les textes ou le traitement des assets autour du flux du sélecteur d’images.