Expo Bildauswahl: Eine umfassende Anleitung für 2026

Sie sind wahrscheinlich an dem Punkt, an dem die Benutzeroberfläche fertig ist, die Profilseite einen "Bild hochladen"-Button hat und jetzt plötzlich das einfache 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.

Dass ist, wo Expo Bildauswahl passt. Es ist die offizielle Expo-Bibliothek für die Öffnung der System-UI, um Bilder und Videos aus der Gerätebibliothek auszuwählen oder eine Fotografie mit der Kamera zu machen, wie in der Expo Paket-Repositorybeschrieben. In der Praxis bedeutet das, dass Sie eine zuverlässige Brücke in die native Medien-Eingabe erhalten, aber nicht eine benutzerdefinierte Medien-Erfahrung, 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, Berechtigungs-Handling, das nicht Sie überraschen wird, sichere Ergebnis-Interpretation und ein praktisches Upload-Muster nachdem der Benutzer ein Datei ausgewählt hat. Wenn Sie in einem benutzerdefinierten native Setup arbeiten, hilft es auch, zu verstehen, wie sich dies von einem Expo Entwicklungsklient-Workflow.

unterscheidet. Inhaltsverzeichnis

• Einstieg in Expo Bildauswahl
• Installation und grundlegende Konfiguration
  • Verwaltetes Workflow-Setup
  • Bare React Native Setup-Daten
• Zugriff auf die Kamera und die Medienbibliothek
  • Ein minimaler aber sicherer Komponent
  • Bibliothek und Kamera-Flüsse
  • Was Sie von der System-UI erwarten können
• Behandlung von Picker-Ergebnissen und Optionen
  • Lesen Sie den Ergebnisobjekt richtig
  • Optionen, die das Downstream-Verhalten ändern
  • URI gegenüber base64
  • Ein sichereres Ergebnispattern für echte Apps
• Erweiterte Muster und Plattformunterschiede
  • Ein praktischer Uploadmuster
  • Wo Plattformunterschiede tatsächlich zählen
  • Verwaltet vs. bare Workflowunterschiede
• Fehlersuche bei gängigen Problemen
  • Schnelle Überprüfungen für gängige Fehler
  • Ein kurzer Produktionscheckliste

Einstieg in Expo Image Picker

Ein Produktmanager bittet um Profilbilder. Eine Woche später benötigt das gleiche Feature auch die Uploads von Rechnungen, die Kamerafunktion für Vorfälle und Wiederholungen, wenn die Benutzer die Erlaubnis zum ersten Mal ablehnen. Die Bildauswahl erweitert sich schnell, weil sie native Berechtigungen, OS-eigene UI, temporäre Dateimanagement und Backend-Upload-Flows berührt.

expo-image-picker ist das Expo SDK-Modul dafür zuständig. Es öffnet den Plattformpicker oder die Kamera-UI und gibt die ausgewählte Medien in einer Form zurück, die Ihr React Native code-Projekt verarbeiten kann. Die JavaScript- API ist klein. Der Hauptwettbewerb liegt darin, die native Einrichtung, die Berechtigungsabläufe und die Ergebnisverwaltung auf beiden verwalteten und bare Projekten richtig zu machen.

Der Hauptwettbewerb ist eindeutig. Sie lassen iOS und Android ihre eigenen Medien-UI präsentieren, anstatt eine benutzerdefinierte Picker zu bauen. Das gibt in der Regel ein besseres Ergebnis: Die Benutzer verstehen die Systemeinstellungen bereits, die Berechtigungsanfragen 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-Oberfläche.

Diese Einstellung hilft, weil die Fehlermodi selten in der Schaltfläche liegen, die den Picker aufruft. Sie kommen normalerweise aus einer der folgenden drei Quellen:

• Native-Konfiguration: fehlende Plugin-Einstellungen, falsche Berechtigungssätze oder ein veraltetes Build nach einer Änderung der Konfiguration
• Laufzeitverhalten: Benutzer können den Zugriff ablehnen, auf iOS nur begrenzten Zugriff auf Bibliotheken gewähren oder den Ablauf ohne Auswahl abbrechen
• Erfolgsergebnis-Verarbeitung: der aktuelle API gibt ein assets Array zurück, sodass ältere Beispiele, die direkt lesen result.uri direkt fehlschlagen

Die Wahl des Workflows ändert auch den Setup-Weg. In einem verwalteten Expo-App leben die meisten native Arbeiten in der App-Konfiguration und erfordern einen Neubau, wenn sich diese Konfiguration ändert. In einer Bare-App erhalten Sie den Expo-Modul API noch immer, müssen aber die zugrunde liegenden iOS- und Android-Projekt-Einstellungen direkt überprüfen. Wenn Ihr Team einen eigenen Client verwendet, anstatt Expo Go, passt sich diese Anleitung gut mit Capgo’s Erklärung von wie sich ein Expo-Entwicklungsklient auf die native Modulprüfung auswirkt.

That spaltet sich für den Rest der Anleitung, weil der glückliche Weg nur die Hälfte der Geschichte ist. Eine Picker-Implementierung ist solide, wenn sie in beiden Workflows funktioniert, Plattform-spezifische Berechtigungs-Quirks ohne Überraschung des Benutzers handhabt und einen verwendbaren Datei an Ihre Upload-Schicht übermittelt, anstatt bei einer lokalen Vorschau zu stoppen.

Installation und wesentliche Konfiguration

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

expo-image-picker bietet eine React-freundliche API über die Plattform-Picker für Fotos, Videos und Kamera-Aufnahmen. Die JavaScript-Anrufer ist einfach. Die Einrichtung ist jedoch nicht, weil der Zugriff auf Fotos und die Kamera-Aufnahmen von iOS und Android kontrolliert werden und nicht von React Native.

Beginnen Sie mit Expo’s version-aware-Installer:

npx expo install expo-image-picker

Verwenden Sie expo install anstatt npm install oder yarn add. Expo passt die Paketversion an Ihre SDK, was eine häufige Klasse von Problemen mit der nativen Kompatibilität vermeidet. Wenn Sie vergleichen, wie Expo-Module in Ihren Release-Prozess passen, ist dies Übersicht über Expo-Tools ein nützlicher Referenzpunkt.

Verwaltetes Workflow-Einrichten

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

Beispiel mit app.json:

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

Das ist die Mindestkonfiguration. In der Praxis fügen Teams üblicherweise auch eine Erlaubnis-Text hinzugefügt, 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 an pluginsErlaubnis-Strings 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 enthaltenen Client-Elemente eingeschränkt. In einem Entwicklungsbuild oder Produktionsbuild spiegelt sich die native Projekt nur nach einem neuen Build Ihre Konfiguration wider.

Details zur Einrichtung von Bare React Native

In einer Bare-Anwendung ist der Paket API derselbe, aber Sie müssen mehrere native Projekt-Elemente selbst überprüfen. Die iOS-Benutzungsbeschreibungen sind das erste, was Sie überprüfen sollten. Wenn Ihr Workflow die Bibliothek öffnen, die Kamera starten oder Video mit Audio aufnehmen kann, benötigt Ihre App die entsprechenden Erlaubnis-Strings in Info.plist vor dem Neubau.

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. Rebauen Sie die iOS- und Android-Apps nach jeder Änderung der nativen Konfiguration.

Der Text für die fehlenden 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 Ausführungsstapel. Ich überprüfe normalerweise Info.plist, die App-Konfiguration und ob die aktuelle Build die neuesten nativen Änderungen enthält, bevor ich den Komponenten code zuwende.

Einige Gewohnheiten machen die Einrichtung vorhersehbarer:

• Schreiben Sie den Berechtigungstext für die tatsächliche Aktion: Benutzer sollten verstehen, warum sie den Hinweis sehen.
• Konfigurieren Sie Kamera und Bibliothek separat: Einer kann funktionieren, während der andere noch scheitert.
• Rebauen Sie nach nativen Änderungen: Hot Reload und Fast Refresh aktualisieren die nativen Berechtigungen nicht.
• Gerät testen: Das Verhalten des Simulators kann Probleme mit der Erlaubnis und der Kamera verbergen.

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

Zugriff auf die Kamera und die Medienbibliothek

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

Das klingt einfach, bis man sowohl die verwalteten als auch die bare Builds auf iOS und Android testet. 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 vorher konfiguriert wurden.

Ein minimaler aber sicherer Komponente

Der Kernfluss ist konsistent in beiden Expo-verwalteten und bare Workflow-Projekten. Fordern Sie die relevanten Berechtigungen an, starten Sie den Picker, überprüfen Sie, ob der Benutzer abgebrochen hat, und lesen Sie dann das erste Asset aus 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.

• Fordern Sie die Bibliothek- und Kamera-Berechtigungen separat an. Sie scheitern unabhängig voneinander.
• Treiben Sie die Stornierung als normales Benutzerhandeln und nicht als Fehlerzustand.
• aus assets[0], weil der Picker eine Asset-Array zurückgibt und nicht ein oberstes Niveau uri.

Bibliothek und Kamera-Flüsse

Beginnen Sie mit dem Bibliotheksfluss, wenn Sie den schnellsten Weg zu einem funktionierenden Feature wollen. Es ist einfacher zu testen, es funktioniert in mehreren Simulator-Setups und es umgeht Kamera-Hardware-Randfälle. Fügen Sie Kamera-Funktionen einmal, wenn der Ergebnis-Handling-Path stabil ist.

Der Kamera-Path hat mehr Möglichkeiten, in der Entwicklung zu scheitern. Die iOS-Simulator-Unterstützung ist begrenzt. Android-Emulatoren mögen die Kamera-Behavior nicht so ausgeben, wie es ein echter Gerät tut. In bare Projekten können diese Lücken Sie dazu bringen, auf einen Komponenten code zu schauen, obwohl das tatsächliche Problem eine native Konfiguration oder ein Testumgebung ist.

Ein sauberes UI-Muster besteht darin, dem Benutzer vor dem Aufruf 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 auf dem Laufenden. Es macht es auch einfacher, Analytics, Feature-Flags oder backend-spezifische Regeln später hinzuzufügen. Zum Beispiel erlauben einige Teams die Bibliothek-Aufnahmen für Profilbilder, aber verlangen frische Kamera-Aufnahmen für Identitätsprüfungen.

Wenn Ihr breiteres App auch Dateizugriffs-Muster außerhalb von Expo unterstützt oder Sie Vergleiche zwischen Konventionen über native Stacks anstellen, ist Capacitor Foto-Bibliothek-Referenz nützlich im Kontext.

Ein kurzer Demo hilft, wenn Sie dieses Fluss Ihren Teamkollegen oder QA zeigen möchten:

What kannst du von der System-Oberfläche erwarten

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

Bei iOS können Benutzer begrenzten Zugriff auf Bibliotheken gewähren anstatt volle Zugriff. Bei Android kann sich das Verhalten des Pickers je nach Betriebssystemversion und -Haut ändern. In Projekten mit verwaltetem Workflow handhabt Expo mehr der nativen Verdrahtung für dich. In Projekten mit barem Workflow musst du bestätigen, dass deine gebaute App die nativen Berechtigungsänderungen enthält, die du vorgenommen hast. Die JavaScript-Anrufrichtung 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
• Benutzerstornierung
• erfolgreiche Bibliotheksverwaltung
• erfolgreiche Kamerafunktion auf einem physischen Gerät
• unmittelbare Vorschau des zurückgegebenen lokalen URI

Diese Fälle entsprechen direkt der realen Produktionsverhalten. Sie setzen auch den nächsten Schritt sauber auf, wenn du das Datei an einen Server, einen Moderationspipeline oder ein Veröffentlichungsziel wie das Instagram-Medienveröffentlichungs API.

Umgang mit Picker-Ergebnissen und -Optionen

Das Picker-Ergebnis ist der Teil, der in der Regel echte Produktionslogik benötigt. 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 Benutzerabbruch.

Das Ergebnisobjekt richtig lesen

Die Ergebnisform, die in aktuellen Expo-Anwendungen relevant ist, ist result.assets[0].uri, nicht ein top-level result.uri. Diese Details wirken sich auf beide verwalteten und bare Workflow-Projekte aus, da der JavaScript API gleich bleibt, obwohl die native Setup unterschiedlich ist.

Verwende einen Wächter-Muster:

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 Fehlerfall-Szenarien. Ein abgebrochener Picker gibt kein Asset zum Lesen, und code, das immer existiert, wird bei Laufzeit fehlschlagen. result.assets[0] Sobald Sie die URI haben, ist die Vorschau-Renderung unkompliziert:

Wenn Sie später hochladen planen, behalten Sie das ganze

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

Objekt bei sich, nicht nur die URI. In der Praxis asset Umgang mit Picker-Ergebnissen und -Optionen fileName, mimeType, width, heightund fileSize sind oft nützlich für die Validierung, Protokollierung oder die Erstellung einer sauberen multipart-Anfrage.

Optionen, die die Abhängigkeit beeinflussen

Eine Handvoll Auswahlmöglichkeiten beeinflussen mehr als die Auswahlseite. Sie prägen Dateigröße, Bearbeitungsverhalten und was Ihr Backend akzeptieren muss.

Einige Kompromisse sind leicht zu übersehen:

• allowsEditing wird nützlich, wenn das Bildfeld eine fixe Form oder Größe hat. Es ist weniger nützlich, wenn Ihr Server seinen eigenen Crop-Pipeline durchführt und Sie das Originalfile wollen.
• quality beeinflusst die Uploadzeit, den Speicherdruck und den Serverspeicher. quality: 1 ist nicht automatisch die richtige Wahl.
• mediaTypes soll sich an die Regeln des Servers anpassen. Wenn der Server Videos ablehnt, lassen Sie den Picker sie nicht zurückgeben.
• base64 vergrößert die Größe des Payloads im Speicher. Verwenden Sie es nur, wenn der empfangende Service 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 eines Dateireferenz teuer.

URI gegenüber Base64

Für die meisten Apps ist die Regel einfach:

• Verwenden URI für Vorschauen.
• Verwenden URI für Datei-Uploads.
• Verwenden base64 Nur dann, wenn das empfangende System explizit nach kodiertem Inhalt fragt.

Das Muster hält den Picker code klein und leicht zu testen. Es passt auch mit der Bauweise vieler Backend-Medien-Flüsse überein, einschließlich Diensten, die letztendlich auf externe Plattformen wie dem Instagram-Medien-Publishing-API.

Wenn Ihr Team häufig OTA-Updates bereitstellt oder Bildschirm-Lasten durch App-Delivery bewegt, haben Entscheidungen über Dateigröße hier Auswirkungen auf den Rest der Pipeline. Diese Anleitung zu Optimierung 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 ist es in Ordnung, nur imageUri zu speichern. In der Produktion sollten Sie ein normalisiertes Objekt speichern, damit der nächste Schritt, die Voransicht, die Validierung, das Hochladen oder die Wiederholung, nicht jedes Mal die Rohdaten des Picker-Antwortes neu 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 Ihnen eine vorhersehbare Form innerhalb der App. Es macht auch managed und bare Projekte einfacher, sie im Einklang zu halten, weil die App-code stabil bleibt, während Sie sich mit den nativen Unterschieden anderweitig auseinandersetzen.

Eine letzte Überprüfung hilft. Aktivieren Sie nicht extra Ergebnisfelder nur aus Vorsicht. Fordern Sie die Daten ab, die Sie benötigen, und halten Sie den Picker auf Auswahl fokussiert, anstatt ihn in einen allgemeinen Dateiverarbeitungsschritt umzuwandeln.

Erweiterte Muster und Plattformunterschiede

Ein Picker-Funktion wird normalerweise nicht einfach, wenn die erste ausgewählte Bilddatei Wiederholungen, Auth-Header, native Berechtigungsunterschiede und eine echte Upload-Endpunkt überstehen muss. expo-image-picker handhabt die Auswahl gut. Der Rest der Funktion liegt bei Ihrer App.

Ein praktisches Upload-Muster

Für APIs, die eine Dateiupload erwarten, FormData ist immer noch der sicherste Standard. Es 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();
}

Das code reicht aus, um den Weg zu beweisen, aber Produktionsanwendungen benötigen normalerweise einen zusätzlichen Schutz. Ableiten name und type aus der ausgewählten Asset, wenn möglich, Auth außerhalb der Picker-Funktion anhängen und den Upload-Zustand getrennt von Picker-Zustand halten, damit ein fehlgeschlagener Antrag den Benutzer nicht zwingt, die Bibliothek neu zu öffnen.

Eine paar Überprüfungen verhindern die häufigen Fehler, die ich in der Überprüfung sehe:

• Bestätigen Sie die lokale Datei uri existiert vor der Erstellung der Anfrage
• Erstelle einen Vorschaubildschirm vor dem Upload, damit die Benutzer frühzeitig erkennen, dass sie das falsche Datei ausgewählt haben
• Verhindere wiederholte Tastenanschläge, während die Anfrage im Flug ist
• Behandle Netzwerkfehler separat von der Abbruch des Pickers oder Authentifizierungsfehlern
• 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 eine Serverbeschränkung und nicht eine Pickeranforderung. Multipart ist günstiger in Bezug auf 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 das, 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 sind in realen Apps relevant:

