Adopting Swift: Migrating to Frameworks on iOS
Article Summary
Felipe Cypriano from Thumbtack reveals how migrating iOS apps to frameworks nearly derailed their Swift adoption—until they discovered a clever workaround for binary dependencies.
Thumbtack's iOS team needed to migrate from static libraries to frameworks to enable Swift in their shared codebase. What seemed like a simple CocoaPods configuration change turned into a deep dive through build errors, runtime crashes, and dependency conflicts with Crashlytics and Google Maps.
Key Takeaways
- Binary dependencies like Crashlytics blocked framework migration as transitive dependencies
- Created adapter layer to isolate static binaries from shared code
- Asset catalogs in bundles fail outside main bundle with frameworks
- Module names must be valid c99ext identifiers, breaking imports with special characters
Thumbtack successfully migrated to frameworks by creating adapters for binary dependencies and moving images out of asset catalogs, finally enabling Swift across their shared iOS codebase.
About This Article
Thumbtack's two iOS apps, one for consumers and one for pros, ran into duplicate symbol errors. The issue happened because test target dependencies relied on app target dependencies, which is a constraint specific to static libraries that made it hard to organize the code properly.
Felipe Cypriano's team made incremental changes in small chunks and tested each one carefully. When they hit nonsensical build errors, they used `pod deintegrate` followed by `pod install` to regenerate CocoaPods references.
The migration let Thumbtack use Swift as their primary iOS language. They built a modular architecture where each library lives in its own module instead of being compiled into a single binary.