Expo Bildauswahl: Ein umfassender Leitfaden für 2026

Sie sind wahrscheinlich an dem Punkt angelangt, an dem die Benutzeroberfläche fertig ist, die Profilseite hat einen „Bild hochladen“-Button und jetzt ist das einfache Teil plötzlich nicht mehr einfach. Die tatsächliche Bildauswahl-Fluss berührt native Berechtigungen, OS-kontrollierte Schnittstellen, verschiedene Rückgabeformate als viele Entwickler erwarten und eine Handvoll Build-Zeit-Details, die erst nach dem Versand eines realen Builds auftauchen.

Das ist, wo die Expo Bildauswahl passt. Es ist die offizielle Expo-Bibliothek für die Öffnung der System-Oberfläche, um Bilder und Videos aus der Gerätebibliothek auszuwählen oder eine Fotografie mit der Kamera aufzunehmen, wie im Expo-Paket-Repository beschrieben. In der Praxis bedeutet das, dass Sie eine zuverlässige Brücke in die native Medieneingabe erhalten, aber nicht eine benutzerdefinierte Medienexperience, die auf jedem Gerät identisch verhält.

Diese Anleitung ist für die erste Implementierung geschrieben, nicht für die Demo. Sie konzentriert sich auf die Entscheidungen, die in der Produktion zählen: Verwaltung versus Bare-Workflow-Einrichtung, Zugriffsverwaltung, die Sie später nicht überraschen wird, sichere Ergebnisauflösung und eine praktische Upload-Muster nachdem der Benutzer ein Datei ausgewählt hat. Wenn Sie in einer benutzerdefinierten native Setup arbeiten, hilft es auch, zu verstehen, wie dies sich von einem Expo-Entwicklungsklient-Workflow unterscheidet. Inhaltsverzeichnis.

Einführung in Expo Bildauswahl

• Installation und grundlegende Konfiguration
• Verwalteter Workflow-Einrichtung
  • Bare React Native Setup Details
  • Zugriff auf die Kamera und Medienbibliothek
• Ein minimaler aber sicherer Komponente
  • Bibliothek und Kamera-Flows
  • Was Sie von der System-UI erwarten können
  • Expo Entwicklungsklient-Workflow
• Ergebnisse und Optionen des Pickers verwalten
  • Das Ergebnisobjekt richtig lesen
  • Optionen, die das Downstream-Verhalten ändern
  • URI gegenüber base64
  • Ein sichereres Ergebnismuster für echte Apps
• Erweiterte Muster und Plattformunterschiede
  • Ein praktisches Uploadmuster
  • Wo sich tatsächliche Plattformunterschiede auswirken
  • Unterschiede zwischen verwaltetem und barem Workflow
• Häufige Probleme im Produktionsumfeld
  • Schnelle Überprüfungen für häufige Fehler
  • Ein kurzer Produktionscheckliste

Einstieg in Expo Image Picker

Ein Produktmanager bittet um Profilbilder. Eine Woche später benötigt derselbe Feature auch die Hochladen von Rechnungen, die Kamerafunktion für Vorfälle und Wiederholungen, wenn Benutzer die erste Zeit die Erlaubnis verweigern.

expo-image-picker ist das Expo SDK-Modul für diese Aufgabe. Es öffnet den Plattform-Chooser oder die Kamera-UI und gibt die ausgewählte Medien in einer Form zurück, die Ihr React Native code verarbeiten kann. Die JavaScript API ist klein. Der Hauptwettbewerb liegt darin, die native Einstellung, die Erlaubnisfluss und die Ergebnisbearbeitung auf beiden verwalteten und barem Projekten richtig zu bekommen.

Der Hauptwettbewerb ist klar. Sie lassen iOS und Android ihre eigenen Medien-UI präsentieren, anstatt eine benutzerdefinierte Picker zu bauen. Das gibt normalerweise ein besseres Ergebnis: Benutzer verstehen bereits die System-Screens, Erlaubnisanfragen verhalten sich wie die OS erwartet und Ihr Team vermeidet die Wartung einer Galerieimplementierung in JavaScript.

Behandeln Sie dies als eine native Integration-Funktion mit einer React-Schnittstelle.

Dieser Ansatz hilft, weil die Fehlerquellen selten in der Schaltfläche liegen, die den Picker aufruft. Sie kommen normalerweise aus einer der drei Orten:

• Native-Konfiguration: fehlende Plugin-Einstellungen, falsche Erlaubnisstrings oder ein veraltetes Build nach einer Änderung der Konfiguration
• Laufzeitverhalten: Benutzer können den Zugriff verweigern, auf iOS begrenzte Bibliotheks-Zugriffe gewähren oder den Flow ohne Auswahl abbrechen
• Ergebnisbearbeitung: Die aktuelle API gibt ein assets array, so ältere Beispiele, die direkt fehlschlagen result.uri Die Wahl des Workflows ändert auch den Pfad der Einrichtung. In einem verwalteten Expo-App leben die meisten nativen Arbeiten in der Anwendungs-Konfiguration und erfordern einen Neubau, wenn sich diese Konfiguration ändert. In einer leeren App erhalten Sie den Expo-Modul __CAPGO_KEEP_0__, aber Sie müssen die zugrunde liegenden iOS- und Android-Projekt-Einstellungen direkt überprüfen. Wenn Ihr Team ein benutzerdefiniertes Client-Modul anstelle von Expo Go verwendet, passt sich diese Anleitung gut mit __CAPGO_KEEP_1__’s Erklärung der Änderung der nativen Modulprüfung bei der Entwicklung eines Expo-Client-Moduls an

Workflow choice also changes the setup path. In a managed Expo app, most of the native work lives in app config and requires a rebuild when that config changes. In a bare app, you still get the Expo module API, but you need to verify the underlying iOS and Android project settings more directly. If your team is using a custom client instead of Expo Go, this guide pairs well with Capgo’s explanation of Installation und wesentliche Konfiguration.

Die Installation erfordert nur einen Befehl. Die richtige nativen Konfiguration bestimmt, ob der Picker auf einem echten Gerät, in einem benutzerdefinierten Entwickler-Client und in Ihrer Produktionsversion funktioniert

Gibt einen React-fokussierten __CAPGO_KEEP_0__ über die Plattform-Picker für Fotos, Videos und Kamera-Aufnahmen. Die JavaScript-Anruferin ist einfach. Die Einrichtung ist nicht, weil der Zugriff auf Fotos und die Kamera von iOS und Android gesteuert werden und nicht von React Native

Ein Entwickler, der an der Implementierung der Expo-Bildwählerarbeit arbeitet, indem er __CAPGO_KEEP_0__ auf einem Laptop-Computerbildschirm tippt

expo-image-picker gives a React-facing API over the platform pickers for photos, videos, and camera capture. The JavaScript call is simple. The setup is not, because photo access and camera access are controlled by iOS and Android, not by React Native.

anstatt

npx expo install expo-image-picker

Stattdessen expo install anstatt npm install oder yarn add. Expo passt die Paketversion mit Ihrem SDK überein, was eine häufige Klasse von Problemen bei der nativen Kompatibilität vermeidet. Wenn Sie vergleichen, wie Expo-Module in Ihrem Release-Prozess passen, ist dies Übersicht über Expo-Tools ist eine nützliche Referenz.

Einstellung des verwalteten Workflows

Im verwalteten Workflow deklarieren Sie den Plugin in der App-Konfiguration, damit Expo die nativen Änderungen bei der Buildzeit anwenden kann.

Beispiel mit app.json:

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

Dies ist die minimale Einstellung. In der Praxis fügen Teams üblicherweise auch die Berechtigungstexte hinzu, insbesondere auf iOS, wo der Systemanzeige erklären sollte, warum die App Zugriff benötigt. Halten Sie die Wortwahl spezifisch auf die Benutzeraktion.

Eine operative Details verursacht viel Zeitverschwendung. Änderungen pluginsan Berechtigungstexten oder anderen nativen Konfigurationen erfordern einen Neubau. Eine erneute JavaScript-Ladung wirkt sich nicht auf diese Änderungen aus. In Expo Go sind Sie auch durch die bereits im Client enthaltenen Einschränkungen eingeschränkt. In einem Entwicklungsbuild oder Produktionsbuild spiegelt sich die native Projekt nur nach einem neuen Build Ihre Konfiguration wider.

Einstellungsdetails für eine Bare-React-Native-Anwendung

In einer Bare-App ist das Paket API gleich, aber Sie müssen mehr der nativen Projekt selbst überprüfen. Die iOS-Benutzungsbeschreibungen sind das erste, was Sie überprüfen sollten. Wenn Ihr Fluss die Bibliothek öffnen, die Kamera starten oder Video mit Audio aufnehmen kann, benötigt Ihre App die entsprechenden Berechtigungstexte in Info.plist bevor Sie neu bauen.

Ein praktischer Checkliste für bare Projekte sieht wie folgt aus:

1. Installieren expo-image-picker mit npx expo install expo-image-picker.
2. Fügen Sie die Plugin-Konfiguration hinzu, wenn Ihr Projekt Expo-Konfigurationsplugins verwendet.
3. Bestätigen Sie, dass die iOS-Benutzungsbeschreibungen den von Ihnen angebotenen Funktionen entsprechen.
4. Bauen Sie die iOS- und Android-Apps neu, nachdem jede native Konfigurationsänderung vorgenommen wurde.

Der Text für fehlende Berechtigungen sieht oft wie ein Laufzeitfehler aus, weil die Benutzeroberfläche code in Ordnung ist und der Button-Handler ausgeführt wird. Der Fehler liegt tiefer in der Stack. Ich überprüfe normalerweise Info.plist, die App-Konfiguration und ob die aktuelle Build die neuesten native Änderungen enthält, bevor ich den Komponenten code zuweisen.

Einige Gewohnheiten machen die Einrichtung vorhersehbarer:

• Schreiben Sie den Text für die tatsächliche Aktion: Benutzer sollten verstehen, warum sie den Hinweis sehen.
• Kamera und Bibliothek separat konfigurieren: Einer funktioniert, während der andere noch nicht funktioniert.
• Nach native Änderungen neu erstellen: Hot Reload und schnelle Aktualisierung aktualisieren die native Berechtigungen nicht.
• Auf Gerät testen: Simulatorverhalten kann Berechtigungs- und Kameraprobleme verbergen.

Wenn der Picker während der Entwicklung funktioniert, aber bei TestFlight oder der Play Store-Buildung bricht, betrachten Sie das als Konfigurationsproblem zuerst. Die meisten der Zeit ist es das.

Zugriff auf die Kamera und die Medienbibliothek

Ein Benutzer klickt auf 'Foto hochladen', erwartet, dass die Kamera oder Bibliothek geöffnet wird, und Ihre App hat in diesem Moment eine Aufgabe. Öffnen Sie das richtige System-UI, behandeln Sie den Widerspruch oder die Abbrechung ohne das Bildschirm zu brechen, und geben Sie einen verwendbaren lokalen Dateireferenz für Voransicht oder Upload zurück.

Das klingt einfach, bis Sie beide verwalteten und bare Builds über iOS und Android testen. Der JavaScript API bleibt kompakt, aber die Laufzeitverhalten hängt immer noch von den OS-Anfragen, der Gerätehardware und davon ab, wie Ihre native Berechtigungen zuvor konfiguriert wurden.

Ein minimaler aber sicherer Komponent

The Kernfluss ist konsistent in beiden Expo-gesteuerten und bare-Workflow-Projekten. Stellen Sie die relevanten Berechtigungen an, starten Sie den Picker, überprüfen Sie, ob der Benutzer abgebrochen hat, und lesen Sie dann den ersten Asset von __CAPGO_KEEP_0__ result.assets.

Eine Basis-Komponente sieht so aus:

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

Drei Details sind hier wichtig.

• Stellen Sie die Bibliothek- und Kamera-Berechtigungen separat an. Sie scheitern unabhängig voneinander.
• Behandeln Sie das Abbrechen als normale Benutzeraktion und nicht als Fehlerzustand.
• Lesen Sie von __CAPGO_KEEP_0__, weil der Picker eine Asset-Array zurückgibt und nicht ein top-level __CAPGO_KEEP_0__ assets[0]Bibliothek- und Kamera-Flüsse uri.

