Guideline 4.0 Design: app ditolak karena tampilannya
Oleh Mehdi Azizi
Terbit , 9 mnt
Guideline 4.0 Design: Apple menolak antarmuka yang sulit dipakai, sering di iPad. Uji tiap layar di iPhone SE dan iPad, perbaiki, lalu balas.
"Guideline 4.0 - Design" bukan aturan bernomor seperti yang lain: ini adalah pembuka bagian Design dalam aturan Apple, yang dikutip saat antarmukamu terlihat di bawah standar yang diharapkan. Penolakan yang dipublikasikan mirip satu sama lain: layar sesak di iPad, teks sulit dibaca, login yang dilempar ke Safari, Sign in with Apple yang diintegrasikan dengan buruk. Perbaikannya hampir selalu dimulai di perangkat yang disebut dalam pesan, layar demi layar.
Saya merilis app iOS saya sendiri dengan Expo: Solys, TradaZen, dan Nolera diatur khusus untuk iPhone, tapi reviewer tetap menguji Solys dan Nolera di iPad. Panduan ini berpegang pada teks Apple, pada penolakan 4.0 yang dipublikasikan developer lain, dan pada daftar cek visual yang saya jalankan sebelum setiap pengiriman. Untuk gambaran umum alasan penolakan, baca kenapa Apple menolak sebuah app.
Apa yang dicakup guideline 4.0 Design?
Bagian 4 dari App Review Guidelines dibuka dengan paragraf tanpa nomor: "Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store." Paragraf itu menambahkan bahwa desain adalah milikmu, tapi bagian selanjutnya menetapkan "minimum standards for approval". Apple juga memperingatkan bahwa app yang kualitasnya menurun setelah disetujui bisa dihapus.
Singkatnya: Apple mengharapkan app yang sederhana, rapi, dan mudah dipakai, dan 4.0 dipakai ketika masalahnya tidak masuk ke sub-aturan mana pun. Teksnya tidak memberi kriteria berupa angka. Acuan praktisnya adalah Human Interface Guidelines, aturan desain Apple.
Penolakan 4.0 yang paling sering
Berikut empat kasus yang saya temukan di pesan-pesan yang dipublikasikan di forum Apple, beserta kalimat yang dikutip.
| Kasus | Kalimat Apple | Perbaikan |
|---|---|---|
| Layar sesak di iPad | "crowded" | Tata letak fleksibel |
| Teks tidak terbaca | "hard to read type" | Ukuran sesuai HIG |
| Login di Safari | "taken to Safari" | Login di dalam app |
| Sign in with Apple | Nama diminta lagi | Nama sudah diberikan |
Layar sesak atau terpotong di iPad
Pesan khasnya, dipublikasikan pada September 2025: "Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0." Lanjutannya menjelaskan bahwa app hanya memakai sebagian layar (thread forum).
Penyebabnya ada di aturan 2.4.1: "iPhone apps should run on iPad whenever possible." Di Expo, opsi ios.supportsTablet bernilai false secara default, menurut konfigurasi app Expo. App iPhone-mu lalu berjalan di iPad dalam mode kompatibilitas, di jendela berformat iPhone. Mengatur app khusus iPhone tidak membuatnya aman dari pengujian di iPad. Di iPad Air-lah demo Solys jadi mustahil dimenangkan, kasus yang saya bahas di panduan guideline 2.1.
Ada dua jalan keluar. Pertama, kamu benar-benar mendukung iPad, dengan tata letak yang mengikuti ruang yang tersedia. Aturan desain Apple meminta tata letak ditentukan berdasarkan size class, bukan model perangkat. Kedua, kamu tetap di iPhone, dan setiap layar harus muat di jendela kompatibilitas.
Teks sulit dibaca
Pesannya, dipublikasikan pada Januari 2025: "Your app included hard to read type or typography." Di situ Apple mengingatkan bahwa pengguna mengharapkan app yang "simple, refined, and easy to use" (thread forum).
Aturan tipografi Apple memberi patokan untuk iOS: 17 poin secara default, minimal 11 poin. Aturan aksesibilitas meminta kontras minimal 4,5 banding 1 untuk teks hingga 17 poin, dan area sentuh 44 x 44 poin secara default.
Ada jebakan kalau kamu mengecilkan font di layar kecil, seperti yang saya lakukan agar pemenggalan baris tetap sama di mana-mana: pastikan teks terkecilmu, setelah dikecilkan di iPhone SE, tetap minimal 11 poin.
Login dilempar ke Safari
Pesannya, dipublikasikan di forum Apple: "We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience." Apple meminta agar pendaftaran dan login bisa dilakukan di dalam app, dan merekomendasikan tampilan Safari yang tertanam.
Di Expo, expo-web-browser memenuhi dua kebutuhan ini tanpa keluar dari app: openAuthSessionAsync membuka sesi autentikasi di jendela modal, dan openBrowserAsync menampilkan halaman di tampilan Safari yang tertanam. Sebaliknya, membuka login dengan Linking.openURL akan melempar pengguna ke app Safari. Sementara itu, pilihan metode login yang ditawarkan diatur oleh aturan lain, yaitu 4.8.
Sign in with Apple yang diintegrasikan dengan buruk
Pesannya, dipublikasikan pada Mei 2024: "Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework." (thread forum).
Dokumentasi expo-apple-authentication menjelaskan jebakannya: nama dan email hanya diberikan saat login pertama. Simpan langsung, kalau tidak kamu akan tergoda untuk memintanya lagi. Gunakan juga tombol yang disediakan library: warnanya dipilih dengan buttonStyle dan sudutnya dengan cornerRadius, jangan pernah lewat style.
4.0, 4.2, 4.3: tiga penolakan desain yang jangan sampai tertukar
| Aturan | Yang dinilai | Perbaikan |
|---|---|---|
| 4.0 | Antarmuka | Memperbaiki layar |
| 4.2 | Kegunaan app | Menambah isi native |
| 4.3 | Kemiripan | Mengganti konsep |
4.2, Minimum Functionality, meminta fitur, konten, dan antarmuka yang mengangkat app "beyond a repackaged website". Batasnya dengan 4.0 tipis: situs yang dibungkus jadi app bisa kena keduanya. Kalau app-mu kurang isi, merapikan layar saja tidak akan cukup.
4.3 menyasar app tiruan dan kategori yang sudah jenuh: saya sudah membahas dua ayatnya di panduan guideline 4.3 Design Spam. Antarmuka yang rapi tidak bisa menyelamatkan app yang mirip dengan seribu app lain.
Daftar cek visual sebelum submit
Ini yang saya tambahkan di setiap pengiriman. Di app saya, setiap layar dirancang untuk iPhone terbesar, lalu diperkecil dengan satu skala saja di iPhone yang lebih kecil: proporsi sama, pemenggalan baris sama. Lalu saya bandingkan hasilnya berdampingan: iPhone SE, iPhone standar, iPhone terbesar, dan satu iPad untuk mode kompatibilitas.
| Pengecekan | Perangkat | Yang harus aman |
|---|---|---|
| Peluncuran pertama | iPhone SE | Tidak ada yang terpotong |
| Onboarding lengkap | iPad | Setiap tombol bisa dijangkau |
| Keyboard terbuka | iPhone SE | Kolom dan tombol terlihat |
| Teks diperbesar | iPhone standar | Tidak ada teks terpotong |
| Mode gelap | Semua | Teks terbaca di mana-mana |
| Safe area | Terbesar | Tidak ada di bawah Dynamic Island |
| Paywall | iPhone SE | Harga dan link terlihat |
| Login | iPad | Tetap di dalam app |
Tiga catatan:
- Teks diperbesar. Aturan tipografi Apple menyarankan tes sederhana: aktifkan ukuran teks terbesar di Settings, Accessibility, Display & Text Size, lalu cek bahwa semuanya tetap terbaca.
- Mode gelap. Aturan Apple tentang mode gelap meminta app tetap terbaca di kedua tampilan. Expo memakai
lightsecara default kalau kamu tidak mengaturuserInterfaceStyle. Solys mengikuti pengaturan ponsel, TradaZen selalu gelap, Nolera selalu terang: di ketiganya, saya menguji tampilan yang ditampilkan. - Safe area. Konten tidak boleh berada di bawah Dynamic Island maupun di bawah indikator Home. Expo menjelaskan caranya di panduan safe area mereka.
Di Mac, simulator bisa diatur lewat command line, jadi daftar cek ini cepat diulang:
xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png
Di ponsel asli, saya mengulang putaran yang sama dengan build TestFlight. Metodologi: daftar cek ini milik saya, disusun dari penolakan yang dialami app saya, bukan daftar dari Apple. Daftar ini mengurangi kejutan tapi tidak menjamin app diterima.
Bagaimana membalas penolakan 4.0?
- Catat perangkat dan versinya yang disebut di pesan, lalu buka model yang sama di simulator.
- Perbaiki semua kemunculannya. Pesan khasnya meminta untuk "address all instances" dari masalah itu, bukan hanya layar di screenshot.
- Kirim build baru: reviewer menguji kode yang ada di dalam app.
- Balas dengan screenshot yang diambil di perangkat yang sama, dengan membalas pesan App Review.
- Ajukan banding hanya kalau kamu yakin: Apple memungkinkan kamu mengajukan ke App Review Board, dengan satu banding per submission yang ditolak.
Template yang akan saya pakai, sesuaikan sendiri:
Hello,
Thank you for your feedback regarding Guideline 4.0.
We reproduced the issue on [device] running [OS version].
Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].
We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.
Attached: screenshots of the updated screens on [device].
Best regards,
Siapkan pengirimanmu tanpa penolakan desain
Review Kit berisi checklist saya sebelum pengiriman, yang antara lain mencakup aturan 2.4.1 soal iPad, dan skill Claude Code yang memeriksa proyekmu. Kalau mau dilihat langsung oleh manusia, booking satu jam dengan saya: kita buka layar-layarmu di berbagai ukuran, lewat video call. Langkah lengkap setelah penolakan ada di halaman app ditolak Apple.
Sedang menyiapkan rilis pertamamu? Ikuti diagnostik gratis: diagnostik ini mengurutkan langkah-langkahnya dan mengirimkan checklist anti-penolakan Apple saya.
Pertanyaan umum
Apa arti "Guideline 4.0 - Design" di pesan penolakan?
Apple menilai antarmukamu di bawah standar yang diharapkan, tanpa menyasar sub-aturan tertentu: layar sesak, teks sulit dibaca, alur login yang dinilai buruk. Pesannya biasanya menyebut perangkat yang dipakai dan sering melampirkan screenshot.
App saya diatur khusus iPhone: kenapa Apple mengujinya di iPad?
Karena aturan 2.4.1 menginginkan app iPhone berjalan di iPad sebisa mungkin. App-mu terbuka di sana dalam mode kompatibilitas, di jendela berformat iPhone, dan setiap layar harus tetap bisa dipakai.
Apakah perlu build baru setelah penolakan 4.0?
Ya, di sebagian besar kasus. Reviewer menguji kode yang ada di dalam app saat peluncuran pertama, dan perbaikan yang dikirim dari jarak jauh bisa terlewat olehnya. Ini yang saya jelaskan di panduan guideline 2.1.
Apakah mode gelap wajib agar diterima?
Teks aturan review tidak mewajibkannya. Aturan desain mengingatkan bahwa pengguna berharap app mengikuti pengaturan mereka. Kalau kamu memaksa mode terang atau gelap, seperti yang dimungkinkan Expo, uji tampilan itu. Kalau kamu mengikuti pengaturan ponsel, uji keduanya.
Bisakah mengajukan banding atas penolakan 4.0?
Bisa, ke App Review Board, kalau kamu yakin app-mu mematuhi aturan. Apple meminta alasan yang spesifik, hanya satu banding per submission yang ditolak, dan menjawab permintaan informasi terlebih dahulu.

