Marketing Version एप्लिकेशन का उपयोगकर्ता-सामने वाला वर्ज़न स्ट्रिंग है जो ऐप स्टोर और डिवाइस पर प्रदर्शित होता है। Build Number के विपरीत, यह पैरामीटर उपयोगकर्ता की धारणा पर आधारित होता है और इसका अर्थपूर्ण महत्व होता है। Apple Developer, 2025 के अनुसार, Marketing Version का सही उपयोग उपयोगकर्ताओं का अपडेट पर विश्वास बढ़ाता है।
मुख्य बातें
Marketing Version एक सिमैंटिक स्ट्रिंग है जो अंतिम उपयोगकर्ता के लिए एप्लिकेशन वर्ज़न का प्रतिनिधित्व करती है। iOS में इसे CFBundleShortVersionString कुंजी के माध्यम से सेट किया जाता है, Android में versionName के माध्यम से।
“Marketing Version” शब्द का आधिकारिक रूप से Xcode में उपयोग किया जाता है: टार्गेट सेटिंग्स इंटरफ़ेस में फ़ील्ड को “Marketing Version” कहा जाता है, और Info.plist में यह CFBundleShortVersionString से मेल खाता है। Android में समतुल्य versionName है, हालाँकि इस शब्द का उपयोग कम बार किया जाता है।
Apple Developer दस्तावेज़ीकरण (2025) के अनुसार, Marketing Version अधिकतम तीन संख्याओं से बिंदुओं द्वारा अलग होकर बनी होनी चाहिए, बिना स्थान या विशेष वर्णों के। प्रत्येक संख्या 255 से अधिक नहीं होनी चाहिए।
अपनी Marketing Version इस प्रकार चुनें कि वह परिवर्तनों के महत्व को दर्शाए: मूलभूत परिवर्तनों के लिए मेजर अपडेट, नई कार्यक्षमता के लिए माइनर अपडेट।
Marketing Version मौलिक रूप से Build Number से उद्देश्य में भिन्न है: पहला उपयोगकर्ता को सूचित करता है, दूसरा स्टोर के लिए बिल्ड की पहचान करता है। Build Number Marketing Version को बदले बिना बढ़ सकता है।
उदाहरण के लिए, जारी किए गए रिलीज़ में किसी महत्वपूर्ण बग को ठीक करते समय, टीम समान Marketing Version (1.2.0) लेकिन बढ़े हुए Build Number (15 से 16) के साथ एप्लिकेशन को फिर से बना सकती है। उपयोगकर्ता को समान वर्ज़न दिखेगा, लेकिन स्टोर को पता चलेगा कि बिल्ड नया है।
यह लचीलापन डेवलपर्स को वर्ज़न बदलने की सूचना दिए बिना सुधार जारी करने की अनुमति देता है।
Marketing Version उपयोगकर्ता के एप्लिकेशन के साथ इंटरैक्शन के कई प्रमुख बिंदुओं पर दिखाई देती है। ऐप स्टोर में, यह ऐप कार्ड, अपडेट विवरण और वर्ज़न इतिहास में दिखाई देती है।
डिवाइस पर, Marketing Version सिस्टम सेटिंग्स (“फ़ोन के बारे में” या “ऐप्स” अनुभाग), App Store या Google Play के माध्यम से अपडेट डायलॉग, और ऐप के अंदर “हमारे बारे में” स्क्रीन पर दिखाई देती है।
एक स्पष्ट Marketing Version उपयोगकर्ताओं को उनके स्थापित वर्ज़न की प्रासंगिकता का मूल्यांकन करने और अपडेट का निर्णय लेने में मदद करती है।
iOS पर, Marketing Version Xcode में टार्गेट सेटिंग्स के General टैब पर “Marketing Version” फ़ील्ड के माध्यम से सेट की जाती है। मान Info.plist में CFBundleShortVersionString के रूप में सहेजा जाता है।
वर्ज़न फ़ॉर्मेट Apple द्वारा सख्ती से विनियमित है: स्ट्रिंग में बिंदुओं द्वारा अलग की गई एक से तीन संख्याएँ होनी चाहिए (जैसे, 1, 1.2 या 1.2.3)। अधिकतम लंबाई 18 वर्ण है। प्रत्येक संख्या 255 से अधिक नहीं होनी चाहिए।
Apple App Store Review Guidelines (2025) के अनुसार, App Store Connect एक बिल्ड अपलोड करने की अनुमति नहीं देता यदि Marketing Version पिछले प्रकाशित वर्ज़न से एक से अधिक मेजर या माइनर मान से भिन्न है — यह उपयोगकर्ताओं को छूटे हुए अपडेट से बचाता है।
कमांड लाइन से Marketing Version प्रबंधित करने के लिए agvtool का उपयोग करें — यह CI/CD के साथ एकीकरण को सरल बनाता है और Build Number के साथ सिंक्रनाइज़ेशन सुनिश्चित करता है।
Android पर, Marketing Version build.gradle फ़ाइल में versionName पैरामीटर के माध्यम से सेट की जाती है। iOS के विपरीत, Android वर्ज़न स्ट्रिंग फ़ॉर्मेट पर सख्त प्रतिबंध नहीं लगाता।
versionName में कोई भी वर्ण हो सकते हैं: अक्षर, अंक, हाइफ़न और बिंदु। Google Play इस स्ट्रिंग को ऐप कार्ड और अपडेट सूची में प्रदर्शित करता है, लेकिन इसे किसी पैटर्न के विरुद्ध मान्य नहीं करता।
हालाँकि, Google Play एकरूपता के लिए सिमैंटिक Major.Minor.Patch फ़ॉर्मेट का पालन करने की अनुशंसा करता है। यह उपयोगकर्ताओं के लिए वर्ज़न को समझना आसान बनाता है और स्वचालित अपडेट विश्लेषण को सक्षम करता है।
versionName निर्धारित करें जो स्पष्ट रूप से रिलीज़ प्रकार — मेजर, माइनर या पैच — को दर्शाता हो। यह उपयोगकर्ताओं को परिवर्तनों के महत्व का तुरंत आकलन करने में मदद करता है।
Android पर versionName Git टैग या CI/CD वेरिएबल के आधार पर डायनामिक रूप से उत्पन्न किया जा सकता है। यह वर्ज़निंग प्रक्रिया को सरल बनाता है और रिपॉज़िटरी और बिल्ड के बीच विसंगतियों को समाप्त करता है।
एक सामान्य दृष्टिकोण Git टैग (जैसे, v2.1.0) पढ़ना और इसके मान को versionName के रूप में उपयोग करना है। यदि टैग मौजूद नहीं है, तो दिनांक और कमिट संख्या के आधार पर एक वर्ज़न उत्पन्न किया जा सकता है।
यह दृष्टिकोण सुनिश्चित करता है कि versionName हमेशा स्रोत कोड की स्थिति से मेल खाता है और मैन्युअल अपडेट की आवश्यकता नहीं है।
Marketing Version और Build Number दो स्वतंत्र पैरामीटर हैं जो विभिन्न उद्देश्यों की पूर्ति करते हैं। Marketing Version उपयोगकर्ता को सूचित करती है, जबकि Build Number तकनीकी रूप से बिल्ड की पहचान करता है।
प्रमुख अंतर अद्वितीयता है। Build Number प्रत्येक बिल्ड के लिए अद्वितीय होना चाहिए। Marketing Version दोहराई जा सकती है: एक ही वर्ज़न के कई बिल्ड में समान Marketing Version लेकिन भिन्न Build Numbers होते हैं।
Google Play नीति (2025) के अनुसार, यदि आप समान Marketing Version लेकिन भिन्न Build Numbers वाले दो APK अपलोड करते हैं, तो Google Play दोनों को एक ही वर्ज़न के भिन्न बिल्ड के रूप में स्वीकार करेगा। App Store के लिए भी यही नियम लागू होता है।
याद रखें: Build Number मशीनों के लिए है, Marketing Version लोगों के लिए है। पहले को स्वचालित करें और दूसरे की सावधानीपूर्वक योजना बनाएँ।
रणनीति चुनना एप्लिकेशन प्रकार, दर्शकों और रिलीज़ प्रक्रिया पर निर्भर करता है। तीन मुख्य योजनाएँ — सिमैंटिक, कैलेंडर और हाइब्रिड — अधिकांश परिदृश्यों को कवर करती हैं।
सिमैंटिक वर्ज़निंग (SemVer) Major.Minor.Patch फ़ॉर्मेट का उपयोग करता है और सख्ती से परिभाषित करता है कि प्रत्येक घटक को कब बढ़ाया जाना चाहिए। यह सार्वजनिक API और जटिल एकीकरण वाले एप्लिकेशन के लिए आदर्श है।
semver.org (2023) के अनुसार, SemVer स्पेसिफिकेशन का संस्करण 2.0.0 89% ओपन-सोर्स मोबाइल प्रोजेक्ट्स में उपयोग किया जाता है और सभी पैकेज मैनेजरों द्वारा समर्थित है।
कैलेंडर वर्ज़निंग (CalVer) रिलीज़ दिनांक को वर्ज़न के रूप में उपयोग करता है — उदाहरण के लिए, जून 2025 के लिए 25.06। यह दृष्टिकोण बार-बार अपडेट वाले एप्लिकेशन में लोकप्रिय है।
CalVer परिवर्तनों के महत्व के बारे में जानकारी नहीं देता, लेकिन वर्ज़न की ताज़गी को स्पष्ट रूप से दर्शाता है। उपयोगकर्ता तुरंत समझ जाते हैं कि वर्ज़न 25.06, 25.03 से नया है।
कैलेंडर वर्ज़निंग चुनें यदि आपका ऐप बार-बार अपडेट होता है और उपयोगकर्ता परिवर्तनों के दायरे से अधिक डेटा की ताज़गी की परवाह करते हैं।
MVP और स्टार्टअप के लिए, बिना पैच के एक सरल सिमैंटिक वर्ज़न (Major.Minor) उपयुक्त है। दीर्घकालिक समर्थन वाले परिपक्व उत्पादों के लिए — पूर्ण SemVer। निरंतर रिलीज़ वाले ऐप्स के लिए — CalVer।
कभी भी दिनांक को Build Number के रूप में उपयोग न करें — इससे प्रति दिन कई बिल्ड के साथ विरोध हो सकता है। Build Number अनुक्रमिक या संयुक्त होना चाहिए, लेकिन हमेशा एकदिशात्मक रूप से बढ़ता हुआ।
एक सामान्य गलती नई मेजर लाइन पर जाते समय वर्ज़न घटक को छोड़ना है। उदाहरण के लिए, वर्ज़न 1.9.9 के बाद, अगला 2.0.0 होना चाहिए, न कि 1.10.0। यह सिमैंटिक्स को तोड़ता है और उपयोगकर्ताओं को भ्रमित करता है।
एक और सामान्य समस्या कोड और ऐप स्टोर में Marketing Version के बीच बेमेल है। समीक्षा के लिए बिल्ड सबमिट करने से पहले हमेशा सत्यापित करें कि build.gradle में versionName Google Play Console या App Store Connect में निर्दिष्ट वर्ज़न से मेल खाता है।
कोड उदाहरण दिखाते हैं कि दोनों प्लेटफ़ॉर्म पर Marketing Version कैसे सेट करें और इसके अपडेट को स्वचालित करें।
Android में, versionName build.gradle में सेट किया जाता है। मान स्थिर हो सकता है या पर्यावरण चर से पढ़ा जा सकता है।
android {
defaultConfig {
versionCode 15
versionName "2.1.0"
}
}
// Git टैग से वर्ज़न पढ़ना
def getVersionNameFromGit = {
def tag = "git describe --tags".execute().
text.trim()
return tag.startsWith("v") ? tag.substring(1) : tag
}
versionName Git टैग से निकाला जाता है, जो रिपॉज़िटरी वर्ज़न और निर्मित एप्लिकेशन के बीच संरेखण सुनिश्चित करता है।
iOS पर, Marketing Version Xcode या agvtool के माध्यम से सेट की जाती है। नीचे दिया गया कमांड एक नया मार्केटिंग वर्ज़न सेट करता है।
# Marketing Version सेट करना
xcrun agvtool new-marketing-version 2.1.0
# स्वचालित वृद्धि
xcrun agvtool next-marketing-version
agvtool स्वचालित रूप से Info.plist को अपडेट करता है और Xcode प्रोजेक्ट के सभी टार्गेट में वर्ज़न को सिंक्रनाइज़ करता है।
Fastlane एक स्क्रिप्ट से दोनों प्लेटफ़ॉर्म पर Marketing Version प्रबंधित करने की अनुमति देता है, जो क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट रखरखाव को सरल बनाता है।
# मार्केटिंग वर्ज़न सेट करना
increment_version_number(
version_number: "2.1.0"
)
# माइनर वर्ज़न की स्वचालित वृद्धि
increment_version_number(
bump_type: "minor"
)
Fastlane दोनों प्लेटफ़ॉर्म पर काम करता है और अधिकांश CI/CD सेवाओं द्वारा समर्थित है।
अक्सर पूछे जाने वाले प्रश्न
Marketing Version उपयोगकर्ता को दिखाई देने वाला वर्ज़न है (स्टोर में दिखता है), जबकि Build Number एक आंतरिक बिल्ड पहचानकर्ता है। Marketing Version दोहराई जा सकती है, Build Number प्रत्येक बिल्ड के लिए अद्वितीय होना चाहिए।
प्रत्येक नई कार्यक्षमता के रिलीज़, API परिवर्तन या बड़े सुधार के साथ। हॉटफ़िक्स रिलीज़ के लिए, Marketing Version अपरिवर्तित रह सकती है — बस Build Number बढ़ाएँ।
Android पर — हाँ, versionName में कोई भी वर्ण हो सकते हैं। iOS पर — केवल संख्याएँ और बिंदु। Apple App Store संगतता के लिए संख्यात्मक फ़ॉर्मेट का उपयोग करने की अनुशंसा करता है।
अनुशंसित नहीं. ऐप स्टोर वर्ज़न रोलबैक का समर्थन नहीं करते। इसके बजाय, सुधारों के साथ एक नया वर्ज़न जारी करें और पैच घटक बढ़ाएँ। उपयोगकर्ता स्वचालित रूप से नए वर्ज़न पर स्विच हो जाएँगे।
प्रोजेक्ट रूट में साझा कॉन्फ़िगरेशन फ़ाइल (जैसे, version.properties) का उपयोग करें। दोनों प्लेटफ़ॉर्म पर बिल्ड स्क्रिप्ट इस फ़ाइल से वर्ज़न पढ़ती हैं, जिससे मान सिंक्रनाइज़ेशन सुनिश्चित होता है।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें