Rilis bertahap App Store: cara kerja peluncuran 7 hari, kapan menjeda, dan cara merilis perbaikan (2026)

Rilis bertahap App Store (phased release) mengirimkan update versi ke porsi pengguna yang terus bertambah, khusus pengguna yang mengaktifkan pembaruan otomatis, selama tujuh hari: dimulai dari 1% pada hari pertama dan mencapai 100% pada hari ketujuh. Jika Anda memeriksa crash dan email dukungan setiap hari lalu menjeda begitu ada yang janggal, build yang bermasalah hanya menjangkau sekelompok kecil orang, bukan seluruh basis pengguna Anda. Namun, rilis bertahap punya satu batasan besar: fitur ini hanya mengendalikan pembaruan otomatis. Siapa pun tetap bisa mengunduh versi baru secara manual.

Apa yang dikendalikan rilis bertahap App Store, dan apa yang tidak?

Rilis bertahap hanya mengendalikan pengguna mana dengan pembaruan otomatis aktif yang menerima update versi Anda, dan kapan. Fitur ini tidak menyembunyikan versi baru dari unduhan manual, dan tidak mengembalikan pengguna yang sudah memilikinya ke versi lama.

Menurut App Store Connect Help dari Apple, "Sampel acak pengguna dengan pembaruan otomatis aktif di perangkat yang memenuhi syarat akan menerima update, tanpa pemberitahuan apa pun tentang keikutsertaan mereka dalam rilis bertahap." Fitur ini berlaku untuk update versi iOS, macOS, dan tvOS, jadi tidak bisa dipakai untuk rilis pertama aplikasi. Untuk mengaturnya, diperlukan peran Account Holder, Admin, atau App Manager. Apple juga menyatakan: "Aplikasi dan update aplikasi dalam rilis bertahap dapat diunduh secara manual dari App Store oleh siapa pun kapan saja."

Bagaimana jadwal rilis bertahap App Store?

Per November 2026, jadwalnya tetap: 1%, 2%, 5%, 10%, 20%, 50%, dan 100% selama tujuh hari, dan tidak bisa diubah. Yang Anda kendalikan adalah kapan menjeda dan kapan langsung melompat ke 100%.

Perlakukan setiap hari sebagai titik pemeriksaan yang diakhiri satu keputusan: lanjut atau jeda.

Bagaimana cara mengaktifkan rilis bertahap di App Store Connect?

Rilis bertahap diaktifkan dari halaman versi, di bagian Phased Release for Automatic Updates, kapan saja sebelum update tayang. Anda tidak harus memutuskannya sebelum submit.

Apple mengizinkannya selama versi berstatus Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected, atau Metadata Rejected.

1. Di Apps, pilih aplikasi Anda, lalu klik versi yang akan Anda submit di sidebar.
2. Gulir ke Phased Release for Automatic Updates.
3. Pilih Release update over a 7-day period using phased release.
4. Klik Save. Setelah disetujui, statusnya menampilkan Ready for Distribution dengan keterangan Phased Release di sebelahnya.

Anda juga bisa mengelola rilis bertahap melalui App Store Connect API, yang berguna jika pipeline rilis Anda sudah berbasis skrip.

Kapan sebaiknya menjeda rilis bertahap, dan bagaimana batas 30 hari bekerja?

Jeda begitu salah satu pemicu yang sudah disepakati sebelumnya terjadi. Total jeda bisa mencapai 30 hari, dan saat dilanjutkan, peluncuran berlanjut dari hari saat dihentikan.

Tuliskan pemicu Anda sebelum hari peluncuran, agar tidak ada yang berdebat soal itu saat pengguna sedang terkena bug. Pemicu yang baik bersifat konkret: sesi bebas crash turun di bawah baseline versi sebelumnya, checkout atau login gagal pada porsi percobaan yang terukur, atau beberapa pengguna melaporkan bug yang sama.

Untuk menjeda, buka versi berstatus Ready for Distribution, pilih Pause Phased Release, lalu klik Save. Untuk melanjutkan, pilih Use Phased Release. Contoh dari Apple: jika Anda menjeda selama 10 hari lalu melanjutkan, sisa waktu jeda Anda 20 hari. Anda bisa menjeda sesering apa pun dalam batas total tersebut. Untuk melewati fase yang tersisa, klik Release to All Users di kanan atas halaman versi.

Seperti apa rilis bertahap ketika bug muncul?

Ketika bug muncul, Anda menjeda, memperbaikinya, lalu merilis versi baru dengan rilis bertahap aktif lagi. Pengguna yang masih menunggu pembaruan otomatis tetap memakai versi sebelumnya selama Anda bekerja.

Misalkan versi 3.4 mengganti mesin sinkronisasi Anda. Pada hari pertama, 1% pengguna dengan pembaruan otomatis menerimanya, dan Anda memeriksa crash reporter serta log error sinkronisasi dua kali. Pada hari ketiga, di angka 5%, muncul kluster kegagalan sinkronisasi pada satu versi iOS lama. Anda langsung menjeda. Pengguna yang terdampak jauh lebih sedikit dibanding jika semua orang menerimanya, dan pengguna pembaruan otomatis yang belum terjangkau tetap di versi 3.3.

