Guide complet de l'outil d'image Expo pour 2026

Vous êtes probablement à un point où l'interface utilisateur est prête, l'écran de profil a un bouton « Télécharger une photo », et maintenant la partie facile n'est plus facile. La sélection réelle de l'image touche les permissions natives, les interfaces contrôlées par le système, les formes de retour différentes que beaucoup de développeurs attendent, et une poignée de détails de construction qui ne se montrent que lorsque vous expédiez une vraie build.

C'est là que le sélecteur d'image Expo entre en jeu. Il s'agit de la bibliothèque officielle d'Expo pour ouvrir l'interface utilisateur système pour choisir des images et des vidéos du dossier de bibliothèque du dispositif ou prendre une photo avec la caméra, comme décrit dans le répertoire de packages Expo. En pratique, cela signifie que vous obtenez un pont fiable vers les entrées de médias natives, mais pas une expérience de médias personnalisée qui se comporte de la même manière sur chaque appareil.

Cette guide est écrit pour la première mise en œuvre, et non pour la démo. Il se concentre sur les décisions qui comptent en production : mise en œuvre de flux de travail gérés ou non gérés, gestion des permissions qui ne vous surprendront pas plus tard, analyse de résultats sûre, et un modèle d'envoi pratique après que l'utilisateur ait sélectionné un fichier. Si vous travaillez dans un setup natif personnalisé, cela vous aide également à comprendre comment cela diffère d'un flux de travail du client de développement Expo.

Table des matières

• Prise en main avec le sélecteur d'image Expo
• Installation et configuration essentielle
  • Configuration de flux de travail géré
  • Détails de configuration de l'installation React Native nue
• Accès à la caméra et à la bibliothèque de médias
  • Un composant minimal mais sûr
  • Flux de bibliothèque et de caméra
  • What to expect from the system UI
• Gestion des résultats et des options du sélecteur
  • Lecture de l'objet de résultat correct
  • Options qui changent le comportement en aval
  • URI versus base64
  • A safer result pattern for real apps
• Modèles avancés et différences de plateforme
  • Un modèle d'upload pratique
  • Où les différences de plateforme comptent vraiment
  • Fonctionnement géré vs. flux de travail non géré
• Résolution des problèmes courants
  • Vérifications rapides des échecs courants
  • Un bref checklist de production

Prise en main de l'outil d'image de l'Expo

A product manager asks for profile photos. A week later, the same feature also needs receipt uploads, camera capture for incident reports, and retries when users deny permission the first time. Image input expands fast because it touches native permissions, OS-owned UI, temporary file handling, and backend upload flows.

expo-image-picker est le module Expo SDK pour ce travail. Il ouvre le sélecteur de plateforme ou l'interface utilisateur de la caméra et retourne les médias sélectionnés sous une forme que votre code React Native peut gérer. Le JavaScript API est petit. Le principal défi réside dans la mise en place native, la gestion des permissions et la gestion des résultats corrects sur les projets gérés et bare.

Le principal compromis est clair. Vous laissez iOS et Android présenter leurs propres interfaces utilisateur de médias au lieu de construire un sélecteur personnalisé. Cela donne généralement de meilleurs résultats : les utilisateurs comprennent déjà les écrans système, les prompts de permission se comportent comme l'OS l'attend, et votre équipe évite de maintenir une mise en page de galerie en JavaScript.

Traitez cela comme une intégration native avec une interface React.

Cette mentalité aide car les modes de failure sont rarement dans le bouton qui appelle le sélecteur. Ils viennent généralement d'une des trois places :

• Configuration native : setup de plugin manquant, chaînes de permission incorrectes, ou une construction obsolète après avoir changé la configuration
• Comportement en temps de cours : Les utilisateurs peuvent refuser l'accès, accorder un accès limité à la bibliothèque sur iOS ou annuler le flux sans sélectionner quoi que ce soit
• Analyse du résultat : l’API actuel retourne un assets tableau, donc les exemples plus anciens qui lisent result.uri directement échouent

Le choix de flux change également le chemin de configuration. Dans une application Expo gérée, la plupart du travail natif se trouve dans la configuration de l'application et nécessite un rebuild lorsque cette configuration change. Dans une application bare, vous obtenez toujours le module Expo API, mais vous devez vérifier les paramètres de projet iOS et Android plus directement. Si votre équipe utilise un client personnalisé au lieu d'Expo Go, ce guide s'accorde bien avec l'explication de Capgo sur comment un client de développement Expo modifie les tests de modules natifs.

