Penolakan App Store: cara memperbaikinya, pedoman demi pedoman (2026)

Penolakan App Store adalah pesan dari App Review yang mengutip sebuah pedoman, menjelaskan apa yang dilihat reviewer, dan menahan rilis sampai Anda memperbaikinya, menjelaskannya, atau mengajukan banding. Mulailah dengan mengubah pesan itu menjadi masalah yang bisa Anda uji. Langkah berikutnya bergantung pada apakah reviewer tidak bisa menggunakan aplikasi, menemukan ketidaksesuaian kebijakan, atau membutuhkan informasi tambahan. Per Oktober 2026, App Review Guidelines terakhir diperbarui pada 16 Oktober 2026, jadi periksa penomoran terkini sebelum Anda mengutip suatu bagian.

Apa yang sebenarnya disampaikan pesan penolakan App Store?

Pesan penolakan App Store menyebutkan pedoman yang diterapkan reviewer, menjelaskan perilaku spesifik yang mereka lihat, dan mencantumkan langkah selanjutnya. Pesan ini sering menyertakan perangkat, versi iOS, dan tangkapan layar.

Simpan pesan lengkapnya, semua tangkapan layar, nomor build, dan detail perangkat. Baca bagian yang dikutip di halaman pedoman terkini. Lalu tulis satu kalimat: "Reviewer tidak dapat menyelesaikan X karena Y." Jika pesan tersebut meminta informasi yang kurang alih-alih melaporkan cacat, catat dengan tepat apa yang kurang. Teks standar Apple untuk 2.1 juga memberi tahu cara mereproduksi masalahnya: "Untuk aplikasi baru, hapus instalan semua versi sebelumnya dari perangkat, lalu instal dan ikuti langkah-langkah untuk mereproduksi masalah."

• Apakah pesan menyebut crash, layar yang tidak dapat diakses, atau fitur yang belum lengkap? Reproduksi alur tersebut di build rilis yang dikirim, pada jenis perangkat yang disebut Apple.
• Apakah pesan menyebut tangkapan layar, deskripsi, atau catatan review? Periksa apakah Anda bisa memperbaikinya hanya lewat metadata.
• Apakah pesan menyebut pembayaran, login, privasi, atau fungsionalitas minimum? Bandingkan perilaku produk dengan pedoman yang dikutip.

Pedoman mana yang sering dikutip dalam penolakan App Store, dan apa syaratnya?

Setiap pedoman menetapkan persyaratan yang konkret, jadi cocokkan nomor yang dikutip dengan bunyinya dan uji aplikasi berdasarkan bunyi tersebut. Tabel berikut mengutip teks terkini dari pedoman yang umum muncul dalam pesan penolakan.

Pembaruan 16 Oktober 2026 menambahkan 2.5.19 untuk fitur tersembunyi, tidak aktif, atau tidak terdokumentasi, yang sebelumnya diatur di 2.3.1. Pembaruan ini juga menambahkan 2.3.14 tentang aset kreatif dan menggabungkan entitlement Music Streaming Services ke dalam entitlement StoreKit External Purchase Link di bawah 3.1.1(a). Anggap tabel ini sebagai titik awal, bukan perbaikan yang dijamin berhasil. Satu pedoman bisa mencakup berbagai masalah, dan contoh dari reviewer adalah kasus konkret yang harus Anda selesaikan.

Bagaimana cara memperbaiki penolakan 4.2 minimum functionality?

Perbaiki penolakan 4.2 dengan menambahkan nilai aplikasi yang nyata, bukan dengan mengubah kata-kata deskripsi. Pedoman 4.2 berbunyi: "Jika aplikasi Anda tidak terlalu berguna, unik, atau 'terasa seperti aplikasi', aplikasi itu tidak layak berada di App Store."

Tanyakan apa yang bisa dilakukan seseorang di aplikasi Anda sehingga aplikasi itu berguna sebagai aplikasi. Mereka mungkin menyelesaikan suatu alur kerja, menyimpan state yang bermakna, menggunakan kemampuan perangkat dengan cara yang sesuai dengan aplikasi, atau mendapatkan pengalaman seluler yang dibangun khusus untuk perangkat tersebut. Tidak ada daftar fitur resmi yang menjamin persetujuan. Jika alur kerja tersebut sudah ada, cantumkan di catatan review beserta langkah persis dan tangkapan layar. Jika aplikasi sebagian besar hanya menampilkan halaman web, aplikasi itu butuh pengembangan produk. Menambahkan notifikasi atau layar pengaturan kosong sekadar agar terlihat native tidak menggantikan nilai nyata bagi pengguna.

Bagaimana cara membalas App Review di App Store Connect?

Balas di App Store Connect: buka pengiriman melalui tautan masalah yang belum terselesaikan pada aplikasi, klik Resolve, lalu klik Reply to App Review. Menurut halaman bantuan Apple, langkah ini memerlukan peran Account Holder, Admin, atau App Manager.

