Expo Bildauswahl: Eine umfassende Anleitung für 2026

Sie sind wahrscheinlich an dem Punkt, an dem die Benutzeroberfläche fertig ist, das Profilbildschirm hat einen "Bild hochladen"-Button und jetzt ist das Leichtgewicht plötzlich nicht mehr leicht. Die tatsächliche Bildauswahl-Fluss berührt native Berechtigungen, OS-kontrollierte Schnittstellen, verschiedene Rückgabeformen als viele Entwickler erwarten und eine Handvoll Build-Zeit-Details, die nur 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-Benutzeroberflä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 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 und nicht für die Demo. Sie konzentriert sich auf die Entscheidungen, die in der Produktion relevant sind: Einrichtung des verwalteten oder nackten Workflows, Handhabung der Berechtigungen, die Sie später nicht überraschen werden, sichere Ergebnisinterpretation und ein praktischer Uploadmuster nachdem der Benutzer ein Datei ausgewählt hat. Expo-Entwicklungsklient-Workflow.

Inhaltsübersicht

• Einführung in Expo Bildauswahl
• Installation und grundlegende Konfiguration
  • Einrichtung des verwalteten Workflows
  • Details zur Einrichtung des nackten React Native-Workflows
• Zugriff auf die Kamera und die Medienbibliothek
  • Ein minimaler aber sicherer Komponente
  • Bibliothek und Kamera-Flows
  • Was Sie von der System-UI erwarten können
• 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ächlich die Plattformunterschiede bemerkbar machen
  • Verwaltungsbetrieb gegenüber Bare-Workflow-Unterschiede
• Häufige Probleme lösen
  • Schnelle Überprüfungen für häufige Fehler
  • Ein kurzer Produktionscheckliste

Mit Expo Bildwähler beginnen

Eine Produktmanagerin bittet um Profilbilder. Eine Woche später benötigt dieselbe Funktion auch die Hochladen von Rechnungen, die Kamerafunktion für Vorfallberichte und Wiederholungen, wenn Benutzer die erste Zeit die Erlaubnis verweigern. Die Bildauswahl erweitert sich schnell, weil sie native Berechtigungen, Betriebssystemeigene UI, temporäre Datei-Verwaltung und Hintergrund-Upload-Flüsse berührt.

expo-image-picker ist der Expo SDK-Modul für diese Aufgabe. Es öffnet die Plattform-Wähler 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 Konfiguration, die Berechtigungsabläufe und die Ergebnisverwaltung auf beiden verwalteten und freien Projekten richtig zu bekommen.

Die Hauptentscheidung ist einfach. Sie lassen iOS und Android ihre eigenen Medien-UI präsentieren, anstatt eine benutzerdefinierte Wähler zu bauen. Das gibt normalerweise ein besseres Ergebnis: Die Benutzer verstehen die Systemeinstellungen bereits, die Berechtigungsanfragen verhalten sich wie die Betriebssysteme erwarten, und Ihr Team vermeidet die Wartung einer Galerieimplementierung in JavaScript.

Behandeln Sie dies als eine native Integration mit einer React-Oberfläche.

Dieser Ansatz hilft, weil die Fehlerquellen selten in der Schaltfläche liegen, die den Bildwähler aufruft. Sie kommen normalerweise aus einem der drei Orte:

• Native Konfiguration: fehlende Plugin-Konfiguration, falsche Berechtigungsstrings oder ein veralteter Build nach einer Änderung der Konfiguration
• Laufzeitverhalten: Benutzer können den Zugriff verweigern, auf iOS nur begrenzte Bibliotheksrechte gewähren oder den Ablauf ohne Auswahl abbrechen
• Ergebnisinterpretation: Die aktuelle API gibt ein assets array, damit ältere Beispiele, die direkt result.uri versagen

Die Wahl des Workflows ändert auch den Pfad der Einrichtung. 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, aber Sie müssen die zugrunde liegenden iOS- und Android-Projekt-Einstellungen direkt überprüfen. Wenn Ihr Team ein benutzerdefiniertes Client-Tool verwendet, anstatt Expo Go, passt diese Anleitung gut mit Capgo’s Erklärung von wie ein Expo-Entwicklungsclient die native Modulprüfung beeinflusst.

Das getrennte Ergebnis ist für den Rest der Anleitung wichtig, 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 die 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 Entwicklungsclient 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-Anweisung ist einfach. Die Einrichtung ist jedoch nicht, weil der Zugriff auf Fotos und die Kamera 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 addExpo passt die Paketversion mit Ihrem SDK überein, was eine häufige Klasse von Problemen mit der nativen Kompatibilität vermeidet. Wenn Sie vergleichen, wie Expo-Module in Ihrem Release-Prozess passen, ist dies Übersicht über Expo-Tools 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"]
  }
}

Das ist die Mindestkonfiguration. In der Praxis fügen Teams üblicherweise auch Erlaubnis-Text hinzu, insbesondere auf iOS, wo der Systemanzeige erklären soll, warum die App Zugriff benötigt. Halten Sie die Wortwahl spezifisch für die Benutzeraktion. 'Ein Profilbild hochladen' ist besser als 'Braucht Medienzugriff'.

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 im Client enthaltenen Funktionen 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

Im Bare-App ist das Paket API gleich, aber Sie müssen mehrere Teile des nativen Projekts 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 Erlaubnis-Strings 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 nach jeder native Konfigurationsänderung neu.

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 Stacks. Ich überprüfe normalerweise Info.plist, die App-Konfiguration und ob die aktuelle Build die neuesten native Änderungen enthält, bevor ich an den Komponenten code herangehe.

Einige Gewohnheiten machen die Einrichtung vorhersehbarer:

• Schreiben Sie den Text für die tatsächliche Aktion: Die 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-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 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 auf iOS und Android testen. Der JavaScript API bleibt kompakt, aber die Laufzeitverhalten hängt immer noch von den OS-Anfragen, dem Gerätehardware und wie Ihre native Berechtigungen zuvor konfiguriert wurden.

Ein minimaler aber sicherer Komponenten

Der Kernfluss 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 __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 Bibliotheks- und Kamera-Berechtigungen separat an. Sie scheitern unabhängig voneinander.
• Behandeln Sie die Abbruchaktion als normale Benutzeraktion und nicht als Fehlerzustand.
• Lesen Sie aus __CAPGO_KEEP_0__, weil der Picker eine Asset-Array zurückgibt und nicht ein oberstes __CAPGO_KEEP_0__ assets[0]Bibliothek und Kamera-Flüsse uri.

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

Der Kamera-Fluss 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 offenlegen, wie es ein echter Gerät tut. In bare-Projekten können diese Lücken Sie dazu bringen, sich die Komponente __CAPGO_KEEP_0__ anzusehen, obwohl das tatsächliche Problem in der native Konfiguration oder der Testumgebung liegt.

Eine saubere UI-Muster ist es, den Benutzer um die Quelle zu bitten, bevor man den Picker code aufruft:

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

Bibliothek und Kamera-Flüsse

Wenn Ihr breiteres App auch Dateizugriffsverhaltensmuster außerhalb von Expo unterstützt oder Sie Konventionen zwischen nativen Stapeln vergleichen, ist dies Capacitor Fotobibliotheksreferenz ist nützlicher Kontext.

Ein kurzer Demo hilft, wenn Sie dieses Flow Ihren Teamkollegen oder QA zeigen:

Was Sie von der System-UI erwarten

expo-image-picker Öffnet die Plattform- oder Kamera-UI. Ihre App kontrolliert nicht jede Seite in diesem Flow. 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 der nativen Verdrahtung 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-Anrufrichtlinie kann in beiden Fällen identisch sein, während die Ausführungsresultate unterschiedlich sind.

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

• erste Berechtigungsanfrage
• abgelehnte Berechtigung
• Benutzerkündigung
• erfolgreiche Bibliotheksabfrage
• Erfolgreiche Kameraaufnahme 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 einen Veröffentlichungs-Endpunkt wie den Instagram-Medien-VeröffentlichungsAPI.

Behandlung von Picker-Ergebnissen und Optionen

Das Picker-Ergebnis ist der Teil, der normalerweise 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 nach einem Benutzerabbrechen.

Lesen Sie das Ergebnisobjekt richtig

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

Verwenden Sie ein Wächtermuster zuerst:

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 behandelt die beiden häufigsten Fehlerfälle. Ein abgebrochener Picker gibt Ihnen kein Asset zum Lesen, und code das annehmen result.assets[0] immer existiert, 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 asset Objekt beibehalten, nicht nur die URI. In der Praxis fileName, mimeType, width, height, und fileSize sind oft nützlich für die Validierung, Protokollierung oder die Erstellung eines sauberen multipart-Anforderung.

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.

Auf ein paar Kompromisse ist leicht zu achten:

• allowsEditing ist nützlich, wenn das Bildschlitze eine feste 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 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 einer Dateireferenz teuer.

URI gegenüber Base64

Für die meisten Apps ist die Regel einfach:

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

Dieser Musterhaltung hält den Picker code klein und erleichtert die Testbarkeit. Es passt auch mit der Bauweise vieler Backend-Medien-Flüsse überein, einschließlich Diensten, die letztendlich auf externe Plattformen wie dem Instagram-MedienveröffentlichungsAPI.

Wenn Ihr Team häufig OTA-Updates oder Bildschwerpunkte über App-Delivery versendet, tragen die Dateigrößenentscheidungen hier in den Rest des Pipelines ein. Diese Anleitung zum Optimieren von Bildern für App-Updates ist ein nützliches Begleitwerk zur Picker-Konfiguration.

Ein sichereres Ergebnismuster für reale Apps

Für Demo code, ist nur Speichern imageUri ist in Ordnung. In der Produktion solltet ihr ein normalisiertes Objekt speichern, damit 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 euch eine vorhersehbare Form innerhalb der App. Es macht auch Managed- und Bare-Projekte einfacher zu verwalten, da die App code stabil bleibt, während ihr durch native 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 zu verwandeln.

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 funktioniert die Auswahl gut. Der Rest der Funktion liegt an eurer App.

Ein praktisches Upload-Muster

Für APIs, die ein Dateiupload erwarten FormData ist immer noch der sicherste Standard. Es funktioniert überall, wo Rails, Node, Laravel, Django und Go im Hintergrund laufen, und es 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 noch eine weitere Schicht. Erstellt name und type Attach Auth außerhalb der Picker-Funktion und halte den Upload-Zustand getrennt vom Picker-Zustand, damit ein fehlgeschlagener Anfrage nicht zwingt, den Benutzer zum Wiedereröffnen der Bibliothek zu zwingen.

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

• Bestätige die lokale Existenz vor der Erstellung der Anfrage uri Rendere einen Vorschau vor dem Upload, damit die Benutzer das falsche Datei frühzeitig erkennen können
• Verhindere wiederholte Tasten während der Anfrage in Flug
• Behandle Netzwerkfehler separat von Picker-Stornierung oder Berechtigungsfehlern
• Erwarte die Validierung durch den Backend, um große Dateien, nicht unterstützte MIME-Typen oder fehlende Authentifizierung abzulehnen
• Wenn Ihr Backend Base64 anstatt Multipart erfordert, ist das in der Regel ein Servereinschränkung und kein 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 Verhalten. 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. Die begrenzte Zugriff auf Fotos kann eine engerere Menge an Assets zurückgeben als Ihr Testkonto auf einem vollständig genehmigten Gerät sah. Auf Android variiert das Verhalten des Pickers mehr nach Betriebssystemversion und Herstellerhaut, insbesondere um Alben, Dateinamen und wie Kameraaufnahmen zurückgegeben werden. Bare React Native-Apps spüren diese Unterschiede direkt mehr, weil Sie mehr des nativen Setups besitzen, aber verwaltete Expo-Apps benötigen code , das den Picker als plattformgeformt anstatt 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:

• Die Bearbeitung und das Schneiden: Die Benutzeroberfläche und das Schneideverhalten sind nicht identisch zwischen iOS und Android
• Die zurückgegebenen Metadaten: fileName, mimeType, und fileSize können fehlen oder ungleichmäßig sein, daher sollten Sie Ersatzmöglichkeiten hinzufügen
• Die Ermessigungsanfragen: Die Zugriff auf Fotos von iOS kann auf ausgewählte Artikel beschränkt sein, während das Verhalten von Android mehr von der Betriebssystemversion und der Unterstützung des Systems für den Picker abhängt
• Die Kameraausgabe: Die aufgenommenen Bilder können mit unterschiedlichen Namen, Orientierung oder Kompressionsmerkmalen als Bibliotheksassets zurückgegeben werden

Wenn Ihr Team auch außerhalb von Expo arbeitet, hilft dies Entwicklerleitfaden für DesignStack-Anwendungen Dies gibt nützliche Kontextinformationen für Android-Medienverwaltung, die sich außerhalb einer einzelnen Bibliothek zeigen.

Unterschiede zwischen verwaltetem und barem Workflow

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

Im verwalteten 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 wird. OTA-Updates patchen nicht fehlende 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-Probleme möglicherweise durch native Konfiguration und nicht durch die JavaScript-Anrufliste 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, und es ist ein gutes Vergleichspunkt, wenn Sie entscheiden, wie viel native Setup Ihr Team besitzen möchte. Meine Vorliebe ist konsistent in beiden Workflows. Halten Sie den Picker Capacitor eng, normalisieren Sie das Ergebnis einmal, laden Sie es über eine dedizierte __CAPGO_KEEP_1__-Schicht hoch und behandeln Sie plattformabhängige Verhaltensweisen als etwas, das konfiguriert und explizit getestet werden muss, anstatt sie mit Annahmen zu glätten.Häufige Probleme lösen

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_1__

Die meisten Expo-Bildauswahlfehler 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. Insbesondere bei barren Apps sind fehlende iOS-Benutzungsbeschreibungen eine häufige Ursache.

Wenn das 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 auslässt. canceled Einige schnelle Zuweisungen helfen:

Berechtigungsfehler:

• Überprüfen Sie Ihre App-Konfiguration und native Berechtigungszeichenfolgen, dann neu bauen. Bild-URI:
• undefined Aus nicht result.assets?.[0]?.uri, not result.uri.
• Nichts passiert nach Abbruch: Das mag korrekt sein. Behandle Abbruch als Zustand ohne Aktion.
• Bild wird nicht angezeigt: Bestätige, dass die URI im Zustand gespeichert und in den <Image source={{ uri }} />.
• Die Kamera verhält sich seltsam im Simulator: Teste auf einem physischen Gerät, bevor du dich auf einen Bibliotheksfehler einlässt.

Ein kurzer Produktionscheckliste

Verwende dies als letzte Überprüfung vor dem Versand:

• Installieren mit Expo-Tooling: Verwende npx expo install expo-image-picker.
• Konfiguriere native Teile: Füge das Plugin und die erforderlichen Berechtigungsbeschreibungen hinzu.
• Bitte genehmige die erforderlichen Berechtigungen: Kameras und Medienbibliotheken separat behandeln.
• Jedes Ergebnis schützen: Überprüfen result.canceled und sicher lesen assets[0].
• URI-basierte Uploads bevorzugen: Base64 nur in besonderen Fällen verwenden.
• Realgeräte testen: Besonders für die Kameraaufnahme und die Berechtigungsanfragen.

Wenn Ihr Team Capacitor oder Electron-Apps neben React Native-Projekten ausliefern möchte, Capgo Kann eine Option sein, JavaScript, CSS, Konfiguration und Asset-Updates ohne Wartezeit auf jede Änderung im Store bereitzustellen. Es ist relevant, wenn imagebezogene Fixes in der Web-Schicht leben, wie z.B. Upload-UI, Validierungsregeln, Kopien oder Asset-Verwaltung im Picker-Flow.