Guida completa all'immagine picker di Expo per il 2026

Probabilmente sei arrivato al punto in cui l'interfaccia utente è pronta, la schermata del profilo ha un pulsante "Carica foto" e ora la parte facile improvvisamente non è più facile. Il flusso di selezione dell'immagine 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 spedito un build reale.

È lì che entra in gioco Expo Image Picker. È la libreria ufficiale di Expo per aprire l'interfaccia di sistema per scegliere immagini e video dal repository del dispositivo o scattare una foto con la fotocamera, come descritto nel repository dei pacchetti Expo. In pratica, significa che otterrai un ponte affidabile verso 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: impostazione di setup di workflow gestito o bare, gestione delle autorizzazioni che non ti sorprenderanno in seguito, parsing dei risultati sicuri, e un modello di upload pratico dopo che l'utente ha selezionato un file. Se lavori in un setup nativo personalizzato, aiuta anche a capire come questo si differenzia da un workflow del client di sviluppo Expo.

Tavola dei contenuti

• Avvio con Expo Image Picker
• Installazione e configurazione essenziale
  • Impostazione del workflow gestito
  • Dettagli di configurazione React Native senza gestione
• Accesso alla camera e alla libreria dei media
  • Un componente minimo ma sicuro
  • Flussi della libreria e della camera
  • Cosa aspettarsi dall'interfaccia utente del sistema
• Gestione dei risultati e delle opzioni del picker
  • Lettura dell'oggetto di risultato correttamente
  • Opzioni che modificano il comportamento downstream
  • URI contro base64
  • Un modello di risultato più sicuro per le real app
• Pattern avanzati e differenze di piattaforma
  • Un modello di caricamento pratico
  • Dove le differenze di piattaforma contano davvero
  • Differenze tra flussi di lavoro gestiti e non gestiti
• Risolvere i problemi comuni
  • Verifiche veloci per fallimenti comuni
  • Un breve checklist di produzione

Iniziare con Expo Image Picker

Un manager di prodotto chiede foto di profilo. Una settimana dopo, la stessa funzionalità ha bisogno anche di caricamenti di ricevute, cattura di foto 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 i 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 nella gestione dei risultati giusta su entrambi i progetti gestiti e non gestiti.

Il principale trade-off è chiaro. Lasciare che iOS e Android presentino le loro interfacce di media al posto di costruire un picker personalizzato. Di solito dà un risultato migliore: gli utenti già capiscono 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.

Integra questo come una funzione nativa con un'interfaccia React.

Quel modo di pensare aiuta perché i modi di fallimento sono raramente nel pulsante che chiama il picker. Di solito vengono da uno dei tre posti:

• Configurazione nativa: impostazione plugin mancante, stringhe di permessi errate, o una build obsoleta dopo aver cambiato la configurazione
• Comportamento di esecuzione: gli utenti possono negare l'accesso, concedere accesso limitato alla libreria su iOS, o annullare il flusso senza selezionare nulla
• Analisi dei risultati: 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 una ricompilazione 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 tuo 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 cambia la verifica dei moduli nativi.

Quella scelta è importante per il resto della guida perché il percorso felice è solo la metà della storia. L'implementazione di un picker è solida quando funziona in entrambi i flussi di lavoro, gestisce le stranezze di autorizzazione specifiche della piattaforma senza sorprendere l'utente e passa un file utilizzabile alla tua layer di caricamento anziché fermarsi a una anteprima locale.

Installazione e configurazione essenziale

L'installazione richiede un solo comando. Il fatto di avere la configurazione nativa giusta è 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 React-facing API sui picker delle piattaforme per foto, video e 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 versione-aware di Expo:

npx expo install expo-image-picker

Usa expo install invece di npm install o yarn add. Expo sincronizza la versione del pacchetto con il tuo SDK, il che evita un comune tipo di problemi di compatibilità nativi. Se stai paragonando come i moduli di Expo si integrano nel tuo processo di rilascio, questo Panoramica degli strumenti di Expo è una utile risorsa di riferimento.

Flusso di lavoro gestito

In fase di flusso di lavoro gestito, dichiara il plugin nella configurazione dell'applicazione in modo che Expo possa applicare i cambiamenti nativi al momento della compilazione.

Esempio con app.json:

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

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

Un dettaglio operativo causa molto tempo perso. Cambiare pluginsstringhe di autorizzazione, o altre configurazioni native richiede una ricompilazione. Il caricamento di JavaScript non applica quei cambiamenti. In Expo Go, sei anche limitato da ciò che il client include già. In una build di sviluppo o in una build di produzione, il progetto nativo riflette la tua configurazione solo dopo una nuova build.

Dettagli di configurazione di React Native senza pacchetti

In un'app senza pacchetti, il pacchetto API è lo stesso, ma devi verificare più del 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, la tua app necessita delle stringhe di autorizzazione corrispondenti in Info.plist prima di ricompilare.

Un elenco di controllo pratico per i progetti senza pacchetti assomiglia a questo:

