Catatan, Agustus 2026: tulisan ini berasal dari rilis sebelumnya dan menggambarkan struktur tingkat langganan pada saat itu. AlcoLog menggabungkan tingkat Pro ke dalam Premium di v1.2.0, sehingga kini hanya ada satu tingkat berbayar. Tidak ada yang hilang dalam penggabungan itu, dan siapa pun yang memiliki Pro dipindahkan ke Premium tanpa biaya tambahan.

Jika Anda akan merilis aplikasi iOS v1.0 dengan langganan, In-App Purchase, pendamping Watch, widget, atau posisi apa pun yang bersinggungan dengan kesehatan, proses App Review akan lebih sulit daripada yang tersirat dalam dokumentasinya. Tulisan ini adalah catatan dari satu siklus peluncuran (empat penolakan dalam lima hari, lima peninjau, satu binary) dan pola-pola yang membuat siklus itu bisa dilalui. Saya membagikannya karena pengalaman ini termasuk bagian yang paling jarang didokumentasikan dari merilis aplikasi indie yang serius, dan versi yang terdokumentasi (sesi WWDC, halaman Review Guidelines, forum developer) tidak sesuai dengan kenyataan sehari-hari.

Jika Anda sedang di tengah siklus dan mencari perbaikan praktis, langsung saja ke “Yang perlu diperbaiki sebelum Anda mengirim” dan “Pola yang perlu dipahami”. Kronologi pribadinya ada di paruh kedua jika Anda ingin konteksnya.

# Yang perlu diperbaiki sebelum Anda mengirim

Inilah hal-hal yang muncul di sepanjang empat penolakan. Jika Anda memperbaikinya sejak awal, Anda menghilangkan sebagian besar celah penolakan untuk v1.0 berlangganan di kategori sensitif.

# Hierarki tampilan harga di paywall langganan

Human Interface Guidelines Apple untuk langganan sangat jelas soal penyajian harga. Jumlah yang ditagihkan harus menjadi elemen harga yang paling menonjol. Naluri pemasaran (membuat diskonnya terasa sebagai kemenangan) adalah naluri yang salah di sini. Naluri kepatuhan (membuat jumlah tagihan menjadi elemen tipografi utama) adalah yang benar.

Artinya dalam praktik: harga reguler harus menjadi elemen terbesar dan paling tebal. Harga perkenalan atau diskon harus lebih kecil, dengan label eksplisit “Periode pertama:”. Hindari lencana persentase pada penanda kecil (gunakan “PENAWARAN PELUNCURAN”, bukan “DISKON 25%”). Penegakan 3.1.2© Payments and Subscriptions untuk poin ini konsisten di semua peninjau.

# Jalur penghapusan data yang eksplisit

Bahkan ketika “akun” Anda hanyalah pengenal anonim yang bersifat opt-in, pedoman 5.1.1(v) Apple mewajibkan jalur penghapusan yang berlabel, terlihat, dan langsung. Mematikan sakelar sebagai penghapusan tersirat tampak patuh dari sisi developer, tetapi tidak memenuhi penegakan yang berlaku saat ini.

Sediakan tombol “Hapus Data Saya” yang eksplisit di layar privasi atau pengaturan sejak build pertama. Tambahkan peringatan konfirmasi. Pastikan teks di sekitarnya menjelaskan perilaku penghapusan yang sebenarnya, bukan jadwal sementara yang berniat Anda ubah nanti.

# Audit Info.plist untuk deklarasi sisa

Background mode, background fetch, entitlement lokasi, deklarasi HealthKit, dan entri Info.plist serupa bisa tidak terpakai selama berbulan-bulan sementara kode terus berkembang. Entri-entri itu akan ditandai jika tidak sesuai dengan fitur yang benar-benar ada. Penegakan 2.5.4 Software Requirements di sini bersifat mekanis dan tidak ambigu.

Secara spesifik: setiap entri UIBackgroundModes harus sesuai dengan fitur yang benar-benar memakainya. Jika aplikasi Anda mendeklarasikan “location” sebagai background mode tetapi Anda tidak pernah memakai lokasi latar belakang yang berkelanjutan dan menetapkan allowsBackgroundLocationUpdates = false, hapus deklarasi itu. Pemantauan wilayah (region monitoring) tidak membutuhkannya. Audit ini hanya memakan waktu sepuluh menit dan mencegah satu siklus penolakan.

# Tautan Terms of Use yang berfungsi di metadata App Store

Kolom Privacy Policy di App Store Connect sudah dikenal luas. Persyaratan Terms of Use kurang dikenal. Jika Anda memakai EULA standar Apple, sertakan tautan ke Terms of Use di App Description. Jika Anda memakai EULA kustom, tambahkan di kolom EULA kustom App Store Connect.

Halaman ketentuan itu sendiri harus mengungkapkan semua produk berbayar beserta durasi langganan, harga, dan mekanisme perpanjangannya. Kebanyakan tim menyebarkan elemen-elemen ini di beberapa halaman terpisah atau menyembunyikannya di dalam kebijakan privasi. Satukan semuanya dalam satu halaman ketentuan yang bisa dibaca peninjau dalam dua menit.

# Video App Preview: gunakan rekaman layar mentah

Mockup ponsel 3D, bingkai perangkat, dan komposisi pemasaran yang digayakan adalah keputusan diskresi peninjau di bawah 2.3.4 Accurate Metadata. Halaman panduan publik tidak secara eksplisit melarang bingkai perangkat, tetapi materi pelatihan internal yang dipakai peninjau tampaknya melarangnya. Rekaman layar biasa dengan resolusi asli jelas aman.

Simpan tampilan pemasaran untuk situs web Anda sendiri, media sosial, dan Reddit. Letakkan rekaman layar di slot App Preview. Perbedaan konversi antara “pratinjau mockup yang rapi” dan “pratinjau rekaman layar mentah” kecil. Penurunan risikonya besar.

Peninjau bekerja dengan jatah waktu 5 sampai 15 menit per aplikasi. Mereka tidak selalu menemukan setiap IAP yang terlampir pada versi tersebut. Jika IAP Anda bisa dicapai lewat jalur yang berbeda-beda di dalam aplikasi (paywall terpisah, kartu terpisah, navigasi yang lebih dalam), sertakan petunjuk navigasi klik demi klik untuk setiap IAP di App Review Notes Anda.

Format yang berhasil:

Premium subscriptions and Lifetime IAP: Settings tab > Premium card > Get Premium button > Premium upgrade sheet Pro subscriptions and Lifetime IAP: Settings tab > Pro card > Get Pro button Consumable Tip Jar items: Settings tab > scroll past tier cards > Tip Jar card > Show Tip Options

Ini terdengar berlebihan. Tetapi cara ini mencegah satu siklus penolakan tertentu (Guideline 2.1(b) Information Needed) yang kalau tidak akan menghabiskan satu hari.

# Jeda kalender antara pengajuan dan tanggal peluncuran yang sudah dijanjikan

Untuk pengajuan v1.0 dengan langganan di kategori sensitif, rencanakan setidaknya tujuh hari kalender antara pengajuan pertama dan tanggal peluncuran yang sudah Anda umumkan ke luar. Setiap siklus penolakan berlangsung sekitar 24 jam jika Anda merespons dengan cepat. Empat siklus penolakan adalah skenario terburuk yang realistis untuk pengajuan v1.0 di kategori sensitif.

Jika tanggal peluncuran Anda sudah dijanjikan ke luar (Pre-Order sudah diatur, In-App Event sudah dijadwalkan, kampanye pemasaran sudah dipesan, jurnalis sudah dihubungi), jeda tujuh hari adalah batas minimum. Sepuluh hari lebih nyaman. Kurang dari tujuh hari, Anda berisiko melewatkan tanggal itu hanya karena satu penolakan prosedural.

# Pola yang perlu dipahami

Beberapa pengamatan dari dalam siklus yang tidak terlihat jelas dari dokumentasi.

# Setiap penolakan menemukan hal yang berbeda

Empat penolakan kembali dengan menandai hal-hal yang tidak saling tumpang tindih. Setiap peninjau punya akses ke setiap layar yang sudah diloloskan peninjau sebelumnya. Peninjau pertama menandai tautan EULA di metadata. Peninjau kedua menandai tiga hal berbeda di binary yang sama (background mode, tampilan harga, tombol penghapusan). Peninjau ketiga menandai aset pemasaran. Peninjau keempat mengajukan pertanyaan tentang navigasi.

Ini bukan bug. Ini adalah ciri dari cara App Review disusun. Peninjauan tampaknya bersifat per masalah, bukan per aplikasi. Peninjau berhenti di masalah besar pertama yang mereka temukan dalam jatah waktunya. Mereka tidak diwajibkan melakukan audit menyeluruh, dan sistemnya tidak memberi status “sudah diloloskan sebelumnya” pada bagian yang telah diterima peninjau sebelumnya. Strukturnya mengutamakan volume kerja lembaga di atas pengalaman developer.

Implikasinya: Anda tidak bisa mendapatkan audit menyeluruh dari satu putaran peninjauan mana pun. Anda hanya mendapatkan apa pun yang dimunculkan peninjau saat itu dalam rentang waktunya, dan Anda harus menerima bahwa peninjau berikutnya bisa secara mandiri memunculkan hal lain di putaran berikutnya.

# Setiap penolakan cenderung lebih kecil cakupannya daripada yang sebelumnya

Ini pola yang longgar, bukan jaminan. Penolakan pertama sering kali substantif (persyaratan yang terlewat, masalah arsitektur). Penolakan kedua masih substantif, tetapi lebih berbentuk daftar periksa. Penolakan ketiga bergeser ke metadata yang sifatnya pinggiran. Penolakan keempat kadang malah berupa pertanyaan prosedural, bukan penolakan sama sekali.

Alasannya bukan karena aplikasinya “makin baik” di setiap putaran. Alasannya adalah permukaan yang bisa ditinjau di binary dan metadata menyusut di setiap putaran, karena hal yang sebelumnya ditandai sudah diperbaiki dan hal yang sebelumnya diloloskan tidak lagi masuk cakupan. Para peninjau secara mandiri menghabiskan permukaan daftar periksa yang tersedia, yang berarti peninjauan berikutnya punya lebih sedikit hal untuk ditemukan.

Pola ini menenangkan selama Anda berada di dalam siklus, tetapi jangan bergantung padanya. Peninjau di akhir siklus tetap bisa memunculkan masalah substantif yang terlewat oleh peninjau sebelumnya.

# Ketelitian peninjau sangat bervariasi

Dari empat peninjauan atas binary yang sama, variasi temuan tiap peninjau cukup besar. Satu peninjau menemukan tiga hal. Yang lain menemukan satu hal pinggiran. Yang ketiga mengajukan pertanyaan yang sebenarnya bisa dijawab dengan mengetuk sebuah kartu di tab kedua aplikasi.

Anda tidak punya pengaruh atas peninjau mana yang menerima pengajuan Anda di putaran mana pun. Rencanakan dengan memperhitungkan variasi itu. Jangan berasumsi putaran berikutnya akan lebih teliti atau lebih longgar daripada yang sebelumnya. Keduanya adalah sampel independen dari sebaran yang lebar.

# Persetujuan Beta App Review tidak memprediksi persetujuan App Review penuh

Kedua jalur itu punya tim yang berbeda dan kriteria yang berbeda. Build yang lolos Beta dengan fitur yang sama yang kemudian ditandai di peninjauan produksi bukanlah kontradiksi. Itu dua proses peninjauan yang berbeda.

