Expo Image Picker: guida completa 2026

Probabilmente sei arrivato al punto in cui la UI è pronta, la schermata del profilo ha un pulsante "Carica foto" e ora la parte facile improvvisamente non lo è più. Il flusso di selezione delle immagini tocca permessi nativi, interfacce gestite dal sistema operativo, strutture di ritorno diverse da quelle che molti sviluppatori si aspettano e una serie di dettagli di build che emergono solo dopo aver rilasciato una build reale.

È qui che entra in gioco Expo Image Picker. È la libreria ufficiale di Expo per aprire l'interfaccia di sistema per scegliere immagini e video dalla libreria del dispositivo o scattare una foto con la fotocamera, come descritto nel repository dei pacchetti Expo. In pratica, questo significa avere un bridge affidabile verso l'input multimediale nativo, ma non un'esperienza multimediale personalizzata che si comporti allo stesso modo su ogni dispositivo.

Questa guida è scritta per una prima implementazione, non per una demo. Si concentra sulle decisioni che contano in produzione: setup managed o bare workflow, gestione dei permessi che non ti sorprenderà più avanti, parsing sicuro dei risultati e un pattern di upload pratico dopo che l'utente ha scelto un file. Se lavori con un setup nativo custom, aiuta anche a capire come questo differisca dalle Confronto tra le opzioni di aggiornamento Expo EAS Capgo nella nostra guida comparativa.

Indice dei contenuti

• Primi passi con Expo Image Picker
• Installazione e configurazione essenziale
  • Configurazione del managed workflow
  • Dettagli del setup bare React Native
• Accesso alla fotocamera e alla libreria multimediale
  • Un componente minimale ma sicuro
  • Flussi di libreria e fotocamera
  • Cosa aspettarsi dalla UI di sistema
• Gestire i risultati e le opzioni del Picker
  • Leggere correttamente l'oggetto risultato
  • Opzioni che modificano il comportamento a valle
  • URI contro base64
  • Un pattern di risultato più sicuro per app reali
• Pattern avanzati e differenze tra piattaforme
  • Un pattern di upload pratico
  • Quando le differenze tra piattaforme contano davvero
  • Differenze tra workflow managed e bare
• Risoluzione dei problemi comuni
  • Controlli rapidi per gli errori comuni
  • Una breve checklist per la produzione

Primi passi con Expo Image Picker

Un product manager chiede le foto profilo. Una settimana dopo, la stessa feature deve gestire anche l'upload delle ricevute, lo scatto dalla fotocamera per i report sugli incidenti e i retry quando gli utenti negano il permesso la prima volta. L'input di immagini si espande in fretta perché tocca permessi nativi, UI gestite dall'OS, gestione dei file temporanei e flussi di upload lato backend.

expo-image-picker è il modulo Expo SDK per questo compito. Apre il picker di sistema o l'interfaccia della fotocamera e restituisce i media selezionati in un formato che il tuo code React Native può gestire. Il API JavaScript è piccolo. La sfida principale è azzeccare setup nativo, flusso dei permessi e gestione dei risultati sia nei progetti managed sia in quelli bare.

Il compromesso principale è semplice. Lasci che iOS e Android mostrino la propria UI per i media invece di costruire un picker custom. Di solito il risultato è migliore: gli utenti conoscono già le schermate di sistema, i prompt dei permessi si comportano come l'OS si aspetta e il tuo team evita di mantenere un'implementazione della galleria in JavaScript.

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

Questo approccio aiuta perché i problemi raramente stanno nel pulsante che richiama il picker. Di solito arrivano da uno di questi tre punti:

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

La scelta del workflow modifica anche il percorso di configurazione. In un'app Expo gestita, la maggior parte del lavoro nativo risiede nella configurazione dell'app e richiede un rebuild quando tale configurazione cambia. In un'app bare, ottieni comunque il modulo Expo API, ma devi verificare le impostazioni del progetto iOS e Android sottostanti in modo più diretto. Se il tuo team utilizza un client personalizzato invece di Expo Go, questa guida si abbina bene con Capgo alternativa a Expo EAS per i team che necessitano di testare moduli nativi oltre Expo Go.

Questa distinzione è importante per il resto della guida, perché il percorso felice è solo metà della storia. Un'implementazione del picker è solida quando funziona in entrambi i workflow, gestisce le peculiarità dei permessi specifiche della piattaforma senza sorprendere l'utente e passa un file utilizzabile al tuo layer di upload, invece di fermarsi a un'anteprima locale.

