Podfile: یہ کیا ہے، نحو اور CocoaPods کے ذریعے لائبریری کی ترتیب

Podfile کیا ہے اور اس کی ضرورت کیوں ہے

Podfile Ruby زبان میں لکھی گئی ایک اعلانیہ اسکرپٹ ہے جو iOS، macOS، tvOS یا watchOS پروجیکٹس کے لیے بیرونی انحصار کی فہرست بناتی ہے۔ یہ پروجیکٹ کی روٹ ڈائریکٹری میں واقع ہوتی ہے اور CocoaPods پیکیج مینیجر کے لیے ترتیب کے واحد نقطہ کے طور پر کام کرتی ہے۔ Podfile کے بغیر، ڈویلپرز کو دستی طور پر لائبریریاں ڈاؤن لوڈ کرنی ہوں گی، انہیں پروجیکٹ میں کاپی کرنا ہوگی اور Xcode میں linker فلیگز ترتیب دینے ہوں گے۔

CocoaPods Podfile کا تجزیہ کرتا ہے اور Podfile.lock فائل بناتا ہے جو انسٹال شدہ لائبریریوں کے عین مطابق ورژن مقفل کرتی ہے۔ یہ ڈویلپمنٹ ٹیم کی تمام مشینوں پر دوبارہ پیدا ہونے والی بلڈ کو یقینی بناتا ہے: اگر ایک ڈویلپر Alamofire کو ورژن 5.9 میں اپ ڈیٹ کرتا ہے، تو Podfile.lock اس تبدیلی کو مقفل کر دے گا، اور pod install چلانے والے سبھی کو بالکل وہی ورژن ملے گا۔ اس طریقہ کار کے بغیر، مختلف ڈویلپرز کے پاس انحصار کے مختلف ورژن ہو سکتے ہیں، جس سے ایسی بگز پیدا ہوتی ہیں جنہیں ڈھونڈنا مشکل ہوتا ہے۔

Podfile تین اہم کام حل کرتا ہے: ورژن کنٹرول کے ساتھ انحصار کا انتظام، کم سے کم OS ورژن کے ساتھ ہدف پلیٹ فارم کی ترتیب، اور Xcode Workspace کے ذریعے خودکار لائبریری انضمام۔ ہر انسٹالیشن پر، CocoaPods ایک Pods.xcodeproj فائل بناتا ہے جو ورک اسپیس کے ذریعے مرکزی پروجیکٹ سے منسلک ہوتی ہے۔ ڈویلپر کو یہ سوچنے کی ضرورت نہیں ہے کہ لائبریریاں کیسے منسلک ہوتی ہیں — بس انہیں Podfile میں بتانا کافی ہے۔

Podfile کا نحو اور ساخت

Podfile Ruby نحو استعمال کرتا ہے لیکن اس کے لیے کم سے کم زبان کا علم درکار ہے۔ بنیادی ساخت ہدایات پر مشتمل ہوتی ہے جو پلیٹ فارم، بلڈ ہدف اور انحصار کی فہرست متعین کرتی ہیں۔ ہر ہدایت Ruby انٹرپریٹر کے سیاق و سباق میں عمل میں آتی ہے، لہذا Podfile پیچیدہ ترتیبات کے لیے مشروط تعمیرات، لوپس اور متغیرات کو سپورٹ کرتا ہے۔

target بلاک

ایپ کا ہر بلڈ ہدف target بلاک کے اندر بیان کیا جاتا ہے۔ ایک معیاری Xcode پروجیکٹ کے لیے، عام طور پر ایپ کے نام کے ساتھ ایک ہدف ہوتا ہے۔ نیسٹڈ ہدف یونٹ ٹیسٹ، UI ٹیسٹ اور ایکسٹینشنز کے لیے استعمال کیے جا سکتے ہیں۔ مختلف ہدف کے انحصار کو الگ کرنے کی سفارش کی جاتی ہے: اہم لائبریریاں مرکزی ہدف میں، ٹیسٹ فریم ورک ٹیسٹ ہدف میں، تاکہ پروڈکشن میں غیر ضروری انحصار سے بچا جا سکے۔

# iOS پروجیکٹ کے لیے کم سے کم Podfile کی مثال
target 'MyApp' do
  use_frameworks!
  pod 'Alamofire', '~> 5.8'
  pod 'Kingfisher', '~> 7.10'
  pod 'SnapKit', '~> 5.6'
end

پلیٹ فارم ہدایات

platform ہدایت کم سے کم OS ورژن مقرر کرتی ہے جس کے لیے پروجیکٹ بنایا گیا ہے۔ یہ ایک لازمی پیرامیٹر ہے جو لائبریری کی مطابقت کو متاثر کرتا ہے۔ CocoaPods میں لائبریریاں عام طور پر podspec میں اپنے کم سے کم OS ورژن بتاتی ہیں، اور اگر پروجیکٹ پلیٹ فارم ضرورت سے کم ہو تو pod install ایک خرابی دکھائے گا۔ iOS پروجیکٹس کے لیے، کم سے کم ورژن عام طور پر 15.0 اور اس سے اوپر ہے، macOS کے لیے — 12.0 اور اس سے اوپر۔