Jika Anda memakai TestFlight untuk memastikan kesiapan menghadapi peninjauan produksi, Anda memakainya untuk sinyal yang salah. TestFlight menangkap validitas build dan masalah kepatuhan dasar. App Review produksi menangkap seluruh cakupan penegakan. Keduanya tidak bisa saling menggantikan.

# Faktor penegakan kategori sensitif saling bertumpuk

Langganan, terutama dengan harga perkenalan atau penawaran uji coba, otomatis memicu penegakan 3.1.2. Kategori yang bersinggungan dengan kesehatan (alkohol, kebugaran, kesehatan mental, tidur) memicu perhatian peninjau terhadap masalah klaim medis 1.4.1. Fitur yang sensitif terhadap privasi (lokasi, HealthKit, pengenal anonim) memicu pemeriksaan 5.1.1. Pengajuan versi pertama v1.0 memicu peninjauan menyeluruh. In-App Event yang terikat pada tanggal peluncuran memicu pemeriksaan metadata.

Masing-masing faktor bisa ditangani. Tetapi faktor-faktor itu bertumpuk secara berlipat. Peluncuran serius di kategori sensitif dengan langganan, beberapa platform, dan In-App Event mengaktifkan semua faktor sekaligus. Utilitas satu layar yang gratis tanpa IAP lolos dalam 2 menit. Tingkat kesulitan peninjauan Anda berkorelasi dengan keseriusan dan luasnya peluncuran Anda, bukan dengan kualitas aplikasi Anda.

# Dokumentasi dan penegakan tidak selalu sepenuhnya cocok

Sebuah penolakan bisa mengutip panduan yang tidak tercantum secara eksplisit di halaman publik yang ditautkan. Peninjau bekerja berdasarkan materi pelatihan internal yang bertumpang tindih dengan Review Guidelines publik, tetapi tidak identik. Jika Anda menemukan penolakan yang tidak sesuai dengan dokumen publik, Anda bisa menyanggahnya dengan sopan. Kadang keputusannya dibatalkan, kadang tidak.

Saat menyanggah, lakukan secara tertulis di Resolution Center, dalam satu paragraf terstruktur yang mengutip panduan publik dan menanyakan klausul spesifik yang diterapkan. Hindari nada frustrasi dalam bahasa Anda. Peninjau membaca tanggapan itu dengan jatah waktu terbatas; tanggapan yang dibaca dengan saksama adalah tanggapan yang menghargai hal itu.

# Cara merespons penolakan secara konstruktif

Beberapa catatan praktis tentang komunikasi bolak-balik di Resolution Center.

# Balas di hari yang sama jika bisa

Cara tercepat keluar dari siklus adalah menjaga siklus tetap bergerak. Hitungan waktu setiap siklus penolakan dimulai ulang saat Anda merespons. Tanggapan di hari yang sama menghasilkan penyelesaian di minggu yang sama; tanggapan yang memakan beberapa hari memperpanjang siklus secara sebanding.

Ini menuntut tim Anda tersusun untuk merilis perbaikan dengan cepat. Bagi developer indie, ini sering berarti mengosongkan jadwal di hari-hari setelah pengajuan. Masa pengajuan tidak bisa diperlakukan sebagai pekerjaan sampingan.

# Gabungkan semua perbaikan dalam satu pengajuan ulang

Jika sebuah penolakan menandai tiga hal, perbaiki ketiganya sebelum mengajukan ulang. Jangan kirim balasan “sudah memperbaiki dua dari tiga, sedang mengerjakan yang ketiga”. Peninjau berikutnya akan memunculkan hal yang sama sekali berbeda; balasan dengan perbaikan parsial hanya menambah satu siklus lagi ke antrean.

# Sertakan rekaman layar yang membuktikan perbaikan

