Guida completa all'immagine picker Expo per il 2026

Probabilmente sei arrivato al punto in cui l'interfaccia utente è pronta, lo schermo del profilo ha un pulsante "Carica foto" e ora la parte facile non è più facile. Il flusso di selezione dell'immagine effettiva tocca le autorizzazioni native, gli interfacce controllate dall'OS, diverse forme di ritorno rispetto a quelle che molti sviluppatori si aspettano, e una manciata di dettagli di build-time che si manifestano solo dopo aver distribuito un build reale.

È lì che Expo Image Picker entra in gioco. È la libreria ufficiale di Expo per aprire l'interfaccia del sistema per scegliere immagini e video dal repository di dispositivi o scattare una foto con la fotocamera, come descritto nel Raccolta di pacchetti Expo. In pratica, significa che otterrai un ponte affidabile per l'input di media nativo, ma non un'esperienza di media personalizzata che si comporta identicamente su ogni dispositivo.

Questa guida è scritta per la prima implementazione, non per la demo. Si concentra sulle decisioni che contano in produzione: configurazione di setup di workflow gestito o nudo, gestione delle autorizzazioni che non ti sorprenderà in seguito, parsing dei risultati sicuri, e un modello di caricamento pratico dopo che l'utente ha selezionato un file. Se lavori in un setup nativo personalizzato, aiuta anche a capire come questo differisce da un Flusso di lavoro del client di sviluppo Expo.

Contenuto della Tabella

• Inizia con Expo Image Picker
• Avvio rapido con Expo Image Picker
  • Installazione e configurazione essenziale
  • Configurazione di setup di workflow gestito
• Accedere alla Camera e alla Libreria dei Media
  • A componente minimale ma sicuro
  • Flussi della libreria e della fotocamera
  • What to expect from the system UI
• Gestione dei risultati e delle opzioni del picker
  • Leggere correttamente l'oggetto di risultato
  • Opzioni che modificano il comportamento downstream
  • URI versus base64
  • Un modello di risultato più sicuro per le app reali
• Patterni avanzati e differenze tra piattaforme
  • Un modello di caricamento pratico
  • Dove le differenze tra piattaforme contano veramente
  • Differenze tra flussi gestiti e non gestiti
• Risolvere Problemi Comuni
  • Verifiche veloci per fallimenti comuni
  • Un breve elenco di controllo di produzione

Avvio rapido con Expo Image Picker

Un manager del prodotto chiede foto di profilo. Una settimana dopo, la stessa funzionalità richiede anche caricamenti di ricevute, cattura della fotocamera per rapporti di incidente e ripetizioni quando gli utenti negano la prima volta il permesso. L'input di immagini si espande rapidamente perché tocca le autorizzazioni native, l'interfaccia utente di sistema di proprietà, il trattamento dei file temporanei e le flussi di caricamento backend.

expo-image-picker è il modulo Expo SDK per quel lavoro. Apre il picker di piattaforma o l'interfaccia utente della fotocamera e restituisce i media selezionati in una forma che il tuo React Native code può gestire. Il JavaScript API è piccolo. Il principale ostacolo risiede nella configurazione nativa, nel flusso di autorizzazione e nel trattamento dei risultati, sia per i progetti gestiti che per quelli bare.

La principale scelta è chiara. Lasci che iOS e Android presentino le loro interfacce di media al posto di costruire un picker personalizzato. Di solito ciò dà un risultato migliore: gli utenti già comprendono le schermate del sistema, le richieste di autorizzazione si comportano nel modo in cui l'OS si aspetta e il tuo team evita di mantenere un'implementazione di galleria in JavaScript.

Considera questo come una funzionalità di integrazione nativa con un'interfaccia React.

Questa mentalità aiuta perché i modi di fallimento sono raramente nella bottone che chiama il picker. Di solito vengono da uno dei tre posti:

• Configurazione nativa: impostazione plugin mancante, stringhe di permessi errate, o un build obsoleto dopo aver modificato la configurazione
• Comportamento di esecuzione: gli utenti possono negare l'accesso, concedere un accesso limitato alla libreria su iOS o annullare il flusso senza selezionare nulla
• Analisi del risultato: il corrente API restituisce un assets array, quindi gli esempi più vecchi che leggevano result.uri direttamente falliscono

La scelta del flusso cambia anche il percorso di configurazione. In un'app Expo gestita, la maggior parte del lavoro nativo vive nella configurazione dell'app e richiede un rebuild quando quella configurazione cambia. In un'app bare, si ottiene ancora il modulo Expo API, ma è necessario verificare le impostazioni dei progetti iOS e Android sottostanti in modo più diretto. Se il suo team sta utilizzando un client personalizzato invece di Expo Go, questa guida si abbina bene con l'illustrazione di Capgo di come un client di sviluppo Expo modifica la verifica dei moduli nativi.

Quel divario è importante per il resto della guida perché il percorso felice è solo la metà della storia. Una implementazione di picker è solida quando funziona in entrambi i flussi, gestisce le stranezze di permesso specifiche della piattaforma senza sorprendere l'utente e passa un file utilizzabile al proprio layer di caricamento anziché fermarsi a una anteprima locale.

Installazione e Configurazione Essenziale

L'installazione richiede un solo comando. Ottenere la configurazione nativa giusta è ciò che determina se il picker funziona su un dispositivo reale, in un client di sviluppo personalizzato e nella propria build di produzione.

expo-image-picker fornisce un API faccia a reattori sulle picker delle piattaforme per le foto, i video e la cattura della fotocamera. La chiamata JavaScript è semplice. La configurazione non lo è, perché l'accesso alle foto e la cattura della fotocamera sono controllati da iOS e Android, non da React Native.

Inizia con l'installatore di Expo versione-aware:

npx expo install expo-image-picker

Usa expo install al posto di npm install o 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 Panoramica degli strumenti Expo Panoramica degli strumenti di Expo

Configurazione del flusso di lavoro gestito

In the managed workflow, declare the plugin in app config so Expo can apply the native changes at build time.

Esempio con app.json:

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

Questo è il minimo impostato. In pratica, gli squadre aggiungono di solito il testo di autorizzazione, soprattutto su iOS, dove la richiesta di sistema dovrebbe spiegare perché l'app necessita di accesso. Mantieni il testo specifico per l'azione dell'utente. 'Carica una foto di profilo' è meglio di 'Necessita di accesso ai media.'

Un dettaglio operativo causa molto tempo perso. Cambiare pluginsle stringhe di permesso o altre configurazioni native richiede una ricompilazione. Caricando nuovamente JavaScript non si applicano quelle modifiche. In Expo Go, sei anche limitato da ciò che il client include già. In un build di sviluppo o di produzione, il progetto nativo riflette la tua configurazione solo dopo una nuova compilazione.

Dettagli di configurazione di base per React Native

In un'app di base, il pacchetto API è lo stesso, ma devi verificare di più il progetto nativo da solo. Le descrizioni di utilizzo di iOS sono la prima cosa da controllare. Se il tuo flusso può aprire la libreria, avviare la fotocamera o registrare un video con audio, il tuo app ha bisogno delle stringhe di permesso corrispondenti in Info.plist prima di ricompilare.

Un elenco pratico per progetti nudi assomiglia a questo:

1. Installa expo-image-picker con npx expo install expo-image-picker.
2. Add the plugin config if your project uses Expo config plugins.
3. Conferma che le descrizioni di utilizzo di iOS corrispondono alle funzionalità che esponi.
4. Ricompila le app di iOS e Android dopo qualsiasi modifica della configurazione nativa.

Testo di permesso mancante spesso sembra un bug di esecuzione a causa della UI code che è fine e il gestore del pulsante esegue. La falla è più in basso nella pila. Di solito controlla Info.plistPrima di toccare il componente code, assicurati che l'app config sia aggiornata e che la build corrente includa le ultime modifiche native.