Cette division est importante pour le reste du guide car le chemin heureux n'est qu'une moitié de l'histoire. Une mise en œuvre de sélection est solide lorsque cela fonctionne dans les deux flux, gère les particularités de permission plateforme sans surprendre l'utilisateur et transmet un fichier utilisable à votre couche d'upload au lieu d'arrêter à une prévisualisation locale.

Installation et Configuration Essentielle

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

expo-image-picker donne un API React-facing sur les sélecteurs de plateforme pour les photos, les vidéos et la capture de la caméra. L'appel JavaScript est simple. La configuration n'est pas, car l'accès aux photos et l'accès à la caméra sont contrôlés par iOS et Android, et non par React Native.

Commencez avec l'installateur de version-aware d'Expo :

npx expo install expo-image-picker

Utilisez expo install au lieu de npm install ou yarn addEn utilisant l'installateur de version-aware d'Expo, vous pouvez éviter les problèmes de compatibilité natives courants en associant la version du package à votre SDK. Vue d'ensemble des outils d'Expo Configuration de flux de travail géré

Configuration de flux de travail géré

Déclarez le plugin dans la configuration d'application pour que Expo puisse appliquer les modifications natives à temps de compilation.

Exemple avec app.json:

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

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

Un détail opérationnel occasionne beaucoup de temps perdu. La modification pluginsdes chaînes de permission ou d'autres configurations natives nécessite une nouvelle compilation. Le rechargement du JavaScript n'applique pas ces changements. Dans Expo Go, vous êtes également limité par ce que le client inclut déjà. Dans une build de développement ou de production, le projet natif reflète votre configuration uniquement après une nouvelle compilation.

Détails de configuration de l'installation React Native nue.

Dans une application sans enveloppe, le package API est le même, mais vous devez vérifier plus de projet natif vous-même. Les descriptions d'utilisation 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 application nécessite les chaînes de permission correspondantes dans Info.plist avant de reconstruire.

Un plan d'action pratique pour les projets sans enveloppe ressemble à ceci:

1. Installer expo-image-picker avec npx expo install expo-image-picker.
2. Ajoutez la configuration du plugin si votre projet utilise des plugins de configuration Expo.
3. Confirmez que les descriptions d'utilisation iOS correspondent aux fonctionnalités exposées.
4. Reconstruire les applications iOS et Android après tout changement de configuration native.

Le texte de permission manquant ressemble souvent à un bug de runtime car l'interface utilisateur code est correcte et le gestionnaire de bouton fonctionne. L'erreur se situe plus bas dans la pile. Je vérifie généralement Info.plistAvant de toucher le composant code, vérifiez la configuration de l'application, les mises à jour natives et les dernières modifications incluses dans la dernière build.

Quelques habitudes rendent la configuration plus prévisible :

• Écrivez le texte de permission pour l'action réelle : Les utilisateurs doivent comprendre pourquoi ils voient la prompt.
• Configurez la caméra et la bibliothèque séparément : On peut travailler tout en attendant que l'autre fonctionne.
• Rebâtissez après les changements natifs : hot reload and fast refresh do not update native permissions.
• Testez sur appareil : Le comportement du simulateur peut cacher les problèmes de permission et de caméra.

Si le sélecteur fonctionne pendant le développement mais se brise dans TestFlight ou la boutique Play, considérez cela comme un problème de configuration avant tout. La plupart du temps, c'est le cas.

Accéder à la Caméra et à la Bibliothèque de Médias

A l'utilisateur appuie sur « Télécharger une photo », il s'attend à ce que la caméra ou la bibliothèque s'ouvre, et votre application a une seule tâche à ce moment. Ouvrez l'interface utilisateur système appropriée, gérez le refus ou l'annulation sans casser l'écran, et renvoyez une référence de fichier local utilisable pour la prévisualisation ou l'envoi.

Ce sonne simple jusqu'à ce que vous testiez les builds gérés et non gérés sur iOS et Android. Le JavaScript API reste compact, mais le comportement en temps de exécution dépend toujours des invites de l'OS, de l'équipement matériel du dispositif et de la façon dont vos permissions natives ont été configurées plus tôt.