1. Installa expo-image-picker con npx expo install expo-image-picker.
2. Aggiungi la configurazione del plugin se il tuo progetto utilizza plugin di configurazione Expo.
3. Conferma che le descrizioni di utilizzo per iOS corrispondono alle funzionalità che esponi.
4. Riavvia gli app di iOS e Android dopo qualsiasi cambiamento nella configurazione nativa.

Il testo delle autorizzazioni mancanti spesso sembra un bug di esecuzione perché l'interfaccia utente code è corretta e il gestore del pulsante viene eseguito. L'errore si trova più in basso nella pila. Di solito controlli Info.plist, la configurazione dell'app e se l'ultima build include le modifiche native più recenti prima di toccare il componente code.

Alcune abitudini rendono la configurazione più prevedibile:

• Scrivi il testo delle autorizzazioni per l'azione effettiva: gli utenti dovrebbero capire perché vedono la richiesta.
• Configura la telecamera e la libreria separatamente: può funzionare mentre l'altra ancora fallisce.
• Riavvia dopo le modifiche native: rilascio caldo e rinfresco veloce non aggiornano le autorizzazioni native.
• Testa sul dispositivo: Il comportamento del simulatore può nascondere problemi di autorizzazione e fotocamera.

Se il picker funziona durante lo sviluppo ma si rompe nella versione di TestFlight o del Play Store, considera questo come un problema di configurazione in primo luogo. La maggior parte delle volte, è così.

Accesso alla Fotocamera e alla Libreria dei Media

Un utente clicca su “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 la rifiutazione o la cancellazione senza rompere lo schermo, e restituisci un riferimento di file locale utilizzabile per la visualizzazione o l'invio.

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

Un componente minimo ma sicuro

Il flusso di base è coerente in entrambi i progetti di workflow Expo gestiti e a nudo. Richiedi la autorizzazione pertinente, 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 della libreria e della fotocamera separatamente. Falliscono independentemente.
• Tratta la cancellazione come un'azione normale dell'utente, non uno stato di errore.
• Leggi da assets[0], perché il picker restituisce un array di asset anziché un livello superiore uri.

Flussi della libreria e della fotocamera

Inizia con il flusso della libreria se desideri la via più veloce per una funzionalità funzionante. È più facile da testare, funziona in più impostazioni di simulatore e evita i casi di bordo del hardware della fotocamera. Aggiungi il supporto della fotocamera una volta stabilito il percorso di gestione dei risultati.

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

Un pattern 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' },
  ]);
};

Quella 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 del profilo ma richiedono catture della 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 delle foto è utile contesto.

Un breve demo è utile quando stai mostrando questo flusso ai tuoi colleghi o QA:

Cosa aspettarsi dall'interfaccia utente del sistema

expo-image-picker apre il picker della piattaforma o l'interfaccia dell'obiettivo. La tua app non controlla ogni schermo in quel flusso. Quella distinzione è importante perché 'funziona sul mio dispositivo' spesso significa 'il sistema operativo ha consentito il percorso che ho testato.'

Su iOS, gli utenti possono concedere accesso alla libreria limitato al posto di 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 gestito, 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 in esecuzione differisce.

Di solito testo questi casi prima di chiamare la funzione completa:

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

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.

Manipolazione 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 di 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 del risultato che interessa negli attuali app Expo è result.assets[0].uri, non un livello superiore result.uriDettaglio che influenza sia i progetti di workflow gestiti che quelli bare perché lo JavaScript API è lo stesso anche se la configurazione nativa differisce sotto.

Usare 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 dà un asset da leggere, e code che assume result.assets[0] esiste sempre fallirà all'esecuzione.

Una volta che hai l'URI, rendere una anteprima è lineare:

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

Se hai in programma 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.

Le opzioni che modificano il comportamento downstream

Alcune opzioni del picker influiscono su più della schermata di selezione. Sono responsabili della dimensione del file, del comportamento di modifica e di cosa il tuo backend deve accettare.

Un paio di compromessi possono essere facilmente trascurati:

• 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 influisce sul tempo di caricamento, sulla pressione di memoria e sullo storage del server. quality: 1 non è automaticamente la scelta giusta.
• mediaTypes Deve corrispondere alle regole del backend. Se il server rifiuta i video, non far tornare il picker.
• base64 Aumenta la dimensione del payload in memoria. Evitalo a meno che il servizio di ricezione non lo richieda.

Quel punto è importante sui dispositivi con memoria bassa. Un URI di file locale è di solito la migliore consegna per la anteprima e l'upload a parti.

URI contro base64

Per la maggior parte degli app, la regola è semplice:

• Usa URI per le anteprime.
• Usa URI per gli upload di file.
• Usa base64 Si il sistema ricevente richiede esplicitamente contenuto codificato.

Questo pattern mantiene il picker code piccolo e più facile da testare. Inoltre, si allinea con la maggior parte delle flussi di media backend, inclusi i servizi che pubblicano eventualmente su piattaforme esterne come quella di pubblicazione dei media Instagram API.

Se il tuo team invia aggiornamenti OTA frequenti o sposta asset immagine pesanti attraverso la consegna dell'applicazione, le decisioni sulle dimensioni dei file qui hanno ripercussioni sulla restante pipeline. Questa guida su l'ottimizzazione delle immagini per gli aggiornamenti dell'applicazione è un utile compagno di configurazione del picker.