platform :ios, '15.0'
platform :macos, '12.0'
platform :tvos, '16.0'

عالمی اور مقامی انحصار

انحصار کو target بلاکس کے باہر عالمی طور پر یا کسی مخصوص ہدف کے اندر مقامی طور پر متعین کیا جا سکتا ہے۔ عالمی pods پروجیکٹ کے تمام ہدف سے منسلک ہوتے ہیں، جو لاگنگ کے لیے CocoaLumberjack جیسی عام مقصد کی لائبریریوں کے لیے آسان ہے۔ مقامی انحصار ٹیسٹ فریم ورک اور پروڈکشن کوڈ کو الگ کرنے کے لیے مفید ہیں: ٹیسٹ کے لیے Quick اور Nimble، تجزیہ کے لیے Firebase، ڈیٹا اسٹوریج کے لیے Realm۔

# تمام ہدف کے لیے عالمی انحصار
pod 'CocoaLumberjack'

target 'MyApp' do
  # مرکزی ایپ کے مقامی انحصار
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Analytics'
  pod 'RealmSwift'
end

target 'MyAppTests' do
  # ٹیسٹ فریم ورک ریلیز میں شامل نہیں ہوں گے
  pod 'Quick'
  pod 'Nimble'
end

انحصار ورژن کا انتظام

CocoaPods موازنہ آپریٹرز کے ذریعے لچکدار ورژن متعین کرنے کی حمایت کرتا ہے۔ یہ اپ ڈیٹس کو کنٹرول کرنے اور غیر مطابقت پذیر API تبدیلیوں سے بچنے کی اجازت دیتا ہے۔ صحیح آپریٹر کا انتخاب پروجیکٹ کے استحکام کے لیے اہم ہے: بہت سخت پابندیاں بگ فکس کے ساتھ اپ ڈیٹس کو روکتی ہیں، جبکہ بہت ڈھیلی پابندیاں بڑی اپ ڈیٹس سے غیر متوقع خرابی کا سبب بن سکتی ہیں۔

مطابق اپ ڈیٹس کے لیے ~> آپریٹر استعمال کرنے کی سفارش کی جاتی ہے۔ یہ بڑی API تبدیلیوں سے بچاتا ہے جبکہ پیچ اور چھوٹی بہتریوں کی اجازت دیتا ہے۔ مثال کے طور پر، ~> 5.8 ورژن 5.8.0، 5.8.1، 5.9.0 کی اجازت دیتا ہے، لیکن 6.0.0 کو روکتا ہے جس میں اہم API تبدیلیاں ہو سکتی ہیں۔

Podfile.lock فائل عین ورژن مقفل کرتی ہے اور اسے ورژن کنٹرول سسٹم میں محفوظ کیا جانا چاہیے۔ pod update کمانڈ انحصار کو اجازت یافتہ تازہ ترین ورژن میں اپ ڈیٹ کرتا ہے اور لاک فائل کو دوبارہ لکھتا ہے، جبکہ pod install ایک جیسی بلڈ کی ضمانت کے لیے Podfile.lock سے پہلے سے مقفل شدہ ورژن استعمال کرتا ہے۔

ترقی اور پروڈکشن کی ترتیبات

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

target 'MyApp' do
  # صرف Debug کے لیے: لنٹر اور ڈیبگنگ
  pod 'SwiftLint', :configurations => ['Debug']
  # پروڈکشن: تجزیہ اور نگرانی
  pod 'Fabric'
  pod 'TestFairy', :configurations => ['Release']
end

inhibit_all_warnings! ہدایت تمام pods سے انتباہات کو دباتی ہے۔ یہ بڑے پروجیکٹس کے لیے مفید ہے جہاں تیسری پارٹی کی لائبریریاں بلڈ لاگز میں بہت زیادہ شور پیدا کرتی ہیں، جس سے اپنے انتباہات اور خرابیاں ڈھونڈنا مشکل ہو جاتا ہے۔ انتخابی انتباہ دبانے کے لیے، کسی مخصوص pod پر inhibit_warnings استعمال کیا جا سکتا ہے۔

صرف ترقی کے دوران استعمال ہونے والی لائبریریوں کو Debug ترتیبات کے ذریعے الگ کیا جانا چاہیے۔ SwiftLint، OHHTTPStubs، RevealServer اور اسی طرح کے ٹولز پروڈکشن بلڈ میں دستیاب نہیں ہونے چاہئیں۔ یہ نہ صرف IPA سائز کم کرتا ہے بلکہ ایپ کے ریلیز ورژن میں ڈیبگنگ معلومات کے حادثاتی افشاء کو بھی روکتا ہے۔ ضرورت کے بغیر Release میں چھوڑا گیا ہر pod شروع ہونے کے وقت اور میموری کی کھپت کو بڑھاتا ہے۔ مزید برآں، CocoaPods abstract_target ہدایت کی حمایت کرتا ہے، جو جسمانی بلڈ ہدف بنائے بغیر مشترکہ انحصار کو گروپ کرتی ہے۔

ماڈیولر فن تعمیر والے بڑے پروجیکٹس کے لیے، ملٹی ٹارگٹ Podfile ساخت استعمال کرنے کی سفارش کی جاتی ہے: ایپ کا ہر ماڈیول انحصار کے الگ تھلگ سیٹ کے ساتھ اپنا ہدف حاصل کرتا ہے۔ یہ بڑھتی ہوئی بلڈ کو تیز کرتا ہے کیونکہ ایک ماڈیول تبدیل کرنے پر صرف اس کے انحصار دوبارہ بنتے ہیں۔ CocoaPods خود بخود ہدف کے درمیان اوورلیپنگ انحصار کو حل کرتا ہے، اس بات کو یقینی بناتا ہے کہ ہر لائبریری پروجیکٹ کے تمام ماڈیولز میں ایک ہی ورژن میں انسٹال ہو۔

پوسٹ انسٹال ہکس اور اضافی خصوصیات

post_install ہک تمام pods انسٹال ہونے کے بعد عمل میں آتا ہے۔ یہ پروگرام کے ذریعے Xcode پروجیکٹ کی ترتیبات تبدیل کرنے کی اجازت دیتا ہے، جیسے انفرادی ہدف کے لیے کم سے کم iOS ورژن سیٹ کرنا، بلڈ مراحل شامل کرنا یا لائبریری info plists میں ترمیم کرنا۔ یہ ایک طاقتور تخصیصی طریقہ کار ہے جس کے بغیر کچھ تیسری پارٹی کی لائبریریاں صحیح طریقے سے ترتیب نہیں دی جا سکتیں۔

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # تمام pods کے لیے کم سے کم ورژن لازمی طور پر سیٹ کریں
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '15.0'
    end
  end
end

use_frameworks! ہدایت جامد لائبریریوں کے بجائے متحرک فریم ورک کو فعال کرتی ہے۔ Swift رن ٹائم کو متحرک لنکنگ کی ضرورت ہوتی ہے، لہذا یہ Swift پروجیکٹس اور Swift میں لکھی لائبریریوں کے لیے لازمی پیرامیٹر ہے۔ تاہم، Objective-C پروجیکٹس کے لیے جامد فریم ورک بنانے کے لیے use_frameworks! :linkage => :static استعمال کیا جا سکتا ہے، جو ایپ شروع ہونے کے وقت اور بنڈل سائز کو کم کرتا ہے۔

انسٹالر میں static_frameworks پرچم جامد فریم ورک بنانے کی اجازت دیتا ہے، ایپ لانچ کے وقت کو کم کرتا ہے۔ static اور dynamic کے درمیان انتخاب پروجیکٹ کے فن تعمیر پر منحصر ہے: متحرک فریم ورک لوڈ ہونے میں زیادہ وقت لیتے ہیں لیکن سسٹم کو عمل کے درمیان میموری بانٹنے دیتے ہیں۔ جامد فریم ورک زیادہ کمپیکٹ ہوتے ہیں، لیکن ہر کاپی ہر عمل میں علیحدہ میموری گھیرتی ہے۔

post_install کے علاوہ، Podfile pre_install ہک کو سپورٹ کرتا ہے، جو pod انسٹالیشن سے پہلے عمل میں آتا ہے۔ یہ انضمام سے پہلے podspecs میں ترمیم کرنے کے لیے مفید ہے، مثال کے طور پر پیچ کے ذریعے لائبریری سورس کوڈ تبدیل کرنا یا مخصوص کمپائلر فلیگز ترتیب دینا۔ ہکس Podfile کو صرف انحصار کی فہرست نہیں بلکہ ایک مکمل ترتیبی اسکرپٹ بناتے ہیں جو بلڈ عمل کو خودکار کرتا ہے۔

source ہدایت CocoaPods Specs ذخیرے کا URL بتاتی ہے۔ ڈیفالٹ طور پر سرکاری ذخیرہ https://github.com/CocoaPods/Specs.git استعمال ہوتا ہے، لیکن نجی لائبریریوں والے پروجیکٹس کے لیے اپنا نجی Specs ذخیرہ شامل کیا جا سکتا ہے۔ متعدد source ہدایات ایک Podfile میں عوامی اور نجی podspecs کو یکجا کرنے کی اجازت دیتی ہیں۔ source کی ترتیب اہم ہے: CocoaPods مخصوص ترتیب میں pods تلاش کرتا ہے اور پہلی ملنے والی مثال استعمال کرتا ہے، جو عوامی لائبریریوں کو نجی ورژن سے اوور رائڈ کرنے کی اجازت دیتا ہے۔