Penolakan App Store 2.1 App Completeness: rencana uji build rilis sebelum mengirim ulang (2026)

Penolakan App Store berdasarkan 2.1 App Completeness berarti peninjau tidak bisa memakai aplikasi Anda seperti seorang pelanggan. Mungkin aplikasinya crash, menampilkan konten placeholder, menghalangi mereka di layar login, atau menyembunyikan pembelian dalam aplikasi. Perbaikannya jarang hanya satu baris kode. Sebelum mengirim ulang, jalankan rencana uji singkat pada build rilis, dengan instalasi baru dan kredensial yang sama dengan yang Anda berikan ke App Review. Artikel ini menguraikan rencana tersebut dan menunjukkan bagaimana developer lain memperbaiki penolakan yang sama.

Apa yang diperiksa pedoman App Store 2.1 App Completeness?

Pedoman 2.1 memeriksa bahwa build yang Anda kirim adalah aplikasi yang sudah jadi dan berfungsi. Build itu memerlukan metadata lengkap, tautan yang berfungsi, login demo, back end yang aktif, serta pembelian dalam aplikasi yang bisa ditemukan dan dipakai peninjau.

App Review Guidelines dari Apple membagi 2.1 menjadi dua bagian. 2.1(a) menyatakan bahwa pengiriman "harus berupa versi final dengan semua metadata yang diperlukan dan URL yang berfungsi penuh" serta teks placeholder dan situs web kosong harus dihapus. Bagian ini juga meminta Anda menguji di perangkat untuk mencari bug dan memastikan stabilitas, serta "sertakan info akun demo (dan nyalakan layanan back-end Anda!) jika aplikasi Anda memiliki login." Apple "akan menolak bundle dan binary aplikasi yang tidak lengkap, yang crash, atau yang menunjukkan masalah teknis yang jelas." 2.1(b) menyatakan bahwa pembelian dalam aplikasi harus "lengkap, mutakhir, terlihat oleh peninjau, dan berfungsi." Jika pembelian yang sudah dikonfigurasi tidak dapat ditemukan di aplikasi, jelaskan alasannya di catatan review.

Penolakan ini umum terjadi. Halaman Preparing for App Review dari Apple menyebutkan: "Rata-rata, lebih dari 40% masalah yang belum terselesaikan terkait pedoman 2.1: App Completeness, yang mencakup crash, konten placeholder, informasi yang tidak lengkap, dan lainnya."

Mengapa menguji build debug tidak menangkap masalah 2.1?

Build debug tidak berjalan seperti salinan milik peninjau. Peninjau menginstal build rilis bertanda tangan distribusi di perangkat bersih, tanpa sesi tersimpan dan tanpa jalan pintas debug.

Simulator Anda sudah dalam keadaan login. API lokal Anda mungkin mengarah ke server staging yang tidak pernah mati. Flag debug melewati paywall, dan feature flag aktif secara default. Peninjau tidak mendapatkan semua itu. Halaman review Apple juga meminta Anda untuk "menguji secara menyeluruh di perangkat yang menjalankan perangkat lunak terbaru," jadi peninjau mungkin memakai iOS yang lebih baru daripada ponsel uji Anda.

TestFlight adalah cara paling mendekati kondisi peninjau. Menurut ikhtisar TestFlight, Anda bisa menambahkan hingga 100 penguji internal dari tim App Store Connect Anda dan hingga 10.000 penguji eksternal. Sebuah build bisa diuji hingga 90 hari. Unggah build yang persis akan Anda kirim, instal dari TestFlight di perangkat yang belum pernah menjalankan aplikasi itu, lalu uji salinan tersebut.

Apa saja yang harus dicakup rencana uji build rilis sebelum mengirim ulang?

Rencana uji build rilis memeriksa setiap titik di mana peninjau baru bisa tertahan: peluncuran, izin, login, back end, konten, tautan, pembelian, gangguan jaringan, dan iPad. Jalankan langkah-langkahnya secara berurutan pada build TestFlight dan catat setiap hasilnya agar bisa Anda kutip di catatan review.

1. Instalasi bersih di iOS terbaru. Hapus salinan sebelumnya, instal dari TestFlight, dan buka tanpa status tersimpan. Lakukan cold launch tiga kali dan pastikan onboarding tidak crash.
2. Tolak setiap permintaan izin satu kali. Tolak notifikasi, lokasi, kamera, dan pelacakan. Aplikasi tetap harus mencapai layar yang bisa dipakai. Pastikan juga Info.plist memiliki usage description untuk setiap sumber daya terlindungi yang dipakai aplikasi atau SDK-nya.
3. Masuk dengan kredensial demo yang persis sama. Salin dari App Store Connect, bukan dari pengelola kata sandi Anda. Akun tersebut harus berisi data yang realistis, tidak memerlukan verifikasi email, dan tidak memakai autentikasi dua faktor yang terhubung ke ponsel Anda sendiri.
4. Pastikan back end adalah produksi dan aktif. Build harus mengarah ke endpoint produksi. Rate limit, allowlist IP, dan geo-blocking tidak boleh mengunci peninjau. Pedoman 2.1(a) meminta Anda menyalakan layanan back-end.
5. Telusuri setiap tab dan layar. Cari lorem ipsum, layar "Segera hadir", tampilan kosong tanpa penjelasan, gambar uji, dan tombol yang tidak melakukan apa-apa.
6. Ketuk setiap tautan. Termasuk kebijakan privasi, dukungan, ketentuan layanan, dan web view apa pun. Apple menyatakan "Tautan ke dukungan pengguna dengan informasi kontak terbaru dan tautan ke kebijakan privasi Anda wajib ada untuk semua aplikasi."
7. Buka setiap pembelian dalam aplikasi. Masuk sebagai akun baru. Periksa bahwa setiap produk yang dikirim bersama versi tersebut muncul dengan harga, bisa dibeli di sandbox, dan bahwa Restore Purchases berfungsi.
8. Uji di jaringan yang lambat atau terputus. Nyalakan mode pesawat di tengah alur. Pesan galat yang jelas tidak masalah. Spinner yang tidak pernah berhenti, atau crash, tidak dapat diterima.
9. Periksa iPad jika Anda mendukungnya. Jika aplikasi berjalan di iPad, buka di sana dan pastikan tata letaknya tidak membuat pengguna terjebak.

Akun demo di langkah 3 menyebabkan penolakan berulang lebih sering daripada langkah lainnya. Panduan kami tentang menyiapkan akun demo untuk review App Store menjelaskan cara membuat akun yang awet.

Bagaimana memetakan pesan penolakan 2.1 ke perbaikannya?

Untuk memetakan penolakan 2.1 ke perbaikannya, baca kalimat setelah nomor pedoman. Kalimat itu menyebutkan gejalanya, dan setiap gejala mengarah ke satu langkah dalam rencana uji.

Misalkan aplikasi pelacak kebiasaan ditolak dengan pesan "We were unable to review the app because it crashed on launch." Catatan kedua menyebutkan bahwa peninjau tidak dapat menemukan pembelian dalam aplikasi. Tabel di bawah mencocokkan gejala umum dengan penyebab, pengujian, dan perbaikannya.

Untuk metode yang lebih luas dalam membaca pesan penolakan apa pun, lihat Penolakan App Store: cara memperbaikinya, pedoman demi pedoman.

Seperti apa penolakan 2.1 yang dialami developer lain?

Kasus 2.1 yang dipublikasikan mengikuti pola yang sama. Aplikasi berjalan di lingkungan developer dan gagal bagi peninjau karena sesuatu yang hanya terungkap lewat instalasi baru atau login orang asing.

• Crash karena usage description yang hilang. Di forum Solar2D, seorang developer menerima pesan "We were unable to review the app because it crashed on launch" pada iPhone 13 mini dengan iOS 18.3.2, padahal aplikasinya berjalan di TestFlight. Anggota lain menemukan ini di log crash yang dilampirkan: "This app has crashed because it attempted to access privacy-sensitive data without a usage description." Developer tersebut melaporkan, "It passed after adding : NSUserTrackingUsageDescription."
• Login sosial yang tidak bisa dipakai peninjau. Seorang developer di Apple Developer Forums melaporkan penolakan 2.1 berulang karena peninjau "were unable to use social logins." Mereka sudah memberikan akun demo Apple dan Google, tetapi login Apple ID memerlukan kode verifikasi yang dikirim ke ponsel developer. Staf Apple membalas bahwa App Review akan menghubungi mereka secara langsung. Tidak ada perbaikan yang dipublikasikan.
• Pembelian dalam aplikasi "could not be found in the submitted binary." Dalam thread komunitas RevenueCat, seorang developer ditolak karena paket bulanan tidak ditemukan di binary, padahal pembelian sandbox berfungsi. Seorang penolong mengatakan penolakan serupa terselesaikan dengan membalas berisi panduan terperinci dan tangkapan layar setiap jalur menuju paywall. Staf RevenueCat menyarankan untuk menampilkan setiap produk yang dikirim di paywall default dan menjauhkan file pengujian StoreKit dari skema Archive.

Dalam ketiga kasus tersebut, pengujian developer sendiri lolos. Kegagalannya baru muncul dari titik awal peninjau: tanpa ponsel 2FA, tanpa sesi sebelumnya, dan tanpa tahu letak paywall. Titik awal itulah yang dibuat ulang oleh rencana uji di atas.

Apa yang harus ditulis di catatan App Review setelah penolakan 2.1?

Catatan review setelah penolakan 2.1 harus memberikan kredensial demo yang berfungsi, mencantumkan apa yang berubah sejak build yang ditolak, dan menyebutkan dengan tepat di mana menemukan pembelian dalam aplikasi serta fitur yang tidak langsung terlihat.

Halaman review Apple meminta Anda menaruh detail akun dan konfigurasi khusus di bagian App Review Information. Jika sebuah fitur memerlukan perangkat keras atau lingkungan yang sulit disiapkan, "bersiaplah untuk menyediakan video demo atau perangkat kerasnya." Pedoman 2.3.1(a) menambahkan bahwa fitur baru harus dijelaskan "secara spesifik" di Notes for Review, dan bahwa "deskripsi generik akan ditolak." Catatan singkat yang terstruktur bekerja dengan baik:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Jika kewajiban hukum atau keamanan tidak memungkinkan adanya akun demo, pedoman 2.1(a) mengizinkan mode demo bawaan, tetapi hanya dengan persetujuan Apple terlebih dahulu, dan mode tersebut harus menampilkan seluruh fitur dan fungsi aplikasi. Jangan beralih ke mode demo tanpa persetujuan itu.

Bagaimana mengirim ulang atau mengajukan banding atas penolakan 2.1?

Untuk mengirim ulang setelah penolakan 2.1, unggah atau pilih build yang sudah Anda uji, balas App Review di App Store Connect dengan apa yang Anda ubah, perbarui catatan review, lalu kirim lagi. Ajukan banding hanya jika Anda yakin peninjau salah memahami aplikasi Anda.

1. Pastikan nomor build yang terpasang pada versi di App Store Connect sama dengan build TestFlight yang Anda uji.
2. Balas pesan penolakan dengan ringkasan singkat setiap perbaikan. Untuk masalah pembelian atau navigasi, tambahkan petunjuk langkah demi langkah dan tangkapan layar.
3. Perbarui bagian App Review Information dengan kredensial dan catatan terbaru.
4. Kirim untuk review. Per Oktober 2026, Apple menyatakan biasanya meninjau "setidaknya 50% pengiriman dalam waktu kurang dari 24 jam dan 90% dalam waktu kurang dari 48 jam."

Jika Anda yakin Apple keliru, halaman App Review memungkinkan Anda mengajukan banding ke App Review Board. Berikan alasan spesifik mengapa aplikasi Anda patuh, dan "Ajukan hanya satu banding per pengiriman yang tidak lolos review." Namun untuk penolakan 2.1, mereproduksi masalahnya di perangkat bersih biasanya lebih cepat daripada berdebat. Jika Anda lebih suka menyerahkan pengiriman ulangnya, layanan pengiriman App Store kami mencakup persiapan review dan penanganan umpan balik penolakan untuk kedua toko seharga $599, belum termasuk biaya akun developer.

Masalah 2.1 sering muncul kembali di pembaruan berikutnya: feature flag baru, API key yang dirotasi, atau akun demo yang kedaluwarsa. Tambahkan rencana uji ini ke rutinitas rilis Anda bersama checklist pengiriman App Store. Untuk pembaruan, phased release membatasi jumlah pengguna yang terkena bug yang terlewat. Untuk mendapatkan pendapat kedua tentang build yang ditolak, kirim email ke yagyeshsrbobde@gmail.com beserta pesan penolakannya.