Un composant minimal mais sûr

Le flux de base est cohérent dans les projets de workflow Expo gérés et non gérés. Demandez la permission pertinente, lancez le sélecteur, vérifiez si l'utilisateur a annulé, puis lisez le premier élément de 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 bibliothèque et de caméra séparément. Elles échouent indépendamment.
• Gérez l'annulation comme une action utilisateur normale, et non comme un état d'erreur.
• Lisez assets[0]Puisque le sélecteur renvoie un tableau d'actifs plutôt qu'un élément de niveau supérieur. uri.

Flux de bibliothèque et de caméra

Start with the library flow if you want the fastest path to a working feature. It is easier to test, it works in more simulator setups, and it avoids camera hardware edge cases. Add camera support once the result handling path is stable.

Le chemin de la caméra a plus de façons de fail en développement. La prise en charge du simulateur iOS est limitée. Les émulateurs Android peuvent ne pas exposer le comportement de la caméra qui correspond à un appareil réel. Dans les projets bare, ces lacunes peuvent vous faire regarder le composant code même si le problème réel est la configuration native ou l'environnement de test.

Demandez à l'utilisateur la source 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 maintient chaque fonction focalisée. Cela rend également plus facile d'ajouter des analyses, des drapeaux de fonctionnalité ou des règles spécifiques au serveur ultérieurement. Par exemple, certaines équipes autorisent les téléchargements de bibliothèque pour les images de profil mais exigent des captures de caméra fraîches pour la vérification d'identité.

Si votre application plus large prend également en charge des modèles d'accès au fichier en dehors d'Expo ou si vous comparez des conventions entre les stacks natives, ce Capacitor référence de la bibliothèque photo est utile en tant que contexte.

Un court démo est utile lorsqu'on montre ce flux à ses collègues ou à la QA.

What to expect from the system UI

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

On 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 en fonction de la version du système d'exploitation et de la peau du fabricant. Dans les projets de flux géré, Expo gère plus de la mise en œuvre native pour vous. Dans les projets de flux bare, vous devez confirmer que votre application construite inclut les modifications de permissions natives que vous avez apportées. Le site d'appel JavaScript peut être identique dans les deux cas, tandis que le résultat de temps d'exécution diffère.

I test généralement ces cas avant d'appeler la fonction terminée :

• première demande de permission
• permission refusée
• annulation de l'utilisateur
• sélection de bibliothèque réussie
• captation de la caméra réussie sur un appareil physique
• prévisualisation immédiate de l'URI local retourné

Ces cas correspondent directement au comportement de production réel. Ils mettent également en place l'étape suivante de manière claire si vous devez envoyer le fichier à un serveur, une chaîne de traitement de moderation ou un point de terminaison de publication comme l' Instagram media publishing API.

Gestion des résultats et des options du sélecteur

Le résultat du sélecteur est la partie qui nécessite généralement une logique de production réelle. L'interface utilisateur système retourne un objet structuré, et non juste un chemin de fichier, et de petites erreurs ici entraînent des prévisualisations brisées, des téléchargements vides ou des plantages après que l'utilisateur annule.

La lecture de l'objet de résultat correcte

La forme de résultat qui compte dans les applications Expo actuelles est result.assets[0].uri, pas un niveau supérieur result.uriCela affecte à la fois les projets de workflow gérés et non gérés car le JavaScript API est le même même si la mise en place native diffère en dessous.

Utilisez un modèle de garde d'abord :

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 de figure d'erreur que je vois le plus souvent. Un sélecteur annulé ne vous donne pas d'actif à lire, et code qui suppose que result.assets[0] existe toujours échouera à l'exécution.

Une fois que vous avez l'URI, la mise en page d'une prévisualisation est simple.

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

Si vous prévoyez d'uploader plus tard, gardez l'ensemble. asset environ l'objet, pas seulement l'URI. Dans la pratique, fileName, mimeType, width, height, and fileSize sont souvent utiles pour la validation, le journalisation ou la construction d'une demande multipart plus propre.

Options qui modifient le comportement en aval

Quelques options du sélecteur affectent plus que l'écran de sélection. Elles façonnent la taille du fichier, le comportement d'édition et ce que votre backend doit accepter.

Quelques compromis peuvent être faciles à manquer :

