Apa yang bisa diubah tanpa versi aplikasi baru: Apple vs Google
Sebelum menyentuh listing toko, ada satu pertanyaan yang layak dijawab dulu: apakah perubahan ini akan memakan biaya submission penuh, atau bisa keluar diam-diam? Salah menilai, dan kamu bisa terjebak antre review yang tidak kamu perhitungkan, atau mengira perubahan sudah live padahal masih menunggu persetujuan. Kedua toko menjawab pertanyaan itu dengan cara yang berlawanan, dan perbedaan itulah alasan menjaga listing tetap sinkron di keduanya jadi merepotkan.
Ini versi jujurnya, kolom demi kolom — dimulai dari matriks, lalu alasan di balik aturan tiap toko supaya kamu bisa menebak kasus-kasus yang tidak dijelaskan tabel ini.
Matriksnya
Setiap kolom listing umum, dan apa yang dituntut tiap toko saat kamu mengubahnya. "Versi / rilis baru" berarti toko memperlakukan perubahan itu sebagai bagian dari submission yang harus kamu kirim; "direview" berarti ada pemeriksaan manusia atau otomatis sebelum tayang.
| Ikon aplikasi | Ikon utama dikemas dalam binary — mengubahnya butuh build baru. Direview bersama build itu. | Ikon toko adalah aset listing. Tidak perlu rilis baru. Direview. |
Dua hal langsung terlihat. Apple menyalurkan hampir segalanya lewat catatan versi. Google membiarkan seluruh listing bergerak sendiri. Tidak ada toko yang melewatkan review pada aset penting — kata "direview" muncul di hampir semua kolom. Jadi pertanyaan sebenarnya jarang "apakah ini akan direview," melainkan "apakah perubahan ini menyeret submission bersamanya."
Apple: catatan versi baru tidak sama dengan build baru
Inilah perbedaan yang sering bikin orang tersandung. Di App Store, mengedit screenshot, nama, subtitle, kolom keyword, atau deskripsi membuat versi baru untuk listing kamu. Kedengarannya seolah kamu harus balik ke Xcode. Nyatanya tidak. Apple otomatis membawa metadata terkini ke versi baru itu, dan perubahan metadata saja tidak butuh kode aplikasi baru — kamu melampirkan build (App Store Connect tetap mewajibkan satu di versi itu) tanpa mengubah apa pun soal fungsi aplikasi. Kamu edit kolom yang antre, submit, dan satu siklus review mencakup semuanya.
Jadi "tanpa kode baru, tapi tetap direview" adalah cara akurat untuk mengingatnya. Tidak ada tahap compile dan tidak ada fitur baru — tapi perubahan tetap masuk App Review dan menunggu giliran sebelum publik. Kelompokkan perubahanmu: karena satu catatan versi bisa memuat screenshot baru, deskripsi yang ditulis ulang, subtitle segar, dan keyword terbaru sekaligus, tidak ada alasan menghabiskan siklus review terpisah untuk masing-masing.
Ikon aplikasi adalah pengecualian yang memang butuh build. Ikon utamamu tertanam dalam binary dan diambil darinya, jadi ikon yang benar-benar baru berarti build baru. Hal yang sama berlaku untuk ikon alternatif — mereka harus dibundel dalam aplikasi agar bisa dipakai, jadi menambahkan satu berarti build, bukan sekadar edit listing.
Dua jalan pintas Apple
Promotional text. Ini satu-satunya kolom yang bisa diubah tanpa versi dan tanpa review. Panjangnya 170 karakter, berada di atas deskripsi, dan bisa diperbarui kapan saja — berguna untuk promo, catatan peluncuran, atau teks yang sensitif waktu. Tidak memengaruhi peringkat pencarian dan bukan bagian dari submission apa pun, itulah tepatnya alasan ini hal tercepat yang bisa diubah di toko. Kalau kamu butuh sesuatu tayang hari ini, kolom inilah jawabannya.
Product Page Optimization. PPO memungkinkanmu menguji hingga tiga versi screenshot, app preview, dan ikon terhadap halaman produk live kamu — tanpa merilis versi aplikasi baru. Ini yang paling dekat dengan Apple mengizinkan perubahan visual di luar submission normal. Dua catatan penting menjaga ini tetap jujur: metadata versi uji tetap harus disetujui sebelum tes berjalan (jadi tetap direview, bukan instan), dan ikon apa pun yang ingin diuji harus sudah menjadi bagian dari binary aplikasi saat ini. PPO mengubah apa yang dilihat pengunjung; tidak melewati review.
Google Play: publikasikan listing tanpa rilis
Play bekerja dengan cara sebaliknya. Listing tokomu — judul, deskripsi singkat, deskripsi lengkap, screenshot, feature graphic, ikon, video promo — bisa diedit dan dipublikasikan sendiri, tanpa rilis aplikasi baru terlampir. Kamu buat perubahan, dan itu muncul di ringkasan Publishing di bawah perubahan yang siap dikirim untuk review. Kamu kirim, perubahan itu melewati review Google, lalu tayang lepas dari build mana pun.
Ada beberapa hal yang perlu diluruskan supaya tidak dilebih-lebihkan. Perubahan tetap direview — review Play juga berjalan pada perubahan listing, dan elemen seperti nama aplikasi dan ikon tetap diperiksa, jadi ini bukan pergantian instan yang diam-diam. Dan listing tidak bisa mengambang bebas tanpa aplikasi yang sudah rilis: Play mengharuskan aplikasi punya rilis sebelumnya sebelum ada listing publik untuk diedit. Kamu tidak bisa memasang halaman toko mandiri untuk sesuatu yang belum pernah dirilis. Managed publishing menambahkan satu hal lagi yang perlu diketahui — jika diaktifkan, perubahan yang disetujui menunggu sampai kamu aktif mempublikasikannya, yang merupakan fitur, bukan keterlambatan, begitu kamu memahaminya.
Asimetrinya, dan kenapa ini menyita waktumu
Sejajarkan kedua model ini dan perbedaannya jelas. Apple mengikat hampir setiap perubahan teks dan gambar ke catatan versi dan tahap review, dengan promotional text dan PPO sebagai satu-satunya jalan keluar. Google memisahkan listing sepenuhnya dari rilis, mereview perubahan, dan menayangkannya sesuai jadwalnya sendiri selama aplikasinya sudah ada.
Asimetri itu diam-diam mahal saat kamu mengelola kedua toko. Pembaruan screenshot yang sama adalah submission catatan versi di satu toko dan pembaruan listing mandiri di toko lain. Penulisan ulang deskripsi adalah versi yang direview di Apple dan perubahan listing yang direview di Google. Kontennya sama; mekanismenya tidak, jadi perubahan yang cuma satu langkah di Play menjadi langkah berbeda di App Store — dan gampang sekali merilis satu tapi lupa yang lain, atau mengira sesuatu sudah live di Apple padahal masih dalam review.
Di mana Mokbi berperan
Asimetri lintas toko inilah alasan utama sebuah alat publishing bernilai. Mokbi dimulai sebagai editor screenshot, tapi listing adalah teks dan gambar bersama-sama — jadi ia mendesain set screenshot dan menyusun teks listing untuk kedua toko dalam satu tempat: nama App Store, subtitle, kolom keyword, dan deskripsi; judul Play, deskripsi singkat, dan deskripsi lengkap. Kamu mendapat kolom yang benar-benar diindeks tiap toko, dibentuk sesuai toko itu, alih-alih satu blok teks yang kamu tempel dua kali.
Lalu ia menerjemahkan seluruh listing — screenshot dan teks — ke dalam 50 bahasa, jadi perubahan yang kamu buat sekali langsung masuk ke kolom yang tepat di setiap pasar, alih-alih tetap berbahasa Inggris di listing yang sudah dilokalkan di tempat lain. Dan ia mempublikasikan: Mokbi mendorong listing yang sudah jadi langsung ke Google Play lewat Play Developer API, dan menyiapkannya di App Store Connect siap disubmit — Apple tetap mewajibkan langkah Submit final dan proses review di sisinya, yang merupakan aturan Apple dan persis asimetri lintas toko yang menjadi inti tulisan ini. Review terakhir itu juga titik di mana jam yang dibahas di tulisan ini mulai berjalan.