Un pattern 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 raw del picker.

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 prevedibile 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 ultimo controllo aiuta. Non abilitare campi di risultato aggiuntivi solo per precauzione. Richiedi i dati che sai di dover avere, e mantieni il picker concentrato sulla selezione piuttosto che trasformarlo in un passo di elaborazione generale dei file.

Modelli Avanzati e Differenze di Piattaforma

Un picker di solito smette di essere semplice nel momento in cui l'immagine selezionata deve sopravvivere alle ripetizioni, ai token di autenticazione, alle differenze di autorizzazione nativa e a un endpoint di upload 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 backends comuni di 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();
}

Quello code è sufficiente per dimostrare che il percorso funziona, ma le applicazioni di produzione solitamente hanno bisogno di un'altra layer. Deriva name e type dall'asset selezionato quando possibile, attacca l'autenticazione all'esterno della funzione 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 prevenire le comuni fallite che vedo in revisione:

• Conferma la locale uri Esiste prima di costruire la richiesta
• Visualizza un anteprima prima dell'upload in modo che gli utenti possano riconoscere il file sbagliato presto
• Prevenire i tocchi ripetuti mentre la richiesta è in volo
• Gestisci le fallite di rete separatamente dalle cancellazioni del picker o dagli errori di autorizzazione
• Spera che la validazione backend rifiuti i file grandi, i tipi MIME non supportati o la mancanza di autenticazione

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 hanno effettivamente importanza

L'interfaccia utente del picker è nativa, quindi eredita il comportamento nativo. Ciò influenza sia ciò che gli utenti vedono sia ciò che 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 insieme più ristretto di asset rispetto a quanto visto dal 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 le riprese della fotocamera vengono restituite. Le app React Native a nudo sentono queste differenze più direttamente perché si hanno più del setup nativo, ma le app Expo gestite ancora hanno bisogno di code che tratta il picker come piattaforma-formato piuttosto che perfettamente uniforme.

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

Un paio di esempi contano nelle app reali:

• Modifica e taglio: La UI e il comportamento di taglio non sono identici tra iOS e Android
• Metadata restituita: fileName, mimeTypee fileSize possono essere assenti o inconsistenti, quindi aggiungi fallback
• Autorizzazioni: L'accesso alle foto di iOS può essere limitato a oggetti selezionati, mentre il comportamento di Android dipende di più dalla versione del sistema operativo e dal supporto del picker del sistema
• 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 al di fuori di Expo, questo Guida allo sviluppo di DesignStack per applicazioni fornisce un contesto di Android utile per le decisioni di gestione dei media che si manifestano al di là di una singola libreria.

Differenze tra flussi di lavoro gestiti e bare

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

Nel flusso di lavoro gestito, le stringhe di autorizzazione e la configurazione dei plugin sono solitamente presenti 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 anche che una correzione della configurazione non è visibile fino alla prossima build nativa. Le aggiornamenti OTA non patch le autorizzazioni native mancanti.

Nel flusso di lavoro bare, la stessa funzionalità ha più parti in movimento. È necessario verificare le descrizioni di utilizzo native di iOS, il comportamento del manifesto Android, l'installazione del pacchetto e la programmazione della ricostruzione da parte dell'utente. L'aspetto positivo è il controllo. Il costo è che un problema di picker può essere causato dalla 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 di piattaforma, e è un punto di confronto valido se si sta decidendo quanto di configurazione nativa il proprio team vuole gestire.

La mia preferenza è coerente in entrambi i flussi di lavoro. 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 dell'immagine picker Expo rientra in una piccola serie di categorie. La soluzione più veloce è spesso identificare quale layer sta fallendo: configurazione, autorizzazione, gestione del risultato o rendering.

Verifiche rapide per fallimenti comuni

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

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

A poche rapide mappature aiutano:

• Errori di autorizzazione negata: Verifica la configurazione dell'app e le stringhe di autorizzazione 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 senza effetti.
• L'immagine non si visualizza: Conferma che l'URI è stato memorizzato nello stato e passato in <Image source={{ uri }} />.
• La camera si comporta in modo strano nel simulatore: Testa sul dispositivo fisico prima di iniziare a cercare un bug nella 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 le parti native: Aggiungi la descrizione del plugin e delle autorizzazioni richieste.
• Richiedi le autorizzazioni in modo intenzionale: Separare flussi di camera e libreria dei media.
• Proteggere ogni risultato: Controlla result.canceled e leggi in modo sicuro assets[0].
• Preferire l'upload basato su URI: Conservare base64 solo per casi speciali.
• Testare dispositivi reali: Soprattutto per la cattura della camera e le richieste di autorizzazione.

Se il tuo team distribuisce Capacitor o app Electron insieme a progetti React Native, Capgo è un'opzione per consegnare aggiornamenti di JavaScript, CSS, configurazione e asset senza dover attendere la revisione della store per ogni modifica. È rilevante quando si risolvono problemi di immagine nella layer web, come l'interfaccia di upload, le regole di validazione, il testo o il trattamento degli asset intorno al flusso del picker.