• allowsEditing est utile lorsque la case d'image a une forme ou une taille fixe. Il est moins utile si votre serveur gère son propre pipeline de coupe et que vous souhaitez le fichier original.
• quality affects upload time, memory pressure, and server storage. quality: 1 n'est pas automatiquement le choix le plus approprié.
• mediaTypes devrait correspondre aux règles du serveur. Si le serveur rejette les vidéos, n'autorisez pas le sélecteur à les retourner.
• base64 Augmente la taille du payload en mémoire. Évitez-le sauf si le service de réception le nécessite.

Ce dernier point est important sur les appareils à faible mémoire. Une URI de fichier local est généralement la meilleure passerelle pour la prévisualisation et l'envoi de fichiers multipart. Le Base64 a des utilisations valides, mais il est coûteux par rapport à la transmission d'une référence de fichier.

URI versus base64

For most apps, the rule is simple:

• Utilisez URI pour les prévisualisations.
• Utilisez URI pour les téléchargements de fichiers.
• Utilisez base64 seulement lorsque le système de réception demande explicitement du contenu encodé.

Ce modèle maintient le sélecteur d'images code petit et plus facile à tester. Il s'aligne également sur la façon dont les flux de médias backend sont construits, y compris les services qui publient finalement sur des plateformes externes telles que Le processus de publication de médias Instagram API.

If your team ships frequent OTA updates or moves image-heavy assets through app delivery, file size decisions here carry into the rest of the pipeline. This guide on optimising images for app updates Un modèle de résultat plus sûr pour les applications réelles

Pour les démos __CAPGO_KEEP_0__, stocker uniquement

Pour la démo code, stocker uniquement imageUri is fine. In production, store a normalized object so the next step, preview, validation, upload, or retry, does not need to reinterpret the raw picker response every time.

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.

One final check helps. Do not enable extra result fields just in case. Request the data you know you need, and keep the picker focused on selection rather than turning it into a general file-processing step.

Modèles Avancés et Différences de Plateforme

Un élément de sélecteur fonctionne généralement de manière simple jusqu'à ce que l'image sélectionnée ait à survivre aux réessais, aux en-têtes d'authentification, aux différences de permissions natives et à un point de terminaison d'envoi réel. expo-image-picker gère bien la sélection. Le reste de la fonctionnalité est à votre application.

Un modèle d'upload pratique

For APIs that expect a file upload, FormData C'est toujours la valeur par défaut la plus sûre. Elle fonctionne sur les backends Rails, Node, Laravel, Django et Go courants, et elle garde le sélecteur séparé des préoccupations 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();
}

That code is enough to prove the path works, but production apps usually need one more layer. Derive name et type Lorsque possible, attachez l'authentification à l'élément sélectionné à l'extérieur de la fonction de sélection, et maintenez l'état de l'upload séparé de l'état de la sélection afin qu'une requête échouée n'oblige pas l'utilisateur à rouvrir la bibliothèque.

Quelques vérifications empêchent les échecs courants que je vois en revue :

• Confirmer la localisation uri existe avant de construire la requête
• Render a preview before upload so users catch the wrong file early
• Évitez les appels répétés pendant l'envoi de la requête
• Gérer les erreurs de réseau séparément des annulations du sélecteur ou des erreurs d'autorisation
• Expect backend validation to reject large files, unsupported MIME types, or missing auth

Si votre serveur exige base64 au lieu de multipart, ce n'est généralement pas une contrainte du sélecteur, mais une contrainte du serveur. Multipart est moins coûteux en mémoire et plus facile à raisonner sur les appareils mobiles.

Où les différences entre plateformes comptent vraiment

L’UI du sélecteur est natif, il hérite donc du comportement natif. Cela affecte à la fois ce que les utilisateurs voient et ce que votre code doit supposer.

Sur iOS, les flux d'édition et les invites de permission suivent les conventions d'Apple. L'accès limité aux Photos peut retourner un ensemble d'actifs plus étroit que votre compte de test a vu sur un appareil entièrement autorisé. Sur Android, le comportement du sélecteur varie plus en fonction de la version du système d'exploitation et de la peau du fabricant, surtout autour des albums, des noms de fichiers et de la façon dont les captures de la caméra sont retournées. Les applications Expo gérées ressentent ces différences plus directement parce que vous possédez plus de la mise en place native, mais les applications Expo gérées nécessitent encore code qui traite le sélecteur comme plateforme-formé plutôt que parfaitement uniforme.

