Marketing Version — adalah versi aplikasi yang terlihat oleh pengguna, ditampilkan di toko aplikasi dan di perangkat. Berbeda dengan Build Number, parameter ini berorientasi pada persepsi pengguna dan memiliki makna semantik. Menurut Apple Developer, 2025, penggunaan Marketing Version yang benar meningkatkan kepercayaan pengguna terhadap pembaruan.
Poin utama
Marketing Version — adalah string semantik yang mewakili versi aplikasi untuk pengguna akhir. Di iOS ditetapkan dengan kunci CFBundleShortVersionString, di Android — dengan parameter versionName.
Istilah „Marketing Version" secara resmi digunakan di Xcode: di antarmuka pengaturan target, bidang tersebut bernama „Marketing Version", dan di Info.plist sesuai dengan CFBundleShortVersionString. Di Android padanannya adalah versionName, meskipun istilah ini lebih jarang digunakan.
Menurut Apple Developer Documentation (2025), Marketing Version harus terdiri dari maksimal tiga angka yang dipisahkan titik, tanpa spasi dan karakter khusus. Setiap angka tidak boleh melebihi 255.
Pilih Marketing Version yang mencerminkan pentingnya perubahan: pembaruan major untuk perubahan radikal, minor untuk fungsionalitas baru.
Marketing Version pada dasarnya berbeda dari Build Number dalam tujuannya: yang pertama memberi tahu pengguna, yang kedua — mengidentifikasi build untuk toko. Build Number dapat bertambah tanpa mengubah Marketing Version.
Misalnya, saat memperbaiki kesalahan kritis dalam rilis yang sudah dirilis, tim dapat membangun ulang aplikasi dengan Marketing Version yang sama (1.2.0) tetapi dengan Build Number yang ditingkatkan (dari 15 ke 16). Pengguna akan melihat versi yang sama, tetapi toko akan memahami bahwa build lebih baru.
Fleksibilitas ini memungkinkan pengembang merilis perbaikan tanpa memberi tahu pengguna tentang perubahan versi.
Marketing Version ditampilkan di beberapa titik interaksi utama pengguna dengan aplikasi. Di toko aplikasi, terlihat di kartu aplikasi, di deskripsi pembaruan, dan di riwayat versi.
Di perangkat, Marketing Version ditampilkan di pengaturan sistem (bagian „Tentang aplikasi" atau „Aplikasi"), di dialog pembaruan melalui App Store atau Google Play, serta di dalam aplikasi itu sendiri di layar „Tentang".
Marketing Version yang jelas membantu pengguna menilai aktualitas versi yang terinstal dan memutuskan untuk memperbarui.
Di iOS, Marketing Version ditetapkan di Xcode melalui bidang „Marketing Version" di tab General pengaturan target. Nilai disimpan di Info.plist sebagai CFBundleShortVersionString.
Format versi diatur secara ketat oleh Apple: string harus berisi satu hingga tiga angka yang dipisahkan titik (misalnya, 1, 1.2, atau 1.2.3). Panjang maksimum — 18 karakter. Setiap angka tidak melebihi 255.
Menurut Apple App Store Review Guidelines (2025), App Store Connect tidak mengizinkan mengunggah build jika Marketing Version berbeda dari versi yang dipublikasikan sebelumnya lebih dari satu nilai major atau minor — ini melindungi pengguna dari pembaruan yang terlewat.
Gunakan agvtool untuk mengelola Marketing Version dari baris perintah — ini menyederhanakan integrasi dengan sistem CI/CD dan menjamin sinkronisasi dengan Build Number.
Di Android, Marketing Version ditetapkan dengan parameter versionName di file build.gradle. Berbeda dengan iOS, Android tidak memberlakukan batasan ketat pada format string versi.
versionName dapat berisi karakter apa pun: huruf, angka, tanda hubung, dan titik. Google Play menampilkan string ini di kartu aplikasi dan di daftar pembaruan, tetapi tidak memeriksanya terhadap pola apa pun.
Namun, Google Play merekomendasikan untuk mengikuti format semantik Major.Minor.Patch demi keseragaman. Ini menyederhanakan persepsi versi oleh pengguna dan memungkinkan analisis pembaruan otomatis.
Tentukan versionName yang dengan jelas mencerminkan jenis rilis — pembaruan major, minor, atau patch. Ini membantu pengguna menilai pentingnya perubahan dengan cepat.
versionName di Android dapat dihasilkan secara dinamis berdasarkan tag Git atau variabel CI/CD. Ini menyederhanakan proses versi dan menghilangkan ketidaksesuaian antara repositori dan build.
Pendekatan tipikal — membaca tag Git (misalnya, v2.1.0) dan menggunakan nilainya sebagai versionName. Jika tag tidak ada, versi dapat dihasilkan berdasarkan tanggal dan nomor commit.
Pendekatan ini memastikan bahwa versionName selalu sesuai dengan status kode sumber dan tidak memerlukan pembaruan manual.
Marketing Version dan Build Number — adalah dua parameter independen yang menyelesaikan tugas berbeda. Marketing Version memberi tahu pengguna, Build Number secara teknis mengidentifikasi build.
Perbedaan utama — keunikan. Build Number harus unik untuk setiap build. Marketing Version dapat diulang: beberapa build dari versi yang sama memiliki Marketing Version yang sama tetapi Build Number berbeda.
Menurut Google Play Policy (2025), jika dua APK diunggah dengan Marketing Version yang sama tetapi Build Number berbeda, Google Play akan menerima keduanya sebagai build berbeda dari versi yang sama. Aturan serupa berlaku untuk App Store.
Ingat: Build Number — untuk mesin, Marketing Version — untuk manusia. Otomatiskan yang pertama dan rencanakan yang kedua dengan cermat.
Pemilihan strategi versi tergantung pada jenis aplikasi, audiens, dan proses rilis. Tiga skema utama — semantik, kalender, dan hibrida — mencakup sebagian besar skenario.
Versi semantik (SemVer) menggunakan format Major.Minor.Patch dan secara ketat menentukan kapan setiap komponen harus ditingkatkan. Ini ideal untuk aplikasi dengan API publik dan integrasi kompleks.
Menurut semver.org (2023), versi 2.0.0 dari spesifikasi SemVer digunakan di 89% proyek mobile open-source dan didukung oleh semua manajer paket.
Versi kalender (CalVer) menggunakan tanggal rilis sebagai versi — misalnya, 25.06 untuk Juni 2025. Pendekatan ini populer di aplikasi dengan pembaruan yang sering.
CalVer tidak membawa informasi tentang pentingnya perubahan, tetapi menunjukkan kesegaran versi dengan baik. Pengguna langsung memahami bahwa versi 25.06 lebih baru dari 25.03.
Pilih versi kalender jika aplikasi Anda sering diperbarui dan pengguna lebih mementingkan aktualitas data daripada volume perubahan.
Untuk MVP dan startup, versi semantik sederhana tanpa patch (Major.Minor) cocok. Untuk produk matang dengan dukungan jangka panjang — SemVer lengkap. Untuk aplikasi dengan rilis berkelanjutan — CalVer.
Jangan pernah menggunakan tanggal sebagai Build Number — ini dapat menyebabkan konflik dengan beberapa build per hari. Build Number harus berurutan atau gabungan, tetapi selalu meningkat secara monoton.
Kesalahan umum — melewatkan komponen versi saat beralih ke lini major baru. Misalnya, setelah versi 1.9.9, berikutnya harus 2.0.0, bukan 1.10.0. Ini melanggar semantik dan membingungkan pengguna.
Masalah umum lainnya — ketidaksesuaian Marketing Version dalam kode dan di toko aplikasi. Selalu periksa bahwa versionName di build.gradle cocok dengan versi yang ditentukan di Google Play Console atau App Store Connect sebelum mengirim build untuk ditinjau.
Contoh kode menunjukkan cara mengatur Marketing Version di kedua platform dan mengotomatiskan pembaruannya.
Di Android, versionName ditetapkan di build.gradle. Nilai bisa statis atau dibaca dari variabel lingkungan.
android {
defaultConfig {
versionCode 15
versionName "2.1.0"
}
}
// Membaca versi dari tag Git
def getVersionNameFromGit = {
def tag = "git describe --tags".execute().
text.trim()
return tag.startsWith("v") ? tag.substring(1) : tag
}
versionName diekstrak dari tag Git, yang memastikan kesesuaian antara versi di repositori dan di aplikasi yang dikompilasi.
Di iOS, Marketing Version ditetapkan melalui Xcode atau agvtool. Perintah di bawah menetapkan versi marketing baru.
# Mengatur Marketing Version
xcrun agvtool new-marketing-version 2.1.0
# Peningkatan otomatis
xcrun agvtool next-marketing-version
agvtool secara otomatis memperbarui Info.plist dan menyinkronkan versi di semua target proyek Xcode.
Fastlane memungkinkan mengelola Marketing Version di kedua platform dari satu skrip, yang menyederhanakan dukungan proyek lintas platform.
# Mengatur versi pemasaran
increment_version_number(
version_number: "2.1.0"
)
# Peningkatan otomatis versi minor
increment_version_number(
bump_type: "minor"
)
Fastlane berfungsi di kedua platform dan didukung oleh sebagian besar layanan CI/CD.
Pertanyaan Umum
Marketing Version — versi untuk pengguna (ditampilkan di toko), Build Number — pengidentifikasi internal build. Marketing Version dapat diulang, Build Number harus unik untuk setiap build.
Setiap rilis fungsionalitas baru, perubahan API, atau perbaikan besar. Untuk rilis korektif (hotfix), Marketing Version tidak perlu diubah — cukup tingkatkan Build Number.
Di Android — ya, versionName dapat berisi karakter apa pun. Di iOS — hanya angka dan titik. Apple merekomendasikan format numerik untuk kompatibilitas dengan App Store.
Tidak disarankan. Toko aplikasi tidak mendukung pengembalian versi. Sebagai gantinya, rilis versi baru dengan perbaikan dan tingkatkan komponen patch. Pengguna akan secara otomatis beralih ke versi baru.
Gunakan file konfigurasi bersama di root proyek (misalnya, version.properties). Skrip build di kedua platform membaca versi dari file ini, memastikan sinkronisasi nilai.
Ringkasan
Kami akan mengembangkan aplikasi seluler turnkey
IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.
Baca juga