Installazione e configurazione essenziale

L'installazione richiede un solo comando. Configurare correttamente le impostazioni native è ciò che determina se il picker funziona su un dispositivo reale, in un client di sviluppo personalizzato e nella tua build di produzione.

expo-image-picker fornisce un API rivolto a React sopra i picker di piattaforma per foto, video e acquisizione dalla fotocamera. La chiamata JavaScript è semplice. La configurazione non lo è, perché l'accesso alle foto e alla fotocamera è controllato da iOS e Android, non da React Native.

Inizia con l'installer di Expo consapevole della versione:

npx expo install expo-image-picker

Usa expo install invece di npm install oppure yarn add. Expo allinea la versione del pacchetto al tuo SDK, evitando una classe comune di problemi di compatibilità nativa. Se stai confrontando come i moduli Expo si integrano nel tuo processo di rilascio, questo Panoramica degli strumenti Expo è un riferimento utile.

Configurazione del managed workflow

Nel managed workflow, dichiara il plugin nell'app config in modo che Expo possa applicare le modifiche native al momento del build.

Esempio con app.json:

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

Questa è la configurazione minima. In pratica, i team di solito aggiungono anche i testi dei permessi, soprattutto su iOS, dove il prompt di sistema deve spiegare perché l'app richiede l'accesso. Mantieni una formulazione specifica per l'azione dell'utente. “Carica una foto profilo” è meglio di “Richiede accesso ai media”.

Un dettaglio operativo fa perdere molto tempo. Cambiare plugins, le stringhe dei permessi o altre configurazioni native richiede un rebuild. Il reload del JavaScript non applica queste modifiche. In Expo Go, sei anche limitato da ciò che il client include già. In una development build o in una production build, il progetto nativo riflette la tua config solo dopo una nuova build.

Dettagli del setup bare React Native

In un'app bare, il pacchetto API è lo stesso, ma devi verificare personalmente più parti del progetto nativo. Le descrizioni d'uso su iOS sono la prima cosa da controllare. Se il tuo flusso può aprire la libreria, avviare la fotocamera o registrare video con audio, la tua app ha bisogno delle relative stringhe di permesso in Info.plist prima di fare il rebuild.

Ecco una checklist pratica per i progetti bare:

1. Installa expo-image-picker con npx expo install expo-image-picker.
2. Aggiungi la configurazione del plugin se il tuo progetto usa gli Expo config plugins.
3. Verifica che le descrizioni d'uso per iOS corrispondano alle funzionalità esposte.
4. Esegui il rebuild delle app iOS e Android dopo ogni modifica alla configurazione nativa.

Il testo dei permessi mancante spesso sembra un bug a runtime perché la UI code è corretta e l'handler del pulsante viene eseguito. Il problema è più in basso nello stack. Di solito controllo Info.plist, l'app config e se la build attuale include le ultime modifiche native prima di toccare il componente code.

Alcune buone abitudini rendono il setup più prevedibile:

• Scrivi il testo dei permessi per l'azione specifica: gli utenti devono capire perché vedono il prompt.
• Configura camera e libreria separatamente: una potrebbe funzionare mentre l'altra fallisce ancora.
• Rebuild dopo modifiche native: hot reload e fast refresh non aggiornano i permessi nativi.
• Testa su dispositivo: il comportamento del simulatore può nascondere problemi di permessi e fotocamera.

Se il picker funziona in sviluppo ma si rompe nella build di TestFlight o del Play Store, trattalo prima di tutto come un problema di configurazione. Nella maggior parte dei casi, lo è.

Accesso alla fotocamera e alla libreria multimediale

Un utente tocca “Carica foto”, si aspetta che si apra la fotocamera o la libreria, e la tua app ha un solo compito in quel momento. Aprire la UI di sistema corretta, gestire il rifiuto o l'annullamento senza rompere la schermata e restituire un riferimento al file locale utilizzabile per anteprima o upload.

Sembra semplice finché non testi sia le build managed che quelle bare su iOS e Android. Il JavaScript API resta compatto, ma il comportamento a runtime dipende ancora dai prompt del sistema operativo, dall'hardware del dispositivo e da come sono stati configurati i permessi nativi in precedenza.

Un componente minimale ma sicuro