Alcune abitudini rendono la configurazione più prevedibile:

• Scrivi il testo di autorizzazione per l'azione effettiva: Gli utenti dovrebbero capire perché vedono la richiesta.
• Configura la camera e la libreria separatamente: Una può funzionare mentre l'altra ancora fallisce.
• Riavvia dopo le modifiche native: La ricarica calda e la ricarica veloce non aggiornano le autorizzazioni native.
• Testa sul dispositivo: simulator behavior can hide permission and camera issues.

Se il picker funziona durante lo sviluppo ma si rompe in TestFlight o nella build del Play Store, consideralo un problema di configurazione. La maggior parte delle volte, lo è.

Accedere alla Camera e alla Libreria dei Media

A un utente tocca “Carica foto,” si aspetta che la fotocamera o la libreria si aprano, e il tuo app ha un solo compito in quel momento. Apri la GUI di sistema giusta, gestisci il rifiuto o la cancellazione senza rompere lo schermo, e restituisci un riferimento di file locale utilizzabile per la visualizzazione o l'upload.

Suona semplice fino a quando non si testano sia le build gestite che quelle bare su iOS e Android. Il JavaScript API rimane compatto, ma il comportamento di runtime dipende ancora dalle richieste di sistema, dal hardware del dispositivo e da come sono state configurate le autorizzazioni native precedentemente.

Un componente minimo ma sicuro.

La core flow è coerente in entrambi i progetti di workflow Expo gestiti e bare. Richiedi la relativa autorizzazione, avvia il picker, controlla se l'utente ha annullato, poi leggi il primo asset da result.assets.

Un componente di base assomiglia a questo:

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

Tre dettagli sono importanti qui.

• Richiedi le autorizzazioni per la libreria e la fotocamera separatamente. Falliscono independentemente.
• Gestisci l'annullamento come un'azione normale dell'utente, non come uno stato di errore.
• Leggi da assets[0]perché il picker restituisce un array di asset anziché un elemento di livello superiore. uri.

Flussi di libreria e fotocamera

Se vuoi il percorso più veloce per una funzione funzionante, inizia con il flusso della libreria. È più facile da testare, funziona in più impostazioni di simulatore e evita i casi d'edge della hardware della fotocamera. Aggiungi il supporto della fotocamera una volta che il percorso di gestione dei risultati è stabile.

Il percorso della fotocamera ha più modi per fallire durante lo sviluppo. Il supporto del simulatore iOS è limitato. Gli emulatori Android potrebbero non esporre il comportamento della fotocamera che corrisponde a un dispositivo reale. In progetti bare, quei vuoti possono farvi guardare il componente code anche se il problema reale è la configurazione nativa o l'ambiente di test.

Un modello di interfaccia utente pulito è chiedere all'utente la fonte prima di chiamare il picker API:

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

Questa separazione mantiene ogni funzione focalizzata. Inoltre, rende più facile aggiungere analisi, flag di funzionalità o regole specifiche del backend in un secondo momento. Ad esempio, alcune squadre consentono l'upload di librerie per le immagini di profilo, ma richiedono catture di fotocamera fresche per la verifica dell'identità.

Se il tuo'app più ampia supporta modelli di accesso ai file al di fuori di Expo o stai confrontando convenzioni tra stack nativi, questo Capacitor riferimento alla libreria di foto è utile contesto.

Un breve demo aiuta quando mostri questo flusso ai tuoi colleghi o QA:

What to expect from the system UI

expo-image-picker Apre il picker o l'interfaccia utente della fotocamera. Il tuo'app non controlla ogni schermo in quel flusso. Quella distinzione conta perché 'funziona sul mio dispositivo' spesso significa 'l'OS ha consentito il percorso che ho testato'.

On iOS, gli utenti possono concedere accesso alla libreria limitato anziché l'accesso completo. Su Android, il comportamento del picker può variare in base alla versione del sistema operativo e alla pelle del fornitore. Nei progetti di workflow gestiti, Expo gestisce più della cablaggio nativo per te. Nei progetti di workflow bare, devi confermare che la tua app costruita include le modifiche alle autorizzazioni native che hai fatto. Il sito di chiamata JavaScript può essere identico in entrambi i casi, mentre l'esito di esecuzione differisce.

