Marketing Version: apa itu, perbedaan dengan Build Number dan instalasi

Penulis: IT Sectr Diterbitkan: 2026-04-18 Waktu membaca: 8 mnt

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 — string versi aplikasi yang dilihat pengguna di App Store, Google Play, dan di perangkat.
  • Di iOS ditetapkan sebagai CFBundleShortVersionString, di Android — sebagai versionName di build.gradle.
  • Berbeda dengan Build Number, Marketing Version tidak harus unik dan dapat diulang untuk beberapa build.
  • Format semantik Major.Minor.Patch — skema paling umum yang dipahami pengguna.
  • Marketing Version disinkronkan dengan nomor rilis di App Store Connect dan Google Play Console untuk keseragaman.

Apa itu Marketing Version

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.

Perbedaan dari Build Number internal

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.

Di mana Marketing Version ditampilkan

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.

Marketing Version di iOS

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.

Marketing Version di Android

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.

Generasi dinamis versionName

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.

Perbedaan Marketing Version dan Build Number

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.

Strategi versi

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

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.

Rekomendasi pemilihan

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 dalam memilih Marketing Version

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 pengaturan Marketing Version

Contoh kode menunjukkan cara mengatur Marketing Version di kedua platform dan mengotomatiskan pembaruannya.

Mengatur versionName di Android Gradle

Di Android, versionName ditetapkan di build.gradle. Nilai bisa statis atau dibaca dari variabel lingkungan.

groovy
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.

Mengelola Marketing Version di Xcode

Di iOS, Marketing Version ditetapkan melalui Xcode atau agvtool. Perintah di bawah menetapkan versi marketing baru.

bash
# 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 untuk kedua platform

Fastlane memungkinkan mengelola Marketing Version di kedua platform dari satu skrip, yang menyederhanakan dukungan proyek lintas platform.

ruby
# 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

Apa perbedaan Marketing Version dengan Build Number?

Marketing Version — versi untuk pengguna (ditampilkan di toko), Build Number — pengidentifikasi internal build. Marketing Version dapat diulang, Build Number harus unik untuk setiap build.

Seberapa sering Marketing Version harus diubah?

Setiap rilis fungsionalitas baru, perubahan API, atau perbaikan besar. Untuk rilis korektif (hotfix), Marketing Version tidak perlu diubah — cukup tingkatkan Build Number.

Bisakah huruf digunakan di Marketing Version?

Di Android — ya, versionName dapat berisi karakter apa pun. Di iOS — hanya angka dan titik. Apple merekomendasikan format numerik untuk kompatibilitas dengan App Store.

Bagaimana cara mengembalikan Marketing Version?

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.

Bagaimana cara menyinkronkan Marketing Version antara iOS dan Android?

Gunakan file konfigurasi bersama di root proyek (misalnya, version.properties). Skrip build di kedua platform membaca versi dari file ini, memastikan sinkronisasi nilai.

Ringkasan

  • Marketing Version — versi aplikasi yang terlihat pengguna, ditampilkan di toko dan di perangkat, berorientasi pada persepsi manusia.
  • Di iOS ditetapkan melalui CFBundleShortVersionString di Xcode, di Android — melalui versionName di build.gradle.
  • Marketing Version dapat diulang untuk beberapa build, berbeda dengan Build Number yang unik.
  • Versi semantik Major.Minor.Patch — standar untuk aplikasi mobile dengan API publik.
  • Versi kalender cocok untuk aplikasi dengan pembaruan sering di mana kesegaran data penting.
  • Otomatisasi melalui agvtool, Gradle, atau fastlane menghilangkan ketidaksesuaian antara repositori dan build.
  • Build Number dan Marketing Version — parameter independen: kelola masing-masing secara terpisah.

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.

Diskusikan proyek

Baca juga