Swift, Frameworks & Modules, Learnings from CocoaPods
summary
Migration of CocoaPods from static libraries to dynamic frameworks to support Swift requires changing Podfile to use frameworks, running cocoapods-deintegrate, and adding a shell build-phase that embeds and signs frameworks plus a resources copy script. The team uses Xcode, Clang, Lipo and Clang modules; they hit code‑signing bugs and platform weirdness with configuration‑dependent pods. A complex app with 60 pods took about a week to migrate and then suffered severe launch‑time stalls (watchdog kills), so some apps revert to static libs or a hybrid approach.
AI-written summary · about
chapters (16)
- 0:00CocoaPods Frameworks intro
- 1:59What is CocoaPods
- 3:46Static libraries history
- 8:29Static libs in CocoaPods
- 13:55Dynamic frameworks structure
- 21:37Advantages and disadvantages of frameworks
- 23:27Frameworks challenges
- 25:37Migrating to frameworks
- 31:44Avoiding frameworks
- 32:29Contributing to CocoaPods
- 32:53CocoaPods vs Carthage
- 34:42App launch times impact
- 36:08Testing with App Store
- 38:20Pods in version control
- 41:58Future CocoaPods ideas
- 44:48Q&A
related talks
30mFrom CocoaPods to Swift Package Manager
36mSummit Session 1 - Adding support for Swift Package Manager
54mCocoaPods, the Objective-c Dependency Manager we've been Waiting for
37mCut costs, not corners: Master modularization with SPM
30mA Micro-services perspective on iOS architecture
47mBuilding and Integrating Frameworks
45mTooling in Swift - Xcode Integration & CI
38mTARGET VS COCOAPODS: why choose one if you can have BOTH?