Mastering Swift‑Objective‑C Interop: Mixing, Modules, and Runtime Hacks

Background Introduction

Swift has become the primary language for iOS and the entire Apple ecosystem. A‑Station’s first part introduced Swift’s background, architecture evolution, and the selection of SwiftUI and Combine. This second part continues with mixed compilation and dynamic features.

How to Mix Swift and Objective‑C

Mixed compilation generates Swift declarations from Objective‑C headers so Swift can call OC APIs directly, and vice‑versa. Xcode integrates the necessary tools (Clang, ld, etc.). To enable mixing in the same project, set Always Embed Swift Standard Libraries to YES and import the required OC classes in the bridging header. For cross‑project mixing, enable Defines Module and import the OC module’s umbrella header.

Preconditions

Configure CocoaPods correctly.

Understand why modules are needed.

Familiarize with name mangling.

Know why Swift can call OC interfaces.

How to Set Up CocoaPods for Mixed Projects

In the podspec, declare dependencies on OC pods. In the Podfile add :modular_headers => true to turn the pod into a module. Running pod install --verbose shows the generation of the module map and umbrella header.

Key CocoaPods Settings

Set Defines Module to YES .

Provide a Module Map File path.

Configure Header Search Paths for the module map.

Set Product Module Name (defaults to target name).

Configure Framework Search Paths , Other C Flags , and Other Swift Flags as needed.

Why Use Modules?

Modules replace the traditional pre‑processor approach, parsing each header only once and storing a binary representation in the module cache. This dramatically reduces compilation complexity and time. When a module changes, only the affected headers are re‑parsed.

<code>#import &lt;FMDB/FMDatabase.h&gt;</code>

The FMDB framework’s module.modulemap declares the umbrella header, allowing Clang to treat FMDatabase.h as a module.

Name Mangling

Swift’s name mangling converts OC symbols into Swift‑friendly names, preventing conflicts and providing Swift‑style APIs. Developers can override the generated names with NS_SWIFT_NAME .

<code>public func int2string(number: Int) -> String {</code><code>    return "\(number)"</code><code>}</code>

Compiled with nm -g , the symbol appears as _$s8demotest10int2string6numberSSSi_tF , encoding module, function, parameter, and return types.

Why Can Swift Call OC Interfaces?

Xcode generates a Swift interface from OC headers (Generated Interface). Types like NSString become String , and initializers map to Swift constructors. Developers can improve ergonomics by using OC generics, converting NSArray to Swift arrays, and applying macros such as NS_ASSUME_NONNULL_BEGIN , NS_DESIGNATED_INITIALIZER , and NS_SWIFT_NAME .

Dynamic Features in Swift

Swift’s runtime does not expose a public dynamic dispatch API, but developers can use @objc dynamic to enable Objective‑C style messaging, or employ low‑level techniques like mach_override , InterposeKit , and SwiftHook to replace method implementations at runtime.

<code>import UIKit</code><code>import FMDB</code><code>class SwiftTestClass: NSObject {</code><code>    var db: FMDB.FMDatabase?</code><code>    override init() {</code><code>        super.init()</code><code>        self.db = FMDB.FMDatabase(path: "dbname")</code><code>        print("init ok")</code><code>    }</code><code>}</code>

Modules must also be built as modules for Swift to import them; otherwise, the import will fail.

Value‑Type Method Replacement

Using imp_implementationWithBlock and class_addMethod , developers can add Objective‑C methods to Swift structs or enums, enabling dynamic dispatch on value types.

<code>struct structWithDynamic {</code><code>    public var str: String</code><code>    public func show(_ str: String) -> String {</code><code>        print("Say \(str)")</code><code>        return str</code><code>    }</code><code>    internal func showDynamic(_ obj: AnyObject, str: String) -> String {</code><code>        return show(str)</code><code>    }</code><code>}</code><code>let structValue = structWithDynamic(str: "Hi!")</code><code>let block: @convention(block)(AnyObject, String) -> String = structValue.showDynamic</code><code>let imp = imp_implementationWithBlock(unsafeBitCast(block, to: AnyObject.self))</code><code>let dycls: AnyClass = object_getClass(structValue)!</code><code>class_addMethod(dycls, NSSelectorFromString("objcShow:"), imp, "@24@0:8@16")</code><code>_ = (structValue as AnyObject).perform(NSSelectorFromString("objcShow:"), with: "Bye!")!</code>

Class Method Replacement

Using class_replaceMethod with an imp generated from a block allows swapping implementations of existing class methods. Projects such as InterposeKit and SwiftHook provide higher‑level APIs for this.

Instrumentation (插桩)

By compiling with DYLD_INSERT_LIBRARIES and leveraging SwiftSyntax to inject replacement logic, developers can modify Swift source during compilation and produce a new binary that overrides selected methods.

ClassContextDescriptorBuilder

The Swift compiler builds metadata for each type. ClassContextDescriptorBuilder extends TypeContextDescriptorBuilderBase to generate class layout, v‑table, and override tables. The generated metadata includes flags, parent references, names, access functions, and reflection fields.

<code>struct SwiftClassInfo {</code><code>    uint32_t flag;</code><code>    uint32_t parent;</code><code>    int32_t name;</code><code>    int32_t accessFunction;</code><code>    int32_t reflectionFieldDescriptor;</code><code>    ...</code><code>    uint32_t vtable;</code><code>    uint32_t overrideTable;</code><code>    ...</code><code>};</code>

Summary

A‑Station’s journey shows how embracing Swift required extensive mixed‑compilation engineering, module‑based architecture, and binary distribution (XCFramework). Despite challenges such as runtime limitations and occasional bugs, the team achieved a smoother development experience, faster builds, and a higher adoption of Swift across the organization.