Untuk setiap perbaikan yang tidak sepele, lampirkan rekaman layar berdurasi 30 detik yang menunjukkan perbaikan itu bekerja. Alur penghapusan, tampilan harga yang sudah dikoreksi, jalur navigasi yang baru. Peninjau lebih mungkin meloloskan masalah itu di putaran berikutnya jika mereka bisa melihat perbaikannya tanpa harus menavigasi sendiri.

# Minta peninjauan menyeluruh dalam balasan Anda

Permintaan sopan agar semua keberatan yang tersisa disampaikan sekaligus di putaran saat ini, alih-alih tersebar ke beberapa siklus tambahan, adalah hal yang wajar. Tidak selalu berhasil, tetapi sesekali berhasil. Pemilihan kata itu penting: “We have addressed every issue raised so far promptly and in good faith. We would appreciate a comprehensive review against all applicable guidelines in this pass to minimize further cycles.” (Kami telah menangani setiap masalah yang diajukan sejauh ini dengan cepat dan dengan itikad baik. Kami akan sangat menghargai peninjauan menyeluruh terhadap semua pedoman yang berlaku di putaran ini untuk meminimalkan siklus berikutnya.)

Ini menempatkan peninjau pada posisi di mana tanggapan berikutnya entah meloloskan aplikasi atau memunculkan semua keberatan yang tersisa. Kedua hasil itu lebih baik daripada satu lagi penolakan dengan satu masalah.

# Perlakukan setiap putaran sebagai hal yang berdiri sendiri

Godaannya adalah berasumsi bahwa peninjau berikutnya sudah membaca catatan peninjau sebelumnya. Kemungkinan besar belum. Setiap balasan di Resolution Center harus bisa berdiri sendiri, merangkum status pengajuan untuk seseorang yang belum melihat percakapan sebelumnya.

Artinya, sedikit pengulangan antarsiklus memang diperlukan. App Review Notes yang terperinci dan berhasil untuk peninjau pertama perlu dilampirkan ulang atau disampaikan ulang untuk peninjau ketiga. Jangan berasumsi ada ingatan lembaga.

# Kronologi pribadi

Sebagai konteks, beginilah lima hari itu sebenarnya berjalan.

Saya mengajukan build 22 pada Sabtu sore. Pengajuannya mencakup 4 langganan yang diperpanjang otomatis, 2 IAP seumur hidup non-consumable, 5 item Tip Jar consumable, App Description, tangkapan layar, video App Preview, In-App Event yang terikat pada minggu peluncuran, dan Pre-Order yang diatur untuk tanggal peluncuran di 175 negara.

Saya sudah menghabiskan enam minggu sebelumnya untuk secara sistematis menghilangkan setiap masalah yang bisa saya antisipasi. App Review Notes sudah disusun dengan penjelasan yang ramah bagi peninjau tentang bagian-bagian aplikasi yang paling mungkin menarik perhatian. Info pedagang DSA sudah disetujui seminggu sebelumnya. Label nutrisi App Privacy sudah aktif. Beta App Review sudah meloloskan beberapa build. Saya merasa siap.

Hari ke-2, 05.15: Penolakan pertama. Guideline 3.1.2©. Tautan Terms of Use yang berfungsi tidak ada di metadata App Store. Perbaikan dirilis di hari yang sama (menambahkan tautan Terms ke lembar upgrade di dalam aplikasi, memperluas halaman ketentuan untuk mengungkapkan semua produk berbayar, memperbarui App Description). Siklus satu hari.

Hari ke-4, 16.03: Penolakan kedua. Tiga hal dalam satu pesan. Guideline 2.5.4 (entri UIBackgroundModes “location” sisa yang seharusnya tidak ada). Guideline 3.1.2© (harga perkenalan ditampilkan lebih menonjol daripada jumlah yang ditagihkan). Guideline 5.1.1(v) (mematikan sakelar pengenal anonim membutuhkan tombol penghapusan berlabel yang eksplisit). Perbaikan dirilis di hari yang sama (menghapus entri Info.plist, membalik hierarki harga, menambahkan tombol “Hapus Data Anonim” yang eksplisit dengan peringatan konfirmasi). Siklus satu hari.

Hari ke-5, 17.05: Penolakan ketiga. Guideline 2.3.4 Accurate Metadata. Video App Preview menampilkan mockup ponsel 3D yang memperagakan layar-layar aplikasi. Catatan peninjau mengutip konten yang tidak “sufficiently show the app in use” (cukup menunjukkan aplikasi saat digunakan) dan secara spesifik menyebut bingkai perangkat.

Tantangannya: halaman panduan publik di developer.apple.com/app-store/app-previews/ tidak secara eksplisit melarang bingkai perangkat. Aturan terdokumentasi yang paling dekat adalah “Stay within the app” (tetap di dalam aplikasi), dengan contoh tentang pengambilan gambar dari balik bahu dan interaksi fisik dengan perangkat. Keduanya tidak berlaku.

Dengan peluncuran tinggal empat hari lagi dan penundaan kumulatif empat hari yang sudah terjadi, saya memilih berkompromi. Saya menghapus video App Preview agar pengajuan ulang tidak terhambat. Saya meminta pertimbangan ulang dengan sopan jika ada klausul pedoman spesifik yang terlewat oleh saya. Saya mengirim satu paragraf yang sopan dan terstruktur, meminta agar semua keberatan yang tersisa disampaikan sekaligus di putaran ini. Penghapusan App Preview tetap berlaku. Permintaan pertimbangan ulang tidak mendapat tanggapan langsung.

Hari ke-6, 19.23: Pesan keempat. Guideline 2.1(b) Information Needed. Secara teknis bukan penolakan. Peninjauan dijeda untuk mengajukan pertanyaan. Peninjau tidak bisa menemukan dua dari IAP yang terlampir pada versi tersebut dan bertanya di mana menemukannya.

Tangkapan layar yang mereka lampirkan menunjukkan paywall pertama dengan benar. Paywall kedua ada di layar Pengaturan yang sama, bisa diakses dengan mengetuk kartu tepat di bawah kartu pertama yang sudah berhasil dicapai peninjau. Saya membalas dengan navigasi langkah demi langkah yang eksplisit untuk ke-11 IAP, terkirim dalam waktu satu jam.

Hari ke-7, 20.30: Disetujui. Build lolos. Pre-Order aktif. Minggu peluncuran ditetapkan pada 11 Mei.

Lima hari itu terasa intens. Jika dilihat kembali, tidak satu pun yang benar-benar mengancam kelangsungan, meskipun di tengah siklus rasanya tidak begitu. Penundaan kumulatifnya nyaris membuat tanggal peluncuran terlewat, tetapi tidak sampai terjadi. Produk yang benar-benar diluncurkan persis sama dengan yang dibangun sebelum pengajuan. Tidak ada yang dipangkas, diubah, atau ditunda demi lolos peninjauan.

# Apa yang tidak ditandai siklus itu justru memberi informasi

Dari empat peninjauan, bagian yang paling lama saya khawatirkan tidak pernah ditandai.

Fitur skor kebiasaan (skor 0 sampai 100 dengan faktor yang membantu dan yang merugikan di enam pilar berbobot). Bagian pelacakan obat (hanya pencatatan, tanpa keluaran berupa saran). Model privasi (tanpa akun, data di perangkat, berbagi anonim yang opt-in dengan penghapusan eksplisit). Penulisan ke HealthKit. Tidak satu pun dari bagian-bagian ini, yang paling mungkin memicu kekhawatiran soal klaim kesehatan atau privasi, ditandai dalam keempat peninjauan. Empat peninjau independen semuanya melihat, dan semuanya memilih untuk tidak menandainya.

