Apa yang Terjadi Setelah Kamu Menekan Tombol "Upload" di Google Play dan App Store

Build kamu hijau. Semua tes lolos. Branch release bersih. Seseorang di tim berkata, "Oke, tinggal upload ke store dan tunggu review." Jika kamu pernah melalui proses rilis mobile sungguhan, kamu tahu kalimat itu menyembunyikan banyak kerumitan.

Mengupload ke Google Play Console atau App Store Connect bukan sekadar mengirim file. Ini adalah proses multi-langkah yang melibatkan metadata, tangkapan layar, changelog, antrean review, dan kemungkinan nyata akan penolakan. Dan jika pipeline kamu menganggap upload sebagai langkah terakhir, kamu sedang menjebak diri sendiri untuk panik tengah malam saat review kembali dengan pemberitahuan penolakan.

Upload Lebih dari Sekadar Transfer File

Saat kamu mengupload Android App Bundle (AAB) atau file IPA iOS, store mengharapkan lebih dari sekadar biner. Kamu juga perlu menyediakan:

  • Judul aplikasi dan deskripsi untuk versi baru
  • Apa yang berubah di rilis ini (changelog)
  • Tangkapan layar untuk berbagai ukuran perangkat
  • Kategori aplikasi dan pembaruan rating konten
  • Negara atau wilayah mana yang mendapatkan pembaruan

Baik Google Play Console maupun App Store Connect menyediakan API yang memungkinkan pipeline kamu menangani semua ini secara terprogram. Sistem CI/CD kamu bisa mendorong artefak, mengisi metadata, melampirkan tangkapan layar yang tepat, dan mengatur jalur rilis. Untuk Android, kamu bisa upload ke internal testing, closed testing, atau open testing sebelum berpikir tentang produksi. Untuk iOS, kamu upload ke TestFlight terlebih dahulu.

Diagram urutan berikut mengilustrasikan alur umum dari pipeline hingga rilis:

Sebagai contoh, menggunakan fastlane supply di Android, kamu bisa mengupload biner, mengatur changelog, dan melampirkan tangkapan layar dalam satu perintah:

# Upload AAB ke jalur internal test Google Play
fastlane supply \
  --aab ./app/build/outputs/bundle/release/app-release.aab \
  --track internal \
  --metadata_path ./fastlane/metadata/android \
  --json_key ./path/to/service-account-key.json \
  --package_name com.example.myapp

# Folder metadata harus berisi:
#   metadata/android/en-US/title.txt
#   metadata/android/en-US/short_description.txt
#   metadata/android/en-US/full_description.txt
#   metadata/android/en-US/changelogs/1.txt (version code sebagai nama file)
#   metadata/android/en-US/images/phoneScreenshots/
sequenceDiagram participant CI as CI/CD Pipeline participant Store as Store API participant Review as Antrean Review participant Track sebagai Jalur Rilis CI->>Store: Upload biner + metadata Store->>Review: Kirim untuk review Review-->>Store: Disetujui atau ditolak alt Ditolak Store-->>CI: Pemberitahuan penolakan CI->>Store: Perbaiki dan upload ulang else Disetujui Store->>Track: Atur jalur rilis (internal/closed/open/production) Track->>Track: Rilis bertahap atau rilis penuh end

Poin kuncinya di sini adalah bahwa langkah upload seharusnya bukan akhir dari pipeline kamu. Ini harus menjadi awal dari proses rilis yang terkendali.

Mengapa Kamu Tidak Harus Langsung Upload ke Produksi

Sangat menggoda untuk membuat pipeline yang langsung dari "tes lolos" ke "dipublikasikan di store." Tapi store mobile menambahkan gerbang yang tidak ada di deployment web atau backend: review manusia.

Apple meninjau setiap aplikasi dan pembaruan terhadap App Store Review Guidelines. Google juga meninjau pengajuan, meskipun prosesnya umumnya lebih cepat dan tidak terlalu ketat. Jika pipeline kamu upload langsung ke produksi dan review menemukan masalah, kamu harus memperbaikinya, upload ulang, dan menunggu lagi. Itu bisa menunda rilis kamu berhari-hari.

Pendekatan yang lebih baik adalah upload ke jalur testing terlebih dahulu. Di Android, kamu bisa menggunakan jalur internal test. Di iOS, kamu menggunakan TestFlight. Ini memberi tim kamu dan sekelompok kecil penguji kesempatan untuk mencoba build yang sebenarnya akan masuk store sebelum melalui review publik. Jika ada yang salah, kamu mengetahuinya lebih awal, memperbaikinya, dan upload lagi tanpa tekanan penolakan pengajuan produksi.

Metadata dan Tangkapan Layar Harus Sesuai dengan Build

Salah satu alasan paling umum penolakan adalah ketidakcocokan antara apa yang dilakukan aplikasi dan apa yang dikatakan listing store. Jika versi baru kamu menambahkan fitur, tetapi tangkapan layar kamu masih menunjukkan antarmuka lama, Apple atau Google mungkin menolaknya karena dianggap menyesatkan.

Pipeline kamu bisa membantu di sini. Simpan tangkapan layar dan metadata untuk setiap versi bersama dengan kode kamu. Saat kamu memicu rilis, pipeline memilih aset yang benar berdasarkan nomor versi atau tag rilis. Ini memastikan bahwa apa yang kamu upload ke store sesuai dengan apa yang sebenarnya ada di dalam biner.

Untuk changelog, buatlah singkat dan faktual. Jangan menulis "memperbaiki bug dan meningkatkan performa" untuk setiap rilis. Pengguna membaca ini. Lebih penting lagi, reviewer store juga membacanya. Jika changelog kamu mengatakan "menambahkan mode gelap" tetapi aplikasi tidak memiliki mode gelap, itu masalah.

Rencanakan Waktu Review dalam Jadwal Rilis Kamu

Review store mobile membutuhkan waktu. Apple biasanya membutuhkan 24 hingga 48 jam untuk pembaruan aplikasi, dan lebih lama untuk aplikasi baru. Google biasanya lebih cepat, terkadang hanya beberapa jam, tetapi selalu ada antrean. Jika kamu memiliki tanggal rilis tetap, kamu perlu upload cukup awal untuk memperhitungkan waktu review ditambah kemungkinan pengajuan ulang.

Jangan berasumsi review pertama akan lolos. Bahkan tim berpengalaman pun bisa ditolak karena hal-hal seperti:

  • Meminta izin tanpa menjelaskan alasannya
  • Menggunakan API privat
  • Metadata yang tidak lengkap atau salah
  • Elemen UI yang tidak cocok dengan tangkapan layar
  • Pelanggaran kebijakan spesifik store (seperti aturan Apple tentang pembelian dalam aplikasi)

Bangun waktu buffer ke dalam rencana rilis kamu. Jika kamu ingin aplikasi live pada hari Jumat, targetkan untuk mengajukan paling lambat hari Selasa atau Rabu. Itu memberi kamu ruang untuk memperbaiki masalah dan mengirim ulang.

Apa yang Terjadi Setelah Review Lolos

Setelah review menyetujui build kamu, kamu memasuki fase rilis. Ini bukan keputusan semua-atau-tidak sama sekali. Kedua store mendukung rilis bertahap.

Di Android, kamu bisa menggunakan staged rollout untuk merilis pembaruan ke persentase pengguna, seperti 10% atau 25%. Di iOS, kamu bisa menggunakan phased release, yang secara bertahap meluncurkan pembaruan selama beberapa hari. Ini memungkinkan kamu memantau tingkat crash, umpan balik pengguna, dan metrik kunci sebelum memperluas ke semua orang.

Pipeline kamu harus mendukung ini. Setelah review lolos, pipeline dapat mengatur persentase rilis awal, menunggu periode pemantauan, lalu meningkatkan persentase atau melanjutkan ke rilis penuh. Jika ada yang salah, kamu bisa menghentikan rilis tanpa mempengaruhi semua pengguna.

Daftar Periksa Praktis untuk Upload ke Store

  • Upload ke jalur internal atau closed testing sebelum mengajukan untuk review publik
  • Simpan metadata dan tangkapan layar di direktori yang memiliki versi bersama dengan kode kamu
  • Gunakan API store untuk mengotomatiskan pengiriman metadata, bukan hanya upload biner
  • Sertakan changelog yang secara akurat menjelaskan apa yang berubah di versi ini
  • Rencanakan setidaknya 48 jam waktu buffer sebelum tanggal rilis target kamu
  • Konfigurasikan staged rollout atau phased release sebagai default, bukan rilis penuh
  • Miliki rencana rollback: ketahui cara menghapus publikasi atau kembali ke versi sebelumnya

Kesimpulan

Mengupload ke store mobile bukanlah garis akhir. Ini adalah awal dari proses yang mencakup review, kemungkinan penolakan, rilis bertahap, dan pemantauan. Jika pipeline kamu memperlakukan upload sebagai langkah terakhir, kamu akan terus dikejutkan oleh penolakan dan rilis yang tertunda. Bangun proses review ke dalam desain pipeline kamu, upload ke jalur testing terlebih dahulu, dan selalu sisakan ruang untuk percobaan kedua. Itulah cara mengubah rilis mobile dari peristiwa yang menegangkan menjadi operasi rutin.