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 l'OS, 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 à partir de la 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 dans 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, pas la démo. Il se concentre sur les décisions qui comptent en production : mise en œuvre gérée versus mise en œuvre bare, gestion des permissions qui ne vous surprendront pas plus tard, analyse de résultats sûre, et un modèle d'upload 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
  • A 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 correcte
  • Options qui modifient 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'envoi pratique
  • Là où les différences de plateforme comptent vraiment
  • Différences entre les workflows gérés et non gérés
• Résolution des problèmes courants
  • Vérifications rapides pour les échecs courants
  • Un bref checklist de production

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

Un responsable produit demande des photos de profil. Une semaine plus tard, la même fonctionnalité nécessite également l'envoi de reçus, la capture de la caméra pour les rapports d'incident, et des retentatives lorsque les utilisateurs refusent la permission la première fois. L'entrée d'image s'élargit rapidement car elle touche les permissions natives, l'interface utilisateur propriétaire du système, la gestion de fichiers temporaires et les flux d'envoi vers le serveur.

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 application React Native code peut gérer. Le code 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 compromis principal 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 invites 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é est utile car les modes d'erreur 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 du workflow 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 une reconstruction 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 se complète 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 de la 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 workflows, gère les particularités de permission des plateformes sans surprendre l'utilisateur et transmet un fichier utilisable à votre couche d'envoi au lieu d'arrêter à une prévisualisation locale.

Installation et Configuration essentielle

Une installation prend 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 la capture de 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 add. Expo matches the package version to your SDK, which avoids a common class of native compatibility problems. If you are comparing how Expo modules fit into your release process, this Vue d'ensemble des outils Expo est une référence utile.

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"]
  }
}

La mise en place d'un flux de travail géré est la méthode recommandée pour les applications Expo. Elle permet d'appliquer les modifications natives lors de la phase de construction, ce qui évite les problèmes de compatibilité natives courants. Si vous comparez comment les modules d'Expo s'intègrent dans votre processus de publication, cette page est une référence utile.

Un détail opérationnel entraîne 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 modifications. 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 bare, 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 bare ressemble à ceci :

1. Installez 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. Reconstruirez 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.

Quelques habitudes rendent la configuration plus prévisible :

• Écrire le texte de permission pour l'action réelle : Les utilisateurs doivent comprendre pourquoi ils voient la prompt.
• Configurer la caméra et la bibliothèque séparément : On peut travailler tout en laissant l'autre échouer.
• Refaire la build après les changements natives : hot reload and fast refresh do not update native permissions.
• Tester 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 mise à jour de Google 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 « 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 cours encore dépend des invites de l'OS, de l'équipement matériel du appareil 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], car 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 facilite également l'ajout d'analytiques, de drapeaux de fonctionnalité ou de 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 que vous comparez des conventions entre les piles natives, ce Capacitor référence de la bibliothèque photo est utile dans le contexte.

Un court démo est utile lorsque vous montrez ce flux à vos 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 de exécution diffère.

Je teste généralement ces cas avant d'appeler la fonctionnalité terminée :

• première demande de permission
• permission refusée
• annulation de l'utilisateur
• selección 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 tel que le 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.

Interpréter correctement l'objet de résultat

La forme de résultat qui compte dans les applications Expo actuelles est result.assets[0].uri, pas un élément de 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 en premier :

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'élément à 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 tout. asset environ 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. Ils 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 effectue 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 Doit 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 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 Cela vous donne une forme prévisible à l'intérieur de l'application. Cela rend également les projets gérés et bare plus faciles à maintenir alignés car l'application __CAPGO_KEEP_0__ reste stable tout en travaillant sur les différences natives ailleurs.

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

A picker feature usually stops being simple the moment the first selected image has to survive retries, auth headers, native permission differences, and a real upload endpoint. expo-image-picker gestionne bien la sélection. Le reste de la fonctionnalité est à votre application.

Un modèle de téléchargement pratique.

For APIs that expect a file upload, FormData 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 maintient 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 contexte : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément de l'interface utilisateur court. Voir : page trust.astro. Clé de message `et` (Et).

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

• Confirmer la localisation uri Confirmez que le fichier local
• 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 de plateforme 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.

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. Faites confiance aux champs que vous pouvez valider, pas à 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, ajoutez donc des valeurs par défaut
• Permissions : iOS photo access can be limited to selected items, while Android behavior depends more on OS version and system picker support
• Sortie de la caméra : Les images capturées peuvent revenir avec des caractéristiques de nommage, d'orientation ou de compression différentes de celles des assets 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.

Differences entre les workflows gérés et bare

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

Dans le workflow géré, les chaînes de permission et la configuration du plugin vivent 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 garde 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 manquantes natives.

In le workflow basique, la même fonctionnalité comporte plus de composants en mouvement. Vous devez vérifier les descriptions d'utilisation natives iOS, le comportement de la manifest Android, l'installation du package et la synchronisation de la rebuild 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 surestiment souvent la différence entre ces couches d'abstraction. Capgo a une explication utile de comment Capacitor gère les différences de plateforme et c'est un point de comparaison pertinent si vous décidez combien de configuration native votre équipe souhaite gérer.

Ma 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 classent dans 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.

If l'application se bloque 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 check.

Un peu de mappages rapides vous aideront :

• Les erreurs de permission refusées : Vérifiez votre configuration d'application et les chaînes de permission natives, puis rebuild.
• undefined URI de l'image : Lire de result.assets?.[0]?.uri, pas result.uri.
• Rien ne se passe après annuler : 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 d'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 de prise de vue et de bibliothèque multimédia séparés.
• 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 la 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 la configuration et des actifs sans attendre la revue de magasin pour chaque changement. Cela est pertinent lorsque des corrections d'image vivent dans votre couche web, comme l'interface utilisateur de téléchargement, les règles de validation, le texte ou la gestion d'actifs autour du flux de sélection de l'image.