Version Name ایپلیکیشن کا ورژن سٹرنگ ہے جسے صارف سٹور اور ڈیوائس پر دیکھتا ہے۔ Build Number کے برعکس، اس پیرامیٹر کا سیمنٹک معنی ہوتا ہے اور یہ تبدیلیوں کی اہمیت کو ظاہر کرتا ہے۔ Android Developers, 2025 کے مطابق، Version Name کا صحیح استعمال صارفین کو اپ ڈیٹس کی مطابقت سمجھنے اور ڈیولپمنٹ کے عمل پر اعتماد کرنے میں مدد کرتا ہے۔
اہم نکات
Version Name ایک سیمنٹک سٹرنگ ہے جو صارف کے لیے ایپلیکیشن ریلیز کی شناخت کرتی ہے۔ تکنیکی بلڈ شناخت کنندگان کے برعکس، یہ پیرامیٹر بامعنی معلومات رکھتا ہے: صارف اندازہ لگا سکتا ہے کہ نیا اپ ڈیٹ پچھلے سے کتنا مختلف ہے۔
Version Name Google Play اور App Store پر ایپلیکیشن کارڈ میں، ڈیوائس پر “ایپ کے بارے میں” سیکشن میں، اور سسٹم اپ ڈیٹ ڈائیلاگ میں ظاہر ہوتا ہے۔ ڈیولپرز ریلیز ورژن بنانے سے پہلے اسے پروجیکٹ کنفیگریشن فائلوں میں متعین کرتے ہیں۔
Semantic Versioning 2.0 (2023) کے مطابق، Major.Minor.Patch فارمیٹ 78% موبائل ایپلیکیشنز میں استعمال ہوتا ہے۔ میجر ورژن غیر مطابقت پذیر API تبدیلیوں کے ساتھ بدلتا ہے، مائنر ورژن نئی فعالیت شامل کرنے کے ساتھ، اور پیچ بگ فکس کے ساتھ۔
صارف کے ساتھ بات چیت کے لیے Version Name استعمال کریں: انہیں فوری طور پر سمجھ لینا چاہیے کہ پیش کردہ اپ ڈیٹ کتنا اہم ہے — میجر، مائنر یا اصلاحی۔
سیمنٹک ورژن تین نمبروں پر مشتمل ہوتا ہے جو نقطوں سے الگ ہوتے ہیں: Major.Minor.Patch۔ ان میں سے ہر ایک جزو ایپلیکیشن میں تبدیلیوں کی ایک مخصوص سطح کے لیے ذمہ دار ہے۔
میجر ورژن (Major) اس وقت بڑھتا ہے جب ایسی بنیادی تبدیلیاں متعارف کروائی جاتی ہیں جو پسماندہ مطابقت کو توڑتی ہیں۔ مائنر ورژن (Minor) موجودہ فعالیت کو توڑے بغیر نئی فعالیت شامل کرتا ہے۔ پیچ (Patch) میں صرف بگ فکس ہوتے ہیں۔
مثال کے طور پر، ورژن 3.2.1 کا مطلب ہے: تیسرا میجر ورژن، دوسرا مائنر اپ ڈیٹ، پہلا پیچ۔ یہ نظام ڈیولپرز اور صارفین دونوں کے لیے قابل فہم ہے۔
Version Name صارف کو کئی اہم مقامات پر نظر آتا ہے۔ ایپ سٹور میں، یہ ایپلیکیشن کارڈ ہیڈر اور اپ ڈیٹ کی فہرست میں ظاہر ہوتا ہے۔ ڈیوائس پر، یہ “ایپ کے بارے میں” سیکشن میں سسٹم سیٹنگز میں ظاہر ہوتا ہے۔
Google Play پر، Version Name ایپلیکیشن نام کے نیچے دکھایا جاتا ہے اور صارف کے اپ ڈیٹ کرنے کے فیصلے کو متاثر کرتا ہے۔ App Store میں، ورژن سٹرنگ ایپلیکیشن پیج دیکھتے وقت اسی جگہ ظاہر ہوتی ہے۔
Apptentive (2024) کی تحقیق کے مطابق، 67% صارفین اپ ڈیٹ سے پہلے ایپ ورژن چیک کرتے ہیں، اور واضح سیمنٹکس انسٹال کنورژن کو 23% تک بڑھاتے ہیں۔
Android پر، Version Name build.gradle فائل (ماڈیول لیول) میں versionName پیرامیٹر سے سیٹ کیا جاتا ہے۔ یہ پیرامیٹر ایک سٹرنگ ہے اور نقطوں، ہائفنز اور حروف سمیت کوئی بھی حرف شامل کر سکتا ہے۔
پیرامیٹر لازمی versionCode پیرامیٹر کے ساتھ android.defaultConfig بلاک کے اندر اعلان کیا جاتا ہے۔ Android سٹرنگ فارمیٹ پر کوئی پابندی نہیں لگاتا، لیکن Google Play سیمنٹک فارمیٹ استعمال کرنے کی سفارش کرتا ہے۔
Android Developers (2025) کے مطابق، Google Play versionName کو سٹور انٹرفیس میں ڈسپلے کے لیے استعمال کرتا ہے لیکن پروگرام کے ذریعے اس کے مواد کا تجزیہ نہیں کرتا — صرف versionCode اپ ڈیٹ منطق کو متاثر کرتا ہے۔
Version Name کو Major.Minor.Patch فارمیٹ میں متعین کریں اور غیر مبہم ریلیز شناخت کے لیے اسے ورژن کنٹرول سسٹم میں ٹیگ کے ساتھ ہم آہنگ کریں۔
Gradle build.gradle میں جامد طور پر یا بلڈ اسکرپٹ کے ذریعے متحرک طور پر versionName سیٹ کرنے کی اجازت دیتا ہے۔ متحرک جنریشن خودکار رات بھر کے بلڈز اور CI/CD پائپ لائنز کے لیے مفید ہے۔
build.gradle میں، versionName بنانے کے لیے ماحولیاتی متغیرات، کمانڈ لائن پیرامیٹرز، یا شیل اسکرپٹ کالز استعمال کی جا سکتی ہیں۔ ایک عام طریقہ version.properties فائل سے ورژن پڑھنا ہے۔
یہ لچک ٹیموں کو ورژننگ کے عمل کو خودکار بنانے اور ریلیز کی تیاری کے دوران انسانی غلطی کو ختم کرنے کی اجازت دیتی ہے۔
iOS پر، Version Name Info.plist فائل میں CFBundleShortVersionString کلید سے سیٹ کیا جاتا ہے۔ App Store پر ایپلیکیشن شائع کرنے کے لیے یہ ایک لازمی پیرامیٹر ہے، اور یہ سختی سے سٹرنگ کے طور پر ٹائپ کیا جاتا ہے۔
Android کے برعکس، App Store Connect Version Name فارمیٹ کو چیک کرتا ہے اور اسے نقطوں سے الگ کردہ نمبروں کے پیٹرن سے ملنے کی ضرورت ہوتی ہے۔ زیادہ سے زیادہ سٹرنگ کی لمبائی 18 حروف ہے، اور ہر ورژن جزو 255 سے تجاوز نہیں کر سکتا۔
Apple Developer Documentation (2025) کے مطابق، CFBundleShortVersionString کو App Store سٹور انٹرفیس اور صارف کے ڈیوائس پر سسٹم ڈائیلاگ میں ورژن ظاہر کرنے کے لیے استعمال کرتا ہے۔
App Store Connect میں بلڈ اپ لوڈ کرتے وقت، یقینی بنائیں کہ Version Name مارکیٹنگ مواد میں بتائے گئے ورژن سے مماثل ہے — یہ صارفین کے ساتھ بات چیت کو آسان بناتا ہے۔
Xcode ہدف کی ترتیبات میں Version Name تبدیل کرنے کے لیے ایک گرافیکل انٹرفیس فراہم کرتا ہے۔ “Marketing Version” فیلڈ Identity سیکشن کے تحت General ٹیب پر واقع ہے۔ تبدیلیاں خود بخود Info.plist میں محفوظ ہو جاتی ہیں۔
آٹومیشن کے لیے، Xcode Build Phases میں بلڈ اسکرپٹ یا agvtool (Apple Generic Version Tool) یوٹیلیٹی استعمال کی جا سکتی ہے۔ agvtool کمانڈ لائن سے ورژنز کو منظم کرنے کی اجازت دیتا ہے اور CI/CD میں ضم ہو جاتا ہے۔
یہ طریقہ خاص طور پر ایپلیکیشنز کی خودکار بلڈنگ اور ڈیلیوری کے لیے fastlane یا Jenkins استعمال کرتے وقت آسان ہے۔
Version Name اور Build Number ڈیولپمنٹ کے عمل میں مختلف کام انجام دیتے ہیں۔ Version Name ایک صارف پر مبنی سٹرنگ ہے، جبکہ Build Number ایک اندرونی عددی شناخت کنندہ ہے جو ہر بلڈ کو منفرد طور پر پہچانتا ہے۔
Build Number (Android میں versionCode، iOS میں CFBundleVersion) ہر نئے بلڈ کے ساتھ بڑھنا چاہیے اور ایپ سٹور اسے یہ تعین کرنے کے لیے استعمال کرتے ہیں کہ کون سا ورژن نیا ہے۔ Version Name ایک ہی ورژن کے متعدد بلڈز میں تبدیل نہیں رہ سکتا۔
Google Play Policy (2025) کے مطابق، ایک ہی versionCode والی دو ایپلیکیشنز ایک ہی ورژن سمجھی جاتی ہیں — versionCode ہر APK کے لیے منفرد ہونا چاہیے۔ Version Name اس جانچ میں حصہ نہیں لیتا۔
ہر بلڈ کے ساتھ ہمیشہ Build Number بڑھائیں اور Version Name صرف اس وقت تبدیل کریں جب فعالیت بدلتی ہے — یہ اشاعت کے دوران تنازعات کو روکتا ہے۔
Version Name کا انتخاب ٹیم کی ورژننگ حکمت عملی پر منحصر ہے۔ سب سے عام طریقہ سیمنٹک ورژننگ (SemVer) ہے، لیکن متبادل اسکیمیں بھی موجود ہیں، جیسے کیلنڈر ورژننگ یا ریلیز تاریخ ورژننگ۔
Semantic Versioning 2.0 اختیاری پری ریلیز لاحقوں کے ساتھ Major.Minor.Patch فارمیٹ کی سفارش کرتا ہے۔ موبائل ایپلیکیشنز کے لیے، Major.Minor اسکیما بھی مقبول ہے، جہاں تصور کو آسان بنانے کے لیے پیچ ورژن چھوڑ دیا جاتا ہے۔
کیلنڈر ورژننگ (CalVer) ریلیز تاریخ کو ورژن نمبر کے طور پر استعمال کرتی ہے — مثال کے طور پر، 25.06 (سال اور مہینہ)۔ یہ طریقہ بار بار ریلیز والی ایپلیکیشنز کے لیے آسان ہے جہاں سیمنٹکس کا کوئی مطلب نہیں۔
سیمنٹک ورژننگ عوامی API والی ایپلیکیشنز کے لیے موزوں ہے جہاں پسماندہ مطابقت اہم ہے۔ صارفین اور انٹیگریٹرز سمجھتے ہیں کہ اپ ڈیٹس کے ساتھ کیا تبدیلیاں متوقع ہیں۔
کیلنڈر ورژننگ ان ایپلیکیشنز کے لیے منتخب کی جاتی ہے جہاں صارف کے لیے ریلیز کی تازگی تبدیلیوں کی وسعت سے زیادہ اہم ہوتی ہے۔ مثال کے طور پر، نیوز ایگریگیٹر یا موسم کی ایپلیکیشنز۔
ہائبرڈ اسکیما دونوں طریقوں کو یکجا کرتی ہے: Major.Minor.RC، جہاں RC کسی مخصوص ریلیز امیدوار کے لیے بلڈ نمبر ہے۔ یہ اسکیما فعال بیٹا ٹیسٹنگ کے دوران آسان ہے۔
نیچے دی گئی کوڈ مثالیں Android اور iOS پر Version Name سیٹ کرنے کا طریقہ دکھاتی ہیں۔ Android کے لیے Gradle استعمال ہوتا ہے، iOS کے لیے — agvtool کے ساتھ Xcode Build Settings۔
Android میں، ورژن app/build.gradle فائل میں defaultConfig بلاک کے اندر سیٹ کیا جاتا ہے۔ versionName پیرامیٹر ایک سٹرنگ ویلیو قبول کرتا ہے۔
android {
defaultConfig {
versionCode 3
versionName "2.1.0"
}
}
versionName کو بیرونی فائل سے بھی پڑھا جا سکتا ہے یا Gradle Script استعمال کرتے ہوئے متحرک طور پر بنایا جا سکتا ہے۔
متحرک ورژن CI/CD سسٹم کے ماحولیاتی متغیرات سے بنتا ہے۔ یہ یقینی بناتا ہے کہ ہر بلڈ کو صحیح ورژن نمبر ملتا ہے۔
def getVersionName = {
return System.getenv("VERSION_NAME") ?:
"2.1.0"
}
android {
defaultConfig {
versionName getVersionName()
}
}
یہ طریقہ ورژننگ کو خودکار بناتا ہے اور بلڈ اور ریپوزٹری ٹیگ کے درمیان عدم مطابقت کے خطرے کو ختم کرتا ہے۔
iOS میں، ورژن Xcode کے ذریعے یا agvtool استعمال کرتے ہوئے کمانڈ لائن کے ذریعے سیٹ کیا جا سکتا ہے۔
# مارکیٹنگ ورژن سیٹ کرنا
xcrun agvtool new-marketing-version 2.1.0
# موجودہ ورژن پڑھنا
xcrun agvtool what-marketing-version
agvtool خود بخود Info.plist کو اپ ڈیٹ کرتا ہے اور Xcode پروجیکٹ میں تمام ہدفوں میں ورژن کو ہم آہنگ کرتا ہے۔
اکثر پوچھے گئے سوالات
Version Name ایک صارف پر مبنی ورژن سٹرنگ ہے جو ایپ سٹور میں ظاہر ہوتا ہے۔ Build Number ایک اندرونی عددی بلڈ شناخت کنندہ ہے جو ہر بلڈ کو منفرد طور پر پہچانتا ہے اور سٹور اسے ورژن کی نئی ہونے کا تعین کرنے کے لیے استعمال کرتے ہیں۔
Android میں، versionName حروف اور ہائفنز سمیت کوئی بھی حرف شامل کر سکتا ہے۔ iOS میں، CFBundleShortVersionString نقطوں سے الگ کردہ نمبروں پر مشتمل ہونا چاہیے، اگرچہ پری ریلیز ورژن کے لیے حرفی لاحقے کی اجازت ہے۔
CI/CD ٹولز استعمال کریں — GitHub Actions، GitLab CI یا Jenkins۔ بلڈ اسکرپٹ فائل سے موجودہ ورژن پڑھتی ہے، ضروری جزو بڑھاتی ہے، اور ریلیز بنانے سے پہلے نئی قیمت لکھتی ہے۔
سٹور نیا بلڈ قبول کرے گا اگر Build Number بڑھ گیا ہے۔ تاہم، صارفین ورژن میں تبدیلی نہیں دیکھیں گے، جو الجھن کا سبب بن سکتا ہے۔ نئی فعالیت کی ہر ریلیز کے ساتھ Version Name تبدیل کرنے کی سفارش کی جاتی ہے۔
Major.Minor.Patch فارمیٹ زیادہ تر پروجیکٹس کے لیے بہترین انتخاب ہے۔ یہ صارفین اور ڈیولپرز کے لیے قابل فہم ہے، SemVer معیار کی تعمیل کرتا ہے، اور تمام ایپ سٹورز کے ذریعے تعاون یافتہ ہے۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں