موبائل ڈیولپمنٹ میں Release: ایپ کی بنیادی باتیں، بلڈ اور اشاعت

Release بلڈ کیا ہے

Release — ایک بلڈ ترتیب ہے جس میں تمام کمپائلر آپٹیمائزیشنز لاگو ہوتی ہیں، ڈیبگ معلومات ہٹا دی جاتی ہیں، وسائل کمپریس کیے جاتے ہیں، اور دانشورانہ املاک کے تحفظ کے لیے قابل عمل کوڈ مبہم کیا جاتا ہے۔ Release کا مقصد سب سے تیز اور کمپیکٹ بائنری فائل حاصل کرنا ہے جو سرکاری چینلز کے ذریعے تقسیم کے لیے تیار ہو۔

Debug کے برعکس، Release بلڈ میں ڈیبگر کے لیے داخلے کے مقامات نہیں ہوتے، اثبات غیر فعال ہوتے ہیں، اور لاگنگ کم سے کم ہوتی ہے۔ یہ صرف ایک جھنڈے کی تبدیلی نہیں — یہ مختلف سرٹیفکیٹس، پروویژننگ پروفائلز اور پیکیجنگ سیٹنگز کے ساتھ ایک مختلف بلڈ پائپ لائن ہے۔ Release بلڈ میں زیادہ وقت لگتا ہے کیونکہ کمپائلر اضافی آپٹیمائزیشن پاسز انجام دیتا ہے۔

iOS کے لیے، Release بلڈ پر Apple تقسیمی سرٹیفکیٹ سے دستخط کیے جاتے ہیں اور یہ App Store Connect میں جائزے سے گزرتا ہے۔ Android کے لیے، Release بلڈ پر اپ لوڈ کی سے دستخط کیے جاتے ہیں اور اسے Google Play Console پر اپ لوڈ کیا جا سکتا ہے۔ دونوں پلیٹ فارمز کو ڈیجیٹل دستخط کی ضرورت ہوتی ہے: اس کے بغیر بنی ایپ صارف کے آلے پر انسٹال نہیں ہوگی۔

Release اور Debug: ترتیب کا موازنہ

Debug اور Release کے درمیان فرق تمام سطحوں پر ظاہر ہوتا ہے: کمپائلر جھنڈوں سے لے کر .apk یا .ipa کے حتمی سائز تک۔ ان فرقوں کو سمجھنا CI/CD پائپ لائن اور ان ریگریشنز کو تلاش کرنے کے لیے اہم ہے جو صرف Release بلڈ میں ظاہر ہوتے ہیں۔

کمپائلر جھنڈے

Release میں، کمپائلر سائز (-Os LLVM کے لیے) یا رفتار (-O2) کے لیے آپٹیمائزیشن فعال کرتا ہے۔ اس کا مطلب ہے ان لائن فنکشنز کو شامل کرنا، مردہ کوڈ ہٹانا، ہدایات کو دوبارہ ترتیب دینا اور لوپس کی جارحانہ آپٹیمائزیشن۔ Debug میں، یہ تمام مراحل چھوڑ دیے جاتے ہیں، جو کوڈ کو سست کرتا ہے لیکن سورس لائنوں اور مشین ہدایات کے درمیان مکمل مطابقت برقرار رکھتا ہے۔

مبہم کاری اور چھوٹا کرنا

ProGuard/R8 (Android) کلاسز، طریقوں اور فیلڈز کو چھوٹے ناموں (a, b, c) میں تبدیل کرتے ہیں، جو ریورس انجینئرنگ کو پیچیدہ بناتا ہے اور DEX فائل کا سائز کم کرتا ہے۔ iOS پر، مساوی فعالیت Strip Symbols اور Swift Symbolication کے ذریعے فراہم کی جاتی ہے۔ ان کلاسز کے لیے keep قوانین ترتیب دینا ضروری ہے جو ریفلیکشن یا XML لے آؤٹ کے ذریعے استعمال ہوتی ہیں، ورنہ ایپ اسٹارٹ اپ پر ClassNotFoundException کے ساتھ کریش ہو جائے گی۔

بلڈ کا سائز

Release بلڈز Debug بلڈز کے مقابلے میں کافی چھوٹے ہوتے ہیں۔ عام تناسب: Debug ورژن 40–80 MB لیتا ہے، Release — 15–30 MB۔ فرق ڈیبگ علامات (DWARF) کو ہٹانے، وسائل کمپریشن (aapt2) اور DEX مبہم کاری کی وجہ سے ہے۔ صارفین کے لیے، ایپ کا سائز انسٹال کے تبادلوں کا ایک اہم عنصر ہے، اس لیے Release میں سائز آپٹیمائزیشن ایک لازمی عمل ہے۔

Android پر Release بلڈ کا عمل

