Biaya nyata di balik review App Store bagi tim

Menampilkan semua 117 cerita.

1. 

   4.3(a) Spam iOS Pedoman 4.3

   Seluruh portofolio kena flag sekaligus

   Apa yang terjadi

   Seorang developer dengan beberapa aplikasi dari starter project yang sama menerima notifikasi 4.3 yang identik untuk setiap aplikasi: aplikasi-aplikasi tersebut memiliki binary, metadata, atau konsep serupa dengan perbedaan minor. Developer tersebut memutuskan untuk menangani aplikasi itu satu per satu.

   Solusi

   Masih dalam proses saat diposting.

   Pelajaran

   4.3(a) juga mencakup tumpang tindih di antara aplikasi Anda sendiri. Jika beberapa aplikasi dikembangkan dari satu template, masing-masing perlu core yang benar-benar berbeda, bukan sekadar ganti ikon dan nama.

2. 

   4.3(a) Spam iOS Pedoman 4.3

   Surat yang sama dua kali dalam satu minggu

   Apa yang terjadi

   Sebuah aplikasi pembantu fotografi sederhana dengan satu fungsi ditolak berdasarkan 4.3(a) di tengah malam, seminggu setelah menerima teks penolakan yang persis sama untuk build sebelumnya.

   Solusi

   Tidak disebutkan.

   Pelajaran

   Resubmit dengan perubahan kosmetik jarang mengubah keputusan 4.3. Ubah konsepnya atau jelaskan dengan jelas di review notes apa yang membuat aplikasi ini berbeda.

3. 

   4.3 Desain / Spam iOS Pedoman 4.3

   Membangun di kategori yang padat

   Apa yang terjadi

   Seorang solo builder yang mendokumentasikan tantangan build harian kena penolakan 4.3 Design / Spam di hari keempat dan mulai mempertanyakan apakah memilih kategori yang jenuh itu sebuah kesalahan.

   Solusi

   Tidak disebutkan.

   Pelajaran

   Kategori yang Apple tandai sebagai jenuh akan diperiksa lebih ketat. Validasi pembeda aplikasi Anda sebelum build, bukan setelah review.

5. 

   2.1 Informasi yang Dibutuhkan iOS Pedoman 2.1

   Tujuh pertanyaan untuk akun baru

   Apa yang terjadi

   Submission pertama sebuah tim dikembalikan dengan alasan 2.1 Information Needed: tujuh pertanyaan, permintaan screen recording, dan akun demo. Menjawab dengan jujur memunculkan empat hal yang mereka lewatkan.

   Solusi

   Mereka sudah memperbaiki masalahnya dan membalas.

   Pelajaran

   Akun developer baru harus mengantisipasi hal ini. Siapkan akun demo, rekaman, dan catatan review yang jelas sebelum submit.

6. 

   2.1 Kelengkapan Aplikasi iOS Pedoman 2.1

   Reviewer tidak bisa mengikuti alur aplikasi

   Apa yang terjadi

   Seorang developer pemula ditolak dua kali sebelum bisa rilis. Penolakan pertama, berdasarkan poin 2.1, terjadi karena reviewer tidak mengerti bagaimana aplikasi tersebut seharusnya digunakan.

   Solusi

   Disetujui setelah menambahkan video demo yang direkam di perangkat fisik dan catatan review langkah demi langkah.

   Pelajaran

   Reviewer hanya punya waktu singkat tanpa konteks. Beritahu mereka persis apa yang harus diklik dan apa yang seharusnya muncul.

7. 

   Setup metadata dan in-app purchase iOS Metadata dan IAP

   Dua penolakan karena checkbox yang sudah diketahui

   Apa yang terjadi

   Seorang indie developer ditolak dua kali karena hal yang sebenarnya sudah mereka tahu. Pertama, build dikirim tanpa in-app purchase terlampir dan deskripsi tidak mencantumkan link syarat penggunaan. Beberapa minggu kemudian, sebuah screenshot menyebut aplikasi itu gratis.

   Solusi

   Diperbaiki dan dikirim ulang setiap kali.

   Pelajaran

   Siapkan checklist pra-submission untuk metadata, subscription, dan link legal. Sebagian besar penolakan metadata bisa dihindari.

8. 

   Waktu antrean review iOS Review tanpa akhir

   9 hari menunggu, lalu 8 hari dalam review

   Apa yang terjadi

   Seorang developer menunggu sembilan hari agar status berubah dari Waiting for Review ke In Review, lalu tertahan di tahap review selama delapan hari lagi tanpa update.

   Solusi

   Tidak ada saat diposting.

   Pelajaran

   Waktu review tidak dijamin. Jangan pernah mengaitkan tanggal peluncuran, kampanye pers, atau kampanye kreator dengan perkiraan tanggal approval.

9. 

   Waktu antrean review iOS Review tanpa akhir

   20 hari terjebak siklus reject, fix, tunggu

   Apa yang terjadi

   Lebih dari 20 hari, seorang developer melewati rejection, fix, Waiting for Review, rejection, fix, dan masih menunggu saat posting ini dibuat.

   Solusi

   Menunggu.

   Pelajaran

   Setiap siklus bisa memakan waktu berhari-hari. Gabungkan semua fix dari catatan rejection ke dalam satu build.

10. 

    Penghentian akun iOS Penghentian akun

    Ditutup sebelum review pertama

    Apa yang terjadi

    Seorang developer dengan pengalaman sepuluh tahun akun developernya diterminasi, disertai tuduhan fraud yang tidak menyebutkan apa yang mereka lakukan, sementara game belajar bahasanya masih menunggu review pertama. Aplikasi yang sudah ada hilang dan pelanggan mulai bertanya kenapa.

    Solusi

    Tidak ada laporan.

    Pelajaran

    Terminasi akun menghapus semua aplikasi sekaligus. Miliki kanal sendiri untuk pengguna (email, website) agar Anda bisa menjangkau mereka jika toko aplikasi hilang.

11. 

    Peringatan terminasi akun iOS Penghentian akun

    Terlalu banyak versi yang ditolak

    Apa yang terjadi

    Seorang developer indie yang produktif menerima pemberitahuan bahwa akun mereka akan ditutup dalam sepuluh hari. Apple mengindikasikan banyaknya versi yang ditolak sebagai salah satu alasannya. Setelah mendapat perhatian publik dan mengajukan banding, akun tersebut tidak jadi ditutup.

    Solusi

    Akun tetap aktif setelah banding.

    Pelajaran

    Penolakan terus menumpuk. Hindari resubmit di hari yang sama hanya dengan mengubah satu kata atau mengirimkan klon aplikasi Anda yang hampir identik.

12. 

    Syarat login (nomor guideline tidak disebutkan) iOS Persyaratan login

    Wajib daftar: aplikasi Anda tidak sebesar itu

    Apa yang terjadi

    Sebuah aplikasi sosial milik developer ditolak karena mewajibkan pengguna membuat akun sebelum bisa melihat home feed. Saat developer menjelaskan bahwa setiap user butuh handle agar aplikasi bisa berfungsi sama sekali, dan mencontohkan jaringan berbagi foto besar yang melakukan hal serupa, reviewer menjawab, pada intinya, bahwa aplikasi mereka bukan jaringan sebesar itu.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Apa yang bisa lolos di aplikasi besar bukanlah preseden yang bisa Anda jadikan acuan. Jika Anda mewajibkan pendaftaran, jelaskan di catatan review mengapa fitur utama tidak bisa berjalan tanpa akun, dan pertimbangkan untuk membiarkan reviewer atau tamu melihat sebagian konten terlebih dahulu.

13. 

    4.3 Spam iOS Pedoman 4.3

    Dari tidak ada review sama sekali hingga hampir semua ditolak

    Apa yang terjadi

    Seorang developer melihat tidak ada satu pun aplikasinya yang direview selama berhari-hari. Selama sekitar seminggu, sambil menunggu, mereka membuat lebih banyak submission. Saat review akhirnya berjalan, hampir semuanya kembali ditolak dengan alasan guideline 4.3 spam.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Antrean yang macet bukan sinyal untuk terus submit. Menumpuk submission saat tidak ada yang direview bisa membuat akun Anda terlihat seperti pola spam saat reviewer akhirnya melihat semuanya sekaligus.

14. 

    4.3 Spam iOS Pedoman 4.3

    Aplikasi tidak terkait ditolak bersamaan

    Apa yang terjadi

    Seorang developer punya beberapa aplikasi, dibangun selama berbulan-bulan dan tidak saling terkait, tetapi semuanya ditolak sebagai spam pada saat yang sama. Developer itu bertanya secara publik apakah itu normal.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Aturan 4.3 bisa diterapkan di level akun, bukan per aplikasi. Jika beberapa aplikasi ditolak sekaligus, jawablah satu per satu dan jelaskan secara detail di catatan review apa yang membuat setiap aplikasi berbeda.

15. 

    Waktu antrean review iOS Review tanpa akhir

    Satu penolakan, lalu dua bulan tanpa kabar

    Apa yang terjadi

    Setelah satu kali penolakan, aplikasi seorang developer tertahan di tahap review selama sekitar dua bulan, dengan setiap siklus review memakan waktu sekitar sebulan. Mereka menduga siklus yang panjang sudah menjadi cara untuk menahan aplikasi baru.

    Solusi

    Masih tertahan saat postingan ini dibuat.

    Pelajaran

    Setelah penolakan, siklus berikutnya bisa jauh lebih lambat daripada yang pertama. Pastikan pengajuan ulang Anda lengkap dan didokumentasikan dengan baik agar tidak menghabiskan waktu sebulan lagi untuk putaran kedua.

16. 

    Konten yang tidak pantas iOS Konten yang tidak pantas

    Ditolak karena mengirim ulang tanpa perbaikan

    Apa yang terjadi

    Aplikasi edit foto AI ditolak karena telah dikirim ulang beberapa kali tanpa memperbaiki masalah yang ditandai Apple, yaitu konten yang tidak pantas.

    Solusi

    Ditolak.

    Pelajaran

    Mengirim ulang build yang sama dengan harapan mendapat reviewer berbeda bisa merugikan Anda. Perbaiki masalah yang ditandai, atau minta klarifikasi melalui Resolution Center sebelum mengirim ulang. Untuk fitur AI generatif, tambahkan filter untuk konten yang dianggap tidak pantas oleh Apple.

17. 

    4.3 Spam iOS Pedoman 4.3

    Ditolak di menit yang sama saat review dimulai

    Apa yang terjadi

    Seorang developer menghabiskan berminggu-minggu membangun aplikasi, tapi ditolak dengan alasan 4.3 spam di menit yang sama saat masuk review. Developer itu yakin reviewer menilai niche-nya, bukan aplikasinya.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Di niche yang padat, penolakan 4.3 bisa datang sebelum ada yang melihat lebih teliti. Awali catatan review dengan hal yang unik dan arahkan reviewer langsung ke sana.

18. 

    Template 4.2.6 iOS Pedoman 4.2.6

    Ditandai karena template yang tidak pernah digunakan

    Apa yang terjadi

    Tim ditolak berdasarkan guideline 4.2.6, yang mencakup aplikasi yang dibuat dari template komersial atau layanan generator aplikasi, padahal mereka sama sekali tidak memakai template atau layanan generator apa pun.

    Solusi

    Tidak disebutkan.

    Pelajaran

    4.2.6 bisa jadi false positive. Balas di Resolution Center dan nyatakan dengan jelas bahwa aplikasi ini dibuat secara custom serta siapa yang membuatnya, lalu tawarkan untuk menunjukkan source code atau riwayat pengembangannya.

19. 

    3.1.2 Langganan iOS Pedoman 3.1.2

    Harga bulanan lebih tinggi daripada harga yang ditagihkan

    Apa yang terjadi

    Paywall seorang developer ditolak karena harga bulanan hasil perhitungan dari langganan yang lebih panjang ditampilkan lebih menonjol daripada jumlah yang sebenarnya ditagihkan. Paywall yang sama sebelumnya lolos review tanpa komentar. Mereka setuju dengan aturan itu, tetapi frustrasi karena baru sekarang ditandai, lalu mendesain ulang paywall agar mengutamakan jumlah yang ditagihkan.

    Solusi

    Diajukan ulang dengan desain baru.

    Pelajaran

    Paywall yang pernah lolos bisa saja ditolak kemudian. Selalu jadikan jumlah yang ditagihkan dan periodenya sebagai harga paling menonjol; tampilkan rincian per bulan lebih kecil dan bersifat sekunder.

20. 

    Enrollment (bukan pedoman App Review) Program Apple Developer Pendaftaran dan akun

    Dua bulan, lalu ditolak tanpa alasan

    Apa yang terjadi

    Seorang developer menghabiskan lebih dari dua bulan untuk mencoba enrollment, dengan banyak panggilan support dan email, verifikasi identitas, detail perangkat, bahkan bukti video. Apple lalu menolak enrollment itu tanpa alasan spesifik.

    Solusi

    Tidak ada saat diposting.

    Pelajaran

    Enrollment bisa memakan waktu jauh lebih lama daripada membangun app. Mulai enrollment lebih awal, sebelum rencana peluncuran Anda bergantung padanya, dan simpan catatan setiap komunikasi dengan support.

21. 

    5.1.2 Penggunaan dan pembagian data iOS Pedoman 5.1.2

    Penolakan App Tracking Transparency yang mengancam startup

    Apa yang terjadi

    Setelah beberapa bulan merilis dengan cepat dan mendapat feedback pengguna yang kuat, aplikasi sebuah startup ditolak pada akhir musim gugur karena App Tracking Transparency, aturan privasi iOS yang mewajibkan izin pengguna sebelum tracking lintas aplikasi dan website. Founder kemudian menyebutnya sebagai penolakan yang membahayakan seluruh perusahaan.

    Solusi

    Tidak disebutkan dalam postingan.

    Pelajaran

    Audit setiap SDK di aplikasi Anda untuk tracking sebelum submit. Jika ada yang menautkan data pengguna dengan data perusahaan lain, Anda perlu prompt izin tracking dan label privasi yang sesuai, meskipun tracking itu berasal dari library pihak ketiga.

22. 

    Login (nomor guideline tidak disebutkan) iOS Masuk

    Reviewer tidak bisa login dengan Apple atau Google

    Apa yang terjadi

    Untuk menghentikan pendaftaran bot, seorang developer menghapus login email dan kata sandi lalu hanya menyisakan Sign in with Apple dan Google sign in. Berhasil di iPhone dan iPad mereka sendiri, bahkan untuk reviewer sebelumnya yang menolak aplikasi karena alasan lain. Reviewer berikutnya menolaknya karena tidak bisa login.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Jika aplikasi Anda hanya menawarkan social login, reviewer tetap bisa terjebak. Beri mereka jalur yang berfungsi di catatan review, seperti akun demo atau login khusus review, dan uji login di perangkat serta akun baru sebelum setiap submission.

23. 

    Simulasi judi (nomor pedoman tidak disebutkan) iOS Simulasi judi

    Fitur staking dalam game pada akun individu

    Apa yang terjadi

    Sebuah game ditolak karena menyertakan simulasi judi: pemain bisa mempertaruhkan item dalam game satu sama lain, mekanik yang umum di game RPG online klasik. Karena developer mempublikasikannya di bawah akun individu, bukan perusahaan, mereka memutuskan untuk menghapus fitur tersebut untuk sementara.

    Solusi

    Menghapus fitur dan submit ulang.

    Pelajaran

    Mekanik bergaya judi diperiksa lebih ketat meski tanpa uang asli, dan apa yang diizinkan Apple bergantung pada tipe akun dan dokumentasi Anda. Cek aturan perjudian sebelum membuat fitur staking, loot, atau wager, dan rencanakan tipe akun developer Anda dengan mempertimbangkan aturan tersebut.

24. 

    Dokumen palsu (nomor guideline tidak disebutkan) iOS Dokumen palsu

    Editor PDF disalahkan atas apa yang mungkin dilakukan pengguna

    Apa yang terjadi

    Sebuah aplikasi editor PDF ditolak karena Apple menyatakan aplikasi itu memungkinkan pengguna membuat ID dan dokumen palsu. Developer berargumen bahwa dengan logika yang sama, aplikasi perbankan atau pesan pun bisa ditolak karena potensi penyalahgunaan oleh oknum jahat.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Tool serbaguna bisa dinilai dari skenario penggunaan terburuknya. Hindari template atau marketing yang menyerupai ID atau sertifikat resmi, dan jelaskan di review notes kegunaan aplikasi serta apa yang tidak didukungnya.

25. 

    Berbagi data AI (nomor guideline tidak disebutkan) iOS Berbagi data AI

    Tidak ada layar persetujuan untuk berbagi data AI pihak ketiga

    Apa yang terjadi

    Sebuah tim mendapat penolakan pertama karena membagikan data pengguna ke penyedia AI pihak ketiga. Apple mewajibkan izin eksplisit dari pengguna plus pengungkapan jelas soal data apa yang dikirim dan ke penyedia AI mana. Kekhawatiran tim itu adalah membangun layar persetujuan yang lolos review tanpa merusak konversi.

    Solusi

    Sedang diproses.

    Pelajaran

    Jika aplikasi Anda mengirim konten pengguna ke layanan AI eksternal, minta persetujuan sebelum request pertama dan sebutkan nama penyedia serta data yang terlibat. Bangun layar itu sebelum submit, bukan setelah ditolak.

26. 

    Entitlement Family Controls (nomor guideline tidak disebutkan dengan jelas) iOS Metadata dan IAP

    Lima kali ditolak gara-gara satu kotak yang terlewat

    Apa yang terjadi

    Seorang developer yang merilis aplikasi bergaya screen time ditolak lima kali. Catatan review yang tidak jelas membuat mereka mengira desainnya yang bermasalah. Ternyata penyebab aslinya adalah satu pengaturan Family Controls yang belum dicentang di setup developer. Begitu dicentang, aplikasi langsung lolos.

    Solusi

    Disetujui setelah mengaktifkan pengaturan Family Controls dan submit ulang.

    Pelajaran

    Jika catatan penolakan tidak spesifik, audit entitlements dan sertifikat Anda sebelum mendesain ulang produk. Aplikasi Screen Time dan Family Controls butuh capability yang sesuai diaktifkan di developer portal, bukan cuma di Xcode.

27. 

    Pedoman 5.1.1(v) iOS Pedoman 5.1.1 Persyaratan login

    Akun wajib untuk fitur berbayar yang berjalan di perangkat

    Apa yang terjadi

    Seorang developer yang datang dari web app ditolak berdasarkan guideline 5.1.1(v). Di web, mereka selalu mengaitkan pembelian dengan akun. Di iOS, Apple yang memegang pembeliannya, jadi pembeli bisa membayar tanpa sign up. Tier berbayar mereka membuka filter on-device yang hanya berjalan di ponsel, tapi baik unlock tier itu maupun Restore purchases tetap mewajibkan pembuatan akun lebih dulu.

    Solusi

    Sedang membangun ulang agar pembelian tanpa akun tetap bisa ditemukan pemiliknya setelah sign up opsional. Masih dalam proses saat posting ini dibuat.

    Pelajaran

    Jika fitur berbayar berjalan di perangkat dan tidak butuh identitas server, biarkan pengguna membeli dan me-restore tanpa akun. Gunakan sign up hanya untuk fitur yang benar-benar membutuhkannya, seperti cloud backup.

28. 

    Pedoman 1.4.2 Bahaya Fisik iOS Pedoman 1.4.2

    Aplikasi kalkulator dosis live ditarik saat aturan diperketat

    Apa yang terjadi

    Seorang developer bangun dan mendapati dua aplikasinya ditandai karena pedoman 1.4.2, padahal tidak ada satu pun yang sedang direview. Keduanya sudah live: kalkulator dosis peptida standalone dan tracker dengan kalkulator yang sama terpasang di dalamnya, yang bersama-sama menjadi kesuksesan pendapatan nyata pertama mereka. Developer lain di niche yang sama melaporkan pemberitahuan yang sama pada waktu yang sama. Isinya: aplikasi yang menghitung dosis obat, termasuk dosis peptida dan rekonstitusi, harus diterbitkan oleh pembuat obat atau institusi yang diakui seperti rumah sakit, perusahaan asuransi, apotek, atau universitas.

    Solusi

    Tidak ada. Developer tersebut mengatakan mereka memahami kekhawatiran soal keamanan dan menganggap itu sebagai akhir dari kedua aplikasi tersebut.

    Pelajaran

    Persetujuan tidak bersifat permanen. Apple bisa mengevaluasi ulang aplikasi yang sudah live saat memperketat aturan. Jika aplikasi Anda menghitung dosis atau memberi panduan kesehatan yang bisa melukai seseorang, baca pedoman 1.4 sebelum build, dan rencanakan untuk terbit lewat institusi yang memenuhi kualifikasi atau hilangkan fitur kalkulasinya.

29. 

    Pedoman 4.3 Spam dan 4.2.6 Layanan Pembuatan Aplikasi iOS Pedoman 4.3 Pedoman 4.2.6

    Aplikasi ticketing offline yang lagi-lagi dicap spam

    Apa yang terjadi

    Seorang developer membuat aplikasi kecil yang mengubah spreadsheet menjadi sistem ticketing dan check-in yang berjalan sepenuhnya offline, tanpa akun dan tanpa langganan. Aplikasi ini sudah dipakai untuk menangani check-in di acara lokal dengan ratusan peserta sepanjang musim panas. Apple menolaknya lagi dengan pemberitahuan gabungan 4.3 dan 4.2.6, dengan alasan aplikasi itu mungkin menduplikasi aplikasi yang sudah ada di store, merupakan varian oportunistik dari kategori yang sudah padat, atau berasal dari template atau layanan pembuatan aplikasi. Developer tersebut mengaku tidak tahu ada aplikasi lain yang melakukan hal serupa, dan versi Android-nya sudah live sekitar satu minggu.

    Solusi

    Masih ditolak saat diposting. Developer tersebut bilang mereka memang tidak berniat mencari uang dari App Store.

    Pelajaran

    Reviewer 4.3 hanya melihat listing dan beberapa menit penggunaan aplikasi Anda, bukan pengguna asli Anda. Jika aplikasi Anda memang benar-benar berbeda, jelaskan secara spesifik di catatan review dan screenshot pertama, sebutkan penggunaan di dunia nyata, dan nyatakan dengan jelas bahwa Anda tidak memakai template atau app generator.

30. 

    Guideline 5.6.4 Kualitas Aplikasi Program Apple Developer Pedoman 5.6.4

    Pencairan dana dibekukan karena angka refund naik

    Apa yang terjadi

    Seorang developer dengan aplikasi berlangganan yang tumbuh pesat dikejutkan oleh peringatan dari Apple bahwa akun developer mereka melanggar Developer Code of Conduct di bawah guideline 5.6.4, App Quality. Notifikasi tersebut menyoroti banyaknya permintaan refund dan keluhan pelanggan, memperingatkan bahwa akun bisa dihentikan, serta menyatakan semua pencairan pendapatan dihentikan sementara dan transfer aplikasi dinonaktifkan. Tingkat refund naik sekitar dua kali lipat dalam dua bulan terakhir. Saat developer menelusuri data, sebagian besar permintaan refund berlabel pembelian tidak disengaja, yang mereka yakini terutama berasal dari pengguna yang lupa membatalkan free trial 3 hari yang otomatis berlanjut ke paket tahunan. Peringatan ini muncul saat redesign besar aplikasi sedang dalam tahap testing.

    Solusi

    Masih terbuka saat artikel ini diposting. Developer tersebut menambahkan lebih banyak pengingat selama masa trial, memperjelas tagihan yang akan datang, menambahkan cara mengelola dan membatalkan langganan di dalam aplikasi, menyelesaikan redesign dengan lebih banyak testing, dan menghentikan sementara semua marketing kreator berbayar sambil menunggu.

    Pelajaran

    Apple memperhatikan tingkat refund dan keluhan, bukan hanya binary Anda. Free trial yang diam-diam berubah menjadi tagihan tahunan bisa menjadi masalah pembelian tidak disengaja dalam skala besar. Ingatkan pengguna sebelum trial berakhir, tampilkan harga sebenarnya dengan jelas, permudah pembatalan, dan anggap kenaikan tingkat refund sebagai risiko akun jauh sebelum Apple melakukannya.

31. 

    Setup metadata dan in-app purchase iOS Metadata dan IAP

    Ditolak tiga kali karena gambar yang tidak bisa dihapus di console

    Apa yang terjadi

    Seorang developer menambahkan gambar promosi ke langganan di App Store Connect dan tidak sengaja menambahkan gambar yang sama dua kali. Setelah itu, gambar tersebut tidak bisa dihapus atau diganti, dan setiap percobaan selalu gagal dengan error generik yang meminta untuk mencoba lagi nanti. Aplikasi ditolak tiga kali karena masalah setup langganan tersebut. Setiap kali ditolak, developer membalas dengan rekaman layar saat mencoba menghapus dan error yang muncul, namun seolah-olah reviewer mengabaikannya. Developer yakin penyebab utamanya adalah bug di App Store Connect itu sendiri.

    Solusi

    Masih tertahan saat proses rilis, tanpa solusi dari Apple.

    Pelajaran

    Saat App Store Connect sendiri memblokir perbaikan, balasan di thread penolakan mungkin tidak sampai ke siapa pun yang bisa menyelesaikannya. Upload gambar langganan dengan hati-hati dan hanya sekali; jika konsolnya bermasalah, hubungi Apple developer support secara terpisah soal bug tersebut sambil tetap membalas App Review.

32. 

    Pedoman 4.3 Spam iOS Pedoman 4.3

    Tiga kali penolakan untuk aplikasi yang dibuat khusus untuk satu gym

    Apa yang terjadi

    Seorang developer membuat aplikasi iOS untuk mengelola gym miliknya sendiri, sekitar seratus tujuh puluh enam commit kerja. Apple menolaknya pada 29 September, menolaknya lagi pada 7 Oktober, dan pada 13 Oktober menolaknya berdasarkan guideline 4.3 Spam. Di hari yang sama, mereka menjawab kesembilan pertanyaan yang dikirim App Review. Enam hari kemudian, pada 19 Oktober, belum ada kabar balik. Daftar aplikasi di App Store Connect mereka menunjukkan beberapa aplikasi lain di akun yang sama juga berstatus ditolak pada waktu yang bersamaan, baik di iOS maupun macOS.

    Solusi

    Masih terbuka saat postingan ini dibuat, tanpa ada balasan dari App Review setelah jawaban dikirimkan.

    Pelajaran

    Effort dan jumlah commit bukan yang diukur oleh 4.3. Jika aplikasi memang dibuat untuk satu bisnis, unlisted app bisa tetap tidak muncul di pencarian namun tetap bisa diakses siapa pun lewat link langsung; Custom App distribution membatasi akses hanya untuk organisasi tertentu. Pilih opsi yang sesuai dengan kontrol akses yang dibutuhkan. Untuk listing publik, buat perbedaan dari aplikasi yang sudah ada terlihat jelas di layar pertama, screenshot, dan catatan review.

33. 

    Guideline 5.6 Developer Code of Conduct dan 2.5.19 Hidden Features iOS Pedoman 5.6 Kode Etik Developer Code Guideline 2.5.19 Fitur Tersembunyi

    Ditolak karena dianggap fraud akibat testing switch yang tertinggal

    Apa yang terjadi

    Pada September 2026, aplikasi iOS milik seorang developer ditolak berdasarkan guideline 5.6 Developer Code of Conduct. Apple menyebut menemukan pola perilaku yang mereka kaitkan dengan fraud, khususnya fitur yang tampak sengaja disembunyikan saat review. Developer itu melacaknya ke tiga testing switch yang tertinggal di release build: mode untuk mengambil screenshot store, switch yang menyimulasikan pengecekan entitlement yang lambat, dan switch yang membuka mock purchases. Tidak satu pun bisa diakses pengguna normal versi App Store. Dalam pembaruan App Review Guidelines Apple 16 Oktober, fitur tersembunyi, dorman, atau tidak terdokumentasi jadi guideline tersendiri, 2.5.19, dan Apple menyatakan pelanggarannya bisa membahayakan seluruh akun developer.

    Solusi

    Developer tersebut kini memeriksa string di dalam setiap release archive sebelum upload. Tidak disebutkan apakah build tersebut akhirnya disetujui.

    Pelajaran

    Jauhkan code khusus testing dari release build pada compile time, misalnya dengan DEBUG flag, bukan di balik runtime check. Periksa apa yang benar-benar ikut terkirim di binary yang diarsipkan, dan catat switch apa pun yang tetap ada di catatan App Review.

34. 

    2.1 Informasi yang Dibutuhkan iOS Pedoman 2.1

    Review ditunda sampai Apple mengetahui target pengguna aplikasi

    Apa yang terjadi

    Seorang developer mengirimkan versi 1.0 aplikasi iPad dan review terhenti di Guideline 2.1, Information Needed. Tidak ada laporan crash, fitur yang rusak, maupun permintaan perbaikan binary. Apple hanya meminta jawaban detail untuk satu pertanyaan sebelum review berlanjut: siapa yang akan menggunakan aplikasi ini.

    Solusi

    Apple meminta penjelasan target user sebelum melanjutkan review.

    Pelajaran

    Perlakukan audiens dan use case sebagai input review, bukan copy marketing yang bisa diisi belakangan. Tulis jawaban target user yang jelas sebelum submit versi pertama.

35. 

    4.3 Desain / Spam iOS Pedoman 4.3

    Tidak cukup berbeda di kategori aplikasi suara yang sudah jenuh

    Apa yang terjadi

    Sebuah aplikasi audio hiburan ditolak berdasarkan Guideline 4.3(b). Apple menyatakan App Store sudah punya cukup banyak aplikasi serupa dan menganggap produk itu konten duplikat di kategori yang jenuh, meskipun tim yakin fitur tambahan membuatnya berbeda.

    Solusi

    Ditolak berdasarkan 4.3(b) karena kurangnya diferensiasi di kategori yang sudah ramai.

    Pelajaran

    Di kategori yang dianggap Apple sudah jenuh, keunikan harus langsung terlihat di menit pertama review. Tonjolkan nilai unik Anda, bukan sekadar gimmick yang sudah sering dilihat reviewer.

36. 

    Metadata dan deskripsi store listing iOS Metadata dan IAP Review tanpa akhir

    Loop metadata yang menelan minggu peluncuran

    Apa yang terjadi

    Tim produk produktivitas konsumen merilis build yang bersih, lalu menghabiskan lebih dari sembilan hari bolak-balik menangani penolakan metadata. Setiap pengajuan ulang menjawab catatan sebelumnya, tapi balasan berikutnya malah fokus ke frasa, screenshot, atau penjelasan lain. Tidak ada code yang berubah sementara rencana peluncuran, press, dan paid acquisition menunggu copy untuk review.

    Solusi

    Disetujui setelah merevisi screenshot, subtitle, dan catatan review tanpa perubahan binary.

    Pelajaran

    Kunci copy listing, screenshot, dan catatan review sekaligus sebelum menetapkan tanggal peluncuran. Penolakan metadata bisa menumpuk meski binary tidak pernah berubah.

37. 

    Export Compliance (App Store Connect) iOS Metadata dan IAP

    Disetujui, lalu terhambat satu pertanyaan kepatuhan lagi

    Apa yang terjadi

    Sebuah build dashboard companion B2B sudah mencapai persetujuan, tapi rilis tetap terhambat saat prompt kepatuhan muncul lagi setelah tim mengira pertanyaan ekspor sudah dijawab. Pemilik rilis menghentikan rollout, mengumpulkan teks legal, memperbarui respons App Store Connect, dan menunggu putaran review berikutnya sementara pelanggan sudah melihat pengumuman sebelum aplikasi tersedia.

    Solusi

    Dirilis setelah menjawab kepatuhan ekspor lagi dan menunggu putaran review berikutnya.

    Pelajaran

    Anggap kepatuhan ekspor sebagai release gate, bukan sekadar centang sekali. Pastikan App Store Connect menunjukkan status siap rilis sebelum Anda mengumumkan tanggal rilis.

38. 

    Izin Google Play dan review kebijakan Google Play Metadata dan IAP Review tanpa akhir

    Kebijakan izin yang menyita waktu

    Apa yang terjadi

    Sebuah aplikasi Android untuk operasional lapangan memicu peninjauan kebijakan menyeluruh setelah satu izin dengan cakupan sempit dipakai di satu layar. Tim sudah mendokumentasikan fitur itu, menambahkan instruksi untuk peninjau, dan merekam alur demo, tetapi tetap harus menghapus izin tersebut dari rilis utama agar pelanggan tidak terblokir setelah tiga belas hari.

    Solusi

    Disetujui setelah menghapus izin, merekam demo baru, dan menulis ulang deklarasi store.

    Pelajaran

    Batasi cakupan permission sensitif ke area terkecil yang bisa Anda rilis dulu. Satu permission saja bisa memicu full policy review di Google Play.

39. 

    Waktu antrean review Google Play Google Play Review tanpa akhir

    Hotfix yang tertahan di antrean kebijakan

    Apa yang terjadi

    Tim ecommerce butuh perbaikan mobile cepat untuk bug checkout, tapi rilis store tertahan di review selama enam hari di saat paling tidak tepat. Tiket support naik sementara status tetap pending. Mereka mitigasi di sisi server dulu, lalu melihat approval binary baru datang setelah darurat itu sudah menghabiskan akhir pekan.

    Solusi

    Perbaikan native store baru tiba setelah tim sudah memitigasi insiden di tempat lain.

    Pelajaran

    Review store bukan jalur respons insiden. Siapkan jalur mitigasi di luar store untuk bug produksi mendesak saat binary masih menunggu antrean.

40. 

    Pedoman 3.1.1 In-App Purchase dan 3.1.3(f) Free Stand-alone Apps iOS Pedoman 3.1.1 Pedoman 3.1.3

    Aplikasi pendamping ditolak karena masa trial-nya berakhir

    Apa yang terjadi

    Seorang developer merilis aplikasi pendamping iOS gratis untuk layanan email berbasis web berbayarnya. Aplikasi itu tidak menjual apa pun di dalamnya. Developer merujuk ke pengecualian 3.1.3(f) untuk aplikasi pendamping gratis yang stand-alone, tapi aplikasi ditolak empat kali. Ia mengajukan banding, dan App Review Board menguatkan penolakan itu. Alasannya: layanan tersebut menawarkan trial gratis 14 hari, jadi bagi pengguna iOS aplikasi itu tidak lagi berguna setelah 14 hari dan bukan pengalaman stand-alone yang sesungguhnya. Apple menawarkan dua jalan keluar: beri aplikasi cukup konten dan fitur gratis agar bisa berdiri sendiri, atau biarkan pelanggan App Store membeli layanan lewat In-App Purchase. Developer mencontohkan aplikasi email terkenal yang tampaknya melakukan hal sama dengan batas 14 hari.

    Solusi

    Masih belum terselesaikan saat artikel ini diterbitkan. Bandingnya ditolak, dan pengembang sedang mempertimbangkan antara menyediakan tier gratis yang terbatas atau menambahkan In-App Purchase.

    Pelajaran

    Pengecualian companion 3.1.3(f) ditafsirkan secara sempit. Jika layanan web Anda punya trial dengan batas waktu, Apple bisa menganggap aplikasi itu paywall terselubung begitu trial berakhir. Sebelum submit, tentukan apa yang masih bisa dilakukan pengguna di aplikasi secara gratis setelah trial, atau siapkan In-App Purchase. Menunjuk aplikasi lain yang tampaknya melakukan hal serupa jarang memenangkan banding.

41. 

    Panduan 3.1.1 In-App Purchase iOS Pedoman 3.1.1

    API key sendiri yang dianggap sebagai pembayaran di luar App Store

    Apa yang terjadi

    Seorang solo developer yang membangun asisten AI untuk iPhone membiarkan pengguna paste API key mereka sendiri dari agregator model pihak ketiga agar bisa menjalankan model cloud besar. Pada putaran review keempat, App Review menolak aplikasi itu berdasarkan guideline 3.1.1, karena menganggap opsi bring your own key sebagai cara membayar fitur di luar App Store. Seperti yang dipahami developer dari penolakan tersebut, key yang dibeli di tempat lain hanya bisa membuka fitur berbayar di aplikasi jika penjualnya menyediakan In-App Purchase di aplikasi iOS miliknya sendiri, dan penyedia ini tidak punya aplikasi iOS. Developer tersebut tidak mengajukan banding.

    Solusi

    Mereka menghapus fitur bring your own key sepenuhnya, membangun ulang versi berikutnya agar model berjalan sepenuhnya di perangkat, dan berencana menghadirkan kembali model cloud nanti sebagai kredit in-app yang dijual lewat In-App Purchase. Hasil pengajuan ulang itu belum diketahui saat tulisan ini dibuat.

    Pelajaran

    Jika fitur berbayar di aplikasi Anda dibuka dengan kredensial yang dibeli di tempat lain, cek dulu sebelum build apakah penjual tersebut menyediakan In-App Purchase di aplikasi iOS miliknya. Jika tidak, siapkan jalur In-App Purchase sendiri atau mode yang bisa berjalan tanpanya.

42. 

    Pedoman 1.2 iOS Pedoman 1.2

    Perbandingan outfit ditolak karena menobatkan pemenang

    Apa yang terjadi

    Developer solo merilis aplikasi AI yang membandingkan dua outfit. Setelah perbandingan, aplikasi mengumumkan bahwa satu tampilan menang. App Review menolaknya berdasarkan pedoman 1.2, karena hasilnya dianggap memeringkat orang, bukan pakaian. Developer tersebut setuju dengan kekhawatiran itu.

    Solusi

    Mereka menghapus semua kata-kata pemenang, badge pemenang, serta skor yang lebih besar atau warna highlight pada opsi mana pun, sehingga kedua tampilan kini mendapat bobot visual yang sama, masing-masing mendapat umpan baliknya sendiri, dan pengguna yang memutuskan. Tidak diungkapkan apakah build yang diperbaiki disetujui.

    Pelajaran

    Apple menilai bagaimana sebuah layar terasa, bukan hanya apa fungsinya. Jika aplikasi Anda memberi skor pada apa pun yang terkait dengan penampilan orang, sajikan umpan balik tanpa peringkat dan asumsikan tafsiran paling keras.

43. 

    Kategori Kids, Pedoman 3.1.2, dan pertanyaan privasi iOS Kategori anak-anak Pedoman 3.1.2 Review tanpa akhir

    Aplikasi cerita anak masih menunggu setelah sebulan penolakan

    Apa yang terjadi

    Seorang developer solo membangun aplikasi cerita untuk anak usia 4 hingga 10 tahun, di mana anak-anak mendengarkan cerita dan bisa jeda untuk bertanya. Aplikasi ini sudah live di Android selama beberapa minggu. Developer itu mengirimkannya ke App Store pada 19 September 2026. Setelah beberapa putaran penolakan dan pengajuan ulang, aplikasi tersebut masih belum disetujui sekitar sebulan kemudian. Di putaran terakhir, Apple meminta dua hal: karena aplikasi menjual langganan mingguan, bulanan, dan tahunan, halaman App Store membutuhkan tautan yang berfungsi ke Ketentuan Penggunaan; dan karena aplikasi berada di kategori Kids, review tidak bisa dilanjutkan sampai developer menjawab empat pertanyaan tentang analytics pihak ketiga, iklan pihak ketiga, apakah ada data yang dibagikan ke pihak ketiga dan di mana datanya disimpan, serta apakah ada data pengguna atau perangkat lain yang dikumpulkan dan untuk apa.

    Solusi

    Developer memperbaiki kedua masalah tersebut dan mengajukan ulang. Hasilnya masih pending saat posting ini dibuat.

    Pelajaran

    Untuk aplikasi anak, kesehatan, keuangan, atau pendidikan, cari tahu lebih awal apa yang akan diminta oleh hukum privasi lokal dan toko, misalnya persetujuan orang tua sebelum mengumpulkan data anak, dan siapkan tautan Ketentuan Penggunaan serta jawaban tertulis tentang data sebelum pengajuan pertama.

44. 

    Pedoman 5.1.1(v) dan 3.1.2 iOS Pedoman 5.1.1 Pedoman 3.1.2

    Versi 1.0 ditolak karena alur sign in, pembelian, dan hapus akun

    Apa yang terjadi

    Versi 1.0 seorang developer ditolak karena tiga masalah sekaligus, dan tidak satu pun soal ide aplikasinya. Setelah Sign in with Apple, aplikasi masih meminta nama pengguna yang sebenarnya sudah diberikan oleh Sign in with Apple. Penghapusan akun harus bisa dimulai dari dalam aplikasi. Layar langganan dan support wajib menampilkan harga, ketentuan perpanjangan, dan link Terms. Pelajaran dari developer itu: ketiganya soal sign in, pembelian, dan penghapusan akun.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Sebelum submisi pertama, uji alur sign in, pembelian, dan hapus akun layaknya seorang reviewer. Ketiga alur ini sering menjadi penyebab penolakan pertama.

45. 

    Guideline 5.2.3 Pengunduhan Audio/Video iOS Guideline 5.2.3 Pengunduhan Audio/Video

    Radio internet vintage ditolak karena hak audio pihak ketiga

    Apa yang terjadi

    Aplikasi radio internet bergaya vintage milik developer solo, versi 1.0 pada build kelima, ditolak berdasarkan guideline 5.2.3. Aturan ini mencakup aplikasi yang memutar atau mengunduh audio dan video dari sumber pihak ketiga dan meminta bukti bahwa developer memiliki hak atas konten tersebut. Developer tersebut membalas di Resolution Center keesokan harinya dengan penjelasan mengenai hak konten.

    Solusi

    Hasil belum diketahui saat postingan ini dibuat.

    Pelajaran

    Jika aplikasi Anda melakukan streaming stasiun atau media yang bukan milik Anda, kumpulkan otorisasi atau gunakan sumber yang ketentuannya secara eksplisit mengizinkan pemutaran di aplikasi, lalu masukkan dokumentasi itu ke catatan review sebelum submit.

46. 

    Pedoman 4.3 (Spam) iOS Pedoman 4.3

    Enam kali ditolak, lalu label spam 4.3 dan menunggu dua minggu untuk panggilan

    Apa yang terjadi

    Seorang solo developer menghabiskan berbulan-bulan untuk aplikasi pertamanya, sebuah aplikasi pembuka percakapan untuk acara sosial. Aplikasi itu ditolak enam kali, terakhir karena Guideline 4.3 (spam), meskipun developer merasa aplikasinya menawarkan lebih dibanding aplikasi serupa yang sudah ada di store. Ia meminta panggilan satu lawan satu dengan App Review. Seminggu berlalu tanpa balasan, dan panggilan itu akhirnya terjadi sekitar dua minggu setelah penolakan 4.3. Developer tersebut keluar dari panggilan dengan kesan bahwa 4.3 kini dipakai untuk menandai aplikasi yang terlihat seperti klon AI minim usaha, yang menurutnya bukan seperti aplikasinya.

    Solusi

    Developer tersebut mengajukan banding. Hingga tulisan ini dibuat, bandingnya masih diproses.

    Pelajaran

    Di kategori yang padat, reviewer menilai berdasarkan screenshot, deskripsi, dan sesi pertama. Pastikan perbedaannya dari aplikasi yang sudah ada terlihat jelas di sana, dan minta panggilan App Review lebih awal, karena untuk mendapatkannya bisa butuh seminggu atau lebih.

47. 

    Agreement belum disetujui (tanpa rujukan guideline) iOS Pendaftaran dan akun

    Seminggu di antrean, ditolak karena agreement belum ditandatangani, lalu seminggu lagi

    Apa yang terjadi

    Sebuah app menunggu sekitar seminggu untuk review, lalu ditolak padahal tidak ada masalah di dalam app-nya. Ternyata akun tersebut belum menyetujui agreement yang baru diterbitkan di App Store Connect. Developer menyetujuinya dan resubmit, dan submission itu kembali masuk antrean selama sekitar seminggu lagi. Developer support hanya membalas bahwa semuanya berjalan sesuai rencana.

    Solusi

    Masih menunggu review saat tulisan ini dibuat.

    Pelajaran

    Sebelum setiap submission, cek App Store Connect untuk melihat apakah ada agreement yang perlu disetujui. Satu klik yang terlewat bisa berarti harus melewati antrean review dari awal.

48. 

    Crash saat review (guideline tidak disebutkan) macOS Pedoman 2.1

    Ditolak karena crash pada versi macOS yang belum diinstal developer

    Apa yang terjadi

    Sebuah aplikasi Mac ditolak karena crash di macOS 27, versi yang belum dijalankan developer dan tidak ingin mereka instal di mesin utama mereka. Saat mencari cara mereproduksi crash tersebut, mereka menemukan bahwa framework Virtualization milik Apple bisa menjalankan virtual machine macOS di Apple silicon secara gratis, lalu menyiapkannya untuk testing di versi baru itu.

    Solusi

    Tidak disebutkan selain mereproduksi crash di virtual machine.

    Pelajaran

    App Review menguji di OS terbaru. Siapkan virtual machine dengan macOS terbaru agar Anda bisa mereproduksi crash saat review tanpa harus upgrade mesin harian Anda.

49. 

    Keterlambatan review (tanpa pedoman yang dikutip) iOS Review tanpa akhir

    Dua belas hari di Waiting for Review setelah dua permintaan expedite

    Apa yang terjadi

    Seorang developer yang sudah memiliki aplikasi yang disetujui di store mengirimkan versi 1.0 aplikasi baru beserta grup langganan berisi lima subscription. Dua belas hari kemudian statusnya masih Waiting for Review, padahal biasanya di bawah 48 jam. Mereka mengajukan expedited review dua kali, menghubungi support tanpa mendapat jawaban, dan mencoba menjadwalkan appointment App Review, tetapi ditolak.

    Solusi

    Masih menunggu saat tulisan ini dibuat.

    Pelajaran

    Jangan jadwalkan tanggal launch berdasarkan rata-rata 48 jam. Sisakan buffer beberapa minggu untuk versi pertama dengan subscription, dan anggap permintaan expedite serta appointment sebagai kemungkinan, bukan jaminan.

50. 

    Prompt izin + metadata screenshot (aturan yang sering dikutip sebagai 5.1.1 dan 2.3.7) iOS Pedoman 5.1.1 Pedoman 2.3.7

    Minggu peluncuran: layar Allow kustom dan harga di screenshot

    Apa yang terjadi

    Selama minggu peluncuran, aplikasi ditolak dua kali. Pertama, aplikasi menampilkan layarnya sendiri dengan tombol Allow tepat sebelum prompt izin sistem, yang tidak diterima Apple. Setelah masalah itu diperbaiki, penolakan kedua terjadi karena screenshot App Store menampilkan harga. Kedua perbaikan itu kecil, tapi setiap submit ulang memakan waktu sekitar satu hari di antrean review.

    Solusi

    Developer tersebut memperbaiki kedua masalah tersebut dan kini mencatat kedua aturan tersebut di dalam proyek agar hal serupa tidak terulang kembali.

    Pelajaran

    Layar pre-permission bisa menjelaskan alasan Anda butuh akses, tapi biarkan pilihan Allow hanya ada di prompt sistem. Jangan tampilkan harga di screenshot, dan jalankan checklist singkat sebelum setiap submit.

51. 

    Keterlambatan review (tanpa pedoman yang dikutip) iOS Review tanpa akhir

    Sepuluh hari tertahan di review, lalu disetujui 30 menit setelah resubmit

    Apa yang terjadi

    Aplikasi tertahan di review selama lebih dari sepuluh hari tanpa progres. Developer lalu resubmit lagi.

    Solusi

    Aplikasi disetujui sekitar 30 menit setelah resubmit.

    Pelajaran

    Review yang macet bukan selalu berarti aplikasi Anda ditolak. Kalau tertahan jauh melewati waktu biasanya, resubmit atau minta expedited review bisa dicoba, tapi tidak ada jaminan.

52. 

    4.3(a) Spam iOS Pedoman 4.3

    Tujuh aplikasi template ditolak karena 4.3 pada menit yang sama

    Apa yang terjadi

    Sebuah tim kecil mengirim tujuh aplikasi yang dibangun dengan template sama untuk direview pada minggu yang sama. Ketujuhnya mendapat penolakan spam 4.3(a) yang identik pada menit yang sama, termasuk dua aplikasi yang belum pernah ditolak sebelumnya. Tim menyimpulkan Apple menilai batch itu, bukan masing-masing aplikasi.

    Solusi

    Tim tersebut kini mengirim satu aplikasi dalam satu waktu.

    Pelajaran

    Aplikasi yang berbagi codebase bisa terbaca sebagai pola spam jika dikirim bersamaan. Beri jeda antar pengiriman dan buat tiap aplikasi jelas berbeda dalam fitur, desain, dan metadata.

53. 

    Pedoman 2.3.6 iOS Pedoman 2.3.6

    Penolakan age rating padahal data di Connect sudah sesuai

    Apa yang terjadi

    Sebuah aplikasi ditolak karena age rating-nya. Developer membuka kuesioner age rating di App Store Connect dan ternyata semua jawabannya sudah sesuai dengan yang diminta di pesan penolakan.

    Solusi

    Mereka tidak mengubah apa pun di Connect, membalas peninjau bahwa pengaturannya sudah sesuai, lalu mengirim ulang. Aplikasi tersebut disetujui beberapa jam kemudian.

    Pelajaran

    Catatan 2.3.6 bisa saja keliru soal pengaturan Anda saat ini. Cek App Store Connect sebelum mengubah apa pun, dan kalau sudah sesuai, sampaikan jelas di balasan Anda daripada menebak-nebak perbaikannya.

54. 

    Panduan 2.1 Informasi Diperlukan iOS Pedoman 2.1

    Riwayat review terbatas: rekaman perangkat dan walkthrough fitur berbayar

    Apa yang terjadi

    Aplikasi yang sudah lolos review Google Play dikembalikan dengan alasan 2.1 Information Needed. Apple menyatakan akun developer memiliki riwayat review terbatas dan meminta rekaman layar di perangkat asli, walkthrough fitur berbayar, serta deskripsi tertulis tentang fungsi aplikasi dan layanan eksternal yang digunakan.

    Solusi

    Developer sedang menyiapkan rekaman dan jawaban saat postingan ini dibuat. Hasil akhirnya belum diketahui.

    Pelajaran

    Lolos review Google Play tidak menjamin kelolosan di Apple. Jika akun developer Anda baru atau belum banyak submission, siapkan rekaman layar di perangkat asli, walkthrough fitur berbayar, dan daftar layanan pihak ketiga sebelum submit.

55. 

    Guidelines 2.1, 2.3.2, dan 5.2.3 iOS Pedoman 2.1 Pedoman 2.3.2 Guideline 5.2.3 Pengunduhan Audio/Video Review tanpa akhir

    Submission pertama: 2.1, lalu 2.3.2, lalu 5.2.3 dalam sebulan

    Apa yang terjadi

    Submission pertama seorang developer menunggu enam hari dan ditolak berdasarkan 2.1. Mereka membalas di hari yang sama. Dua belas hari kemudian ditolak lagi, kali ini berdasarkan 2.3.2. Mereka mengajukan ulang, dan sembilan hari kemudian ditolak berdasarkan 5.2.3. Mereka membalas lagi di hari yang sama dan, dua hari kemudian, masih menunggu. Setiap putaran memunculkan guideline yang berbeda dari sebelumnya.

    Solusi

    Masih menunggu, sudah lebih dari sebulan sejak submission pertama.

    Pelajaran

    Setiap putaran review bisa memunculkan guideline baru, dan masing-masing bisa memakan waktu seminggu atau lebih. Sebelum submission pertama, baca aturan metadata (2.3) dan aturan hak konten yang berlaku untuk Anda (5.2), bukan hanya aturan kelengkapan (2.1), lalu perbaiki semua yang bisa Anda temukan dalam satu build.

56. 

    Pedoman 4.2 Minimum Functionality iOS Pedoman 4.2

    Aplikasi doa ditolak karena dianggap hanya buku berdasarkan 4.2

    Apa yang terjadi

    Sebuah aplikasi doa dan devosi keagamaan ditolak berdasarkan 4.2 dengan alasan bahwa aplikasi itu utamanya adalah sebuah buku. Developer mencatat fitur-fitur interaktif termasuk kalender, pelacak jumlah doa, timer meditasi, koleksi yang bisa dibagikan, widget Home Screen, dan pencarian suara.

    Solusi

    Tidak disebutkan.

    Pelajaran

    Jika reviewer menganggap aplikasi Anda sebagai konten statis, fitur interaktif mungkin tidak terlihat di menit-menit awal review. Tampilkan fitur tersebut di layar dan screenshot pertama, serta cantumkan di catatan review beserta langkah-langkah untuk mengaksesnya.

57. 

    Pedoman 2.3.10 iOS Pedoman 2.3.10

    Menunggu 13 hari di antrean, ditolak dalam 7 menit karena Android

    Apa yang terjadi

    Seorang developer menunggu 13 hari di antrean review, mengecek App Store Connect dan email setiap hari, serta mengajukan dua support request. Saat review akhirnya dimulai, aplikasi ditolak hanya dalam 7 menit karena deskripsi App Store menyebutkan produk dapat berjalan di browser apa pun di iPhone atau Android.

    Solusi

    Mereka menghapus penyebutan platform lain, hanya edit satu baris, lalu submit ulang. Hasilnya belum dilaporkan.

    Pelajaran

    Apple menolak metadata yang menyebut platform mobile lain. Periksa deskripsi, screenshot, dan teks promosi Anda untuk nama platform kompetitor sebelum submit, karena masalah kecil dalam pemilihan kata bisa membuat Anda menunggu antrean penuh.

58. 

    Pedoman 5 (Legal) iOS Pedoman 5 Legal

    Penolakan Guideline 5 karena mencantumkan OpenAI di metadata untuk Tiongkok

    Apa yang terjadi

    Sebuah aplikasi AI ditolak berdasarkan Guideline 5 Legal karena metadatanya mencantumkan OpenAI. Apple menjelaskan bahwa Tiongkok mewajibkan lisensi pemerintah untuk layanan AI generatif dan sintesis mendalam, bahwa ChatGPT tidak memiliki izin tersebut, dan bahwa pengembang harus menghapus fitur AI serta semua referensi OpenAI atau ChatGPT dari nama, subjudul, teks promosi, deskripsi, dan screenshot untuk storefront Tiongkok, atau berhenti mendistribusikan di daratan Tiongkok.

    Solusi

    Developer menyarankan menghapus centang storefront China mainland di Availability sebelum submit app yang menyebut layanan tersebut, sehingga menghemat satu siklus review.

    Pelajaran

    Jika app Anda menggunakan penyedia generative AI, tentukan ketersediaan di China sejak awal. Penolakan ini soal storefront dan metadata, bukan hanya code Anda.

59. 

    Pedoman 3.1.2 iOS Pedoman 3.1.2

    Link Terms ada di dalam app, tetapi tidak ada di deskripsi

    Apa yang terjadi

    Versi pertama app subscription ditolak dua hari setelah submit karena link Terms of Use tidak ada di deskripsi App Store. Link itu sudah ada di dalam app, di paywall dan settings, hanya saja tidak ada di field metadata tersebut.

    Solusi

    Perbaikannya cuma butuh lima menit, tapi setelah submit ulang, build malah tertahan di Waiting for Review selama lebih dari sepuluh hari tanpa kabar. Belum ada yang melapor.

    Pelajaran

    Untuk langganan auto-renewable, sertakan link Terms of Use (EULA) dan Privacy Policy di metadata App Store serta di dalam app sebelum submission pertama, karena perbaikan cepat pun bisa berujung penantian panjang kedua.

60. 

    Penghentian akun iOS Penghentian akun

    Akun dihentikan berdasarkan 3.2(f), pendapatan tertunda belum dibayarkan

    Apa yang terjadi

    Akun Apple Developer milik seorang developer dihentikan berdasarkan bagian 3.2(f) Developer Program License Agreement. Hampir tiga bulan kemudian, pendapatan tertunda mereka masih belum dicairkan dan mereka bertanya ke developer lain apakah ada yang pernah menerima pendapatan yang ditahan setelah penghentian.

    Solusi

    Tidak ada laporan.

    Pelajaran

    Pemutusan akun bisa membekukan pendapatan yang sudah kamu dapatkan, bukan hanya penjualan masa depan. Jaga runway kas, catatan payout, dan channel sendiri ke pengguna agar satu keputusan akun tidak mengakhiri bisnis.

61. 

    Pedoman 2.1 dan 5.1.2 iOS Pedoman 2.1 Pedoman 5.1.2 Review tanpa akhir

    Dua puluh lima hari dalam review, lalu 2.1 dan 5.1.2 sekaligus

    Apa yang terjadi

    Seorang developer indie mengirimkan versi pertama, 1.0, dari sebuah aplikasi iOS. Setelah sekitar tujuh belas hari, build tersebut masih dalam review. Setelah total sekitar dua puluh lima hari, App Review menolaknya berdasarkan guideline 2.1 App Completeness dan guideline 5.1.2 Data Use and Sharing dalam keputusan yang sama. App Store Connect lalu memblokir semua item lain dalam submission itu sampai versi yang ditolak diperbaiki. Developer tersebut bilang masalah yang disebut mudah diperbaiki; bagian yang menyakitkan adalah harus menunggu dua sampai tiga minggu lagi untuk resubmit.

    Solusi

    Mereka memperbaiki kedua masalah itu dan mengirim ulang. Hasil review berikutnya tidak dilaporkan.

    Pelajaran

    Kalau antrean sudah selama ini, setiap penolakan bisa memakan waktu berminggu-minggu. Sebelum submit, lakukan pengecekan kelengkapan menyeluruh: tidak ada flow yang rusak, akun demo yang berfungsi, tidak ada placeholder, dan pastikan jawaban privasi serta berbagi data SDK sesuai dengan yang benar-benar dilakukan aplikasi.

62. 

    Pedoman 2.3.1(a) iOS Pedoman 2.3.1 Metadata dan IAP

    Taruhan uang asli ditolak karena dianggap tersembunyi di bawah 2.3.1(a)

    Apa yang terjadi

    Seorang developer membuat aplikasi habit tracker dan pelacak kedisiplinan yang memungkinkan pengguna mempertaruhkan uang dan kehilangannya jika gagal mencapai target. Pada pertengahan Oktober 2026, App Review menolaknya berdasarkan guideline 2.3.1(a) karena aplikasi tersebut dianggap mengandung fitur tersembunyi, khususnya staking uang dan perampasan stake yang tidak dijelaskan dalam metadata. Surat itu juga menyertakan pemberitahuan Extended Review yang memperingatkan bahwa pengajuan berulang dengan masalah seperti ini akan memperlama waktu review, dan akun yang terus melanggar aturan dapat dikeluarkan dari Apple Developer Program. Aplikasi tersebut ditolak lima kali secara total; satu penolakan lain menyebut crash saat review di iPad. Developer yang membangun aplikasi dengan AI coding tools itu merangkum pelajarannya: baca guideline, sesuaikan metadata dengan aplikasi, jangan pernah menyembunyikan fitur atau pengumpulan data, tinjau code yang dihasilkan, dan tes di berbagai perangkat.

    Solusi

    Tidak disebutkan selain memperbaiki ulang aplikasi setelah lima penolakan. Persetujuan tidak dilaporkan.

    Pelajaran

    Fitur apa pun yang melibatkan uang asli, termasuk stake atau perampasan, harus jelas di deskripsi dan catatan App Review. Tes di iPad meskipun target Anda adalah iPhone, karena reviewer juga melakukannya.

63. 

    Pedoman 4.3(a) iOS Pedoman 4.3

    Fitur baru, screenshot baru, dan 4.3(a) dalam tiga menit dengan peringatan

    Apa yang terjadi

    Seorang developer yang sudah menghabiskan dua bulan membangun aplikasi dari nol ternyata ditolak dengan alasan spam 4.3. Di percobaan berikutnya, mereka menambah fitur baru, mengganti semua screenshot, mengoptimalkan aplikasi untuk lebih banyak ukuran perangkat, dan submit ulang lengkap dengan catatan review serta akun test premium. Tiga menit setelah masuk tahap review, aplikasi ditolak lagi berdasarkan Guideline 4.3(a). Kali ini pesannya diakhiri dengan pemberitahuan review diperpanjang: pengiriman berulang dengan masalah ini akan memperlama waktu review, dan akun yang terus mengirim aplikasi seperti itu berisiko dikeluarkan dari Apple Developer Program. Karena takut submit ulang sekali lagi bisa membuat seluruh akunnya hilang, developer itu pun bingung apakah harus membuang aplikasi ini atau meminta sesi call dengan App Review.

    Solusi

    Belum terselesaikan saat postingan ini dibuat.

    Pelajaran

    Begitu pemberitahuan review diperpanjang muncul, langsung submit ulang adalah langkah paling berisiko. Mintalah sesi call dengan App Review dulu, dan baru submit ulang setelah Anda tahu apa yang mereka anggap terlalu mirip.

64. 

    Pedoman 4.3(b) iOS Pedoman 4.3

    Ditolak dalam tiga menit, lalu tiga minggu tanpa kabar saat banding

    Apa yang terjadi

    Aplikasi seorang developer ditolak berdasarkan Guideline 4.3(b) hanya tiga menit setelah masuk tahap review. Mereka mengajukan banding ke App Review Board. Tiga minggu kemudian, mereka masih belum mendapat jawaban, tidak ada perubahan status, dan tidak ada pesan apa pun.

    Solusi

    Unresolved.

    Pelajaran

    Banding bisa tertahan berminggu-minggu tanpa feedback. Kerjakan secara paralel hal yang membuat aplikasi Anda berbeda dari kategori yang padat, agar Anda tidak hanya terpaku menunggu banding.

65. 

    Penghentian akun iOS Penghentian akun

    Satu aplikasi terlihat seperti website, dan puluhan aplikasi lainnya menghilang

    Apa yang terjadi

    Sebuah studio yang telah merilis aplikasi selama lebih dari satu dekade—lebih dari 80 aplikasi—mendapati akun developer-nya ditandai untuk penghentian. Menurut studio tersebut, alasannya adalah salah satu aplikasinya dianggap mirip dengan situs web yang sudah ada. Tidak ada peringatan dan tidak ada opsi untuk menghapus hanya aplikasi itu. Semua aplikasinya ditarik dari App Store, termasuk aplikasi berlisensi tak terkait yang dibuat untuk klien, dan update-nya diblokir.

    Solusi

    Tidak terselesaikan. Studio tersebut secara terbuka tidak setuju dengan keputusan itu.

    Pelajaran

    Satu akun developer berarti satu titik kegagalan. Jika Anda membangun aplikasi untuk klien, terbitkan di bawah akun developer milik klien sendiri agar sengketa atas salah satu aplikasi Anda tidak ikut menjatuhkan akun mereka juga.

66. 

    Bagian 3.2(f) (Developer Program License Agreement) iOS Penghentian akun

    Update judul, lalu pemberitahuan penghentian 3.2(f)

    Apa yang terjadi

    Seorang developer indie mengirim permintaan perubahan judul sederhana untuk satu aplikasi dan menerima pemberitahuan pemutusan berdasarkan pasal 3.2(f). Semua aplikasi mereka dihapus dari store. Mereka mengajukan banding resmi, dan 15 hari kemudian, belum ada kabar dari siapa pun.

    Solusi

    Unresolved.

    Pelajaran

    Update yang memicu pemberitahuan 3.2(f) mungkin bukan hal yang sedang ditanggapi Apple. Sebelum mengajukan banding, kumpulkan bukti jelas tentang siapa pemilik dan pengoperasional setiap aplikasi, dan bersiaplah bahwa jawaban bisa memakan waktu berminggu-minggu.

67. 

    Bagian 3.2(f) (Developer Program License Agreement) iOS Penghentian akun

    Satu perbaikan paywall, lalu pemberitahuan pemutusan 3.2(f) seminggu kemudian

    Apa yang terjadi

    Aplikasi seorang developer indie pernah ditolak sekali karena cara harga tahunan dan mingguan ditampilkan di paywall-nya. Paywall itu berasal dari template yang disalin oleh asisten coding AI. Mereka memperbaikinya di code, mengirim build baru, dan menunggu sekitar seminggu. Alih-alih hasil review, mereka terbangun dan mendapati pemberitahuan bahwa akun mereka akan dihentikan berdasarkan Pasal 3.2(f). Seluruh keanggotaan developer mereka ditandai, semua aplikasi yang mereka bangun selama bertahun-tahun dihapus dari App Store, dan pencairan dana dibekukan. Developer tersebut mengatakan tidak mengubah apa pun di aplikasi setelah mengirim, punya log untuk membuktikannya, dan bertanya secara terbuka apakah ada yang pernah mendapatkan akunnya kembali.

    Solusi

    Belum terselesaikan saat postingan ini dibuat.

    Pelajaran

    Anggap penolakan paywall atau harga sebagai peringatan, bukan formalitas. Periksa setiap template atau paywall yang dihasilkan code untuk melihat bagaimana harga dan ketentuan uji coba ditampilkan sebelum pengajuan pertama, dan simpan log build serta log perubahan agar Anda bisa mendokumentasikan dengan tepat apa yang Anda kirim jika akun Anda suatu saat dipertanyakan.

68. 

    Panduan 3.1.1 In-App Purchase macOS Pedoman 3.1.1

    Klien cloud gaming gratis ditolak berdasarkan 3.1.1 karena pembelian di dalam game yang di-stream

    Apa yang terjadi

    Seorang developer membangun aplikasi remote play gratis untuk layanan cloud gaming dari produsen konsol besar dan mengirimkannya ke App Store. Versi Mac ditolak berdasarkan pedoman 3.1.1. App Review menyatakan bahwa beberapa game yang di-stream dapat mengarahkan pengguna membeli konten digital di luar App Store. Menurut pemahaman developer, layanan gaming tersebut tidak memungkinkan pemain menyelesaikan pembayaran selama sesi streaming: beberapa game menampilkan opsi pembelian, tetapi pembayaran tidak dapat diproses saat streaming. Mereka menyoroti bahwa beberapa aplikasi streaming serupa sudah ada di store dan mengajukan banding.

    Solusi

    Banding masih diproses saat posting ini dibuat.

    Pelajaran

    Untuk aplikasi streaming dan client, App Review menilai apa yang bisa dilihat pengguna di dalam konten yang di-stream, bukan hanya code milik Anda sendiri. Jelaskan di catatan review secara tepat bagaimana pembelian berjalan di dalam stream, lengkap dengan screenshot, sebelum submission pertama, bukan menundanya sampai banding.

69. 

    Login di iPad (nomor pedoman tidak disebutkan) iOS Masuk

    Penolakan ketiga karena login gagal di iPad saat gangguan backend

    Apa yang terjadi

    Sebuah tim kecil yang membangun aplikasi fitness mengalami penolakan aplikasi iOS untuk ketiga kalinya karena reviewer tidak bisa login di iPad. Penyebabnya bukan di code aplikasi mereka: penyedia backend yang mereka pakai sedang bermasalah dengan autentikasi tepat saat reviewer mencoba, jadi sign in gagal. Tim sudah menyediakan akun demo berisi email dan password, tapi menurut mereka reviewer tidak mencoba lagi setelahnya. Mereka juga tidak punya iPad atau Mac untuk testing. Begitu backend normal kembali, mereka submit ulang. Apple sudah bilang aplikasi akan tetap masuk expedited review meski ditolak lagi, tapi tiga hari kerja kemudian statusnya masih menunggu review.

    Solusi

    Sudah submit ulang, masih menunggu review saat tulisan ini dibuat.

    Pelajaran

    Reviewer sering tes di iPad dan biasanya hanya mencoba login satu kali. Pantau status backend dan auth provider Anda saat build sedang dalam review, tes akun demo di layar ukuran iPad sebelum submit, dan tuliskan di catatan review siapa yang harus dihubungi jika sign in gagal.

70. 

    Guidelines 5.1.1(i) dan 5.1.2(i) iOS Pedoman 5.1.1 Pedoman 5.1.2 Berbagi data AI

    Persetujuan AI yang terkubur dalam syarat dan ketentuan tidak cukup untuk 5.1.1(i) dan 5.1.2(i)

    Apa yang terjadi

    Aplikasi jurnal milik seorang developer ditolak di iOS berdasarkan pedoman 5.1.1(i) dan 5.1.2(i), keduanya tentang berbagi data pengguna dengan layanan AI. Persetujuan untuk pemrosesan itu sudah ada di syarat dan ketentuan aplikasi, tapi App Review tidak menerimanya. Developer memindahkan persetujuan ke layar khusus di dalam aplikasi, ditampilkan paling awal, sebelum model membaca satu pun entri. Mereka lalu memetakan setiap jalur code tempat entri sampai ke model dan menggantungkan masing-masing pada persetujuan itu, sehingga tidak ada request yang dibuat tanpa jawaban ya. Background job sekarang melewati akun yang belum setuju dan menunggu alih-alih gagal, dan pemeriksaan rilis gagal jika aplikasi memanggil host AI yang tidak disebutkan di layar persetujuan.

    Solusi

    Diperbaiki dan dikirim ulang. Keputusan Apple masih belum diketahui saat posting ini dibuat.

    Pelajaran

    Satu baris di syarat dan ketentuan Anda bukan persetujuan untuk berbagi data AI. Minta persetujuan di dalam aplikasi sebelum request pertama, sebutkan provider dan datanya, dan pastikan setiap jalur code yang mengirim konten pengguna memeriksa jawaban itu.

