Expo Image Picker : le guide complet pour 2026

Vous en êtes probablement au stade où l'UI est prête, l'écran de profil possède un bouton « Upload photo », et la partie facile devient soudainement complexe. Le flux de sélection d'image touche aux permissions natives, aux interfaces gérées par l'OS, à des formats de retour différents de ce que beaucoup de développeurs attendent, et à plusieurs détails de build qui n'apparaissent qu'après avoir déployé un vrai build.

C'est là qu'intervient Expo Image Picker. C'est la bibliothèque officielle d'Expo pour ouvrir l'interface système afin de choisir des images et des vidéos depuis la bibliothèque de l'appareil ou prendre une photo avec la caméra, comme décrit dans le répertoire de packages Expo. En pratique, cela signifie que vous bénéficiez d'un bridge fiable vers les entrées média natives, mais pas d'une expérience média personnalisée qui se comporterait de manière identique sur chaque appareil.

Ce guide est écrit pour une première implémentation, pas pour une démo. Il se concentre sur les décisions cruciales en production : configuration du workflow managed vs bare, gestion des permissions pour éviter les surprises, parsing sécurisé des résultats et un pattern d'upload pratique après la sélection d'un fichier. Si vous travaillez sur une configuration native personnalisée, cela aide aussi à comprendre la différence avec les options de mise à jour Expo EAS Capgo compare dans son guide alternatif.

Table des matières

• Démarrer avec Expo Image Picker
• Installation et configuration essentielle
  • Configuration du workflow managed
  • Détails de la configuration Bare React Native
• Accéder à la caméra et à la bibliothèque média
  • Un composant minimal mais sécurisé
  • Bibliothèques et flux de la caméra
  • Ce qu'il faut attendre de l'interface système
• Gestion des résultats et des options du picker
  • Lire correctement l'objet de résultat
  • Options modifiant le comportement en aval
  • URI ou base64
  • Un pattern de résultat plus sûr pour les apps réelles
• Patterns avancés et différences entre plateformes
  • Un pattern d'upload pratique
  • Quand les différences de plateforme comptent vraiment
  • Différences entre workflow managed et bare
• Dépannage des problèmes courants
  • Vérifications rapides pour les échecs fréquents
  • Une courte checklist de production

Démarrer avec Expo Image Picker

Un product manager demande des photos de profil. Une semaine plus tard, cette même fonctionnalité doit aussi permettre l'upload de reçus, la capture par caméra pour des rapports d'incidents, et la gestion des tentatives lorsque les utilisateurs refusent la permission la première fois. L'input d'image évolue vite car il touche aux permissions natives, à l'UI gérée par l'OS, à la gestion des fichiers temporaires et aux flux d'upload backend.

expo-image-picker le module Expo SDK est fait pour ça. Il ouvre le sélecteur de la plateforme ou l'UI de la caméra et renvoie le média sélectionné dans un format que votre code React Native peut gérer. L’API JavaScript est léger. Le principal défi consiste à configurer correctement 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 construire un sélecteur personnalisé. Cela donne généralement un meilleur résultat : 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.

Cette approche est utile car les modes de défaillance proviennent rarement du bouton qui appelle le picker. Ils viennent généralement de l'un de ces trois endroits :

• Configuration native : configuration du plugin manquante, chaînes de permissions incorrectes ou build obsolète après un changement de config
• Comportement au runtime : les utilisateurs peuvent refuser l'accès, accorder un accès limité à la bibliothè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 également le processus de configuration. Dans une application Expo gérée, la majeure partie du travail natif se trouve dans l'app config et nécessite un rebuild lorsque 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é au lieu d'Expo Go, ce guide se complète parfaitement avec l'Capgo de alternative à Expo EAS pour les équipes qui ont besoin de tester des modules natifs au-delà d'Expo Go.

Cette distinction est cruciale pour la suite du guide, car le scénario idéal n'est que la moitié de l'histoire. Une implémentation de sélecteur est robuste lorsqu'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 plutôt que de s'arrêter à un simple aperçu local.

Installation et configuration essentielle

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

expo-image-picker offre une API orientée 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 avec l'installateur d'Expo sensible aux versions :

npx expo install expo-image-picker

Utilisez 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 workflow managed

Dans le workflow managed, déclarez le plugin dans la config de l'app pour qu'Expo puisse appliquer les changements natifs au temps de build.

Exemple avec app.json:

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

C'est la configuration minimale. En pratique, les équipes ajoutent aussi le texte de permission, surtout sur iOS où le prompt système doit expliquer pourquoi l'app nécessite cet accès. Utilisez une formulation spécifique à l'action de l'utilisateur. « Upload d'une photo de profil » est préférable à « Accès aux médias requis ».

