Merilis React Native Tanpa Expo: Checklist Rilis untuk iOS dan Android

Expo membuat rilis React Native terasa mudah, dan untuk banyak aplikasi itu pilihan yang tepat. Tapi sebagian project tumbuh melampaui managed workflow: SDK native tanpa config plugin, kebutuhan kontrol ketat atas pengaturan build, atau tim yang memang ingin memegang folder native sendiri. Saat saya memindahkan dua aplikasi wallet dari Expo ke React Native CLI bare, perubahan kodenya justru bagian yang mudah. Pekerjaan sebenarnya ada di proses rilis.

Ini checklist yang sekarang saya pakai untuk setiap rilis React Native bare.

1. Tentukan aturan versi sekali saja

Store peduli pada dua angka. Di Android, versionCode harus naik di setiap upload; di iOS, CFBundleVersion (nomor build) harus naik dalam satu versi. versionName / CFBundleShortVersionString yang dilihat pengguna mengikuti semantic versioning.

Simpan satu sumber kebenaran — misalnya package.json — dan script kecil yang menulis ke kedua file native. Jangan pernah menaikkan angka manual di Xcode dan Gradle secara terpisah; cepat atau lambat keduanya berbeda dan upload ke store ditolak.

2. Perlakukan bahan signing seperti secret production

• Android: buat upload keystore sekali, simpan di password manager atau secret store, dan rujuk dari ~/.gradle/gradle.properties atau secret CI — jangan pernah dari repository. Aktifkan Play App Signing agar upload key yang hilang masih bisa dipulihkan.
• iOS: pakai automatic signing untuk development, tapi pahami distribution certificate dan provisioning profile mana yang dipakai rilis. Dokumentasikan siapa pemilik akun Apple Developer dan cara memperbarui sertifikat sebelum kedaluwarsa.

Tuliskan ini di catatan handover project. Orang yang menyiapkan signing jarang sama dengan orang yang melakukan rilis setahun kemudian.

3. Pisahkan environment secara eksplisit

Siapkan API base URL, nama aplikasi, dan bundle identifier yang berbeda untuk staging dan production (com.company.app.staging), agar tester bisa memasang keduanya berdampingan. Suntikkan konfigurasi saat build dan buat mustahil merilis build production yang mengarah ke staging — gagalkan build kalau variabel wajib tidak ada.

4. Cek detail native yang sering ditolak store

• Permission: deklarasikan hanya yang dipakai, dan tulis alasan penggunaan yang jujur di Info.plist (kamera untuk scan QR, Face ID untuk buka kunci biometrik). Kalimat yang samar adalah penyebab umum penolakan iOS.
• Target SDK Android: Google Play mewajibkan target API level yang baru. Perbarui sebelum tenggat, bukan di hari rilis.
• Deklarasi privasi: isi detail privasi App Store dan form Data safety Play sesuai data yang benar-benar dikumpulkan aplikasi, termasuk SDK pihak ketiga.
• Hapus akun: kalau pengguna bisa membuat akun di aplikasi, mereka juga harus bisa menghapusnya dari aplikasi.

5. Build seperti production, uji seperti pengguna

Build debug menyembunyikan masalah. Sebelum setiap rilis:

• Build varian release di lokal (./gradlew bundleRelease, Archive di Xcode) dan pasang di perangkat asli.
• Pastikan Hermes aktif dan aturan R8/ProGuard mempertahankan class yang dibutuhkan native module — crash yang hanya terjadi di release sering berasal dari kode yang terbuang.
• Jalankan smoke flow di kedua platform: instal, login, transaksi utama, background lalu kembali, offline lalu online lagi. Tool seperti Maestro menjadikannya alur yang bisa diulang.
• Uji di ponsel Android lama yang kecil. Kalau jalan di sana, aplikasinya jalan di sebagian besar perangkat pengguna.

6. Keamanan untuk aplikasi yang menyentuh uang

Aplikasi wallet dan pembayaran butuh perhatian ekstra:

• Jauhkan secret dari bundle JavaScript; bundle itu bisa dibaca di setiap build release.
• Simpan key dan token di Keychain atau Keystore, bukan di AsyncStorage.
• Lindungi aksi sensitif dengan PIN transaksi, dan biarkan biometrik membuka PIN itu, bukan menggantikan pengecekan di server.
• Nonaktifkan screenshot di layar sensitif di Android, dan blur preview aplikasi saat masuk background.

7. Siapkan listing store sebelum build

Screenshot untuk setiap ukuran perangkat yang diwajibkan, deskripsi singkat dan lengkap, URL kebijakan privasi, kontak dukungan, dan catatan untuk reviewer. Kalau aplikasi butuh akun, beri reviewer akun uji dan langkah yang jelas. Untuk aplikasi Web3 atau finance, jelaskan di catatan apa yang dilakukan aplikasi terhadap dana; reviewer senang tidak perlu menebak.

8. Rilis bertahap dan pantau

Pakai staged rollout di Play dan phased release di App Store. Mulai dari sedikit, pantau laporan crash dan ulasan satu-dua hari, lalu perluas. Tanpa update over-the-air dari Expo, rilis yang buruk berarti build store baru, jadi rem itu penting.

9. Catat rilisnya

Setelah setiap rilis, perbarui catatan rilis singkat di repository: versi, nomor build, apa yang berubah, perangkat apa yang diuji, dan hal tidak biasa soal signing atau review. Rilis berikutnya dimulai dari catatan itu, bukan dari ingatan.

Versi singkatnya

1. Satu sumber kebenaran untuk nomor versi dan build.
2. Key signing tersimpan aman dan terdokumentasi.
3. Build staging dan production yang eksplisit.
4. Permission, form privasi, dan target SDK dicek sebelum hari rilis.
5. Build release diuji di perangkat asli, termasuk ponsel Android lama.
6. Secret di luar bundle, data sensitif di Keychain atau Keystore.
7. Listing store dan catatan reviewer siap.
8. Staged rollout, lalu pantau.
9. Catatan rilis ditulis untuk orang berikutnya.

Memilih bare mengorbankan sedikit kenyamanan demi kontrol penuh. Dengan checklist seperti ini, pilihan itu tidak lagi mengorbankan hari-hari rilis.