71. 

    Bagian 3.2(f) (Developer Program License Agreement), setelah penolakan metadata berulang iOS Penghentian akun Metadata dan IAP

    Satu library baru, delapan penolakan, app yang diganti nama, lalu pemberitahuan terminasi

    Apa yang terjadi

    Seorang indie developer punya app iOS yang usianya hampir tiga tahun, telah menghasilkan pendapatan enam digit, dan telah merilis banyak update dengan tingkat refund rendah. Lebih dari enam bulan lalu, mereka mengirim update kecil yang perubahannya hanya satu library baru. App Review menolaknya lebih dari delapan kali, setiap kali karena metadata: keyword yang sudah live lebih dari setahun, subtitle di salah satu lokalisasi, lalu screenshot, lalu poin yang sama lagi, dan akhirnya nama app itu sendiri, yang jadi sumber utama traffic search mereka. Mereka meminta call dengan App Review, dan reviewer bilang nama adalah satu-satunya masalah yang tersisa. Mereka mengganti nama seluruh app dan mengirim ulang. Tiga hari kemudian, penolakan generik datang lagi dengan masalah subtitle dan screenshot. Mereka memutuskan tidak membutuhkan update itu dan membatalkannya. Berbulan-bulan kemudian, pemberitahuan terminasi muncul di thread review lama yang sama. Isinya menyebutkan bahwa akun tersebut berulang kali melanggar pedoman dalam upaya menghindari proses review dan masalah dari pesan sebelumnya tetap tidak terselesaikan. App itu dihapus dari store dan seluruh akun ditandai untuk dihapus.

    Solusi

    Banding telah diajukan ke App Review Board dan masih pending saat posting ini.

    Pelajaran

    Submission yang dibiarkan begitu saja tetap bisa merugikan akun Anda. Jika loop review terus berlanjut, pastikan setiap masalah yang tersisa dikonfirmasi secara tertulis di thread review, bukan hanya lewat panggilan. Jika Anda memutuskan membatalkan update, balas di thread untuk menyampaikannya dan tarik build dari review, bukan membiarkan penolakan itu tidak terselesaikan.

72. 

    Guideline 1.1 Safety: Objectionable Content, lalu Section 3.2(f) iOS Konten yang tidak pantas Penghentian akun

    Dua penolakan 1.1, satu pertanyaan soal gambar mana, lalu pemberitahuan terminasi

    Apa yang terjadi

    Sebuah aplikasi iOS buatan developer yang menghasilkan foto pasangan berbasis AI ditolak berdasarkan guideline 1.1 karena konten yang tidak pantas. Penolakan itu tidak menyebutkan gambar mana yang bermasalah. Mereka memperhalus gambar sampel, tanpa sentuhan atau condong ke arah satu sama lain, lalu mengirim ulang sekitar lima hari kemudian. Empat hari setelahnya, aplikasi ditolak lagi dengan alasan yang sama. Alih-alih mengirim build baru, mereka menulis ke Apple untuk menanyakan gambar mana yang bermasalah. Sekitar sepuluh hari berlalu tanpa jawaban, lalu aplikasi dihapus dari store dan developer menerima pemberitahuan penghentian yang tertunda. Sejauh yang mereka pahami, Apple menganggap siklus perbaikan dan resubmit berulang sebagai upaya mengakali review. Payout dijeda dan semua aplikasi di akun itu berisiko, dengan 30 hari untuk mengajukan banding. Dari thread forum developer lain dengan pemberitahuan serupa, mereka menemukan bahwa sebagian besar banding didiamkan berminggu-minggu tanpa jawaban, dan satu-satunya pemulihan yang mereka temukan terjadi setelah banding kedua yang menyebutkan penyebab sebenarnya dan mengungkapkan semua hal lainnya.

    Solusi

    Sedang menyiapkan banding saat postingan ini dibuat.

    Pelajaran

    Dua penolakan di bawah guideline yang sama kini bisa cukup untuk membuat akun berisiko. Saat penolakan konten tidak jelas, minta App Review menunjukkan layar atau aset yang tepat sebelum mengirim ulang, simpan catatan setiap perubahan, dan anggap penolakan kedua sebagai sinyal untuk berhenti dulu, bukan mencoba lagi.

73. 

    Guideline 2.3.7, 5.2.5, dan 4.8 iOS Pedoman 2.3.7 Metadata dan IAP Persyaratan login

    Disetujui di Mac, tetapi ditolak di iPhone berdasarkan 2.3.7, 5.2.5, dan 4.8 pada aplikasi yang sama

    Apa yang terjadi

    Seorang developer yang membangun aplikasi klien kalender untuk layanan kalender pihak ketiga besar merilis versi Mac lebih dulu. Versi Mac itu sudah harus mengajukan banding formal hanya untuk menyatakan di listing bahwa aplikasi tersebut berfungsi dengan layanan kalender itu, dan mereka juga sudah menjelaskan ke App Review mengapa aplikasi itu tidak perlu Sign in with Apple. Saat mereka menambahkan versi iPhone, dengan bundle dan App ID yang sama seperti aplikasi Mac, aplikasi itu ditolak karena tiga pedoman sekaligus: 2.3.7 untuk harga yang ditampilkan di in-app event, 5.2.5 untuk satu baris yang menyebut aplikasi ini untuk iPhone, iPad, dan Mac, serta 4.8 karena tidak menawarkan Sign in with Apple di samping login milik layanan kalender tersebut. Pedoman 4.8 punya pengecualian untuk aplikasi yang menjadi klien layanan pihak ketiga tertentu, dan aplikasi ini termasuk di dalamnya, tetapi penjelasan untuk versi Mac tidak ikut terbawa. Setiap target platform ditinjau dari nol.

    Solusi

    Tidak disebutkan saat diposting.

    Pelajaran

    Platform baru berarti review baru, bahkan dengan App ID yang sama. Salin setiap penjelasan dan pengecualian yang sudah Anda peroleh ke catatan review untuk tiap platform, dan periksa in-app event serta deskripsi untuk harga dan nama perangkat Apple sebelum submit.

74. 

    Guideline 3.1.2(c), lalu merek dagang Apple dalam teks Siri (nomor guideline tidak disebutkan) iOS Pedoman 3.1.2 Review tanpa akhir

    Sembilan hari menunggu, penolakan paywall 3.1.2(c), lalu binary ditolak dalam 42 detik karena teks Siri

    Apa yang terjadi

    Seorang developer dengan akun baru mengirimkan versi pertama aplikasi kebiasaan menulis dan menunggu sekitar sembilan hari sebelum statusnya berubah menjadi In Review. Lima puluh menit kemudian, aplikasi ditolak berdasarkan Guideline 3.1.2(c): pada paket tahunan, harga bulanan yang dihitung ditampilkan dengan teks lebih besar daripada harga tahunan yang benar-benar ditagihkan. Mereka memperbaiki ukuran font paywall dan mengunggah build baru. Build tersebut ditolak otomatis dalam 42 detik, karena teks bantuan pada Siri shortcut menyebutkan aplikasi Apple dengan nama brand-nya, dan teks dalam Siri intents tidak boleh menggunakan kata Apple. Mereka mengubah kalimatnya agar merujuk ke aplikasi catatan secara umum dan mengunggah kembali build tersebut.

    Solusi

    Dikirim ulang, hasil belum diketahui saat postingan dibuat.

    Pelajaran

    Sebelum submission pertama, pastikan jumlah yang ditagih jadi harga paling menonjol di setiap plan dan cari merek dagang Apple di semua string yang tampil ke user, termasuk teks Siri, Shortcuts, dan widget. Pengecekan otomatis menangkapnya dalam hitungan detik, tapi setiap putaran tetap membuat Anda kehilangan satu tempat di antrean.

75. 

    Bagian 3.2(f) (Developer Program License Agreement), mengutip penolakan nama lama iOS Penghentian akun Metadata dan IAP

    Penolakan nama yang diperbaiki dan disetujui, lalu pemberitahuan penghentian karena fraud hampir setahun kemudian

    Apa yang terjadi

    Seorang developer solo yang mengelola akun perusahaan kecil telah membangun delapan aplikasi live dalam waktu sekitar satu setengah tahun. Hampir setahun sebelumnya, salah satu aplikasi tersebut ditolak karena Apple keberatan dengan sebuah kata dalam namanya. Developer tersebut mengubah namanya, aplikasi ditinjau kembali dan disetujui, dan update selanjutnya pun disetujui. Riwayat review yang mereka bagikan menunjukkan versi 1.0 ditolak pada dua hari berturut-turut dan disetujui sehari setelahnya, lalu sebuah update disetujui pada percobaan pertama sekitar dua bulan kemudian. Setelah itu, aplikasi tersebut tidak disentuh selama sekitar sembilan bulan. Kemudian, aplikasi baru dari akun yang sama ditolak, dan pemberitahuan penghentian akun yang tertunda datang dengan alasan aktivitas tidak jujur atau penipuan berdasarkan pasal 3.2(f): pengajuan berulang kali melanggar panduan dalam upaya menghindari review, dan masalah dari pesan sebelumnya tetap tidak terselesaikan. Tidak ada masalah baru yang disebutkan dan tidak ada peringatan atau pertanyaan terlebih dahulu. Pendapatan dari semua aplikasi dihentikan sementara, termasuk aplikasi yang tidak pernah bermasalah, dan pemberitahuan itu memperingatkan bahwa akun baru juga bisa dihentikan. Satu-satunya cara untuk merespons adalah formulir web yang dibatasi 2.000 karakter, yang hanya mengembalikan konfirmasi otomatis lalu tidak ada kabar lagi. Developer tersebut menerima penghapusan aplikasi yang ditandai, mematikan server mereka di hari yang sama, menghentikan semua pengajuan, dan mengirim banding lengkap pada hari pertama.

    Solusi

    Banding dikirim pada hari pertama; saat diposting, hanya ada konfirmasi otomatis.

    Pelajaran

    Penolakan yang sudah Anda perbaiki dan disetujui masih bisa dikutip berbulan-bulan kemudian sebagai bagian dari pola. Simpan setiap pesan penolakan, perubahan persis yang Anda buat, dan persetujuan yang menyusul, agar Anda bisa menunjukkan riwayat lengkapnya dalam formulir banding singkat, dan jangan berharap ada perkiraan waktu setelah formulir dikirim.

76. 

    Pedoman 4.3 Spam dan 4.2.6 iOS Pedoman 4.3 Pedoman 4.2.6

    Game yang dibuat sendirian, ditolak dua kali sebagai spam dan sebagai template, sembilan jawaban dikirim, tanpa balasan

    Apa yang terjadi

    Seorang developer yang membuat game sendirian di malam hari mengirim game orisinal dan ditolak dua kali, berjarak empat hari pada awal Oktober, berdasarkan pedoman 4.3 soal spam dan pedoman 4.2.6, yang mencakup aplikasi yang dibuat dari template komersial atau layanan pembuatan aplikasi. Tidak ada template yang terlibat dan setiap baris ditulis sendiri oleh developer tersebut. Kedua penolakan itu berisi teks template yang sama, dan tak satu pun menyebutkan aplikasi yang katanya mirip dengan game tersebut. Apple lalu mengirim sembilan pertanyaan tentang bagaimana game itu dibuat, dan developer menjawab semuanya secara detail keesokan harinya setelah penolakan kedua. Tidak ada balasan. Sekitar sembilan hari kemudian mereka mengajukan banding ke App Review Board, dan seminggu setelah itu mereka masih menunggu. Dugaan mereka sendiri, satu orang yang merilis beberapa game dalam beberapa bulan terlihat seperti pabrik aplikasi dari sisi reviewer. Sementara itu, mereka membuat game tersebut bisa dimainkan gratis di browser.

    Solusi

    Banding ke App Review Board masih dalam proses saat artikel ini dipublikasikan, sekitar tiga minggu setelah penolakan pertama.

    Pelajaran

    4.3 dan 4.2.6 bisa dinilai untuk seluruh akun Anda, bukan satu binary saja. Jika Anda merilis beberapa judul dalam waktu singkat, tunjukkan apa yang membuat masing-masing orisinal sejak pengajuan pertama, lengkap dengan catatan review tentang cara pembuatannya dan video gameplay singkat, karena setelah teks penolakan menjadi templat, jawaban detail bisa tidak terbaca selama berminggu-minggu.

77. 

    Guideline 2.1 App Completeness, lalu Guideline 5 Legal (ketersediaan di Tiongkok) iOS Pedoman 2.1 Pedoman 5 Legal Review tanpa akhir

    Lisensi gratis untuk reviewer menyembunyikan paywall, lalu enam hari antre dan penolakan AI dari China

    Apa yang terjadi

    Seorang developer mengirimkan aplikasi iOS pertamanya, sebuah alat keuangan pribadi untuk melacak pembayaran rutin, namun ditolak berdasarkan guideline 2.1 App Completeness. Penyebabnya adalah niat baik yang berujung bumerang: mereka memberikan lisensi berbayar ke email reviewer, sehingga reviewer melewati paywall dan tidak pernah melihat alur pembelian. Developer tersebut membuat panduan PDF langkah demi langkah dengan screenshot untuk reviewer lalu mengajukan ulang, kali ini mengirimkan versi iOS dan Mac sekaligus. Pengajuan baru itu menunggu enam hari sebelum masuk ke In Review, lalu ditolak lagi, kali ini karena menyebut ChatGPT saat aplikasi tersebut tersedia di China daratan.

    Solusi

    Masih ditolak saat posting ini ditulis, sementara build yang lebih baru sudah ditawarkan ke tester melalui TestFlight.

    Pelajaran

    Biarkan App Review melihat persis apa yang dilihat pengguna baru, termasuk paywall. Beri reviewer akun demo atau sandbox yang berfungsi dan catatan yang jelas, bukan lisensi gratis yang menyembunyikan alur pembelian. Jika aplikasi atau listing-nya menyebut penyedia AI seperti ChatGPT, cek apakah China daratan termasuk dalam ketersediaan aplikasi Anda sebelum submit, karena setiap putaran baru bisa memakan waktu berhari-hari di antrean.

78. 

    Pedoman 2.3.10 Metadata yang Akurat iOS Pedoman 2.3.10 Metadata dan IAP Review tanpa akhir

    Sepuluh hari sampai review pertama, satu penyebutan Google Play, lalu dua minggu lagi menunggu

    Apa yang terjadi

    Seorang developer dengan akun developer yang benar-benar baru mengirimkan aplikasi baru pada awal Oktober. Aplikasi ini memungkinkan pengguna upload gambar mereka sendiri secara publik, yang menurut developer akan memicu pengawasan moderasi konten ekstra. Review pertama datang sepuluh hari kemudian, di iPad, dan berakhir dengan penolakan berdasarkan guideline 2.3.10 Accurate Metadata: aplikasi atau metadatanya menyebut platform pihak ketiga, dan langkah selanjutnya adalah menghapus referensi Google Play. Developer melacak penyebutan itu ke teks yang mendeskripsikan in-app purchase. Setelah diperbaiki, aplikasi kembali masuk antrean, dan dua minggu kemudian masih menunggu review, 24 hari setelah submit pertama dan masih belum live.

    Solusi

    Masih menunggu review saat tulisan ini diposting, 24 hari setelah submit pertama.

    Pelajaran

    Periksa setiap field teks yang Anda submit, termasuk deskripsi in-app purchase, untuk nama store dan platform lain sebelum submit pertama. Di akun baru, setiap bolak-balik bisa memakan seminggu atau lebih di antrean, jadi satu kata penyebutan saja bisa menunda peluncuran hingga berminggu-minggu.

79. 

    Guideline 2.1 Kelengkapan Aplikasi (Informasi Diperlukan) iOS Pedoman 2.1 Review tanpa akhir

    24 hari di antrean, lalu penolakan 2.1 yang meminta rekaman layar penuh

    Apa yang terjadi

    Seorang developer mengirim versi 1.0.0 aplikasi iOS baru beserta grup langganan dan dua langganan, tahunan dan bulanan. Setelah menunggu 24 hari, Apple menolaknya berdasarkan pedoman 2.1 App Completeness, yang menurut developer membuatnya bingung. Karena versi aplikasi ditolak, langganan yang dikirim bersamanya juga tidak bisa disetujui dan tetap berstatus Ready for Review. Pesan di balik penolakan tersebut adalah permintaan 2.1 Information Needed, yang pertama kali diterima developer. Permintaan itu meminta rekaman layar di perangkat fisik yang menjalankan sistem operasi terbaru, dimulai dari peluncuran dan menunjukkan alur pengguna tipikal, termasuk registrasi, login, dan penghapusan akun, konten yang dibuat pengguna beserta alat pelaporan dan pemblokirannya, serta akses ke konten berbayar. Permintaan itu juga mencakup deskripsi tujuan dan audiens target, instruksi setup dengan kredensial login, daftar layanan eksternal yang digunakan aplikasi, termasuk layanan AI, perbedaan regional, dan dokumentasi untuk industri teregulasi atau materi pihak ketiga yang dilindungi. Jawaban-jawaban tersebut juga harus ditambahkan ke catatan review di App Store Connect untuk pengiriman berikutnya.

    Solusi

    Pengembang kembali menyiapkan rekaman dan jawaban saat posting. Hasilnya tidak diketahui.

    Pelajaran

    Permintaan 'Information Needed' setelah berminggu-minggu mengantre memakan satu putaran penuh lagi. Rekam walkthrough itu di perangkat fisik dan tulis jawabannya ke catatan review sebelum submit app baru, terutama yang punya subscription, akun, atau konten pengguna, karena versi yang ditolak juga menahan semua yang diajukan bersamanya.

80. 

    Bagian 3.2(f) (Developer Program License Agreement) Program Apple Developer Penghentian akun Review tanpa akhir

    Enam update disetujui berturut-turut, lalu satu update rutin dan terminasi 3.2(f).

    Apa yang terjadi

    Seorang indie developer mendapatkan enam update yang disetujui berturut-turut. Riwayat review yang mereka bagikan menunjukkan submission terbaru berstatus 'In Review' dan semua yang sebelumnya bertanda 'Review Completed'. Mereka lalu mengirim update rutin pada pertengahan Oktober, tetapi update itu tertahan di tahap review. Alih-alih hasil review, seluruh akun developer justru dihentikan berdasarkan pasal 3.2(f). Di App Store Connect, pesan bertanggal hari pengajuan itu terlampir ke beberapa versi dan ditandai sebagai masalah yang belum terselesaikan. Developer tersebut menyebut app mereka native, dengan rekam jejak update yang bersih, dan mengatakan support Apple sedang menyelidiki banding mereka.

    Solusi

    Banding sedang diinvestigasi saat posting ini dibuat.

    Pelajaran

    Riwayat approval yang bersih tidak melindungi Anda dari terminasi 3.2(f). Simpan catatan bertanggal untuk setiap submission, pesan review, dan approval, lalu cek bagian Messages di App Store Connect setelah setiap review, supaya Anda bisa mengirim seluruh riwayat begitu banding memungkinkan.

81. 

    Permintaan informasi App Review (akun demo dan screen recording) iOS Masuk

    Akun demo yang dihapus lima menit setelah submission, lalu permintaan screen recording yang mencegah penolakan kedua

    Apa yang terjadi

    Sebuah agensi mengirimkan aplikasi klien dengan akun demo untuk App Review. Lima menit setelah submission, akun demo itu sudah dihapus oleh App Review. Apple lalu meminta screen recording aplikasi. Saat membuat rekaman itu, tim menemukan sales copy di dalam aplikasi yang terlewat dan bisa membuat aplikasi ditolak lagi.

    Solusi

    Hasil akhir tidak dibagikan saat postingan dibuat.

    Pelajaran

    Reviewer bisa saja menghapus akun demo yang Anda sediakan, misalnya saat mengecek apakah hapus akun berfungsi, jadi siapkan cara untuk membuatnya ulang atau sediakan lebih dari satu akun. Rekam walkthrough review Anda sendiri sebelum submit: melihat aplikasi dengan cara yang sama seperti reviewer adalah cara murah untuk menangkap teks yang bisa memicu penolakan berikutnya.

82. 

    Bagian 3.2(f) (Developer Program License Agreement) Program Apple Developer Penghentian akun Metadata dan IAP

    Lima penolakan awal, empat update disetujui, lalu notifikasi 3.2(f) lebih dari setahun kemudian

    Apa yang terjadi

    Seorang developer iOS independen yang sudah hampir sepuluh tahun membuat aplikasi mengirim aplikasi AI image-to-video baru pada April 2025. Pengguna mengunggah foto mereka sendiri, mendapat generasi pertama gratis, lalu bisa membeli kredit lewat in-app purchase sekali beli, tanpa langganan. Pengajuan pertama ditolak lima kali, terutama karena screenshot dan metadata: screenshot dinilai terlalu berorientasi pemasaran, dan screenshot yang menampilkan pasangan berciuman, lalu penggantinya yang menampilkan lamaran pernikahan, ditandai melanggar pedoman Objectionable Content. Setelah perubahan pada screenshot, teksnya, dan build, aplikasi disetujui, lalu empat update menyusul tanpa satu pun penolakan, yang terakhir pada Agustus 2025. Tidak ada update yang dikirim setelah itu. Lebih dari empat belas bulan kemudian, sebuah Pending Termination Notice tiba menyatakan bahwa pengajuan dari akun tersebut berulang kali melanggar pedoman dalam upaya menghindari review, dengan pelanggaran yang masih belum diselesaikan setelah beberapa kali pengajuan ulang, dan notice itu dilampirkan ke kelima versi. Developer tersebut mengatakan App Store Connect tidak lagi menampilkan detail yang cukup untuk merekonstruksi penolakan lama. Mereka mengajukan banding sekitar 30 menit setelah notice tiba sekitar tengah malam, dalam batas 2.000 karakter, dan belakangan menyesal tidak menunggu agar bisa menulisnya lebih jelas.

    Solusi

    Banding masih diproses saat posting ini dibuat.

    Pelajaran

    Persetujuan bukan berarti kasus selesai. Simpan salinan setiap pesan penolakan, pedoman yang dikutip, perubahan yang Anda buat, dan tanggal disetujui, karena App Store Connect mungkin tidak menampilkan detail lama nanti. Jika ada pemberitahuan, luangkan waktu untuk menulis banding yang jelas sesuai batas karakter, daripada buru-buru mengirimkannya dalam satu jam pertama.

83. 

    Bagian 3.2(f) (Developer Program License Agreement) Program Apple Developer Penghentian akun Metadata dan IAP

    Kata kunci judul, pemutusan berdasarkan 3.2(f), dan jawaban banding yang merujuk ke referensi streaming

    Apa yang terjadi

    Seorang pengembang indie mengalami pemutusan seluruh akun pengembangnya berdasarkan bagian 3.2(f). Menurut keterangan mereka, itu terjadi tanpa peringatan dan tanpa penolakan metadata sebelumnya, dan mereka yakin penyebabnya adalah kesalahan kata kunci di judul aplikasi. Mereka mengajukan banding. App Review Board membalas bahwa investigasinya mengonfirmasi pelanggaran pedoman: salah satu aplikasi pengembang itu memuat referensi menyesatkan yang membuat pengguna mengira aplikasi tersebut menyediakan layanan streaming, yang oleh Apple disebut keterlaluan. Surat itu menyebut adanya pola perilaku manipulatif atau menyesatkan, membuat pembayaran pendapatan tetap ditahan, dan menyatakan bahwa setelah pemutusan resmi, pengembang dapat mengajukan petisi kepada App Review Board untuk pemulihan akun, dengan menjelaskan alasannya dan perbaikan yang direncanakan.

    Solusi

    Banding ditolak. Permohonan pemulihan dimungkinkan setelah penghentian resmi.

    Pelajaran

    Kata dalam judul atau kata kunci yang mengisyaratkan layanan yang tidak disediakan aplikasi, seperti streaming, bisa dibaca sebagai menyesatkan, bukan sekadar kesalahan metadata, dan itu bisa langsung berujung pada penghentian tanpa penolakan lebih dulu. Periksa setiap judul, subjudul, dan kata kunci terhadap fungsi sebenarnya dari aplikasi sebelum Anda mengirim.

84. 

    Pedoman 4.1(a) Copycats iOS Review tanpa akhir

    15 hari dalam review, lalu 4.1(a) Copycats karena poster film dari API publik

    Apa yang terjadi

    Seorang developer membangun aplikasi iOS yang membantu orang memilih film. Aplikasi ini menampilkan judul dan poster yang diambil dari basis data film publik API, dengan kredit di dalam aplikasi, dan tombol tontonnya membuka aplikasi streaming resmi, bukan melakukan streaming sendiri. Setelah 15 hari dalam review, Apple menolaknya berdasarkan pedoman 4.1(a) Copycats, menganggap poster tersebut sebagai konten pihak ketiga dan meminta bukti hak untuk menggunakannya, atau menghapusnya. Aplikasi yang sama dengan poster yang sama sudah disetujui di Android dan di app store perangkat TV.

    Solusi

    Belum terselesaikan saat diposting. Developer itu bertanya ke developer lain apakah syarat API sudah diterima sebagai bukti atau apakah poster-poster itu harus dihapus.

    Pelajaran

    Atribusi di dalam aplikasi dan persetujuan di store lain tidak dihitung sebagai hak untuk App Review. Jika aplikasi Anda menampilkan poster, artwork, atau logo dari API, siapkan bukti tertulis bahwa Anda boleh menampilkannya sebelum submit, atau rencanakan versi tanpa aset tersebut.

85. 

    Penolakan Metadata (keyword lokal) iOS Metadata dan IAP

    AI menerjemahkan aplikasi ke lima bahasa dan menyelipkan keyword yang bikin aplikasi ditolak

    Apa yang terjadi

    Seorang developer memakai model AI untuk menerjemahkan aplikasinya ke lima bahasa tambahan. Di salah satu bahasa itu, terjemahannya menambahkan keyword yang bisa disalahartikan, dan submission-nya ditolak karenanya. Seminggu kemudian developer tersebut masih menunggu jawaban dan, setelah sepekan mendengar cerita terminasi 3.2(f) dari developer lain, ia khawatir perbaikan yang sudah disetujui pun nanti bisa dijadikan alasan menindak akunnya.

    Solusi

    Masih menunggu jawaban dari Apple saat tulisan ini dibuat.

    Pelajaran

    Pastikan ada orang yang menguasai setiap bahasa untuk memeriksa setiap keyword, judul, dan subtitle yang sudah dilokalkan sebelum submit. Machine translation memang cepat, tapi App Review menilai kata-kata di setiap locale seolah-olah Anda yang memilihnya sendiri.

86. 

    Metadata App preview (referensi harga) iOS Metadata dan IAP

    App preview menyebutkan free trial tersedia, dan update ditolak

    Apa yang terjadi

    Seorang indie developer mengirimkan update dengan video app preview yang mencantumkan kata free trial available. Apple menolak update tersebut karena menganggap setiap penyebutan kata free di preview sebagai referensi harga. Developer tersebut kemudian mengedit ulang videonya dan submit kembali.

    Solusi

    Video diedit ulang dan dikirim ulang. Hasil akhir tidak dibagikan saat posting ini dibuat.

    Pelajaran

    Hindari harga dan kata 'gratis' di preview aplikasi, meskipun trial-nya benar-benar ada. Sebagai gantinya, tampilkan ketentuan trial di dalam aplikasi pada paywall.

87. 

    Guideline 2.5.1 Persyaratan Perangkat Lunak (HealthKit) iOS Review tanpa akhir

    Menunggu enam hari, lalu ditolak 2.5.1 karena sinkronisasi Health tidak punya badge Apple Health

    Apa yang terjadi

    Seorang indie developer mengirimkan update besar yang menambahkan sinkronisasi Apple Health untuk pertama kalinya. Update tersebut tertahan di status Waiting for Review selama enam hari. Baru setelah itu mereka menyadari ada developer agreement baru yang menunggu ditandatangani di akun mereka. Setelah ditandatangani, update itu masuk review sore itu juga, meski mereka tidak bisa memastikan apakah keduanya berkaitan. Update tersebut lalu ditolak berdasarkan guideline 2.5.1 karena fitur Health tidak diidentifikasi dengan jelas di interface aplikasi. Developer itu ternyata belum tahu soal badge Apple Health.

    Solusi

    Menambahkan badge Works with Apple Health di samping toggle sinkronisasi, catatan review, dan rekaman layar dari perangkat asli. Disetujui pada submission berikutnya.

    Pelajaran

    Jika aplikasi Anda membaca atau menulis data Health, tampilkan dengan jelas di antarmuka menggunakan badge Apple Health sejak submission pertama. Dan jika review macet berhari-hari, periksa App Store Connect untuk perjanjian yang belum ditandatangani sebelum hal lain.

88. 

    Pedoman 1.1 Konten yang Tidak Diinginkan iOS Konten yang tidak pantas

    Live lebih dari setahun tanpa penolakan, lalu dihapus di bawah 1.1 tanpa peringatan

    Apa yang terjadi

    Seorang developer indie memiliki aplikasi di App Store selama lebih dari setahun. Aplikasinya tidak pernah ditolak dan menghasilkan pendapatan langganan bulanan yang moderat. Tanpa peringatan sebelumnya, Apple mengirim pesan bahwa aplikasi tersebut telah dihapus dari store karena melanggar guideline 1.1 Objectionable Content.

    Solusi

    Developer itu memberi tahu Apple bahwa mereka tidak akan mengirim ulang, lalu meninggalkan aplikasi dan seluruh niche tersebut karena tidak ingin mempertaruhkan akun developer mereka.

    Pelajaran

    Riwayat review yang bersih tidak menjamin aplikasi aman dari penarikan di kemudian hari, dan aturan konten bisa diterapkan pada aplikasi yang sudah lama disetujui. Jika aplikasi Anda berada di niche yang sensitif, tinjau konten dan screenshot aplikasi Anda terhadap guideline 1.1 sekarang, bukan setelah ada notifikasi penghapusan.

89. 

    Penolakan karena Bug (guideline tidak disebutkan) iOS Review tanpa akhir

    Timeout matchmaking 100 detik dilaporkan sebagai bug, lalu menunggu balasan selama enam hari

    Apa yang terjadi

    Seorang developer mengirim game multiplayer. Reviewer menolaknya karena bug, padahal yang mereka temui bukan crash: game berhenti mencari setelah menunggu 100 detik untuk mencocokkan pemain dengan lawan, dan reviewer menganggap timeout itu sebagai perilaku rusak. Developer membalas reviewer dan menjelaskan cara kerja matchmaking, serta menghapus timeout dari game tersebut. Enam hari kemudian, mereka masih menunggu satu jawaban pun.

    Solusi

    Dijelaskan dalam balasan dan timeout sudah dihapus. Masih menunggu jawaban saat posting ini dibuat.

    Pelajaran

    Reviewer sering bermain sendirian pada jam yang tidak lazim, jadi antrean matchmaking kemungkinan kosong. Beri tim review akses ke game sungguhan, seperti lawan bot atau mode demo, dan jelaskan di catatan review sebelum submit.

90. 

    Penolakan metadata (link Terms dan Privacy) iOS Metadata dan IAP

    Code dipakai ulang dari aplikasi lain, dan link Terms serta Privacy masih mengarah ke aplikasi lama

    Apa yang terjadi

    Seorang developer membangun aplikasi baru dengan memakai ulang sebagian komponen dari salah satu aplikasi sebelumnya. Link Terms of Use dan Privacy Policy di dalamnya masih mengarah ke aplikasi lama, dan App Review menolak submission itu karena itu. Developer tersebut mengatakan pesan penolakan menjelaskan persis apa yang perlu diubah.

    Solusi

    Link sudah diperbaiki dan aplikasi dikirim ulang. Developer bilang review ekspres biasanya selesai dalam sehari, tapi sebaiknya jangan sering dipakai.

    Pelajaran

    Sebelum submit aplikasi yang di-build dari proyek lama, cek semua link, bundle name, dan halaman legal yang ikut terbawa. Baca pesan rejection dengan teliti, karena biasanya menyebutkan persis apa yang perlu diperbaiki.

91. 

    Panduan 2.1 Informasi Diperlukan iOS Pedoman 2.1

    Tidak ada bug di laporan, hanya 2.1 Information Needed, dijawab dengan rekaman 89 detik.

    Apa yang terjadi

    Seorang developer submit aplikasi keduanya, dan aplikasi itu dikembalikan dengan guideline 2.1 Information Needed tanpa bug yang dicantumkan sama sekali. App Review meminta screen recording plus jawaban tentang untuk siapa aplikasi ini, bagaimana penggunaannya, layanan eksternal apa yang diandalkan, dan region mana yang ditargetkan. Developer merekam 89 detik di simulator, mulai dari launch, satu kali penggunaan penuh fitur utama, sampai paywall, menjawab semua pertanyaan di notes, dan submit ulang pada hari yang sama.

    Solusi

    Rekaman dan jawaban dikirim pada hari yang sama. Hasil akhir tidak dibagikan saat publikasi.

    Pelajaran

    Untuk aplikasi baru, perkirakan akan ada permintaan informasi 2.1 dan siapkan diri. Siapkan rekaman singkat alur utama serta jawaban tertulis soal audiens, penggunaan, layanan eksternal, dan wilayah di catatan review sebelum submit, supaya review pertama tidak terhenti karena pertanyaan.

92. 

    Pedoman 2.5.4 Software Requirements (background modes) iOS Review tanpa akhir

    Ditolak karena satu checkbox yang terlewat, audio background mode, lalu menunggu sepuluh hari untuk update berikutnya

    Apa yang terjadi

    Sebuah tim kecil mengirimkan update untuk aplikasi yang sudah live. App Review menolaknya berdasarkan Pedoman 2.5.4 karena satu pengaturan: audio background mode aktif di aplikasi, padahal tidak dibutuhkan. Tim itu menghapus background mode dan resubmit pada hari yang sama, yang membuat mereka kehilangan sekitar satu hari. Update berikutnya lalu tertahan dalam review selama sekitar sepuluh hari.

    Solusi

    Mode latar belakang audio dihapus dan aplikasi dikirim ulang pada hari yang sama. Pembaruan berikutnya menunggu sekitar sepuluh hari dalam proses review.

    Pelajaran

    Background mode hanya diizinkan sesuai peruntukannya. Sebelum setiap pengiriman, buka capability Background Modes dan hapus apa pun yang tidak benar-benar dipakai aplikasi, karena satu checkbox yang tertinggal saja sudah cukup untuk ditolak, dan Anda tidak bisa memprediksi berapa lama review berikutnya.

93. 

    Pedoman 4.3(a) Spam iOS Pedoman 4.3

    Aplikasi web dalam wrapper mendapat penolakan spam 4.3(a), sehingga developer membangun ulang sebagai aplikasi native

    Apa yang terjadi

    Seorang developer mengirimkan versi pertama aplikasi mereka sebagai aplikasi web di dalam wrapper native. App Review menolaknya berdasarkan pedoman 4.3(a), aturan spam. Developer mengakui Apple ada benarnya. Mereka membangun ulang aplikasi sebagai aplikasi native sungguhan, memindahkan backend-nya ke server relay yang mereka jalankan sendiri, dan memublikasikan source code.

    Solusi

    Dibangun ulang sebagai aplikasi native dengan relay server self-hosted. Hasil dari versi yang dibangun ulang tidak dibagikan di postingan tersebut.

    Pelajaran

    Wrapper tipis di sekitar situs web mudah dianggap spam oleh App Review. Jika Anda merilis ke App Store, berikan nilai native yang nyata pada aplikasi sejak submission pertama, bukan berharap situs yang dibungkus bisa lolos.

94. 

    Penolakan konten yang tidak pantas (screenshot, lalu subtitle) iOS Konten yang tidak pantas Metadata dan IAP

    Screenshot ditandai sebagai tidak pantas, lalu subtitle, untuk game yang tidak mengandung konten dewasa

    Apa yang terjadi

    Studio kecil mengembangkan game cerita sederhana untuk iOS, tanpa tema dewasa, judi, atau kripto. Salah satu game, yang pemainnya adalah selebriti yang berusaha menembus Hollywood, ditolak karena konten tidak pantas di screenshot-nya. Screenshot-nya hanya menampilkan karakter game yang berpakaian lengkap. Studio mengganti semua screenshot dan mengirim ulang. Penolakan berikutnya adalah karena konten tidak pantas di subtitle, yang hanya mendeskripsikan game sebagai game kehidupan selebriti dan drama. Setiap review memakan waktu berminggu-minggu.

    Solusi

    Aplikasi ini pertama kali diajukan pada bulan September, namun hingga akhir Oktober masih belum disetujui.

    Pelajaran

    Jika App Review menandai metadata sebagai tidak pantas tanpa menjelaskan alasannya, tanyakan di App Store Connect elemen mana persisnya yang bermasalah dan mengapa, sebelum mengulang semuanya. Periksa screenshot, subtitle, dan keyword sekaligus sebelum resubmit, karena memperbaiki satu hal bisa memunculkan masalah berikutnya.

95. 

    Pedoman 5.2.5 Legal, Kekayaan Intelektual iOS Pedoman 5 Legal Metadata dan IAP

    Ditolak berdasarkan 5.2.5 karena screenshot menggunakan perangkat yang terlihat seperti iPhone

    Apa yang terjadi

    Seorang developer ditolak berdasarkan pedoman 5.2.5. App Review menyatakan metadata berisi gambar yang mirip iPhone di screenshot, yang bisa membingungkan pengguna dengan produk Apple. Perangkat yang ditampilkan bukan perangkat Apple, hanya perangkat yang mirip Apple, dan developer itu terkejut karena aplikasi lain mereka sudah disetujui dengan jenis gambar perangkat yang sama.

    Solusi

    Hasil akhir tidak dibagikan saat posting. Developer lain yang membalas menyebut bahwa App Review juga bisa keberatan dengan bingkai perangkat yang tidak sesuai platform atau render yang terlihat berbeda dari iPhone asli.

    Pelajaran

    Persetujuan satu aplikasi tidak menjadi preseden untuk aplikasi berikutnya. Mockup perangkat yang terlihat hampir seperti iPhone bisa dianggap mirip secara membingungkan dengan produk Apple. Gunakan screenshot biasa, atau hanya bingkai perangkat yang disediakan Apple untuk pemasaran, dan pastikan sesuai platform.

96. 

    Panduan 2.1 Informasi Diperlukan iOS Pedoman 2.1

    Aplikasi iOS pertama mendapat permintaan informasi 2.1, dan perbaikannya adalah membuat semuanya mudah ditemukan

    Apa yang terjadi

    Seorang solo developer yang versi Android-nya sudah live di Google Play submit aplikasi iOS pertamanya. Di dalamnya ada tiga in-app purchase dan user-generated content. App Review tidak langsung menolaknya, tapi mengirim permintaan informasi terkait guideline 2.1. Developer itu membaca ulang guideline 2.1, yang mewajibkan setiap in-app purchase terlihat dan berfungsi bagi reviewer, sekaligus mengecek aturan user-generated content (1.2) dan penghapusan akun (5.1.1(v)). Keesokan harinya dia submit build baru dengan opsi report dan block yang terlihat di setiap konten pengguna, aturan komunitas yang disetujui pengguna sebelum posting, fitur sign out dan switch account, plus rekaman layar yang menunjukkan letak pembelian, fitur keamanan, dan kontrol akun.

    Solusi

    Build baru dikirim sehari setelah permintaan. Hasilnya belum diketahui saat posting ini dibuat.

    Pelajaran

    Anggap review seperti usability test dengan orang asing dalam waktu singkat. Setiap opsi pembelian, report, block, dan kontrol akun harus bisa ditemukan dalam hitungan detik, dan rekaman di review notes harus menunjukkan tiap fitur tersebut. Sudah live di Google Play bukan jaminan lolos App Review.

97. 

    Guideline 4.3(a) Desain, Spam iOS Pedoman 4.3 Review tanpa akhir

    Dua puluh tujuh hari mengantre untuk aplikasi baru, lalu kena penolakan spam 4.3(a)

    Apa yang terjadi

    Seorang developer mengirim aplikasi yang benar-benar baru dan menunggu 27 hari agar App Review meninjaunya. Ketika hasilnya akhirnya muncul di App Store Connect, aplikasinya ditolak berdasarkan pedoman 4.3(a), Design, Spam. Developer tersebut lalu bertanya ke developer lain apakah ada yang pernah lolos dari penolakan 4.3(a).

    Solusi

    Tidak ada solusi yang dibagikan saat postingan itu dibuat. Developer tersebut mencari saran dari orang lain yang pernah kena penolakan 4.3(a).

    Pelajaran

    Waktu tunggu yang lama bukan berarti aplikasi Anda aman. Dengan antrean review yang selambat ini, penolakan 4.3(a) setelah berminggu-minggu berarti kehilangan waktu sebulan penuh. Sebelum mengirim aplikasi baru, bersikaplah jujur soal apa yang membuatnya berbeda dari aplikasi yang sudah ada di kategorinya, dan nyatakan itu dengan jelas di catatan review dan metadata.

98. 

    Guideline 4.3(a) Desain, Spam macOS Pedoman 4.3

    Aplikasi iPhone sudah live, lalu versi Mac-nya ditolak sebagai spam

    Apa yang terjadi

    Seorang developer memiliki aplikasi iPhone yang sudah live di App Store dan membangun versi desktop native dari aplikasi yang sama untuk Mac. App Review menolak aplikasi Mac tersebut berdasarkan pedoman 4.3(a). Pesannya menyatakan bahwa aplikasi tersebut memiliki binary, metadata, atau konsep yang mirip dengan aplikasi yang dikirimkan developer lain, dengan hanya sedikit perbedaan, dan menyarankan untuk mengajukan aplikasi unik dengan konten dan fungsionalitas yang berbeda. Developer tersebut bertanya kepada komunitas apa yang berhasil untuk orang lain yang menghadapi 4.3.

    Solusi

    Tidak ada solusi yang dibagikan saat postingan ini dibuat.

    Pelajaran

    Setiap platform punya review sendiri, dan aplikasi iPhone yang disetujui tidak berlaku untuk Mac. Pesan 4.3(a) membandingkan aplikasi Anda dengan aplikasi dari developer lain, jadi saat Anda membalas, jelaskan secara konkret apa yang dilakukan aplikasi Anda yang tidak dilakukan aplikasi serupa, dan tunjukkan fitur yang hanya ada di aplikasi Anda.

99. 

    Review tanpa akhir iOS Review tanpa akhir

    Lebih dari empat belas hari dalam proses review berakhir dengan penolakan, dan pengajuan ulang menunggu dua minggu lagi

    Apa yang terjadi

    Seorang developer mengatakan review sebelumnya memakan waktu lebih dari empat belas hari dan berakhir dengan penolakan. Developer tersebut mengirim ulang pada 21 Oktober, dan hampir dua minggu kemudian pengajuan masih berstatus Waiting for Review, padahal Apple menyatakan sebagian besar review hanya butuh 24 hingga 48 jam.

    Solusi

    Masih menunggu review saat artikel ini dipublikasikan.

    Pelajaran

    Rata-rata waktu review tidak menggambarkan kasus terburuk, dan penolakan mengembalikan Anda ke ujung antrean yang lambat. Rencanakan peluncuran dengan margin beberapa minggu, dan buat pengajuan pertama selengkap mungkin agar penolakan tidak menggandakan waktu tunggu.

100. 

     Persyaratan penghapusan akun (pedoman 5.1.1(v)) iOS Pedoman 5.1.1

     Ditolak karena tidak menyediakan penghapusan akun, setelah reviewer pertama menghapus beberapa akun

     Apa yang terjadi

     Seorang developer dengan aplikasi berbasis user-generated content ditolak pada review kedua karena dianggap tidak memiliki fitur hapus akun. Berdasarkan logs, saat review pertama, reviewer sempat membuat dan menghapus beberapa akun tanpa masalah. Developer merasa penolakan ini lebih karena kategori aplikasinya yang ketat, bukan karena fiturnya benar-benar tidak ada.

     Solusi

     Tidak ada solusi yang dibagikan saat postingan ini dibuat.

     Pelajaran

     Meski fitur sudah jalan, reviewer harus bisa menemukannya dengan cepat. Cantumkan alur hapus akun di review notes lengkap dengan screen yang harus diketuk, serta lampirkan rekaman singkat. Untuk aplikasi dengan user-generated content, tunjukkan juga fitur reporting, blocking, dan moderasi, karena kategori itu yang paling ketat diperiksa.

101. 

     Guideline 2.1(a) Kelengkapan Aplikasi macOS Pedoman 2.1

     Aplikasi Mac ditolak di bawah aturan 2.1(a) karena membaca login keychain, dan catatan penolakan lamanya hilang

     Apa yang terjadi

     Seorang developer mengirim aplikasi Mac, lalu App Review menolaknya berdasarkan pedoman 2.1(a) karena aplikasi membaca dari login keychain. Perbaikannya hanya butuh satu update. Yang membuat developer kaget adalah App Store Connect itu sendiri: hanya menampilkan sepuluh submission terakhir, sehingga pesan rejection lama lenyap dari riwayat.

     Solusi

     Diperbaiki dalam satu update. Developer sekarang menyalin setiap pesan rejection ke commit yang memperbaikinya.

     Pelajaran

     Jangan andalkan App Store Connect sebagai catatan rejection masa lalu, karena submission lama akan hilang dari tampilan. Simpan teks rejection lengkap di samping perbaikannya, di commit, ticket, atau release notes, agar Anda tetap memiliki persis kata-katanya jika masalah yang sama muncul lagi.

102. 

     Guideline 1.4.1 Physical Harm (kesehatan dan medis) iOS Review tanpa akhir

     Sepuluh hari dalam review untuk aplikasi kesehatan, lalu rejection 1.4.1 diperbaiki dengan halaman sources dalam satu sore

     Apa yang terjadi

     Seorang developer indie yang membangun aplikasi kesehatan menunggu lebih dari sepuluh hari untuk review App Store. Hasilnya adalah penolakan berdasarkan guideline 1.4.1 yang mencakup aplikasi kesehatan dan medis. Perbaikannya kecil: developer menambahkan halaman sumber yang mencantumkan asal informasi kesehatan di aplikasi, dan hanya butuh satu sore untuk membuatnya.

     Solusi

     Menambahkan halaman sumber dengan referensi, yang hanya memakan waktu satu sore. Apakah pengajuan ulang disetujui tidak disebutkan dalam postingan tersebut.

     Pelajaran

     Aplikasi kesehatan dituntut dengan standar yang lebih tinggi, dan penantian lama bisa berakhir dengan permintaan yang sebenarnya bisa Anda penuhi sebelum submit. Jika aplikasi Anda menampilkan informasi kesehatan atau medis, tambahkan referensi yang jelas di dalam aplikasi sebelum pengajuan pertama. Seorang developer yang membalas mencatat bahwa peringatan agar pengguna berkonsultasi dengan dokter juga sering diminta.

103. 

     In-app purchase terlalu sulit diakses oleh reviewer (nomor guideline tidak disebutkan) iOS Metadata dan IAP

     Update game ditolak karena paywall terlalu dalam, lalu lolos dalam 26 jam setelah fitur unlock dipindah ke layar utama

     Apa yang terjadi

     Seorang developer indie butuh 33 hari dan dua penolakan agar versi 1.0 game iOS mereka disetujui. Update pertama, 1.0.1, juga ditolak karena paywall-nya terlalu dalam di game sehingga reviewer tidak bisa menjangkaunya. Developer itu menambahkan tombol unlock di title screen lalu submit ulang. Kali ini seluruh prosesnya makan waktu sekitar 26 jam, dengan waktu review sebenarnya hanya sekitar 12 menit.

     Solusi

     Menambahkan tombol unlock di title screen. Update disetujui sekitar 26 jam setelah submit ulang.

     Pelajaran

     Reviewer tidak akan memainkan game Anda selama dua puluh menit hanya untuk mencari apa yang Anda jual. Letakkan setiap pembelian di tempat yang bisa dijangkau dalam hitungan detik, atau jelaskan alur persisnya di catatan review, agar reviewer bisa mengujinya tanpa harus mencari-cari.

104. 

     Ketidakcocokan metadata In-App Purchase (nomor guideline tidak disebutkan) iOS Metadata dan IAP

     Ditolak karena paywall menyebut gratis 1 bulan, sementara Apple menampilkan biaya tahunan

     Apa yang terjadi

     Seorang developer berpindah dari berminggu-minggu di TestFlight menuju peluncuran publik di App Store dan satu build ditolak karena paywall. Paywall menyatakan 1 bulan gratis, tetapi layar pembelian Apple menunjukkan tagihan tahunan dimulai pada hari yang sama. Reviewer juga tidak dapat menemukan paket mingguan. Developer memperbaiki teks paywall dan visibilitas paket, mengirim build lain, dan menunggu review lagi.

     Solusi

     Memperbaiki paywall agar teks uji coba gratis sesuai dengan sheet pembelian dan paket mingguan dapat diakses. Aplikasi kemudian tayang di App Store.

     Pelajaran

     Apa yang dijanjikan paywall Anda harus sesuai dengan yang ditampilkan sheet pembelian Apple, termasuk durasi trial dan kapan penagihan dimulai. Letakkan setiap paket yang perlu diuji reviewer di tempat yang bisa dijangkau dalam beberapa ketukan, dan periksa jalur tersebut pada instalasi baru sebelum Anda submit.

105. 

     Guideline 2.1 App Completeness (crash saat launch) iOS Pedoman 2.1

     Resubmit dengan perbaikan performa tambahan mengalami crash saat start dan memakan waktu sehari penuh

     Apa yang terjadi

     Setelah penolakan pertama di App Store yang hanya berupa permintaan informasi tambahan, pengembang memutuskan untuk memasukkan perbaikan performa ke dalam resubmission yang sama. Mereka begitu yakin hingga juga menghapus hardware gate yang ditujukan untuk perangkat kelas gaming. App Review menolak build tersebut lagi karena crash saat startup, tanpa crash log, hanya pesan otomatis. Pengembang mengasumsikan itu memory kill, mengembalikan gate, dan menghabiskan hari itu dengan mengecilkan aset, menunda loading, dan membebaskan resource tanpa kehilangan performa.

     Solusi

     Mengembalikan hardware gate, memangkas memory footprint, dan menyiapkan submission ketiga untuk keesokan harinya. Hasil akhir setelah putaran ketiga tidak dibagikan dalam postingan tersebut.

     Pelajaran

     Jangan menumpuk perbaikan yang tidak terkait ke dalam resubmission yang ditujukan untuk menjawab pertanyaan review. Kirim perubahan terkecil yang menjawab penolakan, pertahankan stability gate untuk perangkat terendah yang Anda klaim didukung, dan lakukan cold start pada perangkat tersebut sebelum upload lagi.

106. 

     Pedoman 4.3(a) Spam Desain iOS Pedoman 4.3

     Beberapa game kecil yang dikirim bersama semuanya terkena 4.3(a), lalu dua banding dikabulkan

     Apa yang terjadi

     Seorang developer mengirim beberapa game kecil ke App Store dalam waktu yang hampir bersamaan. Semuanya ditolak berdasarkan pedoman 4.3(a) karena spam. Setelah gelombang itu, mereka mengubah proses dan kini hanya mengirim satu game dalam satu waktu. Dua dari penolakan itu kemudian dibatalkan setelah banding ke App Review Board.

     Solusi

     Beralih ke pengiriman satu per satu. Dua penolakan 4.3(a) dibatalkan melalui banding ke App Review Board.

     Pelajaran

     Mengelompokkan aplikasi serupa ke dalam jendela review yang sama berisiko memicu temuan spam untuk seluruh kelompok. Kirim satu per satu, dan jika penolakan 4.3(a) tampak keliru, ajukan banding ke App Review Board dengan penjelasan jelas mengapa setiap aplikasi berbeda.

107. 

     Pedoman 1.1 Keamanan, Konten yang Tidak Pantas (metadata aplikasi) iOS Konten yang tidak pantas Metadata dan IAP

     Aplikasi pemulihan ditolak berdasarkan 1.1 karena materi pemasarannya menyebutkan kebiasaan yang dibantu aplikasi itu untuk dihentikan

     Apa yang terjadi

     Aplikasi yang dibuat untuk membantu orang mengatasi pornografi dan nafsu ditolak berdasarkan pedoman 1.1. App Review menyatakan bahwa pemasaran aplikasi merujuk pada konten yang tidak pantas dalam metadatanya, termasuk deskripsi, tangkapan layar, dan kata kunci. Ketika pengembang meminta detail, App Review menyebutkan satu kata kunci, porn, mengatakan bahwa daftar itu tidak lengkap, memperingatkan bahwa aplikasi akan mendapat peninjauan penuh saat pengajuan ulang, dan menyatakan bahwa pengajuan ulang dengan pemasaran yang sama, atau sebagai aplikasi baru dengan konsep yang sama, akan menghasilkan pelanggaran yang sama atau lebih banyak. Pengembang menunjukkan bahwa aplikasi serupa yang sudah ada di toko secara terbuka memasarkan bantuan untuk godaan seksual.

     Solusi

     Belum terselesaikan saat pos itu dibuat. App Review meminta semua referensi ke konten yang tidak pantas dihapus dari metadata sebelum peninjauan ulang penuh, dan pengembang mempertanyakan secara publik mengapa aplikasi serupa diperlakukan berbeda.

     Pelajaran

     Aplikasi yang membantu orang berhenti dari kebiasaan dewasa dinilai dari kata-kata dalam pemasaran mereka sendiri, bukan dari niatnya. Jelaskan tujuannya, seperti pemulihan atau kontrol diri, alih-alih menyebut kebiasaan buruk itu di kata kunci, deskripsi, dan tangkapan layar, lalu tanyakan ke App Review istilah persis apa yang memicu penolakan sebelum mengajukan ulang, karena pengajuan berikutnya akan mendapat peninjauan penuh.