Di solito, testo questi casi prima di considerare la funzionalità completa.

• prima richiesta di autorizzazione
• autorizzazione negata
• cancellazione dell'utente
• selezione della libreria riuscita
• captura della camera riuscita su un dispositivo fisico
• anteprima immediata della URI locale restituita

Quei casi si mappano direttamente al comportamento di produzione reale. Inoltre, configurano il passo successivo pulitamente se hai bisogno di inviare il file a un server, una pipeline di moderazione o un endpoint di pubblicazione come il pubblicazione dei media di Instagram API.

Gestione dei Risultati e delle Opzioni del Picker

Il risultato del picker è la parte che di solito richiede logica di produzione reale. L'interfaccia utente del sistema restituisce un oggetto strutturato, non solo un percorso del file, e piccoli errori qui portano a anteprime rotte, upload vuoti o crash dopo che l'utente annulla.

Leggere correttamente l'oggetto di risultato

La forma dell'oggetto di risultato che conta nelle attuali applicazioni Expo è result.assets[0].uri, non un livello superiore result.uri. Dettaglio che influenza sia i progetti di workflow gestiti che quelli bare, perché il JavaScript API è lo stesso anche se la configurazione nativa differisce sotto

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

Questo gestisce i due casi di fallimento che vedo più spesso. Un picker annullato non ti da un asset da leggere, e code che assume result.assets[0] esista sempre fallirà all'esecuzione.

Una volta che hai l'URI, rendere una preview è facile:

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

Se hai l'intenzione di caricare in seguito, conserva l'intero asset oggetto, non solo l'URI. In pratica fileName, mimeType, width, height, e fileSize sono spesso utili per la validazione, il logging o la creazione di una richiesta multipart più pulita.

Opzioni che modificano il comportamento downstream

Alcune opzioni del picker influenzano più della schermata di selezione. Modellano la dimensione del file, il comportamento di editing e cosa il tuo backend deve accettare.

Qualcuni compromessi possono sfuggire facilmente.

• allowsEditing è utile quando lo slot dell'immagine ha una forma o dimensione fisse. È meno utile se il tuo server gestisce il proprio pipeline di taglio e desideri il file originale.
• quality influenza il tempo di upload, la pressione di memoria e lo storage del server. quality: 1 non è automaticamente la scelta giusta.
• mediaTypes deve corrispondere alle regole del backend. Se il server rifiuta i video, non lasciare che il picker li restituisca.
• base64 aumenta la dimensione del payload in memoria. Evitalo a meno che il servizio di ricezione non lo richieda.

Quel punto è importante per i dispositivi con memoria inferiore. Un URI di file locale è di solito il miglior handoff per la preview e l'upload multipart. Base64 ha usi validi, ma è costoso rispetto a passare una referenza di file.

URI contro base64

For most apps, the rule is simple:

• Usa URI per le anteprime.
• Usa URI per gli upload di file.
• Usa base64 solo quando il sistema di destinazione chiede esplicitamente contenuto codificato.

Quel modello mantiene il picker code piccolo e più facile da testare. Inoltre, si allinea con la maggior parte delle flussi di media backend, compresi i servizi che pubblicano eventualmente su piattaforme esterne come Instagram media publishing API.

Se il tuo team invia aggiornamenti OTA frequenti o sposta asset immagine pesanti attraverso la consegna dell'applicazione, le decisioni di dimensione del file qui hanno ripercussioni sull'intero pipeline. Questa guida su optimising images for app updates è un utile compagno di configurazione del picker.

Un modello di risultato più sicuro per le app reali

Per i demo code, memorizzare solo imageUri è sufficiente. In produzione, memorizza un oggetto normalizzato in modo che il passaggio successivo, la visualizzazione, la validazione, l'invio o il ripristino, non debba reinterpretare ogni volta la risposta del picker originale.

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