La règle pratique est simple. Faites confiance aux champs que vous pouvez valider, et non à un UI ou à des métadonnées identiques entre appareils.

Quelques exemples comptent en applications réelles.

• Édition et recadrage : L’UI et le comportement de recadrage ne sont pas identiques entre iOS et Android
• Les métadonnées retournées : fileName, mimeTypeet fileSize peut être absent ou incohérent, il faut donc ajouter des fallbacks
• Permissions : La prise d'accès photo sur iOS peut être limitée aux éléments sélectionnés, tandis que le comportement d'Android dépend plus de la version du système et du support du sélecteur système
• Sortie de la caméra : Les images capturées peuvent avoir des caractéristiques de nommage, d'orientation ou de compression différentes par rapport aux ressources de la bibliothèque.

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

Différences entre les workflows gérés et non gérés

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

Dans le flux de travail géré, les chaînes de permission et la configuration du plugin se trouvent généralement dans la configuration de l'application, et les changements natifs sont appliqués lors de la création d'une nouvelle build. Cela maintient la surface de JavaScript propre, mais cela signifie également que la correction de la configuration n'est pas visible avant la prochaine build native. Les mises à jour OTA ne corrigent pas les permissions natives manquantes.

In le workflow sans abri, la même fonctionnalité a plus de parties en mouvement. Vous devez vérifier les descriptions d'utilisation natives iOS, le comportement de l'Android manifest, l'installation du package et la synchronisation de la mise à jour vous-même. L'avantage est le contrôle. Le coût est que les problèmes de sélection peuvent être causés par la configuration native, et non par le site d'appel JavaScript.

Les équipes qui passent entre Expo et Capacitor sous-estiment souvent la différence entre ces couches d'abstraction. Capgo a une explication utile de comment Capacitor gère les différences de plateforme C'est un bon point de comparaison si vous vous demandez combien de paramétrage natif votre équipe souhaite gérer.

My préférence est cohérente dans les deux workflows. Gardez le sélecteur code étroit, normalisez le résultat une fois, envoyez-l’à travers une couche dédiée API et traitez le comportement spécifique à la plateforme comme quelque chose à configurer et à tester explicitement plutôt que de le lisser avec des hypothèses.

Résoudre les problèmes courants

La plupart des bogues de l'Image Picker Expo se divisent en un petit ensemble de catégories. La solution la plus rapide est généralement d'identifier quel niveau est en panne : config, autorisation, gestion du résultat ou rendu.

Vérifications rapides pour les échecs courants

If the picker won’t open or permissions fail, check native setup first. In bare apps especially, missing iOS usage descriptions are a common root cause.

Si l'application s'effondre après que l'utilisateur ferme le sélecteur, inspectez votre gestion des résultats. Beaucoup d'implémentations supposent toujours une URI directe et ignorent le canceled contrôle.

Un petit nombre de mappages rapides vous aideront :

• Erreurs de permission refusée : Vérifiez votre configuration d'application et les chaînes de permission native, puis rebuild.
• undefined URI de l'image : Lire de result.assets?.[0]?.uri, pas result.uri.
• Rien ne se passe après l'annulation : Cela peut être correct. Traitez 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 poursuivre un bug de bibliothèque.

Un bref checklist de production

Utilisez cela comme dernier passage avant la livraison :

• Installez avec les outils Expo : Utilisez npx expo install expo-image-picker.
• Configurez les pièces natives : Ajoutez le plugin et les descriptions des permissions requises.
• Demandez les permissions intentionnellement : Flux séparés pour la caméra et les médias.
• Gardez chaque résultat : Vérifiez result.canceled et lire en toute sécurité assets[0].
• Préférez les téléchargements basés sur URI : Keep base64 for special cases only.
• Testez des appareils réels : Surtout pour la capture de caméra et les invitations de permission.

Si votre équipe livre des applications Capacitor ou Electron aux côtés de projets React Native, Capgo est une option pour livrer des mises à jour de JavaScript, CSS, de configuration et d'actifs sans attendre la revue de magasin pour chaque changement. Cela est pertinent lorsque les corrections d'image vivent dans votre couche web, comme la mise à jour de l'interface utilisateur, les règles de validation, le texte ou la gestion d'actifs autour du flux de sélection de l'image.