Implikasinya bagi pembuat aplikasi di kategori sensitif: pengungkapan secara proaktif itu penting. App Review Notes yang menjelaskan metodologi, penafian di dalam aplikasi, pemilihan nama yang cermat, pembingkaian yang hati-hati di App Description. Semua itu tidak glamor. Semuanya berkontribusi pada empat peninjau berturut-turut yang memilih untuk tidak menandai bagian yang paling bisa diperdebatkan. Rating usia 18+, gerbang lembar penafian saat pertama kali dibuka, teks eksplisit “kami tidak memberikan nasihat medis” di bagian yang relevan. Semuanya berhasil.

Yang ditandai justru permukaan yang bersifat prosedural dan mekanis. Hierarki tampilan harga. Deklarasi background mode. Keberadaan tautan di metadata. Komposisi aset pemasaran. Kemudahan menemukan IAP. Bagian substantif dari aplikasi lolos di setiap putaran.

# Catatan akhir untuk developer indie

Beberapa pengamatan yang tidak pas dimasukkan di bagian atas.

Aplikasi murahan yang Anda lihat di App Store tidak mendapat perlakuan yang lebih longgar. Aplikasi itu disetujui bertahun-tahun lalu saat standarnya lebih rendah, atau tidak memicu faktor pemeriksaan yang dipicu peluncuran serius Anda. Sistemnya memberi imbalan pemeriksaan ringan pada aplikasi yang dibuat seadanya dan berisiko rendah. Usaha dan kepedulian Anda adalah bagian dari alasan peninjauan Anda lebih sulit. Itu bukan penilaian atas kualitas aplikasi Anda.

Sistemnya tidak diisi cukup orang untuk memberi Anda pengalaman yang Anda inginkan. App Review adalah kumpulan tenaga kontrak. Peninjau menangani puluhan aplikasi per hari, dengan hitungan menit per aplikasi. Mereka dilatih memakai Review Guidelines sebagai daftar periksa, bukan memahami UX spesifik dari aplikasi tertentu. Kesenjangan empati itu bersifat struktural, bukan pribadi.

Dokumentasi pengalaman developer indie pada akhirnya menggerakkan perubahan. Apple telah memperbaiki App Review secara berarti selama satu dekade terakhir. Sebagian dari perbaikan itu berawal dari developer indie yang secara konsisten mendokumentasikan pengalaman mereka dan tekanan kolektif yang terus terbangun. Penolakan Anda secara pribadi tidak akan membuat peninjau tertentu dilatih ulang. Kumpulan pengalaman developer indie yang terdokumentasi dengan terstruktur pada akhirnya menggerakkan lembaga itu.

Kemungkinan besar Anda akan merilis produk yang Anda bangun. Setiap fitur yang saya khawatirkan akan dipangkas akhirnya dirilis utuh. Siklus empat penolakan itu terasa mengancam segalanya saat sedang berlangsung. Hasil akhirnya tetap mengarah ke persetujuan selama saya terus merespons dengan jelas dan menyimpan jeda tenggat peluncuran sebagai cadangan.

Jika Anda sedang di tengah siklus saat ini, begadang semalaman di Resolution Center: peluncuran itu akan terjadi. Terus merespons. Sistemnya tidak bersifat pribadi. Produknya milik Anda.

Tulisan ini mendokumentasikan peluncuran AlcoLog, aplikasi iOS untuk melacak minuman. AlcoLog diluncurkan di App Store pada 11 Mei 2026, setelah siklus yang diceritakan di atas. Aplikasinya gratis dengan tingkat Premium opsional dan kini tersedia untuk pre-order di 175 negara.

Jika Anda developer iOS dan ingin bertukar catatan tentang pengalaman App Review, komunitas iOS indie di r/iOSProgramming dan Indie Hackers adalah tempat yang baik untuk memulai. Semakin spesifik kita masing-masing mendokumentasikan apa yang kita alami, semakin berguna kumpulan pengalaman itu bagi orang berikutnya.