Swift and Objective‑C Interoperability: Moduleization and Mixed‑Language Integration Practices at 58.com

In March 2019 Apple released Swift 5.0 with ABI stability, encouraging developers to move from Objective‑C to Swift. By 2020 Apple introduced Swift‑centric SDKs such as SwiftUI and Combine, prompting many Chinese internet companies, including 58.com, to accelerate pure‑Swift ecosystem construction.

58.com launched the "Mixed‑Heaven" project at the end of 2020 to provide a Swift‑friendly development environment, including base components, debugging tools, coding standards, and mixed‑language infrastructure. The project aims to reduce Apple review risk, lower development costs, and improve business efficiency (e.g., 30% crash‑rate reduction, 20‑30% code‑size reduction).

The core of the effort is SDK module‑ization to enable Swift code to call Objective‑C libraries. Two main approaches are used: creating a bridging header that imports required Objective‑C headers, and leveraging Clang’s module system to generate a modulemap describing the SDK’s public interface. Example modulemap content:

frameworkmodule SwiftFramework { umbrella header "SwiftFramework.h" export * module * { export * } }

For static or dynamic libraries that lack module support, a module.modulemap file is added to the project and copied via the Build Phase. The article also explains how to enable the "Defines Module" build setting in Xcode and how to create a framework that automatically generates the module file.

When bridging Objective‑C APIs, nullability annotations ( _Nullable , _Nonnull ) are added to header files to give Swift accurate optionality information. Example:

NS_ASSUME_NONNULL_BEGIN @interface AAPLList : NSObject <NSCoding, NSCopying> @property (copy, nullable) NSString *name; - (nullable AAPLListItem *)itemWithName:(NSString *)name; NS_ASSUME_NONNULL_END

Macros used in Objective‑C cannot be directly accessed from Swift. The article proposes three strategies: replace simple macros with Swift constants, translate simple macro expressions into Swift code, and wrap complex macros in Swift functions or Objective‑C methods. Example of converting a color macro:

public func hexColor(_ value: UInt64) -> UIColor { let red = CGFloat((value & 0xFF0000) >> 16) / 255.0 let green = CGFloat((value & 0x00FF00) >> 8) / 255.0 let blue = CGFloat(value & 0x0000FF) / 255.0 return UIColor(red: red, green: green, blue: blue, alpha: 1.0) }

Since Swift no longer supports the +load method, three alternatives are presented: (1) runtime class‑list traversal to invoke a custom launch_load method on classes conforming to a protocol, (2) a centralized launch‑configuration object that manually registers load actions, and (3) using @objc to expose Swift classes to Objective‑C and invoke load‑like behavior via a generated Objective‑C category. Example of the first approach:

protocol LaunchLoad { static func launch_load() } class TestA: NSObject, LaunchLoad { static func launch_load() { print("TestA loaded") } } class LaunchConfig { static func do_load() { let count = Int(objc_getClassList(nil, 0)) ... } }

The article concludes with performance measurements showing that module‑based builds with Header Maps reduce compilation time by about 36% compared to non‑module builds. Future work includes defining Objective‑C to Swift coding guidelines, creating a tool to automatically translate Objective‑C code to Swift, and further expanding module‑ization across the company’s SDK portfolio.