Expo Bildauswahl: Eine umfassende Anleitung für 2026

Sie sind wahrscheinlich an dem Punkt angelangt, an dem die Benutzeroberfläche fertig ist, die Profilseite einen „Bild hochladen“-Button hat und jetzt plötzlich das Easy-Teil nicht mehr so einfach ist. 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 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 zu machen, wie in der Expo Paket-Repository. 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.

Dieses Handbuch ist für die erste Implementierung geschrieben und nicht für die Demo. Es konzentriert sich auf die Entscheidungen, die in der Produktion zählen: Verwaltung versus Bare-Workflow-Einrichtung, Berechtigungsverwaltung, 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-Entwicklungsklienten-Workflow unterscheidet. Inhaltsverzeichnis.

Erste Schritte mit dem Expo Bildwähler

• Installation und wesentliche Konfiguration
• Verwaltung 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
  • This guide is written for the first implementation, not the demo. It focuses on the decisions that matter in production: managed versus bare workflow setup, permission handling that won’t surprise you later, safe result parsing, and a practical upload pattern after the user picks a file. If you’re working in a custom native setup, it also helps to understand how this differs from an Expo development client workflow
• Ergebnisse und Optionen des Pickers verwalten
  • Das Ergebnisobjekt richtig lesen
  • Optionen, die das Downstream-Verhalten beeinflussen
  • 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 nacktem Workflow
• Häufige Probleme lösen
  • 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 die Benutzer die erste Zeit die Erlaubnis verweigern.

expo-image-picker ist das Expo SDK-Modul dafür zuständig. 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 Hauptfehler liegt in der richtigen Konfiguration der native Einstellungen, der Erlaubnis-Fluss und der Ergebnis-Verarbeitung auf beiden verwalteten und freien Projekten.

Der Haupt-Vorteil ist eindeutig. Sie lassen iOS und Android ihre eigenen Medien-UI präsentieren, anstatt ein benutzerdefiniertes Picker zu bauen. Das gibt in der Regel ein besseres Ergebnis: Die Benutzer verstehen die System-Screens bereits, die Erlaubnis-Anfragen verhalten sich wie die OS erwartet und Ihr Team vermeidet die Wartung einer Galerie-Implementierung in JavaScript.

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

Dieser Ansatz hilft, weil die Fehlerquellen selten im Button liegen, der den Picker aufruft. Sie kommen in der Regel aus einem der drei Orte:

• Native-Konfiguration: fehlende Plugin-Einstellungen, falsche Erlaubnis-Strings oder ein veralteter Build nach einer Änderung der Konfiguration
• Laufzeit-Verhalten: Benutzer können den Zugriff verweigern, auf iOS nur begrenzte Bibliotheks-Zugriffe gewähren oder den Flow ohne Auswahl abbrechen
• Ergebnis-Verarbeitung: Die aktuelle API gibt ein assets array, so ältere Beispiele, die direkt fehlschlagen result.uri Workflow-Wahl ändert auch den Pfad der Einrichtung. In einem verwalteten Expo-App leben die meisten nativen Arbeiten in der App-Konfiguration und erfordern einen Neubau, wenn sich diese Konfiguration ändert. In einer Bare-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-Tool anstelle von Expo Go verwendet, passt sich diese Anleitung gut mit __CAPGO_KEEP_1__’s Erklärung der Änderung der nativen Modul-Testung durch einen Expo-Entwicklungsclient 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 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

bietet eine React-freundliche __CAPGO_KEEP_0__ über die Plattform-Picker für Fotos, Videos und Kamera-Aufnahmen. Die JavaScript-Anweisung 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ählerarbeitsfläche 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

__CAPGO_KEEP_0__ expo install __CAPGO_KEEP_1__ 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

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

Das ist die Mindesteinstellung. In der Praxis fügen Teams üblicherweise auch die Erlaubnis-Texthinweis hinzu, insbesondere auf iOS, wo der Systemanzeige erklären soll, warum die App Zugriff benötigt. Halten Sie die Wortwahl spezifisch auf die Benutzeraktion.

Eine operative Details verursacht viel Zeitverschwendung. Änderungen pluginsan Erlaubnis-Texthinweis oder andere native Konfiguration 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 Entwicklungsbau oder Produktionsbau spiegelt sich die native Projekt nur nach einem neuen Build Ihre Konfiguration wider.

Einstellung des Bare-React-Native-Setup

Bei einem Bare-App ist die Paketversion API gleich, aber Sie müssen mehr der nativen Projekt selbst überprüfen. Die iOS-Benutzungsbeschreibung ist 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 Erlaubnis-Texthinweis in Info.plist vor der Wiederherstellung.

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. Stellen Sie sicher, dass die iOS-Benutzungsbeschreibungen den von Ihnen angebotenen Funktionen entsprechen.
4. Rekonstruieren Sie die iOS- und Android-Apps nach jeder native Konfigurationsänderung.

Der Text für die fehlenden Berechtigungen sieht oft wie eine Laufzeitfehler aus, weil die UI 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 zuwende.

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: Während eines kann das andere noch scheitern.
• Rebuild nach native Änderungen: Hot Reload und schnelle Aktualisierung aktualisieren keine native Berechtigungen.
• Auf Gerät testen: Simulatorverhalten kann Probleme mit Berechtigungen und Kamera verbergen.

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

Zugriff auf Kamera und Medienbibliothek:

Ein Benutzer klickt auf 'Bild 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 das Ablehnen oder die Abbrechen ohne das Bildschirm zu zerstören, und geben Sie einen verwendbaren lokalen Dateireferenz für Vorschau 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 OS-Anfragen, Gerätehardware und wie Ihre native Berechtigungen zuvor konfiguriert wurden.

Ein minimaler aber sicherer Komponente

Die Kernströmung ist in beiden Expo-gesteuerten und bare-Workflow-Projekten konsistent. Stellen Sie die relevanten Berechtigungen an, starten Sie den Picker, überprüfen Sie, ob der Benutzer abgebrochen hat, und lesen Sie dann das erste Asset von result.assets.

Ein Baseline-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.

• Bitten Sie um die Bibliothek- und Kamera-Berechtigungen getrennt. Sie scheitern unabhängig voneinander.
• Behandeln Sie die Abbruchmeldung als normale Benutzeraktion und nicht als Fehlerzustand.
• Aus assets[0], weil der Picker eine Asset-Array zurückgibt und nicht ein top-level uri.

Bibliothek- und Kamera-Flüsse

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

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

Ein sauberes UI-Muster besteht darin, dem Benutzer vor dem Aufrufen des Pickers API nach der Quelle zu fragen:

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

Diese Trennung hält jede Funktion konzentriert. Es macht es auch einfacher, Analytics, Feature-Flags oder backend-spezifische Regeln später hinzuzufügen. Zum Beispiel ermöglichen einige Teams die Bibliothek-Uploads für Profilbilder, aber erfordern frische Kamera-Aufnahmen für die Identitätsprüfung.

If your broader app also supports file access patterns outside Expo or you are comparing conventions across native stacks, this Capacitor Fotobibliothek ist nützlich im Kontext.

Eine kurze Demo hilft, wenn Sie diese Flussanzeige Ihren Teamkollegen oder QA vorstellen möchten:

Was Sie von der System-UI erwarten können

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

Auf iOS können Benutzer begrenzten Bibliothekszugriff statt vollem Zugriff gewähren. Auf Android kann sich das Verhalten des Pickers je nach Betriebssystemversion und Händlerhaut unterscheiden. 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-Anrufoption kann in beiden Fällen identisch sein, während das Laufzeitergebnis sich unterscheidet.

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

• erste Berechtigungsanfrage
• abgelehnte Berechtigung
• Benutzerkündigung
• erfolgreiche Bibliotheksanwahl
• 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, ein Moderationspipeline oder einen Veröffentlichungs-Endpunkt wie den Instagram-Medien-Veröffentlichungs-API.

Umgang mit Picker-Ergebnissen und Optionen

Das Picker-Ergebnis ist der Teil, der normalerweise realen Produktionslogik bedarf. Die System-UI gibt ein strukturiertes Objekt zurück, nicht nur einen Dateipfad, und kleine Fehler hier führen zu gebrochenen Vorschauen, leeren Uploads oder Abstürzen nach einem Benutzer-Stornieren.

Lesen Sie das Ergebnisobjekt richtig

Die Ergebnisform, die in aktuellen Expo-Anwendungen relevant ist result.assets[0].uri, ist kein oberster result.uri. Diese Details wirken sich sowohl auf verwaltete als auch auf bare Workflow-Projekte aus, da der JavaScript-API gleich bleibt, obwohl die native Setup unterschiedlich ist.

Verwenden Sie ein Wächter-Vorlagenmuster:

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

Dies handhabt die beiden häufigsten Fehlerfallen, die ich sehe. Ein abgebrochener Picker gibt Ihnen kein Asset zum Lesen, und code das annehmen 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 das Erstellen eines sauberen multipart-Anforderung. fileSize Optionen, die die Abhängigkeit der Ausführung beeinflussen

Einige Auswahlmöglichkeiten des Pickers beeinflussen mehr als nur die Auswahlseite. 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 Bildslot 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 den Server-Speicher. quality: 1 ist nicht automatisch die richtige Wahl.
• mediaTypes sollte sich an den Backend-Regeln anpassen. Wenn der Server Videos ablehnt, lassen Sie den Picker sie nicht zurückgeben.
• base64 erhöht die Payload-Größe im Speicher. Verwenden Sie es nur, wenn der Empfangsdienst es erfordert.

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 einer Dateireferenz teuer.

URI gegenüber Base64

Für die meisten Apps ist die Regel einfach:

• Verwenden URI für Vorschauen.
• Werden Sie URI zur Dateiübertragung verwenden.
• Werden Sie base64 nur dann verwenden, wenn das empfangende System explizit nach kodiertem Inhalt fragt.

Dieses Muster hält den Picker code klein und leichter zu testen. Es passt auch zu der Art, wie viele Backend-Medien-Flüsse erstellt werden, einschließlich Diensten, die letztendlich auf externe Plattformen wie dem Instagram-MedienveröffentlichungsAPI.

Wenn Ihr Team häufig OTA-Updates bereitstellt oder Bildschwerpunkte über die App-Delivery bewegt, haben Entscheidungen über Dateigröße hier Auswirkungen auf den Rest des Pipelines. Diese Anleitung zum Optimieren von Bildern für App-Updates ist ein nützliches Begleitwerk zur Picker-Konfiguration.

Ein sichereres Ergebnismuster für echte Apps

Für Demo code, wird nur gespeichert imageUri Ist in der Produktion ein normalisierter Objekt speichern, so dass der nächste Schritt, Vorschau, Validierung, Upload oder 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,
});

Das gibt dir eine vorhersehbare Form innerhalb der App. Es macht auch verwaltete und bare Projekte einfacher, sich zu verbinden, da die App code stabil bleibt, während Sie durch native Unterschiede arbeiten.

Ein letzter Check hilft. Aktiviere keine zusätzlichen Ergebnisfelder nur aus Sicherheitsgründen. Fordere die Daten, die du benötigst, und halte den Picker auf die Auswahl konzentriert, anstatt ihn in einen allgemeinen Dateiverarbeitungsschritt umzuwandeln.

Erweiterte Muster und Plattformunterschiede

Ein Picker-Funktion wird normalerweise nicht mehr einfach, wenn die erste ausgewählte Bild das Überleben von Wiederholungen, Auth-Header, native Berechtigungsdifferenzen und einem realen Upload-Endpunkt überleben muss. expo-image-picker erledigt die Auswahl gut. Der Rest der Funktion liegt bei deiner App.

Ein praktisches Upload-Muster

Für APIs, die ein Dateiupload erwarten, FormData ist immer noch der sichere Standard. Es funktioniert über gemeinsame Rails, Node, Laravel, Django und Go-Backends und hält den Picker von Transport-Bedürfnissen 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();
}

Das code reicht aus, um den Weg zu beweisen, aber Produktionsanwendungen benötigen normalerweise einen zusätzlichen Schritt. Ableiten Sie es name And verwenden Sie Auth, wenn möglich, außerhalb der Picker-Funktion, und halten Sie den Upload-Zustand getrennt vom Picker-Zustand, damit ein fehlgeschlagener Anfrage den Benutzer nicht zwingt, das Bibliothek neu zu öffnen. type Eine Handvoll Überprüfungen verhindern die häufigsten Fehler, die ich in der Überprüfung sehe:

Bestätigen Sie die lokale