Il flusso principale è coerente sia nei progetti Expo managed che in quelli bare workflow. Richiedi il permesso necessario, avvia il picker, verifica se l'utente ha annullato, quindi leggi il primo asset da result.assets.

Ecco come appare un componente di base:

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

Qui contano tre dettagli.

• Richiedi i permessi per libreria e fotocamera separatamente. Falliscono in modo indipendente.
• Tratta 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 uri.

Flussi di libreria e fotocamera

Inizia dal flusso della libreria se vuoi la via più rapida a una feature funzionante. È più facile da testare, funziona in più configurazioni di simulatori ed evita i casi limite dell'hardware della fotocamera. Aggiungi il supporto alla fotocamera una volta che il percorso di gestione dei risultati è stabile.

Il percorso della fotocamera ha più modi per fallire in sviluppo. Il supporto di iOS Simulator è limitato. Gli emulatori Android potrebbero non esporre un comportamento della fotocamera coerente con un dispositivo reale. Nei progetti bare, queste lacune possono portarti a guardare il componente code anche se il problema reale è la configurazione nativa o l'ambiente di test.

Un pattern UI pulito è chiedere all'utente la sorgente 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. Facilita anche l'aggiunta di analytics, feature flag o regole specifiche del backend in seguito. Ad esempio, alcuni team consentono upload dalla libreria per le immagini del profilo ma richiedono scatti freschi dalla fotocamera per la verifica dell'identità.

Se la tua app supporta anche pattern di accesso ai file al di fuori di Expo o stai confrontando le convenzioni tra stack nativi, questo riferimento alla libreria foto Capacitor è un contesto utile.

Una breve demo è utile quando mostri questo flusso ai colleghi o al team QA:

Cosa aspettarsi dalla UI di sistema

expo-image-picker apre il picker della piattaforma o la UI della fotocamera. La tua app non controlla ogni schermata di quel flusso. Questa distinzione è importante perché "funziona sul mio dispositivo" spesso significa "l'OS ha permesso il percorso che ho testato".

Su iOS, gli utenti potrebbero concedere un accesso limitato alla libreria invece di quello completo. Su Android, il comportamento del picker può variare in base alla versione dell'OS e alla skin del vendor. Nei progetti con managed workflow, Expo gestisce gran parte del wiring nativo per te. Nei progetti con bare workflow, devi confermare che la tua app compilata includa le modifiche ai permessi nativi che hai apportato. La chiamata JavaScript può essere identica in entrambi i casi, mentre il risultato a runtime differisce.

Di solito testo questi casi prima di considerare la feature completata:

• prima richiesta di permesso
• permesso negato
• annullamento da parte dell'utente
• selezione dalla libreria riuscita
• scatto riuscito dalla fotocamera su un dispositivo fisico
• anteprima immediata dell'URI locale restituito

Questi casi riflettono direttamente il comportamento in produzione. Inoltre preparano bene il passaggio successivo se devi inviare il file a un server, a una pipeline di moderazione o a un endpoint di pubblicazione come il la pubblicazione di media su Instagram API.

Gestire i risultati e le opzioni del Picker

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

Leggere correttamente l'oggetto risultato

La struttura del risultato rilevante nelle app Expo attuali è result.assets[0].uri, non un livello superiore result.uri. Questo dettaglio influisce sia sui progetti con workflow managed che bare, perché il JavaScript API è lo stesso, anche se la configurazione nativa sottostante differisce.

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 errore che incontro più spesso. Un picker annullato non ti fornisce un asset da leggere, e code che presuppone result.assets[0] esista sempre fallirà a runtime.

Una volta ottenuta la URI, il rendering di un'anteprima è semplice:

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

Se prevedi di fare upload in seguito, conserva l'intero asset oggetto, non solo la URI. Nella pratica, fileName, mimeType, width, height, e fileSize sono spesso utili per la convalida, il logging o la costruzione di una richiesta multipart più pulita.

Opzioni che cambiano il comportamento a valle

Alcune opzioni del picker influenzano più della sola schermata di selezione: determinano la dimensione dei file, il comportamento di editing e ciò che il backend deve accettare.

Alcuni compromessi sono facili da sottovalutare:

• allowsEditing è utile quando lo slot dell'immagine ha forma o dimensioni fisse. È meno utile se il server gestisce la sua pipeline di crop e vuoi il file originale.
• quality influisce sui tempi di upload, sulla pressione di memoria e sullo storage del server. quality: 1 non è automaticamente la scelta giusta.
• mediaTypes dovrebbe rispettare le 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 ricevente non lo richieda.

