Contoh catatan rilis App Store: tulis teks What's New yang menjelaskan apa yang berubah (2026)

Catatan rilis App Store yang baik menjawab satu pertanyaan: apa yang berbeda bagi saya setelah memperbarui? Contoh-contoh catatan rilis App Store di bawah ini semuanya mengikuti satu pola. Awali dengan perubahan yang akan disadari pengguna, sebutkan setiap perbaikan secara spesifik, dan buang apa pun yang tidak bisa mereka lihat. Panduan Apple sendiri untuk kolom What's New in This Version mengatakan hal yang sama. Apple meminta fitur baru, peningkatan UI, atau perbaikan bug, dan menyarankan agar Anda memberi tahu pengguna "rincian perubahan, peningkatan, atau perbaikan dalam versi tersebut."

Apa saja aturan catatan rilis di App Store Connect dan Google Play?

Kolom What's New milik Apple menampung 4.000 karakter dan wajib diisi pada setiap versi setelah versi pertama. Google Play mengizinkan 500 karakter Unicode per bahasa dan melarang konten promosi.

Per Oktober 2026, Bantuan Play Console menyatakan: "Jangan gunakan catatan rilis untuk tujuan promosi atau untuk meminta tindakan pengguna." Di Apple, taruh teks pemasaran di Promotional Text. Kolom tersebut menampung 170 karakter, tampil di atas deskripsi Anda, dan Apple mengizinkan Anda memperbaruinya tanpa mengirim versi baru.

Seperti apa catatan rilis App Store yang baik?

Catatan rilis yang baik menyebutkan situasi yang dialami pengguna dan hasil yang kini mereka dapatkan. Contoh di bawah ini berasal dari aplikasi pelacak kebiasaan fiktif. Versi yang samar adalah jenis catatan yang biasanya ditulis di menit terakhir.

Jika suatu perbaikan terlalu teknis untuk dijelaskan dalam satu kalimat, kemungkinan besar pengguna tidak akan menyadarinya, jadi perbaikan itu bisa digabung dalam satu baris "peningkatan stabilitas" di akhir. Pedoman 2.3.12 mengizinkan hal itu untuk perbaikan kecil, tetapi tidak untuk perubahan fitur yang nyata.

Adakah template catatan rilis yang bisa saya pakai ulang?

Ada. Template yang bisa dipakai ulang terdiri dari satu judul, lalu bagian New, Improved, dan Fixed. Simpan di repositori Anda di samping changelog dan isi saat Anda membuat release branch, bukan setelah build diunggah.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Untuk Google Play, ringkas catatan yang sama menjadi judul ditambah dua atau tiga poin teratas agar muat dalam 500 karakter. Letakkan tag setiap bahasa di barisnya sendiri, misalnya <en-US> dan </en-US>. Hapus kalimat penutup di Play, karena kalimat itu meminta pengguna melakukan sesuatu.

Bagaimana cara mengubah pull request yang sudah di-merge menjadi catatan rilis?

Untuk mengubah pull request yang sudah di-merge menjadi catatan rilis, saring perubahan yang tidak terlihat oleh pengguna, lalu tulis ulang setiap perubahan yang tersisa sebagai gejala atau hasil. Ikuti langkah-langkah ini untuk setiap rilis.

1. Ekspor judul pull request yang di-merge sejak tag terakhir, lalu hapus apa pun yang tidak terlihat oleh pengguna, seperti refactor, pembaruan dependensi, dan perubahan CI.
2. Tulis ulang setiap item yang tersisa sebagai gejala atau hasil. "Fix nil coordinator" menjadi "Memperbaiki layar kosong setelah masuk dengan Apple."
3. Urutkan item berdasarkan jumlah pengguna yang terdampak, bukan berdasarkan besarnya pekerjaan engineering yang dibutuhkan.
4. Di App Store Connect, buat versi baru, lalu kosongkan teks What's New hasil salinan sebelum menempelkan catatan baru, karena metadata versi sebelumnya ikut terbawa.
5. Tempelkan catatan ke setiap lokalisasi yang Anda dukung, diterjemahkan atau setidaknya diperiksa di setiap bahasa, agar pengguna di lokal lain tidak melihat catatan versi lalu.
6. Untuk Play, tempelkan versi ringkas di dalam tag bahasa dan pastikan setiap bahasa tetap di bawah 500 karakter.
7. Bacakan catatan itu dengan suara keras satu kali. Jika ada kalimat yang perlu dijelaskan oleh developer, tulis ulang.

Apa yang sebaiknya ditulis di catatan rilis untuk hotfix?

Catatan rilis hotfix sebaiknya menyebutkan versi yang bermasalah, menjelaskan gejala yang kini sudah diperbaiki, dan memberi tahu pengguna yang terdampak apa yang terjadi setelah mereka memperbarui. Apple tidak mengizinkan Anda kembali ke versi sebelumnya di App Store, jadi perbaikan selalu dirilis sebagai versi baru.

Contohnya: "Memperbaiki masalah di 3.4.0 yang membuat pengingat berhenti berbunyi bagi sebagian pengguna. Pengingat yang Anda atur sebelum memperbarui akan aktif kembali secara otomatis." Pengguna yang terdampak jadi tahu harus memperbarui, dan pengguna yang tidak terdampak bisa melihat bahwa perbaikan ini tidak menyangkut mereka. Jangan menyalahkan sistem operasi dan jangan menjanjikan tanggal untuk perbaikan berikutnya. Jika Anda merilis pembaruan dengan phased release, menjeda peluncuran akan membatasi jumlah pengguna yang mendapat build bermasalah selama perbaikan sedang di-review. Jika hotfix mengubah cara kerja suatu fitur, jalankan kembali checklist pengiriman App Store agar catatan, screenshot, dan catatan untuk reviewer tetap selaras.

Bisakah App Review menolak pembaruan karena catatan rilisnya?

Bisa. Catatan rilis termasuk metadata, dan App Review Guidelines mengaturnya secara langsung. Pedoman 2.3.12 menyatakan "Aplikasi harus menjelaskan fitur baru dan perubahan produk dengan jelas dalam teks "What's New"."

Kata-kata umum diperbolehkan untuk "perbaikan bug sederhana, pembaruan keamanan, dan peningkatan performa," tetapi "perubahan yang lebih signifikan harus dicantumkan dalam catatan." Pedoman 2.3.10 melarang nama atau gambar platform seluler lain di metadata, termasuk What's New. Jangan menjelaskan fitur yang tersembunyi di balik feature flag atau apa pun yang tidak ada di build yang dikirim. Pedoman 2.3.1(a) secara terpisah mewajibkan fitur baru "dijelaskan secara spesifik di bagian Notes for Review," jadi letakkan langkah-langkah untuk reviewer dan akun demo di sana, bukan di catatan publik. Jika Anda mendapat pertanyaan terkait metadata, panduan kami tentang cara memperbaiki penolakan App Store menjelaskan cara membalasnya.

Masalah catatan rilis apa saja yang pernah dialami developer lain?

Kasus yang dilaporkan secara publik menunjukkan dua jenis kegagalan: unggahan ditolak karena melebihi batas panjang toko, dan penolakan review yang menyertakan teks What's New dalam instruksi pembersihannya.

• Batas panjang Play di CI. Sebuah issue GitHub di template deployment Flutter melaporkan changelog buatan AI yang menggagalkan unggahan internal test Google Play melalui fastlane dengan pesan: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." Para maintainer menambahkan skrip yang memotong catatan sebelum diunggah: 480 karakter untuk Play dan 3.800 byte untuk TestFlight, yang mengukur batasnya dalam byte.
• Pembersihan 2.3.10 yang mencakup What's New. Seorang developer di Apple Developer Forums membagikan penolakan berdasarkan Pedoman 2.3.10 yang dipicu oleh status bar non-iOS di screenshot. Langkah selanjutnya dari Apple meminta untuk "menghapus semua informasi ini dari aplikasi dan metadatanya, termasuk deskripsi aplikasi, promotional text, info What's New, preview, dan screenshot." Balasan di thread menyarankan untuk mengambil ulang screenshot dan memeriksa setiap kolom metadata, termasuk catatan rilis.

Pelajarannya: batas panjang bersifat mekanis dan langsung gagal saat unggah, sedangkan aturan review menyangkut isi dan berlaku untuk setiap kolom metadata. Otomatiskan pengecekan jumlah karakter, dan baca What's New secermat Anda memeriksa screenshot.

Apa yang perlu diperiksa sebelum mengirim catatan rilis?

Sebelum mengirim, pastikan catatan hanya menjelaskan apa yang ada di build, sesuai batas setiap toko, dan menggantikan teks versi lalu di setiap bahasa.

• Judul menyebutkan perubahan yang akan disadari sebagian besar pengguna.
• Setiap fitur atau perubahan produk yang signifikan dicantumkan, sesuai ketentuan pedoman 2.3.12.
• Setiap perbaikan menjelaskan gejala yang dialami pengguna, bukan kode internal.
• Tidak ada fitur di balik feature flag, janji masa depan, nomor tiket internal, atau nama platform lain.
• Teks What's New versi sebelumnya sudah dikosongkan dan diganti di setiap lokalisasi.
• Catatan Play di bawah 500 karakter per bahasa, dibungkus tag bahasa yang benar, tanpa promosi atau ajakan bertindak.
• Pesan pemasaran dipindahkan ke Promotional Text di Apple.
• Jika Anda juga menjalankan tester Android, catatan yang sama sudah dicek terhadap rencana closed testing Anda.

Jika Anda ingin ada orang lain yang memeriksa metadata pembaruan Anda sebelum dikirim, kirim email ke yagyeshsrbobde@gmail.com berisi draf catatan dan daftar perubahan di build tersebut, atau lihat layanan kami.