Ciò ti dà una forma predittiva all'interno dell'app. Inoltre, rende i progetti gestiti e bare più facili da tenere allineati perché l'app code rimane stabile mentre lavori attraverso le differenze native altrove.

Un controllo finale aiuta. Non abilitare campi di risultato aggiuntivi solo per precauzione. Richiedi i dati di cui hai bisogno e mantieni il picker concentrato sulla selezione piuttosto che trasformarlo in un passo di elaborazione generale dei file.

Patterni avanzati e differenze di piattaforma

Un feature del picker di solito smette di essere semplice non appena l'immagine selezionata deve sopravvivere alle ripetizioni, ai capi di autenticazione, alle differenze di autorizzazione native e a un endpoint di invio reale. expo-image-picker gestisce la selezione bene. Il resto della funzione è a carico dell'applicazione.

Un modello di caricamento pratico

Per API che attendono un caricamento di file, FormData è ancora il default più sicuro. Funziona su back-end comuni come Rails, Node, Laravel, Django e Go, e mantiene il picker separato dalle preoccupazioni di trasporto.

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

Quel code è sufficiente per dimostrare che il percorso funziona, ma le app di produzione solitamente richiedono un'altra layer. Deriva name e type dall'elemento selezionato quando possibile, attacca l'autenticazione all'esterno della funzione del picker e mantiene lo stato di caricamento separato dallo stato del picker, in modo che una richiesta fallita non costringa l'utente a riaprire la libreria.

Un paio di controlli prevenono le comuni fallite che vedo in revisione:

• Conferma l'esistenza locale uri prima di costruire la richiesta
• Render a preview before upload so users catch the wrong file early
• Prevenire i tocchi ripetuti mentre la richiesta è in corso
• Gestisci le connessioni fallite separatamente dalle cancellazioni del picker o dagli errori di autorizzazione
• Aspettarsi la validazione del backend rifiuti file troppo grandi, tipi MIME non supportati o autenticazione mancante

Se il tuo backend richiede base64 invece di multipart, è di solito una restrizione del server, non una richiesta del picker. Multipart è più economico in termini di memoria e più facile da ragionare su dispositivi mobili

Dove le differenze tra piattaforme contano veramente

Il UI del picker è nativo, quindi eredita il comportamento nativo. Ciò influenza sia cosa gli utenti vedono sia cosa il tuo code dovrebbe assumere.

Sui dispositivi iOS, le flussi di modifica e le richieste di autorizzazione seguono le convenzioni di Apple. L'accesso limitato alle foto può restituire un set più ristretto di asset rispetto a quanto visto nel tuo account di test su un dispositivo completamente autorizzato. Sui dispositivi Android, il comportamento del picker varia più a seconda della versione del sistema operativo e della pelle del produttore, soprattutto intorno agli album, ai nomi dei file e a come sono restituiti i captures della fotocamera. Le app React Native a gestione nuda sentono queste differenze più direttamente perché si possiede più della configurazione nativa, ma le app Expo a gestione gestita ancora devono code che trattano il picker come piattaforma-orientato piuttosto che perfettamente uniforme

La regola pratica è semplice. Dipendi dai campi che puoi validare, non sulla UI identica o sulla metadata identica tra dispositivi

Esempi reali che contano:

• Modifica e taglio: L'interfaccia e il comportamento di taglio non sono identici tra iOS e Android
• Metadata restituite: fileName, mimeTypee fileSize possono essere assenti o inconsistenti, quindi aggiungi fallback
• Autorizzazioni: iOS photo access can be limited to selected items, while Android behavior depends more on OS version and system picker support
• Output della fotocamera: le immagini catturate possono tornare con caratteristiche di denominazione, orientamento o compressione diverse rispetto agli asset della libreria

Se il tuo team lavora anche fuori da Expo, questo Guida di sviluppo di DesignStack fornisce contesto Android utile per le decisioni di gestione dei media che si verificano al di là di una singola libreria.