L'ultimo punto conta sui dispositivi con poca memoria. Un URI di file locale è di solito il passaggio migliore per anteprima e upload multipart. Base64 ha usi validi, ma è costoso rispetto al passaggio di un riferimento al file.

URI contro base64

For most apps, the rule is simple:

• Usa URI per le anteprime.
• Usa URI per l'upload dei file.
• Usa base64 solo quando il sistema ricevente richiede esplicitamente contenuto codificato.

Questo pattern mantiene il picker code piccolo e più semplice da testare. Si allinea anche a come sono costruiti molti flussi media backend, compresi i servizi che alla fine pubblicano su piattaforme esterne come la pubblicazione di media su Instagram API.

Se il tuo team rilascia frequenti aggiornamenti OTA o sposta asset con molte immagini tramite la distribuzione dell'app, le decisioni sulla dimensione dei file prese qui si ripercuotono sul resto della pipeline. Questa guida sull' optimising images for app updates è un utile complemento alla configurazione del picker.

Un pattern di risultato più sicuro per app reali

Per la demo code, salvare solo imageUri va bene. In produzione, salva un oggetto normalizzato in modo che i passaggi successivi (anteprima, validazione, upload o retry) non debbano reinterpretare la risposta grezza del picker ogni volta.

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

Questo ti garantisce una struttura prevedibile all'interno dell'app. Facilita inoltre l'allineamento tra progetti managed e bare, poiché l'app code rimane stabile mentre gestisci le differenze native altrove.

Un ultimo controllo non guasta. Non abilitare campi extra nel risultato solo per sicurezza. Richiedi i dati che sai di dover usare e mantieni il picker concentrato sulla selezione, invece di trasformarlo in un passaggio generico di elaborazione file.

Pattern avanzati e differenze tra piattaforme

Una feature di picker di solito smette di essere semplice nel momento in cui la prima immagine selezionata deve fare i conti con retry, header di auth, differenze nei permessi nativi e un vero endpoint di upload. expo-image-picker gestisce bene la selezione. Il resto della feature spetta alla tua app.

Un pattern di upload pratico

Per le API che prevedono l'upload di un file, FormData è ancora il default più sicuro. Funziona con i backend 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 basta a dimostrare che il percorso funziona, ma le app in produzione di solito richiedono un livello in più. Deriva name e type dall'asset selezionato quando possibile, allega l'autenticazione fuori dalla funzione del picker e mantieni lo stato di upload separato dallo stato del picker, in modo che una richiesta fallita non costringa l'utente a riaprire la libreria.

Alcuni controlli prevengono i fallimenti comuni che vedo in review:

• Conferma che il locale uri esiste prima di costruire la richiesta
• Mostra un'anteprima prima dell'upload in modo che gli utenti notino subito il file sbagliato
• Previene tap ripetuti mentre la richiesta è in corso
• Gestisci i fallimenti di rete separatamente da annullamento del picker o errori di autorizzazione
• Aspettati che la validazione del backend rifiuti file grandi, tipi MIME non supportati o autenticazione mancante

Se il tuo backend richiede base64 invece di multipart, di solito si tratta di un vincolo del server, non di un requisito del picker. Multipart è più leggero in memoria e più facile da gestire su mobile.

Quando le differenze tra piattaforme contano davvero

L'interfaccia del picker è nativa, quindi eredita il comportamento nativo. Questo influenza sia ciò che vedono gli utenti sia ciò che il tuo code dovrebbe presupporre.

Su iOS, i flussi di modifica e le richieste di autorizzazione seguono le convenzioni di Apple. L'accesso limitato alle foto può restituire un set di asset più ristretto rispetto a quello visto sul tuo account di test su un dispositivo con autorizzazioni complete. Su Android, il comportamento del picker varia di più in base alla versione del sistema operativo e alla skin del produttore, soprattutto per quanto riguarda album, nomi dei file e il modo in cui vengono restituite le riprese della fotocamera. Le app React Native bare sentono queste differenze in modo più diretto perché gestisci più della configurazione nativa, ma le app Expo gestite hanno comunque bisogno di code che tratti il picker come modellato dalla piattaforma anziché perfettamente uniforme.

La regola pratica è semplice. Affidati ai campi che puoi validare, non a un'interfaccia o a metadati identici su tutti i dispositivi.