Gradle Release ورژن بنانے کے لیے بلٹ ان ٹاسک فراہم کرتا ہے: assembleRelease، bundleRelease (AAB کے لیے) اور signingReport۔ ماڈیول سطح پر build.gradle کی درست ترتیب ایک مستحکم CI/CD بلڈ کی بنیاد ہے۔ ایک عام پروجیکٹ کی مثال استعمال کرتے ہوئے اہم مراحل کا جائزہ لیتے ہیں۔

build.gradle ترتیب

buildTypes بلاک میں release ترتیب متعین کی جاتی ہے: چھوٹا کرنا فعال کیا جاتا ہے، shrinkResources آن کیا جاتا ہے، اور proguard قوانین مرتب کیے جاتے ہیں۔ signingConfig بلاک کو storeFile، storePassword، keyAlias اور keyPassword کا حوالہ دینا چاہیے — یہ پیرامیٹرز VCS میں محفوظ نہیں ہونے چاہئیں۔ CI/CD کے لیے، ماحولیاتی متغیرات یا Keystore Provisioning Plugin استعمال کریں۔

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ), "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
    }
}

AAB اور APK بلڈ کرنا

Android App Bundle (AAB) Google Play پر اشاعت کے لیے تجویز کردہ فارمیٹ ہے۔ AAB میں ایک APK نہیں بلکہ وسائل کا ایک ماڈیولر سیٹ ہوتا ہے، جس سے Google Play کسی مخصوص ڈیوائس کے لیے متحرک طور پر ایک آپٹیمائزڈ APK تیار کرتا ہے۔ کمانڈ ./gradlew bundleRelease AAB بلڈ کرتا ہے، جبکہ ./gradlew assembleRelease اپ لوڈ سے پہلے جانچ کے لیے ایک یونیورسل APK بلڈ کرتا ہے۔

دستخط اور تصدیق

دستخط شدہ APK/AAB کی تصدیق apksigner verify کے ذریعے کی جاتی ہے۔ Google Play Console اپ لوڈ کرنے پر خود بخود دستخط چیک کرتا ہے۔ Android 9 (API 28) سے شروع کرتے ہوئے، Google کو v2 یا v3 دستخطی اسکیموں کی ضرورت ہے۔ Wear OS اور Android TV کے لیے، گھومنے والی کلید کے ساتھ v3.1 اضافی طور پر درکار ہے۔

iOS پر Release بلڈ کا عمل

Xcode Archive ترتیب میں Release ورژن بلڈ کرتا ہے — یہ صرف ایک بلڈ نہیں بلکہ ایک مکمل پائپ لائن ہے: آپٹیمائزیشن کے ساتھ کمپائلیشن، .xcarchive میں پیکیجنگ، تقسیمی سرٹیفکیٹ کے ساتھ دستخط، اور .ipa میں برآمد۔ عمل Product → Archive یا xcodebuild کمانڈ کے ذریعے شروع کیا جاتا ہے۔

بلڈ اسکیم ترتیب

Edit Scheme → Run → Build Configuration میں، حتمی جانچ کے لیے Release منتخب کریں۔ App Store Connect پر جمع کرانے کے لیے، Product مینو سے Archive استعمال کریں۔ Xcode ایک .xcarchive بناتا ہے جس میں بائنری فائل، dSYM اور وسائل کے بنڈل ہوتے ہیں۔ آرکائیو سے Ad Hoc، Development یا App Store تقسیم کے لیے .ipa برآمد کیا جاتا ہے۔

App Store Connect اور TestFlight

TestFlight App Store تقسیمی سرٹیفکیٹ سے دستخط شدہ Release بلڈز قبول کرتا ہے۔ App Store پر بھیجنے سے پہلے، بلڈ Xcode میں خودکار توثیق سے گزرتا ہے: سرٹیفکیٹ کی مطابقت، تمام سائز کے آئیکنز، Info.plist کی درستی، اور بائنری فائل میں سمیلیٹر آرکیٹیکچرز کی عدم موجودگی کی جانچ کی جاتی ہے۔

# xcodebuild کے ذریعے Release بلڈ
xcodebuild archive \
  -project MyApp.xcodeproj \
  -scheme "MyApp" \
  -configuration "Release" \
  -archivePath "build/MyApp.xcarchive"

# App Store کے لیے .ipa برآمد
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode اور App Thinning

App Thinning ڈاؤن لوڈ کردہ ایپ کے سائز کو کم کرنے کے لیے Apple کی ٹیکنالوجی ہے۔ App Store پر اپ لوڈ کرتے وقت، Apple صارف کے مخصوص ڈیوائس کے لیے بائنری فائل کو دوبارہ کمپائل کرتا ہے، غیر استعمال شدہ آرکیٹیکچرز کو ہٹاتا ہے۔ Bitcode (LLVM انٹرمیڈیٹ نمائندگی) Release بلڈز میں شامل کیا جاتا ہے اگر پروجیکٹ iOS 14+ اور Xcode 12+ استعمال کرتا ہے۔

Release تیار کرتے وقت عام غلطیاں

Release بلڈ ترتیب کی غلطیاں تین اقسام میں آتی ہیں: کمپائلیشن مسائل، دستخطی مسائل، اور منطقی غلطیاں جو صرف آپٹیمائزیشن کے بعد ظاہر ہوتی ہیں۔ آئیے Debug سے Release میں منتقلی کے وقت ڈیولپرز کو درپیش سب سے عام منظرناموں کو دیکھتے ہیں۔

مبہم کاری کے بعد ClassNotFoundException

Android پر سب سے عام غلطی — minifyEnabled فعال کرنے کے بعد اسٹارٹ اپ پر کریش۔ وجہ: R8 نے ایک کلاس کا نام تبدیل کر دیا جو ریفلیکشن کے ذریعے استعمال ہوتی ہے (مثال کے طور پر، Gson سیریلائزیشن، data class کے ساتھ Retrofit @Body)۔ حل — سیریلائزیشن میں شامل تمام کلاسز کے لیے -keep اصول شامل کریں اور بلڈ سے پہلے proguard اصولوں کی جانچ کریں۔

سمبولیکیشن کے لیے dSYM کی کمی

iOS پر، ڈیولپرز اکثر Archive کے بعد dSYM فائلیں محفوظ کرنا بھول جاتے ہیں۔ dSYM کے بغیر، App Store Connect سے کریش لاگ پڑھنے کے قابل فنکشن ناموں کے بجائے ہیکساڈیسیمل پتوں کے طور پر آتے ہیں۔ حل — .ipa کے ساتھ dSYM کو آرکائیو کرنے اور App Store Connect پر اپ لوڈ کرنے کے لیے CI/CD ترتیب دیں۔

پروویژننگ پروفائل کے مسائل

میعاد ختم شدہ تقسیمی سرٹیفکیٹ یا پروویژننگ پروفائل میں غلط App ID وہ وجہ ہے جس کی بنا پر App Store Connect بلڈ کو مسترد کرتا ہے۔ سرٹیفکیٹ 1 سال (Apple) یا 3 سال (Google) کے لیے درست ہوتے ہیں، اور ان کی تجدید کو ریلیز کیلنڈر میں شامل کیا جانا چاہیے۔ ہر Release بلڈ سے پہلے سرٹیفکیٹ کی حیثیت کی جانچ کرنا CI/CD پائپ لائن میں ایک لازمی مرحلہ ہے۔

SDK ورژن اور ڈیپلائمنٹ ٹارگٹ کی عدم مطابقت

Debug سے Release میں منتقلی کے وقت ایک عام مسئلہ — ہدف OS ورژن پر غیر دستیاب API کا استعمال۔ Debug میں، بلڈ کو تازہ ترین ورژن والے سمیلیٹر پر جانچا جاتا ہے، جہاں تمام نئی APIs دستیاب ہوتی ہیں۔ Release میں، ایپ مختلف OS ورژن والے صارفین کے آلات پر انسٹال ہوتی ہے، اور غیر دستیاب API کو کال کرنا اسٹارٹ اپ پر کریش کا سبب بنتا ہے۔ کم از کم ورژن واضح طور پر متعین کرنے کے لیے @available (Swift) یا compileSdkVersion + minSdkVersion (Android) استعمال کریں۔

مقامی کاری کی کمی اور مختلف ترتیبوں کے لیے وسائل

Debug بلڈز میں، وسائل اکثر ترتیب کی تصدیق کے بغیر سورس ڈائریکٹریز سے لوڈ کیے جاتے ہیں۔ Release میں، Gradle اور Xcode وسائل فلٹرنگ لاگو کرتے ہیں: اگر ہدف مقامی زبان میں کوئی سٹرنگ یا drawable نہ ملے تو ایپ کریش ہوتی ہے یا پلیس ہولڈر دکھاتی ہے۔ یہ Android کے لیے خاص طور پر اہم ہے: values-XX میں ترجمے کی کمی XML پارس کرتے وقت ClassCastException کا سبب بنتی ہے۔ Release بلڈ سے پہلے lint اور xcodebuild -showBuildSettings کے ساتھ تمام مقامی زبانوں کی جانچ کریں۔ اس طرح کے مسائل کا پتہ لگانے کے لیے، عوامی ریلیز سے پہلے TestFlight اور Internal Testing ٹریک استعمال کریں — یہ مختلف زبان کی ترتیبات والے حقیقی آلات پر چلتے ہیں۔