108. 

     Ikon aplikasi ditandai sebagai ofensif (nomor pedoman tidak disebutkan) iOS Konten yang tidak pantas Metadata dan IAP

     Ikon aplikasi yang sudah disetujui ditolak karena menampilkan terlalu banyak kulit

     Apa yang terjadi

     Aplikasi AI menggunakan karakter ilustrasi sebagai ikon aplikasi, mengenakan crop top yang memperlihatkan sebagian dada dan perut. Ikon yang sama sebelumnya telah lolos App Review. Pada pengajuan berikutnya, Apple menolaknya karena dada dan perut terlalu terbuka. Pengembang menggambar ulang karakter dengan atasan tertutup yang menutupi keduanya dan submit ulang.

     Solusi

     Menggambar ulang ikon agar bagian atasnya menutupi dada dan perut. Postingan tersebut tidak menyebutkan berapa lama proses review baru itu berlangsung.

     Pelajaran

     Persetujuan sebelumnya tidak mengunci ikon atau screenshot Anda, karena setiap pengajuan dapat dinilai ulang. Jika karakter di gambar Anda menampilkan kulit, asumsikan reviewer yang lebih ketat mungkin menandainya, dan siapkan varian yang lebih tertutup agar perbaikannya cukup ganti, bukan desain ulang.

109. 

     Alur pembatalan langganan (nomor pedoman tidak disebutkan) iOS Metadata dan IAP

     Ditolak karena ada langkah konfirmasi tambahan saat pembatalan, seminggu sebelum Apple meluncurkan fitur pesan retensi

     Apa yang terjadi

     Sebuah aplikasi langganan menampilkan layar konfirmasi 'apakah Anda yakin' sendiri saat pengguna mencoba membatalkan. App Review menolak aplikasi tersebut karena hal ini. Kurang dari seminggu kemudian, App Store Connect mengumumkan fitur pesan retensi, yang memungkinkan pengembang menampilkan pesan, dengan gambar opsional atau tawaran retensi, kepada pelanggan saat mereka mencoba membatalkan langganan.

     Solusi

     Artikel tersebut tidak menjelaskan bagaimana penolakan itu diperbaiki. Fitur baru di App Store Connect kini menyediakan cara yang disetujui Apple untuk menampilkan pesan saat pembatalan.

     Pelajaran

     Jangan tambahkan hambatan tambahan di depan alur pembatalan langganan. Biarkan pengguna mengakses alur pembatalan secara langsung, dan jika Anda ingin memberikan kesempatan terakhir untuk mempertahankan mereka, gunakan pesan dan tawaran retensi Apple alih-alih layar kustom.

110. 

     Guideline 5.6 Developer Code of Conduct dan 2.5.19 Hidden Features iOS Pedoman 5.6 Kode Etik Developer Code Guideline 2.5.19 Fitur Tersembunyi

     Ditolak berdasarkan 5.6 karena fitur tersembunyi yang ternyata checkout code yang dibundel dalam SDK langganan

     Apa yang terjadi

     Seorang developer solo memiliki aplikasi pelacak tujuan iOS yang ditolak tujuh kali sebelum peluncuran. Salah satu penolakan sebelumnya berkaitan dengan taruhan uang sungguhan. Penolakan terakhir datang di bawah Developer Code of Conduct: App Review menyatakan bahwa aplikasi memiliki fungsi tersembunyi atau menyesatkan dan meminta semua fitur tersembunyi dihapus, tanpa menyebutkan yang mana. Aplikasi tidak memiliki remote feature flags, tidak ada code yang diunduh, dan tidak ada perilaku khusus untuk reviewer. Alih-alih menebak, developer memindai binary rilis mereka sendiri dan menemukan web checkout code dari penyedia pembayaran yang tidak pernah mereka tulis. Hal ini datang terbundel di dalam SDK langganan mereka untuk SDK platform web tersebut, dan aplikasi iOS tidak pernah menggunakannya. Mengingat penolakan taruhan uang sebelumnya, developer mencurigai hal itu terlihat seperti jalur pembayaran tersembunyi.

     Solusi

     Tanpa mengubah code apa pun, developer tersebut membalas App Review dengan fakta-fakta sederhana: apa yang dilakukan dan tidak dilakukan oleh aplikasi, bahwa tidak ada risiko uang sungguhan, dari mana code checkout berasal, bahwa SDK web code yang tidak terpakai dan izin perpustakaan foto yang tidak terpakai akan dihapus di build berikutnya, serta permintaan untuk menyebutkan layar yang ditandai. Sekitar sembilan jam kemudian, App Review menyatakan akan melanjutkan review, dan aplikasi pun tayang.

     Pelajaran

     Kenali semua yang dikirimkan oleh binary Anda, termasuk code yang dibawa oleh SDK Anda untuk platform lain, karena App Review menilai apa yang ada di build, bukan apa yang Anda sebut. Setelah penolakan 5.6, jangan menebak-nebak dan mengirim ulang. Balas dengan tenang menggunakan detail spesifik dan tanyakan layar atau perilaku mana yang ditandai.

111. 

     Pedoman 2.3.4 Metadata yang Akurat (Pratinjau Aplikasi) iOS Metadata dan IAP

     App Preview yang lolos review di bulan Oktober ditolak berdasarkan 2.3.4 karena framing-nya satu bulan kemudian

     Apa yang terjadi

     Seorang developer mengirim pembaruan untuk aplikasi iOS mereka dan ditolak berdasarkan guideline 2.3.4. App Review menyatakan bahwa video App Preview memiliki framing di sekitar tangkapan layar. Video yang sama telah lolos review bulan sebelumnya. Developer tersebut menunjukkan bahwa aplikasi lain di store, termasuk satu yang terkenal yang prewiewnya menampilkan orang alih-alih aplikasi, menggunakan App Preview dengan sedikit atau tanpa footage aplikasi itu sendiri.

     Solusi

     Pengembang menghapus video App Preview sepenuhnya dan mengirim ulang update tersebut. Postingan itu tidak menjelaskan bagaimana hasil review barunya.

     Pelajaran

     App Preview yang pernah lolos bisa ditolak lagi di update berikutnya, karena setiap submission di-review ulang. Batasi preview hanya pada tangkapan layar aplikasi polos tanpa bingkai dekoratif. Jika ada yang ditandai, menghapusnya adalah cara tercepat untuk membuka blokir update sambil Anda memperbaikinya.

112. 

     Bagian 3.2(f) (Developer Program License Agreement) macOS Penghentian akun Review tanpa akhir

     Update macOS yang memperbaiki masalah ikon tertahan di review selama sekitar 45 hari, lalu notifikasi 3.2(f) tiba

     Apa yang terjadi

     Seorang pengembang independen memiliki aplikasi macOS yang ditandai App Review karena masalah branding. Pada 15 September 2026, mereka mengirim update yang menanggapi umpan balik, termasuk ikon aplikasi yang dirancang ulang sepenuhnya. Update tersebut kemudian tetap berstatus In Review selama sekitar 45 hari tanpa keputusan, dan pengembang mengirim dua permintaan review dipercepat melalui saluran resmi. Pada 30 Oktober 2026, saat update yang sudah diperbaiki itu masih menunggu, notifikasi Pending Developer Account Termination Notice tiba di bawah bagian 3.2(f).

     Solusi

     Banding masih diproses saat artikel ini dipublikasikan. Developer telah mengajukan banding resmi dan menghubungi Developer Support secara terpisah, namun belum menerima tanggapan substantif.

     Pelajaran

     Perbaikan yang menunggu di antrean tidak menghentikan penegakan aturan pada submission lama. Simpan catatan bertanggal untuk setiap penolakan, setiap perubahan yang Anda lakukan sebagai respons, dan setiap permintaan percepatan, agar banding dapat menunjukkan persis apa yang telah Anda perbaiki dan kapan.

113. 

     Pedoman 3.2.2 Model Bisnis yang Tidak Dapat Diterima iOS Pedoman 3.2.2

     Aplikasi tantangan langkah berbayar ditolak berdasarkan 3.2.2, dan panggilan dengan App Review mengonfirmasi bahwa seluruh model bisnisnya tidak diizinkan

     Apa yang terjadi

     Sebuah tim yang sudah menjalankan aplikasi fitness dengan ribuan pengguna membangun aplikasi iOS kedua di sekitar tantangan langkah berbayar: pengguna membayar biaya untuk bergabung dalam tantangan berjalan kaki, model dasar yang sama dengan beberapa aplikasi fitness yang sudah ada di store. App Review menolaknya berdasarkan guideline 3.2.2. Penjelasannya adalah bahwa model berbasis penalti apa pun tidak diizinkan, baik pengguna membayar sebelum tantangan dimulai atau dikenakan biaya setelah tidak mencapai target. Tim tersebut bertemu dengan tim App Review untuk bertanya apa yang harus diubah, dan diberitahu bahwa konsepnya sendiri yang tidak diizinkan, bukan satu layar atau langkah tertentu dalam alur.

     Solusi

     Tim memutuskan untuk tidak mengajukan banding karena tidak ingin mempertaruhkan akun developer mereka. Saat artikel dipublikasikan, aplikasi tersebut belum ada di store, dan mereka masih belum paham mengapa aplikasi dengan model yang sama tetap aktif.

     Pelajaran

     Aplikasi serupa yang sudah ada di store bukan preseden yang akan diterima App Review, karena build Anda dinilai berdasarkan cara guideline dibaca saat ini. Jika ada uang berpindah tangan berdasarkan apakah pengguna mencapai target, periksa model tersebut terhadap 3.2.2 sebelum membangun seluruh produk di sekitarnya, misalnya dengan bertanya langsung ke App Review.

114. 

     Pedoman 5.6 Kode Etik Developer Code iOS Pedoman 5.6 Kode Etik Developer Code

     Update yang ditolak berdasarkan 5.6 karena fitur tersembunyi mendapat penolakan yang persis sama setelah review kedua yang memakan waktu hampir tiga minggu

     Apa yang terjadi

     Seorang developer mengirim update untuk aplikasi iOS mereka dan ditolak berdasarkan Developer Code of Conduct. Notifikasinya menyatakan bahwa App Review melihat pola perilaku tidak biasa yang umum dikaitkan dengan aktivitas penipuan, khususnya fitur yang tampaknya sengaja disembunyikan selama review. Developer tersebut menyatakan tidak ada yang disembunyikan di dalam aplikasi dan tidak menggunakan trik atau perilaku yang menyesatkan. Mereka mengunggah ulang aplikasi dengan penjelasan persis tentang apa yang dilakukan aplikasi, lalu menunggu hampir tiga minggu untuk review kedua. Hasilnya kembali dengan penolakan yang persis sama, masih tanpa menyebutkan fitur atau layar tertentu.

     Solusi

     Belum terselesaikan saat postingan dibuat. Developer tersebut mengatakan akan mengajukan banding.

     Pelajaran

     Notifikasi 5.6 generik yang tidak menyebutkan fitur tertentu jarang bisa lolos hanya dengan build yang sama plus penjelasan. Tanyakan ke App Review di thread mana layar atau perilaku yang ditandai, periksa apa saja SDK yang ada di binary Anda, dan gunakan jalur banding formal jika balasan tidak membuahkan hasil.

115. 

     Pedoman 4.3(a) Spam iOS Pedoman 4.3

     Game baru dalam seri indie ditolak berdasarkan 4.3(a) karena terlalu mirip dengan game sebelumnya dari developer tersebut

     Apa yang terjadi

     Seorang developer independen sedang mempersiapkan rilis iOS untuk game baru di seri mereka, sambil menerjemahkannya ke lebih banyak bahasa. App Review menolak versi iOS tersebut sebagai spam berdasarkan pedoman 4.3(a), dengan alasan terlalu mirip dengan game-game sebelumnya dari developer tersebut. Developer tersebut telah merombak sistem pertempuran inti secara signifikan, tetapi mengakui bahwa beberapa bagian yang diwariskan dari seri tersebut, seperti antarmuka dasar, ikon, dan logo, masih terlihat sangat mirip dengan judul-judul sebelumnya. App Review hanya mengirim pesan penolakan standar, dan seminggu setelah meminta detail lebih lanjut, developer tersebut belum mendapat balasan.

     Solusi

     Belum terselesaikan saat postingan ini dibuat. Developer tersebut sedang menjelaskan kepada App Review apa yang membedakan game baru ini dari judul-judul sebelumnya, dan mengatakan bahwa mereka tidak bisa memastikan kapan atau apakah versi iOS akan dirilis.

     Pelajaran

     Berdasarkan 4.3(a), katalog belakang Anda sendiri dihitung sebagai pembanding, sehingga sekuel yang menggunakan kembali antarmuka, ikon, dan branding dari game sebelumnya bisa dianggap sebagai duplikat meskipun gameplay-nya berubah. Buat bagian-bagian baru terlihat jelas di build dan screenshot, dan daftarkan untuk reviewer di catatan sebelum Anda submit.

116. 

     Pedoman 5.2.5 dan 2.3.10 iOS Pedoman 5 Legal Pedoman 2.3.10

     Aplikasi untuk membuat tangkapan layar toko ditolak karena ikonnya sendiri menampilkan logo App Store

     Apa yang terjadi

     Seorang developer membangun aplikasi yang membantu orang membuat screenshot untuk App Store dan Google Play. Build iOS pertamanya ditolak karena dua pedoman. Berdasarkan 5.2.5, ikon aplikasi menampilkan logo App Store di samping logo Google Play, dan subtitle di listing diawali dengan kata App Store. Berdasarkan 2.3.10, Google Play muncul di dalam build iOS itu sendiri, di binary, ikon, dan screenshot. Developer tersebut sudah melihat ikon itu setiap hari selama berminggu-minggu tanpa menyadari masalahnya.

     Solusi

     Developer tersebut menggambar ulang ikon, menulis ulang subtitle, dan menambahkan satu switch yang menyembunyikan Google Play di seluruh versi iOS, dari onboarding dan export hingga settings dan pesan error, tanpa mengubah proyek yang tersimpan dan tetap mempertahankan kedua store di Android. Mereka menjelaskan perubahan itu dalam satu baris di catatan review. Build kedua sudah menunggu review setidaknya tiga hari saat posting.

     Pelajaran

     Apple meninjau ikon dan subtitle seketat layar aplikasi. Meskipun aplikasi Anda tentang app store, jauhkan tanda Apple dari ikon dan listing, dan pastikan tidak ada nama store lain yang muncul di mana pun dalam build iOS, termasuk screenshot.

117. 

     Kegagalan in-app purchase (pedoman tidak disebutkan) iOS Metadata dan IAP Review tanpa akhir

     Sebuah game ditolak tiga hari setelah tanggal rilis yang diumumkan karena pembelian gagal saat reviewer sedang offline

     Apa yang terjadi

     Seorang developer independen sudah mengumumkan tanggal rilis untuk game mereka. Build tersebut berada di review selama lebih dari seminggu dan baru diproses setelah mereka meminta expedited review. Akhirnya, game itu ditolak tiga hari setelah tanggal yang diumumkan. Berdasarkan screenshot yang dilampirkan pada penolakan, reviewer tidak memiliki koneksi internet saat mencoba melakukan in-app purchase. Aplikasi memang menampilkan error yang menyatakan pembelian gagal, tetapi pesannya terlalu ambigu.

     Solusi

     Developer tersebut mengajukan banding dan masih belum mendapat jawaban sekitar sebulan kemudian. Sementara itu, mereka merancang ulang antarmuka, menulis ulang pesan error untuk menjelaskan lebih jelas apa yang salah, dan berencana mengirim ulang versi yang sudah diperbaiki.

     Pelajaran

     Reviewer juga bisa mengalami jaringan yang buruk. Coba setiap skenario pembelian tanpa koneksi dan dengan permintaan store yang gagal, lalu pastikan aplikasi menampilkan pesan yang jelas dan opsi untuk mencoba lagi. Hindari mengumumkan tanggal peluncuran sebelum build disetujui.

118. 

     Penolakan terkait Crash, subscription, EULA, dan paywall (nomor guideline tidak disebutkan) iOS Pedoman 2.1 Pedoman 3.1.2 Review tanpa akhir

     Aplikasi iOS pertama butuh 37 hari dan empat penolakan, dengan setiap review menemukan masalah baru

     Apa yang terjadi

     Seorang developer mengirim aplikasi iOS pertamanya, yang menjual langganan, pada 1 Oktober. Delapan hari kemudian ditolak karena crash. Mereka mengirim ulang keesokan harinya, dan sekitar dua minggu kemudian ditolak karena masalah langganan. Pengiriman ulang berikutnya ditolak dua hari kemudian karena EULA. Penolakan keempat, pada 5 November, menyangkut tautan di paywall dan pratinjau. Setiap putaran memunculkan masalah yang tidak disebutkan di review sebelumnya.

     Solusi

     Disetujui pada 7 November, 37 hari setelah pengiriman pertama. Developer senang bisa meluncurkan, tetapi mengatakan review bisa lebih cepat dan transparan untuk developer indie.

     Pelajaran

     Penolakan tidak selalu mencantumkan semua masalah di build. Sebelum pengiriman pertama, periksa peluncuran di perangkat asli, detail langganan, tautan Terms of Use (EULA), dan tautan paywall secara bersamaan, karena setiap putaran tambahan bisa memakan waktu seminggu atau lebih.

Halaman ini bukan nasihat hukum dan tidak memprediksi apa yang akan dilakukan Apple pada submission Anda berikutnya.