Podfile: چیست، syntax و پیکربندی کتابخانه‌ها از طریق CocoaPods

Podfile چیست و به چه دردی می‌خورد

Podfile یک اسکریپت اعلانی به زبان Ruby است که وابستگی‌های خارجی پروژه iOS، macOS، tvOS یا watchOS در آن فهرست می‌شوند. این فایل در دایرکتوری ریشه پروژه قرار دارد و به عنوان تنها نقطه پیکربندی مدیر بسته CocoaPods عمل می‌کند. بدون Podfile، توسعه‌دهندگان مجبور بودند کتابخانه‌ها را به صورت دستی دانلود کرده، در پروژه کپی کرده و پرچم‌های linker را در Xcode تنظیم کنند.

CocoaPods Podfile را تجزیه و تحلیل کرده و یک فایل بسته Podfile.lock ایجاد می‌کند که نسخه‌های دقیق کتابخانه‌های نصب شده را ثابت می‌کند. این کار تکرارپذیری ساخت را در همه ماشین‌های تیم توسعه تضمین می‌کند: اگر یک توسعه‌دهنده Alamofire را به نسخه ۵.۹ به‌روزرسانی کند، Podfile.lock این تغییر را ثبت می‌کند و بقیه با اجرای podinstall دقیقاً همان نسخه را دریافت می‌کنند. بدون این مکانیزم، توسعه‌دهندگان مختلف ممکن است نسخه‌های متفاوتی از وابستگی‌ها داشته باشند که منجر به باگ‌های سخت‌یاب می‌شود.

Podfile سه وظیفه اصلی را حل می‌کند: مدیریت وابستگی‌ها با کنترل نسخه، پیکربندی پلتفرم هدف با حداقل نسخه سیستم‌عامل و یکپارچه‌سازی خودکار کتابخانه‌ها از طریق Xcode Workspace. CocoaPods در هر نصب، فایل Pods.xcodeproj را تولید می‌کند که از طریق workspace به پروژه اصلی متصل می‌شود. توسعه‌دهنده نیازی به فکر کردن درباره نحوه اتصال کتابخانه‌ها ندارد — کافی است آنها را در Podfile مشخص کند.

syntax و ساختار Podfile

Podfile از syntax Ruby استفاده می‌کند، اما به دانش حداقلی از زبان نیاز دارد. ساختار پایه شامل دستوراتی است که پلتفرم، اهداف ساخت و لیست وابستگی‌ها را تعیین می‌کنند. هر دستور در بافت مفسر Ruby اجرا می‌شود، بنابراین Podfile از ساختارهای شرطی، حلقه‌ها و متغیرها برای پیکربندی‌های پیچیده پشتیبانی می‌کند.

بلوک target

هر هدف ساخت برنامه در داخل بلوک target توصیف می‌شود. برای یک پروژه استاندارد Xcode، این معمولاً یک هدف با نام برنامه است. targetهای تو در تو می‌توانند برای تست‌های واحد، تست‌های UI و افزونه‌ها استفاده شوند. توصیه می‌شود وابستگی‌های targetهای مختلف ایزوله شوند: کتابخانه‌های اصلی در target اصلی، فریمورک‌های تستی در target تستی تا از ورود وابستگی‌های اضافی به نسخه تولید جلوگیری شود.

# نمونه حداقلی Podfile برای پروژه iOS
target 'MyApp' do
  use_frameworks!
  pod 'Alamofire', '~> 5.8'
  pod 'Kingfisher', '~> 7.10'
  pod 'SnapKit', '~> 5.6'
end

دستورات پلتفرم

دستور platform حداقل نسخه سیستم‌عامل را که پروژه برای آن ساخته می‌شود تعیین می‌کند. این یک پارامتر اجباری است که بر سازگاری کتابخانه‌ها تأثیر می‌گذارد. کتابخانه‌ها در CocoaPods معمولاً حداقل نسخه سیستم‌عامل خود را در podspec مشخص می‌کنند و اگر پلتفرم پروژه پایین‌تر از حد نیاز باشد، pod install خطا می‌دهد. برای پروژه‌های iOS، حداقل نسخه معمولاً ۱۵.۰ و بالاتر و برای macOS ۱۲.۰ و بالاتر است.

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

وابستگی‌های سراسری و محلی

وابستگی‌ها را می‌توان به صورت سراسری خارج از بلوک‌های target یا به صورت محلی در داخل یک هدف خاص مشخص کرد. podهای سراسری به همه اهداف پروژه متصل می‌شوند که برای کتابخانه‌های عمومی مانند 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 محافظت می‌کند و در عین حال امکان دریافت patchها و بهبودهای جزئی را فراهم می‌کند. برای مثال، ~> ۵.۸ نسخه‌های ۵.۸.۰، ۵.۸.۱، ۵.۹.۰ را مجاز می‌کند اما ۶.۰.۰ را که ممکن است تغییرات بحرانی API داشته باشد مسدود می‌کند.

فایل Podfile.lock نسخه‌های دقیق را ثابت می‌کند و باید در سیستم کنترل نسخه ذخیره شود. دستور pod update وابستگی‌ها را به آخرین نسخه‌های مجاز به‌روزرسانی کرده و فایل lock را بازنویسی می‌کند، در حالی که pod install از نسخه‌های قبلاً ثابت شده در Podfile.lock برای تضمین یکسانی ساخت‌ها استفاده می‌کند.

پیکربندی‌های توسعه و تولید

Podfile از تفکیک پیکربندی‌ها از طریق دستورات برای طرح‌های ساخت مختلف پشتیبانی می‌کند. می‌توان مجموعه کتابخانه‌های متفاوتی را برای Debug و Release متصل کرد که اندازه بیلد تولید را به میزان قابل توجهی کاهش داده و کامپایل آن را سرعت می‌بخشد. linterها، تولیدکنندگان کد و ابزارهای اشکال‌زدایی باید فقط در پیکربندی Debug کار کنند.

target 'MyApp' do
  # فقط برای Debug: linter و اشکال‌زدایی
  pod 'SwiftLint', :configurations => ['Debug']
  # تولید: تحلیل و نظارت
  pod 'Fabric'
  pod 'TestFairy', :configurations => ['Release']
end

دستور inhibit_all_warnings! هشدارهای همه podها را غیرفعال می‌کند. این در پروژه‌های بزرگ مفید است، جایی که کتابخانه‌های شخص ثالث نویز زیادی در لاگ‌های ساخت ایجاد کرده و یافتن هشدارها و خطاهای خودی را دشوار می‌کنند. برای غیرفعال‌سازی انتخابی می‌توان از inhibit_warnings روی یک pod خاص استفاده کرد.

توصیه می‌شود کتابخانه‌هایی که فقط در مرحله توسعه استفاده می‌شوند از طریق پیکربندی‌های Debug ایزوله شوند. SwiftLint، OHHTTPStubs، RevealServer و ابزارهای مشابه باید در نسخه تولید غیرقابل دسترس باشند. این کار نه تنها اندازه IPA را کاهش می‌دهد، بلکه افشای تصادفی اطلاعات اشکال‌زدایی در نسخه منتشر شده برنامه را نیز حذف می‌کند. هر pod باقی مانده در Release بدون نیاز، زمان راه‌اندازی و مصرف حافظه را افزایش می‌دهد. علاوه بر این، CocoaPods از دستور abstract_target پشتیبانی می‌کند که وابستگی‌های مشترک را بدون ایجاد هدف فیزیکی ساخت گروه‌بندی می‌کند.

برای پروژه‌های بزرگ با معماری ماژولار، توصیه می‌شود از ساختار چندtargetی Podfile استفاده کنید: هر ماژول برنامه target خود را با مجموعه وابستگی‌های ایزوله دریافت می‌کند. این کار ساخت افزایشی را سرعت می‌بخشد، زیرا با تغییر یک ماژول، فقط وابستگی‌های آن بازسازی می‌شوند. CocoaPods به طور خودکار وابستگی‌های متقاطع بین targetها را حل کرده و تضمین می‌کند که هر کتابخانه در یک نسخه واحد برای همه ماژول‌های پروژه نصب می‌شود.

هوک‌های پس از نصب و قابلیت‌های اضافی

هوک post_install پس از نصب همه podها اجرا می‌شود. این هوک امکان تغییر برنامه‌ریزی شده تنظیمات پروژه Xcode را فراهم می‌کند، به عنوان مثال پیکربندی حداقل نسخه iOS برای targetهای جداگانه، اضافه کردن فازهای ساخت یا تغییر infoplist کتابخانه‌ها. این یک مکانیزم قدرتمند سفارشی‌سازی است که بدون آن برخی کتابخانه‌های شخص ثالث نمی‌توانند به درستی پیکربندی شوند.

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # اجباری تعیین حداقل نسخه برای همه podها
      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ها اجرا می‌شود. این هوک برای تغییر podspec قبل از یکپارچه‌سازی مفید است، برای مثال برای تغییر کد منبع کتابخانه‌ها از طریق patchها یا برای تنظیم پرچم‌های خاص کامپایلر. هوک‌ها Podfile را نه تنها به یک لیست وابستگی، بلکه به یک اسکریپت پیکربندی کامل تبدیل می‌کنند که فرآیند ساخت را خودکار می‌کند.

دستور source URL مخزن CocoaPods Specs را مشخص می‌کند. به طور پیش‌فرض از مخزن رسمی https://github.com/CocoaPods/Specs.git استفاده می‌شود، اما برای پروژه‌های با کتابخانه‌های خصوصی می‌توان مخزن Specs خصوصی خود را اضافه کرد. sourceهای متعدد امکان ترکیب podspecهای عمومی و خصوصی را در یک Podfile فراهم می‌کنند. ترتیب source مهم است: CocoaPods podها را به ترتیب مشخص شده جستجو کرده و از اولین نمونه یافت شده استفاده می‌کند که امکان بازنویسی کتابخانه‌های عمومی با نسخه‌های خصوصی را فراهم می‌کند.