Build Number मोबाइल एप्लिकेशन बिल्ड का एक अनोखा संख्यात्मक पहचानकर्ता है जो आंतरिक संस्करण पहचान के लिए काम आता है। Version Name के विपरीत, यह पैरामीटर उपयोगकर्ता को नहीं दिखाया जाता, लेकिन एप्ल स्टोर्स के लिए यह अत्यन्त महत्वपूर्ण है। Android Developers, 2025 के अनुसार, Build Number का सही उपयोग अपडेट प्रकाशित करते समय विरोधों को रोकता है।
मुख्य बातें
Build Number एक अनोखा पूर्णांक पहचानकर्ता है जो मोबाइल एप्लिकेशन के प्रत्येक बिल्ड को दिया जाता है। एप्ल स्टोर्स इसका उपयोग संस्करण की नवीनता निर्धारित करने के लिए करते हैं — संख्या जितनी अधिक होगी, बिल्ड उतना ही नया होगा।
Android में इस पैरामीटर को versionCode कहा जाता है, iOS में — CFBundleVersion। दोनों पैरामीटर प्रकाशन के लिए अनिवार्य हैं और प्रत्येक नए बिल्ड के साथ एकात्मक रूप से बढ़ने चाहिए।
Google Play Console Help (2025) के अनुसार, प्रत्येक APK अपलोड के साथ versionCode की जाँच की जाती है: यदि पहले से प्रकाशित संस्करण से कम या बराबर versionCode वाला बिल्ड अपलोड किया जाता है, तो Google Play त्रुटि के साथ फ़ाइल को अस्वीकार कर देता है।
आंतरिक बिल्ड ट्रैकिंग के लिए Build Number का उपयोग करें — समस्यापूर्ण रिलीज़ की त्वरित पहचान के लिए अपने वर्जन कंट्रोल सिस्टम में नंबर को commit hash से लिंक करें।
Build Number प्रत्येक बने एप्लिकेशन संस्करण की अनोखी पहचान की समस्या को हल करता है। इसके बिना, यह निर्धारित करना असंभव है कि कौन सा बिल्ड नया है यदि Version Name नहीं बदला है।
Google Play और App Store जैसे एप्ल स्टोर्स अपडेट के दौरान विरोधों को हल करने के लिए Build Number का उपयोग करते हैं। जब कोई उपयोगकर्ता पुराने संस्करण के ओपर एक नया संस्करण स्थापित करता है, तो सिस्टम Build Number की तुलना करता है और केवल उच्च मान होने पर ही अपडेट प्रदान करता है।
यह तंत्र सही अपडेट डिलीवरी के लिए अत्यन्त महत्वपूर्ण है: एकात्मक रूप से बढ़ने वाले Build Number के बिना, उपयोगकर्ता एप्लिकेशन के पुराने संस्करण पर अटक सकते हैं।
Build Number एक सरल अनुक्रमिक संख्या (1, 2, 3...) या एक मिश्रित संख्या हो सकती है जो अतिरिक्त जानकारी को एन्कोड करती है। मिश्रित संख्याओं में अक्सर बिल्ड तारीख या CI/CD सिस्टम बिल्ड नंबर शामिल होता है।
Android के लिए versionCode int प्रकार का एक पूर्णांक है, अधिकतम मान 2100000000 है। iOS के लिए CFBundleVersion तीन बिंदुओं से अलग की गई संख्याओं की एक स्ट्रिंग है, प्रत्येक 255 से अधिक नहीं होनी चाहिए।
Apple Developer (2025) के अनुसार, CFBundleVersion 3 घटकों तक का समर्थन करता है, लेकिन App Store संस्करण तुलना के लिए उन्हें एक ही क्रमसूचक संख्या के रूप में उपयोग करता है।
Android में Build Number को build.gradle फ़ाइल में versionCode पैरामीटर द्वारा सेट किया जाता है। यह एक पूर्णांक है जो Google Play पर प्रकाशित एप्लिकेशन के प्रत्येक संस्करण के लिए अनोखा होना चाहिए।
यह पैरामीटर android.defaultConfig ब्लॉक के अंदर घोषित किया जाता है और प्रत्येक नए रिलीज़ के साथ बढ़ना चाहिए। Google Play एक ही एप्लिकेशन के दूसरे संस्करण के लिए पहले से उपयोग किए गए versionCode वाला APK अपलोड करने की अनुमति नहीं देता है।
Google Play Developer API (2025) के अनुसार, अधिकतम versionCode मान 2100000000 है। सीमा समाप्त होने से बचने के लिए प्रत्येक नए बिल्ड के लिए 1 से शुरू करके 1 बढ़ाने की अनुशंसा की जाती है।
संस्करण संख्या को एन्कोड करने वाला एक मिश्रित versionCode उपयोग करें: Major * 1000000 + Minor * 1000 + Patch — यह सेमांटिक संस्करण के साथ मिलान को सरल बनाता है।
versionCode पर सभी प्रतिबंध हैं: यह एक 32-बिट हस्ताक्षरित पूर्णांक है, इसलिए अधिकतम मान 2100000000 है। यदि सीमा समाप्त हो जाती है, तो एप्लिकेशन को Google Play पर अपडेट नहीं किया जा सकता।
Android App Bundle के लिए versionCode बेस मॉड्यूल में भी निर्दिष्ट किया जाता है, और प्रत्येक फ़ीचर मॉड्यूल का अपना versionCode हो सकता है। Google Play उन्हें एक ही सत्यापन प्रणाली में संयोजित करता है।
संस्करण रणनीति चुनते समय इस सीमा पर विचार करना महत्वपूर्ण है — संख्या का बहुत तेज़ बढ़ना लंबी अवधि में समस्याएँ पैदा कर सकता है।
iOS में Build Number को Info.plist फ़ाइल में CFBundleVersion की कुंजी द्वारा सेट किया जाता है। Android के विपरीत, यह पैरामीटर एक स्ट्रिंग है, लेकिन इसे भी प्रत्येक नए बिल्ड के साथ बढ़ना चाहिए।
CFBundleVersion का प्रारूप एक से तीन बिंदु-पृथक संख्याओं का होता है। प्रत्येक संख्या 255 से अधिक नहीं हो सकती। App Store तुलना के लिए स्ट्रिंग की व्याख्या संख्याओं के अनुक्रम के रूप में करता है: 1.0.1 को 1.0.0 से नया माना जाता है।
Apple Developer Documentation (2025) के अनुसार, App Store Connect को प्रत्येक अपलोड किए गए बिल्ड के लिए अनोखे CFBundleVersion की आवश्यकता होती है। यदि पहले से उपयोग किए गए नंबर वाला बिल्ड अपलोड किया जाता है, तो सिस्टम उसे अस्वीकार कर देता है।
प्रत्येक बिल्ड के साथ संख्या की एकात्मक वृद्धि सुनिश्चित करने के लिए CFBundleVersion को agvtool या Xcode बिल्ड स्क्रिप्ट के माध्यम से प्रबंधित करें।
Xcode Build Settings के माध्यम से CFBundleVersion को प्रबंधित करने की अनुमति देता है। “Current Project Version” फ़ील्ड मूल मान निर्धारित करता है, और Build Phase स्क्रिप्ट इसे स्वचालित रूप से बढ़ा सकते हैं।
CI/CD के लिए fastlane प्लगिन increment_build_number का उपयोग करें, जो Info.plist से वर्तमान संस्करण पढ़ता है और इसे निर्दिष्ट मान से बढ़ाता है। यह प्रत्येक बिल्ड की विशिष्टता की गारंटी देता है।
यह दृष्टिकोण Build Number प्रबंधन को पूर्ण रूप से स्वचालित करता है और रिलीज़ तैयारी के दौरान मानवीय त्रुटियों को समाप्त करता है।
Build Number की स्वचालित वृद्धि आधुनिक CI/CD पाइपलाइन में एक मानक अभ्यास है। बिल्ड नंबर की मैनुअल वृद्धि प्रकाशन के दौरान त्रुटियों और विरोधों का कारण बनती है।
GitHub Actions, GitLab CI और Jenkins बिल्ड नंबर के साथ बिल्ट-इन वेरिएबुल प्रदान करते हैं। इन वेरिएबुल का उपयोग Build Number के स्वचालित प्रतिस्थापन के लिए Gradle या Xcode स्क्रिप्ट में किया जाता है।
GitLab CI Documentation (2025) के अनुसार, CI_PIPELINE_IID चर प्रत्येक पाइपलाइन के लिए एक अनोखा नंबर सुनिश्चित करता है, जो Build Number के रूप में उपयोग के लिए आदर्श है।
CI/CD स्तर पर स्वचालित वृद्धि कॉन्फ़िगर करें — यह रिलीज़ ब्रांच में प्रत्येक commit के लिए Build Number को मैनुअली बदलने की आवश्यकता को समाप्त करता है।
GitHub Actions बिल्ट-इन चर run_number का समर्थन करता है, जो पाइपलाइन के प्रत्येक रन के साथ स्वचालित रूप से बढ़ता है। मान को versionCode के माध्यम से Gradle में भेजा जा सकता है।
Jenkins BUILD_NUMBER चर का उपयोग करता है, जो सभी बिल्ड चरणों पर उपलब्ध होता है। Xcode परियोजनाओं के लिए, Jenkins इस नंबर के साथ agvtool चलाता है।
अतिरिक्त कॉन्फ़िगरेशन को कम करने के लिए अपने स्टैक में एकीकृत उपकरण चुनें।
Build Number और Version Name एक जोड़ी के रूप में काम करते हैं: पहला मशीनों के लिए, दूसरा लोगों के लिए। Build Number तकनीकी विशिष्टता सुनिश्चित करता है, Version Name उपयोगकर्ता के अनुकूल अर्थ विज्ञान प्रदान करता है।
Android में ये दोनों पैरामीटर स्वतंत्र हैं: versionCode, versionName को बदले बिना बढ़ सकता है (उदाहरण के लिए, बिल्ड त्रुटि को ठीक करने के लिए)। iOS में CFBundleVersion भी CFBundleShortVersionString से बंधा नहीं है।
Stack Overflow Developer Survey (2024) के अनुसार, 82% टीमें Build Number की स्वचालित वृद्धि का उपयोग करती हैं, लेकिन केवल 45% Version Name अपडेट को स्वचालित करती हैं — यह रिलीज़ त्रुटियों के सामान्य कारणों में से एक है।
भले ही Version Name न बदले, प्रत्येक बिल्ड के साथ Build Number बढ़ाएँ — यह एप्ल स्टोर्स में अपडेट तंत्र के सही संचालन को सुनिश्चित करता है।
versionCode को 1 से शुरू करें और प्रत्येक बिल्ड के लिए 1 बढ़ाएँ। iOS के लिए CFBundleVersion के साथ एवं ही दृष्टिकोण अपनाएँ। जब तक सड़ी आवश्यक न हो, मिश्रित संख्याओं से बचें — एक सरल अनुक्रमिक संख्या ट्रैक करने में आसान है।
Build Number को CI/CD सिस्टम बिल्ड नंबर से लिंक करें — यह त्रुटि से विशिष्ट commit तक ट्रेसिंग को सरल बनाता है। बिल्ड नंबर और संस्करण के साथ Git टैग रिलीज़ प्रबंधन के लिए सभी से अच्छी प्रथा है।
कोड उदाहरण दिखाते हैं कि दोनों प्लेटफॉर्म पर Build Number की स्वचालित वृद्धि कैसे कॉन्फ़िगर करें।
Android में versionCode को CI/CD पर्यावरण चर के माध्यम से सेट किया जा सकता है। यदि चर सेट नहीं है, तो डिफ़ॉल्ट मान का उपयोग किया जाता है।
android {
defaultConfig {
versionCode System.getenv("CI_PIPELINE_ID")?.toInteger() ?: 1
versionName "1.2.0"
}
}
versionCode को CI/CD चर से अपना मान मिलता है, जो पाइपलाइन में प्रत्येक बिल्ड के लिए नंबर की विशिष्टता की गारंटी देता है।
iOS में Build Number की स्वचालित वृद्धि के लिए agvtool का उपयोग किया जाता है, जो Xcode Command Line Tools में बनाया गया है।
# बिल्ड नंबर में 1 का इजाफा
xcrun agvtool next-version -all
# विशिष्ट बिल्ड नंबर सेट करें
xcrun agvtool new-version -all "3.0.1"
फ़्लैग -all परियोजना के सभी लक्ष्यों में संस्करण को अपडेट करता है, जो मुख्य एप्लिकेशन और एक्सटेंशन के बीच मानों के सिंक्रोनिज़ेशन की गारंटी देता है।
Fastlane मोबाइल एप्लिकेशन बिल्ड को स्वचालित करने का एक लोकप्रिय उपकरण है। increment_build_number प्लगिन स्वचालित रूप से Build Number बढ़ाता है।
increment_build_number(
build_number: ENV["BUILD_NUMBER"] ||
latest_testflight_build_number + 1
)
Fastlane किसी भी CI/CD सिस्टम के साथ एकीकृत होता है और Android और iOS दोनों परियोजनाओं का समर्थन करता है।
अक्सर पूछे जाने वाले प्रश्न
एप्ल स्टोर अपलोड को अस्वीकार कर देगा। Google Play और App Store जाँच करते हैं कि नए बिल्ड का Build Number पहले प्रकाशित संस्करण से अधिक है। यदि शर्त पूरी नहीं होती, तो अपलोड अस्वीकार कर दिया जाएगा।
केवल एक नए एप्लिकेशन के लिए। पहले प्रकाशन के बाद, Build Number केवल बढ़ना चाहिए। इसे 1 पर रीसेट करने से नए संस्करण को प्रकाशित करने की कोशिश करने पर «versionCode already exists» त्रुटि उत्पन्न होगी।
2100000000 Android में versionCode का अधिकतम मान है, क्योंकि यह एक 32-बिट हस्ताक्षरित पूर्णांक है। प्रति बिल्ड 1 की उचित वृद्धि के साथ, सीमा अरबों बिल्ड के लिए पर्याप्त होगी।
CFBundleVersion आंतरिक बिल्ड नंबर है जो प्रत्येक बिल्ड के साथ बढ़ना चाहिए। CFBundleShortVersionString App Store में दिखाया जाने वाला उपयोगकर्ता-दृश्य संस्करण है। पहला मशीनों के लिए, दूसरा लोगों के लिए।
हाँ, निश्चित रूप से। TestFlight को भी आवश्यकता होती है कि प्रत्येक अपलोड किए गए बिल्ड का एक अनोखा Build Number हो। यदि नंबर नहीं बढ़ाया जाता, तो TestFlight अपलोड को अस्वीकार कर देगा।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें