Expo Image Picker: Panduan Lengkap untuk 2026

Anda mungkin sudah di titik di mana UI siap, layar profil punya tombol “Upload foto”, dan bagian yang tadinya mudah tiba-tiba jadi rumit. Alur pemilihan gambar yang sebenarnya menyentuh izin native, antarmuka yang dikontrol OS, bentuk return yang berbeda dari ekspektasi banyak developer, dan beberapa detail build-time yang baru muncul setelah Anda merilis build sungguhan.

Di sinilah Expo Image Picker berperan. Ini adalah library resmi Expo untuk membuka UI sistem guna memilih gambar dan video dari perpustakaan perangkat atau mengambil foto dengan kamera, seperti yang dijelaskan dalam Repositori paket Expo. Pada praktiknya, ini berarti Anda mendapatkan bridge yang andal ke input media native, tetapi bukan pengalaman media kustom yang berperilaku identik di setiap perangkat.

Panduan ini ditulis untuk implementasi pertama, bukan demo. Fokusnya pada keputusan yang penting di produksi: setup workflow managed versus bare, penanganan izin yang tidak akan mengejutkan Anda nanti, parsing hasil yang aman, dan pola upload praktis setelah pengguna memilih file. Jika Anda bekerja di setup native kustom, ini juga membantu memahami bagaimana ini berbeda dari Opsi update Expo EAS Capgo dibandingkan di panduan alternatifnya.

Table of Contents

• Memulai dengan Expo Image Picker
• Instalasi dan Konfigurasi Penting
  • Setup managed workflow
  • Detail setup Bare React Native
• Mengakses Kamera dan Media Library
  • Komponen minimal namun aman
  • Alur library dan kamera
  • Ekspektasi tampilan system UI
• Menangani Hasil dan Opsi Picker
  • Membaca objek hasil dengan benar
  • Opsi yang mengubah perilaku downstream
  • URI vs base64
  • Pola hasil yang lebih aman untuk aplikasi nyata
• Pola Lanjutan dan Perbedaan Platform
  • Pola upload yang praktis
  • Di mana perbedaan platform benar-benar berpengaruh
  • Perbedaan workflow managed vs bare
• Troubleshooting Masalah Umum
  • Pemeriksaan cepat untuk kegagalan umum
  • Checklist singkat produksi

Memulai dengan Expo Image Picker

Product manager meminta fitur foto profil. Sepekan kemudian, fitur yang sama juga butuh upload struk, tangkapan kamera untuk laporan insiden, dan retry saat pengguna menolak izin di awal. Input gambar berkembang cepat karena menyentuh izin native, UI milik OS, penanganan file sementara, dan alur upload ke backend.

expo-image-picker adalah modul Expo SDK untuk tugas itu. Modul ini membuka UI picker atau kamera platform dan mengembalikan media terpilih dalam format yang bisa ditangani oleh code React Native Anda. API JavaScript-nya kecil. Tantangan utamanya ada pada pengaturan native, alur izin, dan penanganan hasil yang benar di proyek managed maupun bare.

Trade-off utamanya sederhana. Anda membiarkan iOS dan Android menampilkan UI media mereka sendiri, bukan membangun picker kustom. Ini biasanya menghasilkan pengalaman lebih baik: pengguna sudah memahami layar sistem, prompt izin berperilaku sesuai ekspektasi OS, dan tim Anda tidak perlu memelihara implementasi galeri di JavaScript.

Anggap ini sebagai fitur integrasi native dengan antarmuka React.

Pola pikir ini membantu karena mode kegagalan jarang ada di tombol yang memanggil picker. Biasanya berasal dari salah satu dari tiga tempat ini:

• Konfigurasi native: setup plugin yang hilang, string izin yang salah, atau build yang usang setelah mengubah config
• Perilaku runtime: pengguna bisa menolak akses, memberikan akses perpustakaan terbatas di iOS, atau membatalkan alur tanpa memilih apa pun
• Parsing hasil: API saat ini mengembalikan assets array, sehingga contoh lama yang membaca result.uri langsung gagal

Pilihan workflow juga mengubah jalur setup. Pada aplikasi Expo managed, sebagian besar pekerjaan native ada di app config dan perlu rebuild saat config tersebut berubah. Pada bare app, Anda tetap mendapat modul Expo API, tetapi perlu memverifikasi pengaturan proyek iOS dan Android yang mendasarinya secara lebih langsung. Jika tim Anda memakai custom client alih-alih Expo Go, panduan ini cocok dipasangkan dengan Capgo, alternatif untuk Expo EAS untuk tim yang perlu pengujian modul native di luar Expo Go.

Pembagian ini penting untuk sisa panduan karena jalur yang mulus hanyalah separuh cerita. Implementasi picker baru bisa dibilang solid kalau berfungsi di kedua workflow, menangani keanehan izin khas tiap platform tanpa mengejutkan pengguna, dan meneruskan file yang siap dipakai ke lapisan upload Anda, bukan berhenti di pratinjau lokal.

Instalasi dan Konfigurasi Penting

Instalasi cukup satu perintah. Konfigurasi native yang benar itulah yang menentukan apakah picker berfungsi di perangkat fisik, di custom dev client, dan di production build Anda.

expo-image-picker menyediakan API yang bisa dipakai dari React di atas picker platform untuk foto, video, dan pengambilan gambar dengan kamera. Panggilan JavaScript-nya sederhana. Setup-nya tidak, karena akses foto dan akses kamera dikendalikan oleh iOS dan Android, bukan oleh React Native.

Mulai dengan installer Expo yang sadar versi:

npx expo install expo-image-picker

Gunakan expo install alih-alih npm install atau yarn add. Expo mencocokkan versi paket dengan SDK Anda, yang menghindari masalah kompatibilitas native yang umum. Jika Anda membandingkan bagaimana modul Expo masuk ke dalam proses rilis Anda, ini Ringkasan tooling Expo adalah referensi yang berguna.

Setup managed workflow

Pada managed workflow, deklarasikan plugin di app config agar Expo dapat menerapkan perubahan native saat build.

Contoh dengan app.json:

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

Itu adalah setup minimum. Dalam praktiknya, tim biasanya juga menambahkan teks izin, terutama di iOS di mana system prompt harus menjelaskan mengapa aplikasi membutuhkan akses. Pertahankan kata-kata yang spesifik untuk tindakan pengguna. “Upload foto profil” lebih baik daripada “Butuh akses media.”

Satu detail operasional menyebabkan banyak waktu terbuang. Mengubah plugins, string izin, atau konfigurasi native lainnya memerlukan rebuild. Memuat ulang JavaScript tidak menerapkan perubahan tersebut. Di Expo Go, Anda juga dibatasi oleh apa yang sudah termasuk dalam klien. Dalam development build atau production build, proyek native mencerminkan konfigurasi Anda hanya setelah build baru.

Detail setup Bare React Native

Di bare app, package API tetap sama, tetapi Anda perlu memverifikasi lebih banyak bagian dari proyek native secara mandiri. iOS usage descriptions adalah hal pertama yang harus diperiksa. Jika alur Anda dapat membuka library, meluncurkan kamera, atau merekam video dengan audio, aplikasi Anda memerlukan string izin yang sesuai di Info.plist sebelum Anda rebuild.

Checklist praktis untuk proyek bare terlihat seperti ini:

1. Instal expo-image-picker dengan npx expo install expo-image-picker.
2. Tambahkan konfigurasi plugin jika proyek Anda menggunakan Expo config plugins.
3. Pastikan iOS usage descriptions sesuai dengan fitur yang Anda tampilkan.
4. Rebuild aplikasi iOS dan Android setelah perubahan konfigurasi native apa pun.

Teks izin yang hilang sering terlihat seperti bug runtime karena UI code berfungsi dengan baik dan handler tombol berjalan. Kegagalan terjadi lebih dalam di stack. Saya biasanya memeriksa Info.plist, konfigurasi aplikasi, dan apakah build saat ini mencakup perubahan native terbaru sebelum saya menyentuh komponen code.