Differenze tra flussi di lavoro gestiti e bare

In questo punto, le scelte di configurazione iniziano a contare operativamente.

Nel flusso di lavoro gestito, le stringhe di autorizzazione e la configurazione del plugin solitamente vivono nella configurazione dell'app, e le modifiche native vengono applicate quando si crea una nuova build. Ciò mantiene la superficie di JavaScript pulita, ma significa che una correzione di configurazione non è visibile fino alla prossima build nativa. Le aggiornamenti OTA non riparano le autorizzazioni native mancanti.

In questo workflow base, la stessa funzione ha più parti in movimento. È necessario verificare le descrizioni di utilizzo native di iOS, il comportamento del manifesto Android, l'installazione del pacchetto e il timing della ricostruzione da soli. L'aspetto positivo è il controllo. Il costo è che un problema di selezione può essere causato da una configurazione nativa, non dal sito di chiamata JavaScript.

Le squadre che passano da Expo a Capacitor spesso sottostimano quanto siano diversi questi layer di astrazione. Capgo ha una spiegazione utile di come Capacitor gestisce le differenze tra piattaformee rappresenta un buon punto di confronto se si sta decidendo quanto setup nativo il proprio team vuole gestire.

La mia preferenza è coerente in entrambi i workflow. Mantenere il picker code ristretto, normalizzare il risultato una volta, caricarlo attraverso un layer dedicato API e considerare il comportamento specifico della piattaforma come qualcosa da configurare e testare esplicitamente, piuttosto che livellare con ipotesi.

Risolvere Problemi Comuni

La maggior parte dei bug di Expo Image Picker rientra in una piccola serie di categorie. La soluzione più veloce è spesso identificare quale layer sta fallendo: config, autorizzazione, gestione del risultato o rendering.

Controlli veloci per fallimenti comuni

Se il picker non si apre o le autorizzazioni falliscono, controlla la configurazione nativa per primo. In particolare, le descrizioni di utilizzo mancanti di iOS sono una causa comune di base.

Se l'app si blocca dopo che l'utente chiude il picker, controlla il tuo trattamento dei risultati. Molti implementazioni ancora presuppongono una URI diretta e saltano il canceled controllo.

Un paio di mappature veloci aiutano:

• Errori di permesso negato: Verifica la tua configurazione dell'app e le stringhe di permesso native, quindi ricostruisci.
• undefined URI dell'immagine: Leggi da result.assets?.[0]?.uri, non result.uri.
• Niente accade dopo l'annullamento: Potrebbe essere corretto. Tratta l'annullamento come uno stato no-op.
• L'immagine non si visualizza: Conferma che l'URI è stato memorizzato nello stato e passato in <Image source={{ uri }} />.
• La camera funziona in modo strano nel simulatore: Testa sul dispositivo fisico prima di inseguitare un bug di libreria.

Un breve elenco di controllo di produzione

Usa questo come passaggio finale prima di distribuire:

• Installa con Expo tooling: Usa npx expo install expo-image-picker.
• Configura pezzi nativi: Aggiungi il plugin e le descrizioni delle autorizzazioni richieste.
• Richiedi le autorizzazioni in modo intenzionale: Flussi di camera e biblioteca dei media separati.
• Guarda ogni risultato: Controlla result.canceled e leggere in modo sicuro assets[0].
• Preferire l'upload basato su URI: Tenere base64 solo per casi speciali.
• Testare dispositivi reali: Soprattutto per la cattura della fotocamera e le richieste di autorizzazione.

Se il tuo team distribuisce Capacitor o applicazioni Electron insieme ai progetti React Native Capgo è una delle opzioni per consegnare aggiornamenti di JavaScript, CSS, configurazione e risorse senza dover attendere la revisione del store per ogni modifica. È rilevante quando le correzioni relative alle immagini vivono nel layer web, come ad esempio l'interfaccia utente di upload, le regole di validazione, il testo o la gestione delle risorse intorno al flusso del picker.