Beginnen Sie mit dem Bibliothek-Fluss, wenn Sie den schnellsten Weg zu einem funktionierenden Feature wollen. Es ist einfacher zu testen, es funktioniert in mehreren Simulator-Setup, und es vermeidet Kamera-Hardware-Randfälle. Fügen Sie Kamera-Unterstützung hinzu, sobald der Ergebnis-Handling-Weg stabil ist.

Der Kamera-Weg hat mehr Möglichkeiten zum Scheitern in der Entwicklung. Die iOS-Simulator-Unterstützung ist begrenzt. Android-Emulatoren mögen die Kamera-Verhalten nicht so ausgeben, wie es ein echter Gerät tut. In bare-Projekten können diese Lücken Sie dazu bringen, sich auf die Komponente __CAPGO_KEEP_0__ zu konzentrieren, obwohl das tatsächliche Problem die native Konfiguration oder die Testumgebung ist.

Ein sauberes UI-Muster besteht darin, den Benutzer vor dem Aufrufen des Pickers um die Quelle zu bitten: code

A clean UI pattern is to ask the user for the source before calling the picker API:

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

Die Kamera-Unterstützung ist nicht erforderlich, um eine Bibliothek-App zu erstellen.

If Ihr breiteres App auch Dateizugriffsverhaltensmuster außerhalb von Expo unterstützt oder Sie Vergleiche zwischen Konventionen über native Stapel anstellen, ist dies Capacitor Fotobibliotheksreferenz wichtiger Kontext.

Ein kurzer Demo hilft, wenn Sie diese Fluss Ihren Teamkollegen oder QA zeigen:

Was Sie von der System-UI erwarten können

expo-image-picker Öffnet die Plattformpicker oder Kamera-UI. Ihre App kontrolliert nicht jede Seite in diesem Fluss. Diese Unterscheidung ist wichtig, weil 'funktioniert auf meinem Gerät' oft bedeutet 'die OS erlaubte den Pfad, den ich getestet habe.'

Auf iOS können Benutzer begrenzten Bibliothekszugriff statt vollem Zugriff gewähren. Auf Android kann sich das Verhalten des Pickers je nach OS-Version und Händlerhaut ändern. In Projekten mit verwaltetem Workflow handhabt Expo mehr von der nativen Verkabelung für Sie. In Projekten mit barem Workflow müssen Sie bestätigen, dass Ihre gebaute App die nativen Berechtigungsänderungen enthält, die Sie vorgenommen haben. Die JavaScript-Anrufliste kann in beiden Fällen identisch sein, während sich die Ausführungszeitdifferenz ändert.

Ich teste diese Fälle normalerweise, bevor ich die Funktion als abgeschlossen betrachte:

• erster Berechtigungsantrag
• abgelehnter Berechtigung
• Benutzerstornierung
• erfolgreiche Bibliotheksabfrage
• Erfolgreiche Kamerafunktion auf einem physischen Gerät
• Unmittelbare Vorschau der zurückgegebenen lokalen URI

Diese Fälle entsprechen direkt der realen Produktionsverhalten. Sie setzen auch den nächsten Schritt sauber ein, wenn Sie das Datei an einen Server, einen Moderationspipeline oder ein Veröffentlichungsziel wie das "Instagram media publishing __CAPGO_KEEP_0__" senden müssen Instagram media publishing API.

Das Picker-Ergebnis ist der Teil, der in der Regel echte Produktionslogik benötigt. Das System-UI gibt ein strukturiertes Objekt zurück, nicht nur einen Dateipfad, und kleine Fehler hier führen zu gebrochenen Vorschauen, leeren Uploads oder Crashes, wenn der Benutzer den Picker abbricht

Lesen Sie das Ergebnisobjekt richtig

Die Ergebnisform, die in aktuellen Expo-Anwendungen relevant ist, ist

nicht ein oberstes Niveau result.assets[0].uriDiese Details wirken sich sowohl auf Projekte mit verwaltetem als auch auf Projekte mit barem Workflow aus, da der JavaScript-Code __CAPGO_KEEP_0__ gleich bleibt, obwohl die native Setup unterschiedlich ist result.uri. That detail affects both managed and bare workflow projects because the JavaScript API is the same even though native setup differs underneath.

Dies handhabt die beiden häufigsten Fehlerfälle, die ich sehe. Ein abgebrochener Picker gibt Ihnen kein Asset zum Lesen, und __CAPGO_KEEP_0__ das annehmen würde

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

This handles the two failure cases I see most often. A canceled picker does not give you an asset to read, and code that assumes result.assets[0] immer existiert und wird bei der Ausführung fehlschlagen.

Sobald Sie die URI haben, ist die Darstellung eines Vorschaubildes unkompliziert:

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

Wenn Sie später hochladen planen, sollten Sie das ganze Objekt aufbewahren, nicht nur die URI. In der Praxis, asset , und fileName, mimeType, width, heightsind oft nützlich für die Validierung, Protokollierung oder die Erstellung eines sauberen multipart-Anforderung. fileSize Optionen, die die Abhängigkeit der Ausführung ändern

Einige Auswahlmöglichkeiten des Pickers beeinflussen mehr als nur das Auswahlbildschirm. Sie prägen Dateigröße, Bearbeitungsverhalten und, was Ihr Backend akzeptieren muss.

Option

Einige Kompromisse sind leicht zu übersehen:

• allowsEditing ist nützlich, wenn das Bildschlitze eine fixe Form oder Größe hat. Es ist weniger nützlich, wenn Ihr Server sein eigenes Crop-Pipeline durchführt und Sie das Original-File wollen.
• quality beeinflusst die Upload-Zeit, den Speicherdruck und die Server-Speicherung. quality: 1 ist nicht automatisch die richtige Wahl.
• mediaTypes sollte den Hintergrund-Regeln entsprechen. Wenn der Server Videos ablehnt, lassen Sie den Picker sie nicht zurückgeben.
• base64 erhöht die Payload-Größe im Speicher. Vermeiden Sie es, es sei denn, die empfangende Dienst erfordert es.

Das letzte Punkt ist auf Geräten mit geringer Speicherkapazität wichtig. Eine lokale Datei-URI ist in der Regel die bessere Übergabe für die Vorschau und das multipart-Upload. Base64 hat gültige Verwendung, aber es ist im Vergleich zum Übergeben eines Dateireferenz teuer.

URI gegenüber Base64

Für die meisten Apps ist die Regel einfach:

• Verwenden Sie URI für Vorschauen.
• Verwenden URI für Dateiuploads.
• Verwenden Sie nur Base64, wenn das empfangende System explizit nach kodiertem Inhalt fragt. Dieser Musterhalt macht den Picker __CAPGO_KEEP_0__ kleiner und einfacher zu testen. Es passt auch zu der Art, wie viele Backend-Medien-Flüsse aufgebaut sind, einschließlich Diensten, die letztendlich auf externe Plattformen wie dem Instagram-Medienveröffentlichungs__CAPGO_KEEP_0__

That pattern keeps picker code small and easier to test. It also lines up with how many backend media flows are built, including services that eventually publish to external platforms such as the Instagram media publishing API.

ist ein nützliches Begleitwerk zur Picker-Konfiguration. Ein sichereres Ergebnismuster für echte Apps Use

URI

For demo code, nur speichern imageUri ist in Ordnung. In der Produktion solltet ihr ein normalisiertes Objekt speichern, damit der nächste Schritt, der Vorschau, die Validierung, der Upload oder die Wiederholung, nicht jedes Mal die Rohauswahl interpretieren muss.

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

Dadurch habt ihr eine vorhersehbare Form innerhalb der App. Es macht auch die Verwaltung und die Bare-Projekte einfacher, sie zu synchronisieren, weil die App code stabil bleibt, während ihr durch die nativen Unterschiede arbeitet.

Ein letzter Check hilft. Aktiviert nicht extra Ergebnisfelder nur aus Sicherheitsgründen. Fordert die Daten, die ihr benötigt, und lasst den Picker auf die Auswahl fokussieren, anstatt ihn in einen allgemeinen Dateiverarbeitungsschritt umzuwandeln.

Erweiterte Muster und Plattformunterschiede

Eine Picker-Funktion wird sich in dem Moment nicht mehr einfach handhaben lassen, wenn die erste ausgewählte Bild das Überleben von Wiederholungen, Auth-Header, nativen Berechtigungsunterschieden und einem echten Upload-Endpunkt angeht. expo-image-picker handhabt die Auswahl gut. Der Rest der Funktion liegt bei eurer App.

Eine praktische Upload-Muster

Für APIs, die ein Dateiupload erwarten FormData ist immer noch der sichere Standard. Er funktioniert auf allen gängigen Rails, Node, Laravel, Django und Go-Backends und hält den Picker von den Transportanliegen getrennt.

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

Dass code genügt, um zu beweisen, dass der Weg funktioniert, aber Produktionsanwendungen benötigen normalerweise einen zusätzlichen Schritt. Ableiten name und type wenn möglich, Auth außerhalb der Picker-Funktion anhängen, und den Upload-Zustand separat vom Picker-Zustand halten, damit ein fehlgeschlagener Anfrage den Benutzer nicht zwingt, das Bibliothek neu zu öffnen.

Einige Kontrollen verhindern die häufigen Fehler, die ich in der Überprüfung sehe:

• Bestätige die lokale uri existiert vor der Erstellung der Anfrage
• Erstelle einen Vorschau vor dem Upload, damit die Benutzer frühzeitig erkennen, dass sie falsche Dateien ausgewählt haben.
• Verhindere wiederholte Tasten, während die Anfrage im Flug ist
• Behandle Netzwerkfehler separat von Picker-Stornierungen oder Berechtigungsfehlern
• Erwarte, dass die Backend-Validierung große Dateien, nicht unterstützte MIME-Typen oder fehlende Authentifizierung ablehnt.

Wenn Ihr Backend Base64 anstelle von multipart erfordert, ist das in der Regel ein Server-Beschränkung und nicht eine Picker-Anforderung. Multipart ist günstiger im Speicher und einfacher zu verstehen auf mobilen Geräten.

Wo Plattformunterschiede tatsächlich relevant sind

Die Picker-UI ist native, daher erbt sie native Verhaltensweisen. Das betrifft sowohl das, was die Benutzer sehen, als auch, was Ihr code annehmen sollte.

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.

Die praktische Regel ist einfach. Vertraue auf die Felder, die du validieren kannst, und nicht auf identische Benutzeroberflächen oder identische Metadaten auf verschiedenen Geräten.

Einige Beispiele zählen in realen Apps:

• Bearbeitung und Kropfung: Die Benutzeroberfläche und das Kropfverhalten sind nicht identisch zwischen iOS und Android
• Gesendete Metadaten: fileName, mimeTypeund fileSize können abwesend oder inkonsistent sein, daher füge Fallbacks hinzu
• Berechtigungen: Die Zugriffsberechtigungen auf Fotos können auf iOS auf ausgewählte Artikel beschränkt sein, während das Verhalten von Android mehr von der Betriebssystemversion und der Unterstützung des Systempickers abhängt
• Kameraausgabe: Die aufgenommenen Bilder können mit unterschiedlichen Namens, Orientierung oder Kompressionsmerkmalen als Bibliotheksassets zurückgegeben werden

Wenn Ihr Team auch außerhalb von Expo arbeitet, ist dies Entwicklerhandbuch für DesignStack-Anwendungen Dieses Handbuch liefert nützliche Kontextinformationen für die Android-Medienverwaltung, die sich außerhalb einer einzelnen Bibliothek zeigen.

Unterstützte vs. bare Workflow-Unterschiede

Zu diesem Zeitpunkt beginnen die Setup-Optionen, operativ zu zählen.

Im managed Workflow leben die Berechtigungszeichen und Plugin-Konfigurationen in der App-Konfiguration, und native Änderungen werden bei der Erstellung einer neuen Build angewendet. Das hält die JavaScript-Oberfläche sauber, aber es bedeutet auch, dass eine Konfigurationsänderung erst bei der nächsten native Build sichtbar ist. OTA-Updates patchen fehlende native Berechtigungen nicht.