Beberapa kebiasaan membuat setup lebih dapat diprediksi:

• Teks izin untuk aksi sebenarnya: pengguna perlu memahami mengapa mereka melihat prompt ini.
• Konfigurasi kamera dan galeri secara terpisah: satu bisa berfungsi sementara yang lain masih gagal.
• Rebuild setelah perubahan native: hot reload dan fast refresh tidak memperbarui izin native.
• Tes di perangkat: perilaku simulator bisa menyembunyikan masalah izin dan kamera.

Jika picker berfungsi saat development tapi gagal di TestFlight atau build Play Store, anggap itu masalah konfigurasi dulu. Biasanya memang begitu.

Mengakses Kamera dan Media Library

Pengguna mengetuk “Upload foto”, berharap kamera atau library terbuka, dan aplikasi Anda punya satu tugas saat itu: buka UI sistem yang tepat, tangani penolakan atau pembatalan tanpa merusak layar, dan kembalikan referensi file lokal yang bisa dipakai untuk preview atau upload.

Kedengarannya simpel sampai Anda menguji managed dan bare build di iOS dan Android. JavaScript API tetap ringkas, tapi perilaku runtime tetap bergantung pada prompt OS, hardware perangkat, dan bagaimana izin native dikonfigurasi sebelumnya.

Komponen minimal namun aman

Alur intinya konsisten baik di proyek Expo managed maupun bare workflow. Minta izin yang relevan, jalankan picker, cek apakah pengguna membatalkan, lalu baca asset pertama dari result.assets.

Komponen baseline terlihat seperti ini:

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

Ada tiga detail penting di sini.

• Minta izin library dan kamera secara terpisah. Keduanya bisa gagal secara independen.
• Anggap pembatalan sebagai aksi user normal, bukan error.
• Baca dari assets[0], karena picker mengembalikan array asset, bukan top-level uri.

Alur library dan kamera

Mulai dengan alur library kalau mau jalur tercepat ke fitur yang berfungsi. Lebih mudah dites, jalan di lebih banyak setup simulator, dan menghindari edge case hardware kamera. Tambahkan dukungan kamera setelah alur handling result stabil.

Alur kamera punya lebih banyak potensi error saat development. Dukungan iOS Simulator terbatas. Emulator Android mungkin tidak mengekspos perilaku kamera yang sama dengan device asli. Di bare projects, celah ini bisa membuat Anda memeriksa komponen code padahal masalah aslinya ada di native config atau environment testing.

Pola UI yang bersih adalah menanyakan sumber ke user sebelum memanggil picker API:

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

Pemisahan itu menjaga setiap fungsi tetap fokus. Ini juga memudahkan menambahkan analytics, feature flags, atau aturan khusus backend nanti. Contohnya, beberapa tim mengizinkan upload dari library untuk foto profil, tapi mewajibkan capture kamera baru untuk verifikasi identitas.

Jika aplikasi Anda juga mendukung pola akses file di luar Expo atau Anda sedang membandingkan konvensi lintas native stack, ini referensi library foto Capacitor adalah konteks yang berguna.

Demo singkat membantu saat Anda menunjukkan alur ini ke tim atau QA:

Ekspektasi tampilan system UI

expo-image-picker membuka platform picker atau UI kamera. Aplikasi Anda tidak mengontrol setiap layar dalam alur tersebut. Pembeda ini penting karena “berjalan di perangkat saya” sering berarti “OS mengizinkan jalur yang saya uji.”

Di iOS, pengguna mungkin memberikan akses terbatas ke perpustakaan alih-alih akses penuh. Di Android, perilaku picker bisa bervariasi tergantung versi OS dan vendor skin. Pada proyek managed workflow, Expo menangani lebih banyak wiring native untuk Anda. Pada proyek bare workflow, Anda perlu memastikan bahwa aplikasi yang dibangun mencakup perubahan izin native yang Anda buat. Panggilan JavaScript bisa identik di kedua kasus, sementara hasil runtime berbeda.

Saya biasanya menguji kasus-kasus ini sebelum menyatakan fitur selesai:

• permintaan izin pertama
• izin ditolak
• pembatalan oleh pengguna
• pemilihan library berhasil
• pengambilan foto kamera berhasil di perangkat fisik
• pratinjau URI lokal yang dikembalikan secara langsung

Kasus-kasus ini memetakan perilaku produksi nyata secara langsung. Mereka juga menyiapkan langkah berikutnya dengan rapi jika Anda perlu mengirim file ke server, pipeline moderasi, atau endpoint publikasi seperti publikasi media Instagram API.

Menangani Hasil dan Opsi Picker

Hasil picker adalah bagian yang biasanya membutuhkan logika produksi nyata. UI sistem mengembalikan objek terstruktur, bukan sekadar path file, dan kesalahan kecil di sini dapat menyebabkan pratinjau rusak, upload kosong, atau crash setelah pengguna membatalkan.

Membaca objek hasil dengan benar

Bentuk hasil yang penting di aplikasi Expo saat ini adalah result.assets[0].uri, bukan tingkat atas result.uri. Detail tersebut memengaruhi proyek dengan workflow managed maupun bare, karena JavaScript API tetap sama meskipun setup native di baliknya berbeda.

Gunakan pola guard-first:

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 1,
});

if (result.canceled) {
  return;
}

const asset = result.assets?.[0];
if (!asset) {
  return;
}

const { uri } = asset;
setImageUri(uri);

Ini menangani dua kasus kegagalan yang paling sering saya temui. Picker yang dibatalkan tidak memberi Anda aset untuk dibaca, dan code yang mengasumsikan result.assets[0] selalu ada akan gagal saat runtime.

Setelah Anda mendapatkan URI, merender preview cukup mudah:

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

Jika Anda berencana upload nanti, simpan seluruh asset objek, bukan hanya URI. Dalam praktiknya, fileName, mimeType, width, height, dan fileSize sering berguna untuk validasi, logging, atau membangun request multipart yang lebih rapi.

Opsi yang mengubah perilaku downstream

Beberapa opsi picker memengaruhi lebih dari layar pemilihan. Opsi ini menentukan ukuran file, perilaku editing, dan apa yang harus diterima backend Anda.

Beberapa trade-off mudah terlewat:

• allowsEditing berguna ketika slot gambar memiliki bentuk atau ukuran tetap. Kurang berguna jika server Anda memiliki pipeline crop sendiri dan Anda menginginkan file asli.
• quality memengaruhi waktu upload, tekanan memori, dan penyimpanan server. quality: 1 tidak otomatis menjadi pilihan yang tepat.
• mediaTypes seharusnya sesuai dengan aturan backend. Jika server menolak video, jangan biarkan picker mengembalikannya.
• base64 meningkatkan ukuran payload di memori. Hindari kecuali layanan penerima membutuhkannya.

Poin terakhir ini penting pada perangkat dengan memori rendah. URI file lokal biasanya lebih baik untuk preview dan upload multipart. Base64 memiliki kegunaan yang valid, tetapi lebih mahal dibandingkan dengan meneruskan referensi file.

URI versus base64

Untuk sebagian besar aplikasi, aturannya sederhana:

• Gunakan URI untuk pratinjau.
• Gunakan URI untuk upload file.
• Gunakan base64 hanya jika sistem penerima secara eksplisit meminta konten terenkripsi.

Pola ini menjaga code picker tetap kecil dan lebih mudah diuji. Pola ini juga selaras dengan cara banyak alur media backend dibangun, termasuk layanan yang pada akhirnya menerbitkan ke platform eksternal seperti publikasi media Instagram API.

Jika tim Anda sering merilis pembaruan OTA atau memindahkan aset berbasis gambar melalui pengiriman aplikasi, keputusan ukuran file di sini akan berdampak ke sisa pipeline. Panduan ini tentang mengoptimalkan gambar untuk pembaruan aplikasi adalah pendamping yang berguna untuk konfigurasi picker.

Pola hasil yang lebih aman untuk aplikasi nyata