Alcuni esempi sono importanti nelle app reali:

• Modifica e ritaglio: L'interfaccia e il comportamento del ritaglio non sono identici tra iOS e Android
• Metadati restituiti: fileName, mimeType, e fileSize possono essere assenti o incoerenti, quindi aggiungi fallback
• Permessi: 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 denominazioni, orientamenti o caratteristiche di compressione diversi rispetto alle risorse della libreria

Se il tuo team lavora anche al di fuori di Expo, questo Guida allo sviluppo di app DesignStack fornisce un contesto Android utile per le decisioni sulla gestione dei media che vanno oltre una singola libreria.

Differenze tra workflow managed e bare

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

Nel workflow gestito, le stringhe di autorizzazione e la configurazione dei plugin risiedono solitamente nella configurazione dell'app, e le modifiche native vengono applicate quando crei un nuovo build. Questo mantiene la superficie JavaScript pulita, ma significa anche che una correzione di configurazione non sarà visibile fino al prossimo build nativo. Gli aggiornamenti OTA non correggono le autorizzazioni native mancanti.

Nel workflow bare, la stessa funzionalità ha più parti mobili. Devi verificare tu stesso le descrizioni di utilizzo native iOS, il comportamento del manifest Android, l'installazione dei pacchetti e i tempi di rebuild. Il vantaggio è il controllo. Il costo è che un problema con il picker potrebbe essere causato dalla configurazione nativa, non dal punto di chiamata JavaScript.

I team che passano da Expo a Capacitor spesso sottovalutano quanto siano diverse questi livelli di astrazione. Capgo ha una spiegazione utile di come Capacitor gestisce le differenze tra piattaforme, ed è un buon punto di confronto se stai decidendo quanta configurazione nativa il tuo team vuole gestire.

La mia preferenza è la stessa in entrambi i workflow. Mantieni il picker code focalizzato, normalizza il risultato una sola volta, fai l'upload tramite un layer API dedicato e tratta il comportamento specifico della piattaforma come qualcosa da configurare e testare esplicitamente, invece di mascherarlo con assunzioni.

Risoluzione dei problemi comuni

La maggior parte dei bug di Expo Image Picker rientra in un piccolo insieme di categorie. La soluzione più rapida è di solito identificare quale layer sta fallendo: config, permessi, result handling o rendering.

Controlli rapidi per gli errori comuni

Se il picker non si apre o i permessi falliscono, controlla prima il setup nativo. Nelle bare app in particolare, le descrizioni di utilizzo iOS mancanti sono spesso la causa principale.

Se l'app crasha dopo che l'utente chiude il picker, controlla il tuo result handling. Molte implementazioni assumono ancora un URI diretto e saltano il canceled controllo.

Alcuni mapping rapidi aiutano:

• Errori di permesso negato: Verifica la config dell'app e le stringhe dei permessi nativi, poi rebuild.
• undefined URI dell'immagine: Leggi da result.assets?.[0]?.uri, non result.uri.
• Niente succede dopo l'annullamento: Potrebbe essere corretto. Gestisci l'annullamento come stato no-op.
• L'immagine non viene renderizzata: Conferma che l'URI sia stato salvato nello stato e passato a <Image source={{ uri }} />.
• Camera acts strangely in simulator: Testa su un dispositivo fisico prima di inseguire un bug della libreria.

Una breve checklist per la produzione

Usa questo come ultima verifica prima del rilascio:

• Installa con gli strumenti Expo: Usa npx expo install expo-image-picker.
• Configura le parti native: Aggiungi il plugin e le descrizioni dei permessi richiesti.
• Richiedi i permessi in modo intenzionale: Separa i flussi per fotocamera e libreria multimediale.
• Proteggi ogni risultato: Verifica result.canceled e leggi in sicurezza assets[0].
• Preferisci upload basati su URI: Usa base64 solo per casi particolari.
• Testa su dispositivi reali: Soprattutto per la cattura con fotocamera e i prompt di permesso.

Se il tuo team rilascia app Capacitor o Electron insieme a progetti React Native, Capgo è un'opzione per distribuire aggiornamenti di JavaScript, CSS, configurazione e asset senza attendere la revisione dello store per ogni modifica. È rilevante quando le correzioni relative alle immagini si trovano nel tuo layer web, come l'interfaccia di upload, le regole di validazione, i testi o la gestione degli asset attorno al flusso del picker.