• Bearbeitung und Kropping: Die Benutzeroberfläche und das Kornverhalten sind zwischen iOS und Android nicht identisch
• Gespeicherte Metadaten: fileName, mimeTypekann fehlen oder unkonistent sein, daher fügen Sie Fallbacks hinzu fileSize Zugriffsrechte:
• Die Zugriffsrechte auf Fotos auf iOS können auf bestimmte Artikel beschränkt werden, während die Android-Verhalten mehr von der Betriebssystemversion und der Unterstützung des Systempickers abhängt Kameraausgabe:
• Gefangene Bilder können mit unterschiedlichen Namen, Orientierung oder Kompressionsmerkmalen als Bibliotheksassets zurückkehren Wenn Ihr Team auch außerhalb von Expo arbeitet, gibt es

Die DesignStack-Entwickleranleitung für Apps bietet wertvolle Android-Kontext für Entscheidungen zum Medienhandling, die außerhalb einer einzelnen Bibliothek auftreten. Verwaltetes vs. Bare-Workflow-Unterschiede

__CAPGO_KEEP_0__

At diesem Punkt beginnen die Setup-Optionen operativ zu zählen.

In der verwalteten Workflow-Option leben die Berechtigungsstrings und Plugin-Konfigurationen normalerweise im App-Konfiguration, und native Änderungen werden bei der Erstellung eines neuen Builds 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 wird. OTA-Updates patchen keine fehlenden native Berechtigungen.

In der bare Workflow-Option 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-Issue möglicherweise durch native Konfiguration und nicht durch die JavaScript-Anruferstelle verursacht wird.

Teams, die zwischen Expo und Capacitor hin- und herswitchen, 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 einmalig, laden Sie es über eine dedizierte __CAPGO_KEEP_1__-Layer hoch und behandeln Sie plattform-spezifische Verhaltensweisen als etwas, das konfiguriert und explizit getestet werden muss, 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.

Die meisten Expo Image Picker-Bugs fallen in eine kleine Anzahl von Kategorien. Der schnellste Fix ist normalerweise, zu identifizieren, welcher Layer fehlschlägt: Konfiguration, Berechtigung, Ergebnis-Handling oder Rendering.

__CAPGO_KEEP_0__ handles platform differences how __CAPGO_KEEP_1__ has a useful explanation of

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 Fall von bare Apps fehlen iOS-Benutzungsbeschreibungen oft als häufige Ursache.

Wenn das App nachdem ein Benutzer den Picker schließt abstürzt, überprüfen Sie Ihre Ergebnishandling. Viele Implementierungen nehmen an, dass eine direkte URI vorhanden ist und die Überprüfung daher überspringen. canceled Eine paar schnelle Mappings helfen:

Zugriffsverweigerung-Fehler:

• Überprüfen Sie Ihre App-Konfiguration und native Berechtigungszeichenfolgen, dann neu erstellen. Bild-URI:
• undefined Aus , nicht result.assets?.[0]?.uriNach dem Abbrechen passiert nichts: result.uri.
• __CAPGO_KEEP_0__ Das mag korrekt sein. Abbrechen als no-op-Zustand behandeln.
• Die Bildrenderung funktioniert nicht: 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 eine Bibliotheksfehlerjagd einlassen, testen Sie auf einem physischen Gerät.

Kurzlehrbuch für die Produktion

Verwenden Sie dies als letzter Durchlauf 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.
• Genehmigungen absichtlich anfordern: Trennen Sie die Kameralaufnahmen- und Medienbibliothek-Flüsse.
• Schützen Sie jeden Ergebnis: Überprüfen result.canceled und lesen Sie sicher 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 Kameraaufnahmen und die Ermächtigungsanfragen.

Wenn Ihr Team Capacitor oder Electron-Apps neben React Native-Projekten ausliefert, Capgo ist eine Option, um JavaScript, CSS, Konfiguration und Asset-Updates ohne auf jede Änderung warten zu müssen, wenn sie im Store-Bereich überprüft werden müssen. Es ist relevant, wenn bei der Bildbearbeitung im Weblayer Änderungen vorgenommen werden, wie z.B. Upload-UI, Validierungsregeln, Kopien oder Asset-Verwaltung im Picker-Flow.