Why Not to Use Swift for Business Logic in Componentized Projects

This article discusses the challenges of using Swift in componentized iOS projects. It begins by comparing static library dependencies in C/C++ and Objective-C, explaining that Objective-C's non-fragile runtime and dynamic dispatch make it more resilient to binary compatibility issues compared to Swift's static and dynamic dispatch mechanisms.

The author then outlines two main problems with using Swift in componentized projects: (1) ABI incompatibility issues that can cause binary compatibility problems when libraries are updated, and (2) performance issues caused by having too many dynamic libraries loaded at app startup. When using CocoaPods with use_framework!, all libraries become dynamic frameworks, which can lead to slow app startup times as the number of components grows.

The article proposes a solution for companies with mixed Swift/Objective-C projects: selectively convert only Swift-containing components to dynamic libraries while keeping other components as static libraries integrated into the main binary. This approach balances development convenience with app performance.

The author provides practical implementation details, including how to configure Podfile to handle Swift dependencies without requiring use_framework!, and explains why adding an empty Swift file to the main project is necessary to ensure Swift runtime libraries are included in the app bundle.

The article concludes by acknowledging that while the solution works, it's not perfect since it still requires manual steps, and the author suggests potential automation through Ruby scripting in Podfile to modify Xcode project configurations automatically.