Untuk demo code, menyimpan hanya imageUri sudah cukup. Di produksi, simpan objek ternormalisasi agar langkah berikutnya, preview, validasi, upload, atau retry, tidak perlu menafsirkan ulang respons mentah picker setiap kali.

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

Ini memberi Anda satu bentuk yang dapat diprediksi di dalam aplikasi. Ini juga memudahkan proyek managed dan bare untuk tetap selaras karena code aplikasi tetap stabil sementara Anda menangani perbedaan native di tempat lain.

Satu pemeriksaan terakhir membantu. Jangan mengaktifkan bidang hasil tambahan hanya untuk berjaga-jaga. Minta data yang Anda ketahui Anda butuhkan, dan biarkan picker fokus pada pemilihan alih-alih menjadikannya langkah pemrosesan file umum.

Pola Lanjutan dan Perbedaan Platform

Fitur picker biasanya berhenti menjadi sederhana begitu gambar pertama yang dipilih harus bertahan dari retry, header auth, perbedaan izin native, dan endpoint upload yang nyata. expo-image-picker menangani pemilihan dengan baik. Sisa fitur ada di aplikasi Anda.

Pola upload yang praktis

Untuk API yang mengharapkan upload file, FormData tetap jadi default paling aman. Ini berfungsi di backend Rails, Node, Laravel, Django, dan Go yang umum, serta menjaga picker tetap terpisah dari urusan transport.

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

Itu code sudah cukup untuk membuktikan alur ini berfungsi, tetapi aplikasi produksi biasanya butuh satu lapisan lagi. Turunkan name dan type dari aset yang dipilih jika memungkinkan, pasang auth di luar fungsi picker, dan pisahkan state upload dari state picker agar request yang gagal tidak memaksa pengguna membuka ulang library.

Beberapa pengecekan mencegah kegagalan umum yang saya lihat saat review:

• Pastikan local uri ada sebelum menyusun request
• Tampilkan preview sebelum upload agar pengguna bisa mendeteksi file yang salah lebih awal
• Cegah tap berulang saat request sedang berjalan
• Tangani kegagalan jaringan secara terpisah dari pembatalan picker atau error izin
• Harapkan validasi backend menolak file besar, tipe MIME yang tidak didukung, atau auth yang hilang

Jika backend Anda membutuhkan base64 alih-alih multipart, itu biasanya batasan server, bukan persyaratan picker. Multipart lebih hemat memori dan lebih mudah dipahami di mobile.

Di mana perbedaan platform benar-benar berpengaruh

UI picker bersifat native, sehingga mewarisi perilaku native. Hal ini memengaruhi apa yang dilihat pengguna dan apa yang harus diasumsikan oleh code Anda.

Di iOS, alur editing dan prompt izin mengikuti konvensi Apple. Akses Foto Terbatas dapat mengembalikan set aset yang lebih sempit daripada yang dilihat akun uji Anda di perangkat dengan izin penuh. Di Android, perilaku picker lebih bervariasi tergantung versi OS dan skin pabrikan, terutama terkait album, nama file, dan cara hasil kamera dikembalikan. Aplikasi React Native bare merasakan perbedaan ini lebih langsung karena Anda mengelola lebih banyak setup native, tetapi aplikasi Expo managed tetap membutuhkan code yang memperlakukan picker sebagai bentuk platform, bukan seragam sempurna.

Aturan praktisnya sederhana. Bergantung pada field yang bisa Anda validasi, bukan pada UI atau metadata yang identik di semua perangkat.

Beberapa contoh penting di aplikasi nyata:

• Editing dan cropping: UI dan perilaku cropping tidak identik antara iOS dan Android
• Metadata yang dikembalikan: fileName, mimeType, dan fileSize bisa tidak ada atau tidak konsisten, jadi tambahkan fallback
• Permissions: Akses foto di iOS bisa dibatasi pada item tertentu, sementara perilaku Android lebih bergantung pada versi OS dan dukungan system picker
• Output kamera: Gambar yang diambil mungkin kembali dengan penamaan, orientasi, atau karakteristik kompresi yang berbeda dari aset library

Jika tim Anda juga bekerja di luar Expo, ini panduan pengembangan aplikasi DesignStack memberikan konteks Android yang berguna untuk keputusan penanganan media yang muncul di luar satu library.

Perbedaan workflow managed vs. bare

Pada titik ini, pilihan setup mulai berdampak secara operasional.

Dalam workflow managed, string izin dan konfigurasi plugin biasanya ada di app config, dan perubahan native diterapkan saat Anda membuat build baru. Itu menjaga permukaan JavaScript tetap bersih, tetapi juga berarti perbaikan config tidak terlihat sampai build native berikutnya. OTA updates tidak menambal izin native yang hilang.

Dalam workflow bare, fitur yang sama memiliki lebih banyak komponen bergerak. Anda perlu memverifikasi deskripsi penggunaan native iOS, perilaku manifest Android, instalasi package, dan waktu rebuild sendiri. Keuntungannya adalah kontrol. Biayanya adalah masalah picker mungkin disebabkan oleh konfigurasi native, bukan oleh call site JavaScript.

Tim yang berpindah antara Expo dan Capacitor sering meremehkan seberapa berbeda lapisan abstraksi ini. Capgo memiliki penjelasan yang berguna tentang bagaimana Capacitor menangani perbedaan platform, dan itu adalah titik perbandingan yang baik jika Anda memutuskan berapa banyak setup native yang ingin dimiliki tim Anda.

Preferensi saya konsisten di kedua workflow. Jaga agar code picker tetap sempit, normalisasi hasil sekali, upload melalui lapisan API khusus, dan perlakukan perilaku spesifik platform sebagai sesuatu yang harus dikonfigurasi dan diuji secara eksplisit, bukan dihaluskan dengan asumsi.

Troubleshooting Masalah Umum

Sebagian besar bug Expo Image Picker masuk ke dalam beberapa kategori kecil. Perbaikan tercepat biasanya adalah mengidentifikasi lapisan mana yang gagal: config, permission, penanganan hasil, atau rendering.

Pemeriksaan cepat untuk kegagalan umum

Jika picker tidak terbuka atau permission gagal, periksa setup native terlebih dahulu. Terutama di bare apps, deskripsi penggunaan iOS yang hilang adalah penyebab umum.

Jika app crash setelah user menutup picker, periksa penanganan result Anda. Banyak implementasi masih mengasumsikan URI langsung dan melewatkan canceled pemeriksaan.

Beberapa pemetaan cepat membantu:

• Error permission ditolak: Verifikasi config aplikasi dan string permission native Anda, lalu rebuild.
• undefined URI gambar: Baca dari result.assets?.[0]?.uri, bukan result.uri.
• Tidak ada yang terjadi setelah dibatalkan: Mungkin itu benar. Tangani cancel sebagai state no-op.
• Gambar tidak muncul: Pastikan URI sudah tersimpan di state dan diteruskan ke <Image source={{ uri }} />.
• Kamera berperilaku aneh di simulator: Tes di perangkat fisik sebelum mencari bug di library.

Checklist singkat produksi

Gunakan ini sebagai pengecekan terakhir sebelum rilis:

• Install dengan tooling Expo: Gunakan npx expo install expo-image-picker.
• Konfigurasikan bagian native: Tambahkan plugin dan deskripsi permission yang diperlukan.
• Minta permission secara sengaja: Pisahkan alur kamera dan perpustakaan media.
• Validasi setiap hasil: Periksa result.canceled dan baca dengan aman assets[0].
• Utamakan upload berbasis URI: Gunakan base64 hanya untuk kasus khusus.
• Uji di perangkat fisik: Terutama untuk capture kamera dan prompt izin.

Jika tim Anda merilis Capacitor atau aplikasi Electron bersamaan dengan proyek React Native, Capgo adalah salah satu opsi untuk mendistribusikan pembaruan JavaScript, CSS, konfigurasi, dan aset tanpa menunggu review store untuk setiap perubahan. Ini relevan ketika perbaikan terkait gambar berada di lapisan web Anda, seperti UI upload, aturan validasi, teks, atau penanganan aset di sekitar alur picker.