Selanjutnya, perbaiki bug dan submit 3.4.1 dengan rilis bertahap aktif. Uji perbaikan di build rilis, bukan hanya di debug; rencana pengujian build rilis kami membahas langkah ini. Sebutkan dengan jelas di catatan rilis 3.4.1 bahwa sinkronisasi sudah diperbaiki; contoh catatan rilis kami menunjukkan caranya. Jika perbaikannya mendesak dan Anda yakin dengannya, gunakan Release to All Users setelah disetujui alih-alih menunggu seminggu lagi.

Satu pengaman lagi: letakkan mesin sinkronisasi baru di balik flag sisi server. Menjeda menghentikan penyebaran update, tetapi flag memungkinkan Anda mematikan kode berisiko bagi orang yang sudah memasang 3.4. Keduanya saling melengkapi dengan baik.

Apa yang dialami developer lain saat menjeda rilis bertahap?

Diskusi publik menunjukkan pola yang sama: developer menjeda versi yang bermasalah, lalu tidak yakin apa dampak rilis bertahap berikutnya bagi pengguna yang sudah menerimanya. Dokumentasi Apple tidak menjawabnya, jadi rencanakan seolah-olah perbaikan memerlukan peluncurannya sendiri.

• Seorang developer di Apple Developer Forums melaporkan bahwa mereka "melihat crash, menjeda peluncuran update, menambal aplikasi, mengunggahnya, dan memulai peluncuran bertahap lain" saat kurang dari 10% pengguna memakai build bermasalah. Mereka bertanya apakah pengguna yang sama akan menerima peluncuran baru. Thread itu tidak pernah mendapat jawaban resmi; satu balasan menyebut pengguna 8.0 "seharusnya mendapat pemberitahuan bahwa update 8.1 tersedia begitu dirilis."
• Di thread forum lain, seorang developer mengatakan mereka "berhenti di 1%" pada versi 15.0.1 karena bug kritis dan ingin meluncurkan 15.0.2 secara bertahap juga, dengan harapan 15.0.1 "praktis terlewati bagi sebagian besar pengguna." Balasan sebelumnya di thread itu menyarankan meminta expedited review selama versi bermasalah dijeda, dan mungkin menarik aplikasi dari penjualan "agar tidak ada pengguna baru yang mengambil versi rusak itu." Sebelum melakukannya, ingat aturan penarikan dari penjualan di kotak peringatan di atas.
• Tim pembuat alat rilis di balik catatan store-quirks Tramline mendokumentasikan bahwa memulai rilis baru "hanya akan membatalkan peluncuran yang sedang berjalan," dan versi lama berpindah ke REPLACED_WITH_NEW_VERSION dengan rilis bertahapnya ditandai COMPLETE. Catatan yang sama menyebut jeda "tidak bisa berbuat apa-apa terhadap pengguna yang sudah menerima update."

Di ketiga kasus, menjeda hanya memberi waktu. Perbaikannya selalu berupa versi baru, dan tidak ada yang bisa mengandalkan bahwa kohort yang sama akan diperbarui lebih dulu. Itulah sebabnya flag sisi server dan branch hotfix yang bisa dirilis cepat lebih penting daripada tombol jeda.

Bagaimana perbandingannya dengan staged rollout Google Play?

Staged rollout Google Play memakai persentase yang Anda pilih dan naikkan secara manual. Setelah dihentikan, peluncuran yang dilanjutkan menjangkau kelompok pengguna yang sama. Rencanakan peluncuran di kedua store secara terpisah.

Menurut Play Console Help, "persentase staged rollout aplikasi Anda tidak akan naik secara otomatis," dan staged rollout "hanya dapat digunakan untuk update aplikasi, bukan saat memublikasikan aplikasi untuk pertama kali." Setelah dihentikan, pengguna yang sudah menerima versi tersebut tetap memakainya, dan Google menyarankan merilis versi baru dengan bundle yang sudah diperbaiki alih-alih melanjutkan versi yang rusak. Peluncuran produksi bisa dibatasi ke negara tertentu, tetapi setelah dimulai, Anda tidak bisa menghapus negara. Jika update Android berikutnya juga harus memenuhi target SDK baru, lihat panduan kami tentang target API level 36 di Google Play.

Apa yang perlu diperiksa sebelum memulai rilis bertahap?

Sebelum peluncuran dimulai, pastikan rilis bertahap sudah disimpan pada versi, baseline dan pemicu jeda sudah tertulis, dan perbaikan bisa dirilis dengan cepat. Gunakan checklist ini:

• Rilis bertahap dipilih dan disimpan di halaman versi
• Dasbor crash reporting dan error backend sudah di-bookmark, dengan baseline dari versi sebelumnya
• Pemicu jeda tertulis yang disepakati semua orang yang berwenang menekan tombolnya
• Fitur berisiko berada di balik flag sisi server
• Satu orang yang ditunjuk untuk memeriksa metrik di setiap hari dari 7 hari
• Branch hotfix siap, ditambah checklist submission App Store kami untuk build lanjutan
• Perubahan listing store ditahan sampai peluncuran menjangkau semua pengguna

Jika Anda lebih suka menyerahkan proses rilisnya, layanan submission App Store kami mencakup penyiapan App Store Connect dan Play Console, persiapan review, dan rilis di kedua store seharga $599 (biaya akun developer terpisah). Untuk pendapat kedua tentang update yang berisiko, kirim email ke yagyeshsrbobde@gmail.com berisi aplikasi Anda dan apa saja yang berubah.