• Existiert vor der Erstellung der Anfrage uri Eine Vorschau rendern, bevor Sie hochladen, damit die Benutzer frühzeitig erkennen, dass sie das falsche Datei ausgewählt haben
• Verhindern Sie wiederholte Tasten, während die Anfrage im Flug ist
• Netzwerkfehler separat von Picker-Stornierung oder Berechtigungsfehlern behandeln
• Erwarten Sie, 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 eine 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 zählen

Die Picker-UI ist native, also erbt sie native Verhaltensweisen. Das wirkt sich sowohl auf das, was die Benutzer sehen, als auch auf das, was Ihr __CAPGO_KEEP_0__ annehmen sollte.

The picker UI is native, so it inherits native behavior. That affects both what users see and what your code should assume.

On iOS folgen die Bearbeitungsflüsse und die Ermessigungsanfragen den Konventionen von Apple. Der Zugriff auf Fotos kann auf iOS eine eingeschränktere Menge an Assets zurückgeben als Ihr Testkonto auf einem vollständig genehmigten Gerät sah. Auf Android variiert die Verhaltensweise der Picker mehr je nach Betriebssystemversion und Herstellerhaut, insbesondere um Alben, Dateinamen und wie Kameraaufnahmen zurückgegeben werden. Bare React Native-Anwendungen spüren diese Unterschiede direkt mehr, weil Sie mehr vom native Setup besitzen, aber verwaltete Expo-Anwendungen benötigen code , das den Picker als plattformgeformt anstatt als perfekt gleichmäßig behandelt.

Die praktische Regel ist einfach. Verlassen Sie sich auf die Felder, die Sie validieren können, 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
• Zurückgegebene Metadaten: fileName, mimeType, und fileSize können fehlen oder unkonistent sein, daher sollten Sie Ersatzmöglichkeiten hinzufügen
• Ermessigungen: Der Zugriff auf Fotos auf iOS kann 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

If Ihr Team auch außerhalb von Expo arbeitet, ist dies Entwicklerhandbuch für DesignStack-Anwendungen Dies gibt nützliche Kontextinformationen für die Medienverwaltung auf Android, 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 unterstützten Workflow leben die Berechtigungszeichen und Plugin-Konfigurationen in der Anwendungs-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 keine fehlenden native Berechtigungen.

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.

Troubleshooting Common Issues

Die meisten Expo Image Picker-Fehler fallen in eine kleine Anzahl von Kategorien. Der schnellste Fix ist meistens, die fehlende Schicht zu identifizieren: 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 geschlossen hat abstürzt, überprüfen Sie Ihre Ergebnisbearbeitung. Viele Implementierungen nehmen an, dass es sich um eine direkte URI handelt und überspringen die Überprüfung. canceled Einige schnelle Zuweisungen helfen:

Berechtigungsfehler:

• Überprüfen Sie Ihre App-Konfiguration und native Berechtigungszeichenfolgen, dann neu erstellen. image-URI:
• undefined Lesen Sie von , nicht result.assets?.[0]?.uri, not result.uri.
• Nichts passiert nach Abbruch: Das mag korrekt sein. Abbruch als Zustand ohne Aktion behandeln.
• Bild wird nicht angezeigt: Bestätige, dass die URI im Zustand gespeichert und in <Image source={{ uri }} />.
• Kamera verhält sich seltsam im Simulator: Testen Sie auf einem physischen Gerät, bevor Sie sich um eine Bibliotheksfehler kümmern.

Kurzlehrplan für die Produktion

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

• Installieren Sie mit Expo-Tooling: Verwenden Sie npx expo install expo-image-picker.
• Konfigurieren Sie native Teile: Fügen Sie die Plugin- und erforderliche Berechtigungsbeschreibungen hinzu.
• Request permissions absichtlich: Trennen Sie die Kameralaufnahmen- und Medienbibliothek-Flüsse.
• Schützen Sie jeden Ergebnis: Überprüfen result.canceled und sicher lesen assets[0].
• Präferieren Sie URI-basierte Uploads: Behalten Sie Base64 nur für besondere Fälle bei.
• Testen Sie echte Geräte: Besonders für die Kameralaufnahmen und die Berechtigungsanfragen.

Wenn Ihr Team Capacitor oder Electron-Apps neben React Native-Projekten ausliefern möchte, 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 in Ihrer Web-Schicht leben, wie z.B. Upload-UI, Validierungsregeln, Kopien oder Asset-Verwaltung um den Picker-Flow herum.