1. Di Apps, pilih aplikasinya.
2. Di bagian atas halaman, klik tautan yang menunjukkan adanya masalah yang belum terselesaikan.
3. Di bagian In Progress, klik Resolve di samping pengiriman tersebut.
4. Klik Reply to App Review dan masukkan teks Anda.
5. Untuk menyertakan tangkapan layar atau dokumen, klik Attach File, lalu klik Reply.

Apple menyatakan Anda dapat berkorespondensi dan melampirkan file "hingga Anda mengirim ulang ke App Review", jadi kirimkan bukti Anda sebelum mengirim ulang. Buat balasan singkat dan faktual: sebutkan apa yang berubah, di mana letaknya, dan cara memverifikasinya. Jangan berdebat soal aplikasi lain yang tampaknya melakukan hal yang sama.

Perbaiki metadata, unggah build baru, atau ajukan banding?

Perbaiki metadata dan kirim ulang build yang sama jika hanya informasi listing yang salah. Unggah build baru jika perilaku aplikasi harus diubah. Ajukan banding hanya jika Anda yakin aplikasi sudah mematuhi pedoman.

Panduan banding Apple meminta Anda untuk "menjelaskan poin demi poin bagaimana aplikasi Anda memenuhi" pedoman tersebut. Panduan itu juga menyatakan agar tidak mengajukan banding setelah Anda memperbaiki masalah dan mengirim ulang. Banding yang lengkap "tidak menjamin" keputusan akan dibatalkan. Untuk aplikasi yang sudah ada di store, kebijakan Bug Fix Submissions dalam pedoman menyatakan bahwa perbaikan bug tidak akan ditunda karena pelanggaran pedoman "kecuali yang terkait masalah hukum atau keselamatan".

Bagaimana developer lain memperbaiki penolakan App Store yang nyata?

Di thread forum publik, banyak penolakan 2.1 berasal dari perbedaan antara pengaturan reviewer dan developer: jaringan, perangkat, atau status izin yang berbeda. Penolakan 4.2 adalah masalah produk, jadi penyesuaian kecil jarang berhasil.

Error login di bawah 2.1. Seorang developer di Apple Developer Forums mengutip pesan "Secara spesifik, kami tidak dapat login karena terjadi error", padahal versi live dan TestFlight bisa login dengan kredensial yang sama. Developer lain di thread tersebut melaporkan perbaikan yang berbeda-beda. Satu orang memperbaikinya dengan "mengubah http menjadi https di web server". Yang lain, setelah tiga kali ditolak, menambahkan status "Periksa koneksi Anda" alih-alih loader yang berputar tanpa henti. Orang ketiga menghapus iPad dari deployment target setelah lima kali ditolak, yang sebenarnya hanya mengakali masalah dengan menghentikan dukungan iPad.

Crash saat dibuka. Di forum Solar2D, seorang developer menerima pesan "Kami tidak dapat meninjau aplikasi karena aplikasi crash saat dibuka" pada iPhone 13 mini dengan iOS 18.3.2. Crash log yang dilampirkan menunjukkan key NSUserTrackingUsageDescription yang hilang. Developer itu mengonfirmasi: "Lolos setelah menambahkan: NSUserTrackingUsageDescription."

Aplikasi WebView di bawah 4.2. Seorang developer di Apple Developer Forums melaporkan penolakan ke-10 untuk aplikasi berbasis WebView. Reviewer mengirim tangkapan layar menu kiri dan menyatakan menu itu kurang konten. Layar-layar utama sudah native, tetapi dua atau tiga layar masih membuka WebView. Balasan yang ditandai sebagai jawaban datang dari App Review dan merekomendasikan konsultasi App Review empat mata. Thread tersebut tidak mengonfirmasi adanya persetujuan.

Perbandingannya: kasus 2.1 diselesaikan dengan mereproduksi kondisi reviewer dan membaca crash log. Kasus 4.2 macet karena setiap pengiriman ulang hanya mengubah sebagian dari aplikasi yang sebagian besar masih berupa situs web.

Bagaimana mencegah penolakan yang sama terulang?

Jadikan setiap masalah yang sudah selesai sebagai item checklist rilis dan uji ulang di build rilis sebelum setiap pengiriman. Pedoman Apple memperingatkan bahwa review "akan memakan waktu lebih lama" jika sebuah aplikasi berulang kali ditolak karena pelanggaran pedoman yang sama.

• Hapus aplikasi, lalu instal ulang build rilis dari awal di iPhone dan iPad fisik.
• Login dengan akun review di jaringan tanpa server pengembangan atau pengecualian HTTP.
• Buka setiap prompt izin dan pastikan setiap usage description di Info.plist tersedia.
• Pastikan setiap in-app purchase sudah dikirim, terlihat, dan dijelaskan di catatan review.
• Perbarui catatan review setiap kali alur berubah. Jangan menempelkan catatan dari enam rilis yang lalu.

Untuk masalah 2.1, ikuti rencana pengujian build rilis untuk penolakan 2.1 dan siapkan akun demo untuk reviewer. Lalu jalankan checklist pengiriman untuk build berikutnya. Jika pesan review masih membuat Anda buntu, kirimkan detailnya kepada kami dan kami akan membantu Anda mengetahui apakah yang kurang adalah akses, metadata, atau kode.