Un détail opérationnel fait perdre beaucoup de temps. Modifier plugins, les chaînes de permission ou d'autres configs natives nécessite un nouveau build. Recharger le JavaScript ne suffit pas à appliquer ces changements. Avec Expo Go, vous êtes également limité par ce que le client inclut déjà. Dans un development build ou un build de production, 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 davantage de choses dans le projet natif vous-même. Les descriptions d'usage iOS sont la première chose à vérifier. Si votre flux peut ouvrir la bibliothèque, lancer la caméra ou enregistrer une vidéo avec audio, votre app a besoin des chaînes de permission correspondantes dans Info.plist avant de relancer un build.

Voici une checklist pratique pour les projets bare :

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

L'absence de texte de permission ressemble souvent à un bug au runtime car l'UI code est correcte et le handler du bouton s'exécute. L'erreur 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 derniers changements natifs 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 le prompt.
• Configurez la caméra et la bibliothèque séparément : l'une peut fonctionner alors que l'autre échoue encore.
• Recompilez après les changements natifs : le hot reload et le fast refresh ne mettent pas à jour les permissions natives.
• Test sur appareil : le comportement du simulateur peut masquer des problèmes de permissions ou de caméra.

Si le picker fonctionne en développement mais plante sur TestFlight ou sur le build du Play Store, considérez d'abord cela comme un problème de configuration. C'est le cas la plupart du temps.

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

Un utilisateur appuie sur « Upload photo », s'attend à ce que la caméra ou la bibliothèque s'ouvre, et votre application n'a qu'une mission à ce moment-là : ouvrir la bonne interface système, gérer le refus ou l'annulation sans faire planter l'écran, et renvoyer une référence de fichier local exploitable pour l'aperçu ou l'upload.

Cela semble simple jusqu'à ce que vous testiez les builds managed et bare sur iOS et Android. L’API JavaScript reste compact, mais le comportement au runtime dépend toujours des prompts de l'OS, du matériel de l'appareil et de la façon dont vos permissions natives ont été configurées précédemment.

Un composant minimal mais sûr

Le flux principal est identique dans les projets Expo managed et bare workflow. Demandez la permission pertinente, lancez le picker, 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 de manière indépendante.
• 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 uri.

Bibliothèques et flux de la caméra

Commencez par le flux de la bibliothèque pour obtenir le chemin le plus rapide vers une fonctionnalité opérationnelle. C'est plus facile à tester, cela fonctionne sur plus de configurations de simulateurs et cela évite les cas limites du matériel de la 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 de caméra identique à un appareil réel. Dans les projets bare, ces écarts peuvent vous pousser à inspecter le composant code alors que le problème réel vient de la config native ou de l'environnement de test.

Un pattern d'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 focalisée. Cela facilite également 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 à la bibliothèque photo Capacitor est un contexte utile.

Une courte démo est utile pour montrer ce flux à vos collègues ou à la QA :

Ce qu'il faut attendre de l'interface système

expo-image-picker ouvre le sélecteur de la plateforme ou l'interface de la caméra. Votre app ne contrôle pas chaque écran de ce flux. Cette distinction est cruciale car « ça marche sur mon appareil » signifie souvent « l'OS a autorisé le chemin que j'ai testé ».

Sur iOS, les utilisateurs peuvent accorder un accès limité à la bibliothèque plutôt qu'un accès complet. Sur Android, le comportement du sélecteur peut varier selon la version de l'OS et la surcouche du constructeur. Dans les projets en managed workflow, Expo gère une plus grande partie du câblage natif pour vous. Dans les projets en bare workflow, vous devez confirmer que votre build inclut bien les changements de permissions natifs que vous avez effectués. L'appel JavaScript peut être identique dans les deux cas alors que le résultat au runtime diffère.

Je teste généralement ces cas avant de valider la fonctionnalité :

• première demande de permission
• permission refusée
• annulation par l'utilisateur
• sélection réussie dans la bibliothèque
• capture réussie avec la caméra 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 nécessite généralement une logique de production réelle. 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 de l'utilisateur.

Lire correctement l'objet de résultat

La structure du résultat qui importe dans les apps Expo actuelles est result.assets[0].uri, pas au premier niveau result.uri. Ce détail affecte les projets en workflow managed et bare car l’API JavaScript est identique, même si la configuration native diffère en dessous.

Utilisez un pattern de garde (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 donne pas d'asset à lire, et un code qui suppose que result.assets[0] l'objet existe toujours échouera au runtime.

Une fois que vous avez l'URI, l'affichage d'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 un objet complet, pas seulement l'URI. En pratique, fileName, mimeType, width, height, et fileSize sont souvent utiles pour la validation, les logs ou pour construire une requête multipart plus propre.

Options modifiant le comportement en aval

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

Quelques compromis peuvent passer inaperçus :

• allowsEditing est utile quand l'emplacement de l'image a une forme ou une taille fixe. C'est moins utile si votre serveur gère son propre pipeline de recadrage et que vous voulez 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 récepteur l'exige.

Ce dernier point est crucial sur les appareils à faible mémoire. Une 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 contre base64

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

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

Ce modèle permet de garder le code du picker léger et plus facile à tester. Cela s'aligne également sur la manière dont de nombreux flux média backend sont construits, y compris les services qui publient finalement sur des plateformes externes telles que l' publication de médias Instagram API.

Si votre équipe déploie des mises à jour OTA fréquentes ou gère des assets lourds en images lors de la livraison de l'app, les décisions sur la taille des fichiers impactent le reste du pipeline. Ce guide sur 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 apps réelles

Pour une démo code, stocker uniquement imageUri convient. En production, stockez un objet normalisé afin que l'étape suivante (aperçu, validation, upload ou retry) n'ait pas besoin de 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'app. Cela facilite également l'alignement des projets managed et bare, car le code de l'app 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 par précaution. Ne demandez que les données dont vous avez réellement besoin, afin que le picker reste concentré sur la sélection plutôt que de devenir une étape 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 l'instant où la première image sélectionnée doit survivre aux tentatives de reconnexion, 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 est toujours l'option par défaut la plus sûre. Cela fonctionne avec les backends courants comme Rails, Node, Laravel, Django et Go, tout en gardant 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 nécessitent généralement une couche supplémentaire. Extrayez 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.

A few checks prevent the common failures I see in review:

• Confirmer le fichier local uri existe avant de construire la requête
• Afficher un aperçu avant l'upload pour que l'utilisateur détecte l'erreur rapidement
• 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 exige du base64 plutôt que 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 vraiment

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 anticiper.

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.

La règle pratique est simple. Fiez-vous aux champs que vous pouvez valider, pas à une UI ou des métadonnées identiques sur tous les appareils.

Quelques exemples importants pour les apps réelles :

• É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 : L'accès aux photos sur iOS peut être limité aux éléments sélectionnés, tandis que le comportement sur Android dépend davantage de la version de l'OS et du support du sélecteur système
• Sortie caméra : Les images capturées peuvent avoir un nom, une orientation ou une compression différents des assets de la bibliothèque

Si votre équipe travaille également en dehors d'Expo, ceci Guide de développement de l'app DesignStack offre un contexte Android utile pour les décisions de gestion des médias au-delà d'une seule bibliothèque.

Différences entre les workflows 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 lors de la création d'un nouveau build. Cela garde la partie JavaScript propre, mais implique aussi qu'un correctif 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é implique plus d'éléments à gérer. Vous devez vérifier vous-même les descriptions d'utilisation 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 diffèrent. 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 sur les deux workflows. Gardez le picker code restreint, normalisez le résultat une seule fois, faites l'upload via une couche API dédiée, et traitez le comportement spécifique à chaque plateforme comme un point à configurer et tester explicitement plutôt que de le gommer à coups d'hypothèses.

Dépannage des problèmes courants

La plupart des bugs d'Expo Image Picker entrent dans un petit nombre de catégories. Le correctif le plus rapide consiste généralement à identifier la couche qui é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. De nombreuses implémentations supposent encore une URI directe et sautent l'étape de canceled vérification.

Quelques correspondances rapides pour vous aider :

• 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, pas result.uri.
• Rien ne se passe après l'annulation : C'est peut-être correct. Gérez l'annulation comme un état sans opération.
• L'image ne s'affiche pas : Confirmez 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 vérification avant de déployer :

• Installation avec les outils Expo : Utilisez npx expo install expo-image-picker.
• Configurez les éléments natifs : Ajoutez le plugin et les descriptions de permissions requises.
• Request permissions intentionally: Separate camera and media library flows.
• Sécurisez chaque résultat : Vérifier result.canceled et lire en toute sécurité assets[0].
• Privilégiez les uploads via URI : Réservez le base64 aux cas particuliers uniquement.
• Testez sur des appareils réels : Surtout pour la capture photo et les prompts de permission.

Si votre équipe déploie des apps Capacitor ou Electron en plus de projets React Native, Capgo est une option pour livrer des mises à jour de JavaScript, CSS, config et assets sans attendre la validation des stores à chaque changement. C'est pertinent quand les correctifs liés aux images se trouvent dans votre couche web, comme l'UI d'upload, les règles de validation, le texte ou la gestion des assets autour du flux du picker.