Im bare Workflow hat das gleiche Feature mehr bewegliche Teile. Sie müssen die native iOS-Benutzungsbeschreibungen, die Android-Manifestverhalten, die Paketinstallation und die Rebuild-Zeit selbst überprüfen. Der Vorteil ist die Kontrolle. Der Nachteil ist, dass ein Picker-Fehler durch native Konfiguration verursacht werden kann, nicht durch die JavaScript-Anrufliste.

Teams, die zwischen Expo und Capacitor hin- und herwechseln, unterschätzen oft, wie unterschiedlich diese Abstraktionsschichten sind. Capgo hat eine nützliche Erklärung, wie Capacitor Plattformunterschiede handhabt how Capacitor handles platform differencesMeine Vorliebe ist konsistent in beiden Workflows. Halten Sie den Picker __CAPGO_KEEP_0__ eng, normalisieren Sie das Ergebnis einmal, laden Sie es über eine dedizierte __CAPGO_KEEP_1__-Schicht hoch und behandeln Sie plattform-spezifische Verhaltensweisen als etwas, das konfiguriert und explizit getestet werden soll, anstatt sie mit Annahmen zu glätten.

My preference is consistent across both workflows. Keep picker code narrow, normalize the result once, upload through a dedicated API layer, and treat platform-specific behavior as something to configure and test explicitly rather than smooth over with assumptions.

__CAPGO_KEEP_0__

Die meisten Expo Image Picker-Fehler fallen in eine kleine Anzahl von Kategorien. Die schnellste Lösung ist meistens, zu identifizieren, welcher Layer fehlschlägt: Konfiguration, Berechtigung, Ergebnisbearbeitung oder Rendering.

Schnelle Überprüfungen für häufige Fehler

Wenn der Picker nicht öffnet oder die Berechtigungen fehlschlagen, überprüfen Sie zunächst die native Einstellungen. In besonderen Fällen von bare Apps sind fehlende iOS-Benutzungsbeschreibungen eine häufige Ursache.

Wenn die App nachdem ein Benutzer den Picker schließt abstürzt, überprüfen Sie Ihre Ergebnisbearbeitung. Viele Implementierungen nehmen an, dass es sich um eine direkte URI handelt und die Überprüfung canceled verpassen.

Einige schnelle Zuweisungen helfen:

• Berechtigungsfehler: Überprüfen Sie Ihre App-Konfiguration und native Berechtigungszeichenfolgen, dann neu erstellen.
• undefined Bild-URI: Aus result.assets?.[0]?.uri, nicht result.uri.
• Nach Abbruch passiert nichts: Das mag korrekt sein. Abbruch als Zustand ohne Aktion behandeln.
• Bild wird nicht angezeigt: Bestätigen Sie, dass die URI im Zustand gespeichert und in <Image source={{ uri }} />.
• Die Kamera verhält sich seltsam im Simulator: Bevor Sie sich auf ein Bibliotheksproblem einlassen, testen Sie auf einem physischen Gerät.

Kurzlehrer für die Produktion

Verwenden Sie dies als letzte Überprüfung vor dem Versand:

• Mit dem Expo-Tool installieren: Verwenden Sie npx expo install expo-image-picker.
• Konfigurieren Sie native Komponenten: Fügen Sie die Plugin und erforderliche Berechtigungen hinzu.
• Berechtigungen absichtlich anfordern: Kamera- und Medienbibliotheksflüsse getrennen.
• Jedes Ergebnis schützen: Überprüfen result.canceled und sicher lesen assets[0].
• URI-basierte Uploads bevorzugen: Base64 nur für besondere Fälle behalten.
• Realgeräte testen: Besonders für die Kameraaufnahme und die Berechtigungsanfragen.

Wenn Ihr Team Capacitor oder Electron-Apps neben React Native-Projekten ausliefert, Capgo ist eine Option für die Lieferung von JavaScript, CSS, Konfiguration und Asset-Updates ohne auf jede Änderung warten zu müssen, die im Store überprüft werden muss. Es ist relevant, wenn imagebezogene Fixes im Weblayer leben, wie z.B. Upload-UI, Validierungsregeln, Kopien oder Asset-Handling um den Picker-Flow herum.