Mixing Swift and Objective‑C in iOS Projects: Module System, CocoaPods, and Best Practices

With the release of Xcode 11 and Swift 5.1, Swift has achieved ABI stability and module stability, making its syntax and implementation more mature. The article shares practical experiences of mixing Swift and Objective‑C in the micro‑mall and retail business lines, especially when using CocoaPods for modular development.

1. Current mixing approaches

There are two common ways to mix Swift and Objective‑C within the same project:

Use a bridging header (Bridging-Header.h) in the host project: Swift can access Objective‑C classes by importing them in the bridging header. Objective‑C can access Swift code by importing ProductName-Swift.h in the Objective‑C files.

Use CocoaPods to manage second‑/third‑party libraries as development pods, placing Swift code inside those pods and letting the module system handle the inter‑language references.

Because many business modules (e.g., product, message, asset) are already managed by CocoaPods, the team prefers the second method, keeping business code inside dedicated pods.

2. LLVM Module System

Apple introduced the LLVM Module system in November 2012. It replaces the traditional #include hierarchy with a tree‑structured description, e.g., #include becomes import std.io . This provides:

Complete semantic description of a framework’s purpose.

Improved compile‑time scalability (each module compiled/imported only once).

Reduced fragmentation and consistent behavior across environments.

3. modulemap file

The modulemap file (default name module.modulemap ) gives a structured description of all files in a framework or library. It is essential for the LLVM module system and is referenced in the Clang documentation.

4. Swift Module

SwiftModule generates a corresponding modulemap and umbrella.h for a Swift target. The generated artifacts depend on the Swift compiler version. To enable mutual access between Swift and Objective‑C, an Objective‑C library must provide an umbrella.h and a modulemap . Dynamic frameworks let Xcode generate these automatically; static libraries require manual creation.

5. Architecture adjustment for the micro‑mall

The team plans to replace the previous sub‑project structure with a shell project and development pods (CocoaPods) that share the same Git repository. Dependencies are managed via podspec and Podfile . This approach supports long‑term evolution without disrupting ongoing development.

6. Second‑party library mixing challenges

Framework targets do not support Bridging‑Header : Mixing must rely on Swift modules instead of bridging headers.

Namespace conflicts : Importing Objective‑C libraries requires a distinct namespace to avoid file‑not‑found errors.

C++ mixing : Objective‑C++ files (.mm) can contain both Objective‑C and C++ code; for libraries like WCDB, header extensions from .h to .mm are needed.

Linking errors : Missing Swift system libraries in the host project can cause link failures; adding a dummy Swift file resolves this.

Swift calling Objective‑C : Use import xxx in Swift files to reference Objective‑C pods.

Objective‑C calling Swift : Mark Swift classes as public . Annotate exposed methods with @objc . Import ProductName-Swift.h in Objective‑C files.

pod spec lint and publishing : Add --use-modular-headers to lint and push commands, otherwise validation fails.

7. Advantages

The number of binary Swift libraries is growing (over 141 by iOS 13), and many system classes in Foundation are now Swift‑implemented.

ABI stability (iOS 12.2+) does not increase app size.

Using use_modular_headers! in CocoaPods builds Swift static libraries without impacting launch performance.

8. Conclusion

The micro‑mall project has already adopted mixed‑language development for several modules. New modules will be written in Swift, while legacy modules remain in Objective‑C, gradually transitioning via mixed compilation. This article provides a reference for developers planning similar mixed‑language strategies.