DEV Community: phoenix

How to Gracefully Use OC +load Timing in Swift

phoenix — Fri, 09 May 2025 14:37:32 +0000

In the world of Objective-C, the +load method is a special existence. It executes when a class is added to the Objective-C runtime, even before the main function. This makes +load a powerful tool in specific scenarios, such as performing some global initializations, registration logic, or Method Swizzling. Developers can leverage this timing to "silently" complete some necessary work at the very early stages of application startup.

However, as Swift becomes the mainstream language for Apple ecosystem development, we find that Swift itself does not directly provide a mechanism completely equivalent to Objective-C's +load. This poses some challenges for developers accustomed to the convenience of +load or when migrating old code that relies on +load functionality to Swift. How can we "gracefully" regain this capability in Swift?

Introducing! Rhea - Unlocking `+load` Timing in Swift

This is where our protagonist—Rhea(https://github.com/reers/Rhea) —comes into play!

Rhea is a lightweight open-source Swift library that cleverly utilizes Swift's latest Macro feature, allowing us to concisely and intuitively register code blocks in Swift code that need to be executed at specific timings (including simulating Objective-C +load timing).

Imagine, you just need to write:

import Rhea

#load {
    // This code will execute at a timing similar to OC +load
    print("Swift code executed via Rhea at load timing!")
    // Perform your early initialization, module registration, etc., here
}

// Rhea also supports other preset timings, such as premain and appDidFinishLaunching
#premain {
    print("Swift code executed via Rhea at premain timing!")
}

#appDidFinishLaunching { context in
    print("Swift code executed via Rhea at appDidFinishLaunching timing!")
    if let launchOptions = context as? [UIApplication.LaunchOptionsKey: Any] {
        // Handle launch options
    }
}

You can even define custom event timings:

extension RheaEvent {
    static let myCustomEvent: RheaEvent = "myCustomEvent"
}

#rhea(time: .myCustomEvent, priority: .normal) { _ in
    print("Custom event myCustomEvent was triggered!")
}
// Trigger the custom event at the appropriate time
Rhea.trigger(.myCustomEvent)

You can also use the async parameter for callback on a background thread:

#rhea(time: .homePageDidAppear, async: true, func: { context in
    // This will be called back on a background thread
    print("~~~~ homepageDidAppear")
})

Even in XCode 16 and above, you can nest it within types, just like the load method in the OC era:

class ViewController: UIViewController {

    #load {
        print("~~~~ load nested in main")
    }

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
    }
}

Through the #load macro provided by Rhea (as well as #premain, #appDidFinishLaunching, etc.), you can very "Swiftly" arrange the logic that needs to be executed in the early stages of application startup. Rhea handles the underlying implementation details, allowing your codebase to maintain a pure Swift style while enjoying the convenience similar to +load. Moreover, it only requires import RheaTime without any other configuration or initialization. This undoubtedly provides an elegant solution for scenarios requiring modular automatic registration, early configuration, and so on.

Sounds great, doesn't it? Rhea makes goals that originally needed to be achieved through +load in Objective-C, or through some other complex techniques, readily accessible in Swift.

Wait, Is Using load Extensively in Swift Really "Graceful"?

Just as we are immersed in this "gracefulness" brought by Rhea, an important question emerges: should we really promote and use this +load timing code execution method extensively in Swift projects?

The answer is likely no.

Although Rhea provides the powerful capability to simulate +load timing in Swift, abusing this mechanism, even if implemented in Swift through such a clever library, is not truly the "graceful" way. On the contrary, it might bring some non-negligible negative impacts to your application, the most significant of which is slowing down the app's cold launch speed.

+load and Application Startup Time

Objective-C's +load method (and similar timings simulated by Rhea) has a notable characteristic: it is called before the main function executes. When an application starts, the dynamic linker (dyld) loads all dependent libraries and classes. During this process, if a class implements the +load method, that method will be executed.

This means:

Blocking the startup path: +load methods are executed synchronously. If the code in a +load method takes too long to execute, it will directly block the subsequent startup process, extending the time from when the user taps the App icon to when they see the first screen.
Cumulative effect: If a large number of classes in the project use +load (or register #load code blocks via Rhea), each will contribute a little bit to the startup time. When these times accumulate, the impact on cold launch performance becomes very significant. Users are very sensitive to slow-launching Apps.

Apple has also been emphasizing the importance of optimizing application startup time. In WWDC presentations, they have clearly pointed out that the time before the main function executes (Pre-main time) is one of the key stages affecting startup performance. This stage includes dylib loading, rebase/binding, ObjC setup, and initializers (including +load methods and C++ static constructors, etc.).

Simply put, the more you do at the +load timing, the slower your application will start.

Other Potential Issues

Besides the direct impact on startup performance, over-reliance on +load timing might also bring:

Environmental limitations: When +load executes, the complete application environment may not yet be ready. For example, some UIKit classes may not be available or may not behave as expected. Although Rhea itself works in a Swift environment, executing complex logic too early still requires caution.
Debugging difficulty: Code that executes very early in the startup chain, if problems occur, can sometimes be harder to trace and debug than code that runs after the application is normally running.
Risk of order dependency: Although the Objective-C Runtime has rules for the calling order of +load (superclass before subclass, class before category), in complex projects, implicit execution order dependencies can still cause problems. Rhea provides priority settings, which can alleviate this problem to some extent, but still require careful management by developers.

Conclusion: Use with Caution, Not Abuse

Rhea is a cleverly designed library that indeed provides Swift developers with an effective means to simulate Objective-C +load and other early timing execution of code in specific scenarios. For some lightweight initialization or registration tasks that truly need to be performed very early and cannot be achieved through other better methods, Rhea can be a good choice.

However, this does not mean we should make the +load pattern (even if implemented in Swift via Rhea) a common option in our regular arsenal.

True "gracefulness" is not just about being able to implement a certain function with some trick, but more about understanding the costs behind this function and making wise trade-offs.

For most initialization and configuration tasks, Swift provides more recommended and language-idiomatic ways:

Lazy Initialization: For objects that do not need to be used immediately, postpone their creation and initialization time.
AppDelegate / SceneDelegate: Perform application-level and UI-level configurations in application(_:didFinishLaunchingWithOptions:) or related SceneDelegate methods. This is the most common and recommended initialization timing.
Dependency Injection: Manage and pass dependencies through constructor injection, property injection, etc., rather than relying on global state or early automatic registration.
Static properties and global constants: For simple constants or type properties, their initialization is already efficient and safe enough.

Summary

In conclusion, the Rhea library opens a window for you to explore +load timing in Swift. But please remember, powerful tools need to be used prudently. Do not sacrifice your application's startup performance and the user's initial experience for the sake of some "magical" automatic execution. In most cases, choosing an initialization scheme that is more in line with Swift's design philosophy and friendlier to startup performance is the truly "graceful" way.

Codable Macros Make Swift Serialization So Simple!

phoenix — Thu, 08 May 2025 12:05:40 +0000

Codable Macros Make Swift Serialization So Simple!

Hello everyone! As Swift developers, we deal with data every day, and the conversion between JSON and models is undoubtedly a daily task. Apple provided us with the Codable protocol, which performs well in many situations, but as business logic becomes more complex, we often find ourselves stuck writing a lot of boilerplate code: manually defining CodingKeys, implementing init(from:) and encode(to:), handling nested structures, dealing with different naming styles, parsing various date formats... These tedious tasks are not only time-consuming but also error-prone.

Is there a more elegant and efficient way to handle Codable in Swift?

The answer is definitely yes! With Swift Macros introduced in Swift 5.9+, the possibilities for code generation have been greatly expanded. Today, I'm introducing a framework built on Swift Macros called ReerCodable!

ReerCodable (https://github.com/reers/ReerCodable) aims to completely simplify the Codable experience through declarative annotations, allowing you to say goodbye to tedious boilerplate code and focus on business logic itself.

Practical Application Example

Let's look at a practical example to see how ReerCodable simplifies development work. Suppose we have a complex API response:

{
  "code": 0,
  "data": {
    "user_info": {
      "user_name": "phoenix",
      "birth_date": "1990-01-01T00:00:00Z",
      "location": {
        "city": "Beijing",
        "country": "China"
      },
      "height_in_meters": 1.85,
      "is_vip": true,
      "tags": ["tech", null, "swift"],
      "last_login": 1731585275944
    }
  }
}

Using ReerCodable, we can define our model like this:

@Codable
struct ApiResponse {
    var code: Int

    @CodingKey("data.user_info")
    var userInfo: UserInfo
}

@Codable
@SnakeCase
struct UserInfo {
    var userName: String

    @DateCoding(.iso8601)
    var birthDate: Date

    @CodingKey("location.city")
    var city: String

    @CodingKey("location.country")
    var country: String

    @CustomCoding<Double>(
        decode: { return try $0.value(forKeys: "height_in_meters") * 100.0 },
        encode: { try $0.set($1 / 100.0, forKey: "height_in_meters") }
    )
    var heightInCentimeters: Double

    var isVip: Bool

    @CompactDecoding
    var tags: [String]

    @DateCoding(.millisecondsSince1970)
    var lastLogin: Date
}

// Usage
do {
    // The original way remains unchanged
    let resp = try JSONDecoder().decode(ApiResponse.self, from: jsonString.data(using: .utf8)!)
    // Convenient method provided by ReerCodable
    let response = try ApiResponse.decode(from: jsonString)
    print("Username: \(response.userInfo.userName)")
    print("Birth date: \(response.userInfo.birthDate)")
    print("Height(cm): \(response.userInfo.heightInCentimeters)")
} catch {
    print("Parsing failed: \(error)")
}

The "Pain" of Native Codable

Before we dive into the magic of ReerCodable, let's review the common pain points when using native Codable:

Manual CodingKeys: When JSON keys don't match property names, you need to manually write the CodingKeys enum. Even if you only modify one property, you have to write all other properties as well. This might be manageable with few properties, but becomes a nightmare once you have many.
Nested Keys: When dealing with deeply nested JSON data, you need to define multiple intermediate structures or manually write decoding logic.
Naming Style Conversion: Backend returns snake_case or kebab-case, while Swift recommends camelCase, requiring manual mapping.
Complex Decoding Logic: If you need custom decoding (type conversion, data fixing, etc.), you have to implement init(from:).
Default Value Handling: For non-Optional properties missing in JSON, an exception will be thrown even if a default value exists. Even Optional enums can fail decoding.
Ignoring Properties: Some properties don't need to participate in encoding/decoding, requiring manual handling in CodingKeys or implementations.
Various Date Formats: Timestamps, ISO8601, custom formats... require configuring different dateDecodingStrategy for JSONDecoder or manual handling.
null in Collections: When arrays or dictionaries contain null values, decoding fails if the corresponding type is non-Optional.
Inheritance: Parent class properties can't be automatically handled in the child class's Codable implementation.
Enum Handling: Enums with associated values or those needing to match multiple raw values have limited support in native Codable.

Community Status

To solve JSON serialization problems, the Swift community has produced many excellent third-party frameworks. Understanding their design philosophies and pros/cons helps us better understand why Swift Macros-based solutions are a better choice today.

1. Frameworks Based on Custom Protocols

ObjectMapper

ObjectMapper is one of the earliest Swift JSON parsing libraries, based on a custom Mappable protocol:

class User: Mappable {
    var name: String?
    var age: Int?

    required init?(map: Map) {}

    func mapping(map: Map) {
        name <- map["user_name"]
        age <- map["user_age"]
    }
}

Features:

Not dependent on Swift's native Codable
Not dependent on reflection mechanisms
Custom operator <- makes mapping code concise
Requires manually writing mapping relationships
Supports nested mapping and custom conversions

ObjectMapper's advantage is relatively concise code that doesn't depend on Swift's internal implementation details, but its disadvantage is requiring manual mapping code and being incompatible with Swift's native serialization mechanism.

2. Frameworks Based on Runtime Reflection

HandyJSON and KakaJSON

These frameworks adopt similar implementation principles, both obtaining type information through runtime reflection:

struct User: HandyJSON {
    var name: String?
    var age: Int?
}

// Usage
let user = User.deserialize(from: jsonString)

Features:

Obtain type metadata through low-level runtime reflection
Directly manipulate memory for property assignment
Almost no additional code required
Relatively high performance

The main problem with these frameworks is their strong dependence on Swift's internal implementation details and metadata structure, making them prone to incompatibility issues or crashes as Swift versions upgrade. They achieve the ideal of "zero code" but sacrifice stability and safety.

3. Frameworks Based on Property Wrappers

ExCodable and BetterCodable

These frameworks leverage property wrappers introduced in Swift 5.1 to extend Codable:

struct User: Codable {
    @CustomKey("user_name")
    var name: String

    @DefaultValue(33)
    var age: Int
}

Features:

Based on Swift's native Codable
Use property wrappers to simplify common encoding/decoding tasks
No need to manually write CodingKeys and Codable implementations
Type-safe, compile-time checking

Property wrapper solutions have obvious advantages over the previous two categories: they maintain compatibility with Swift's native Codable while simplifying code writing. However, PropertyWrappers have limited capabilities, and some complex encapsulation designs can't be achieved.

4. Frameworks Based on Macros

CodableWrapper, CodableWrappers, MetaCodable, and this article's ReerCodable

These frameworks leverage macro features introduced in Swift 5.9 to generate Codable implementation code at compile time:

@Codable
struct User {
    @CodingKey("user_name")
    var name: String

    var age: Int = 33
}

Features:

Based on Swift's native Codable
Declarative syntax, intuitive and easy to understand
Highly flexible, supporting complex encoding/decoding logic
Can apply macros at the type level

The macro approach combines the advantages of all previous approaches while avoiding their disadvantages: it's based on native Codable, maintaining type safety; it supports declarative syntax, keeping code concise; it generates code at compile time without runtime performance loss; it can handle complex scenarios with strong adaptability.

Why are Macros the Most Elegant Solution?

Among all these frameworks, macro-based solutions (like ReerCodable) provide the most elegant solution for the following reasons:

Seamless Integration with Native Codable: Generated code is identical to handwritten Codable implementations, working perfectly with other APIs using Codable. For modern third-party frameworks like Alamofire, GRDB, etc., they're all compatible with Codable.
Support for Third-party Encoders/Decoders with Codable: If you don't want to use Foundation's decoder, you can use third-party libraries.
Declarative Syntax: Declare serialization requirements through annotations, making code concise, intuitive, and with clear intentions.
Type Safety: All operations undergo type checking at compile time, avoiding runtime errors.
High Flexibility: Can handle various complex scenarios such as nested structures, custom conversions, conditional encoding/decoding, etc.
Good Maintainability: Macro-generated code is predictable and doesn't depend on Swift's internal implementation details, avoiding compatibility issues with Swift version updates.
Strong Debuggability: You can view the expanded code after macro execution, facilitating understanding and debugging.
Extensibility: Different macros can be combined to build complex encoding/decoding logic.

ReerCodable: Magic that Simplifies Complexity

ReerCodable leverages the power of Swift Macros, allowing you to automatically generate efficient, robust Codable implementations by simply adding annotations before types or properties. The core is the @Codable macro, which works with other macros provided by ReerCodable to generate the final encoding/decoding logic. The framework supports both Cocoapods and SwiftPackageManager.

The code implementation references excellent projects like winddpan/CodableWrapper, GottaGetSwifty/CodableWrappers, and MetaCodable, but ReerCodable offers richer features or more concise usage compared to them.

Let's see how ReerCodable elegantly solves the pain points mentioned earlier:

1. Custom CodingKey

Use @CodingKey to specify custom keys for properties without manually writing the CodingKeys enum:

ReerCodable

@Codable
struct User {
    @CodingKey("user_name")
    var name: String

    @CodingKey("user_age")
    var age: Int

    var height: Double
}

Codable

struct User: Codable {
    var name: String
    var age: Int
    var height: Double

    enum CodingKeys: String, CodingKey {
        case name = "user_name"
        case age = "user_age"
        case height
    }
}

2. Nested CodingKey

Support nested key paths through dot notation:

@Codable
struct User {
    @CodingKey("other_info.weight")
    var weight: Double

    @CodingKey("location.city")
    var city: String
}

3. Multiple Keys for Decoding

Multiple keys can be specified for decoding, the system will try them in order until successful:

@Codable
struct User {
    @CodingKey("name", "username", "nick_name")
    var name: String
}

4. Name Style Conversion

Support multiple naming style conversions, can be applied to types or individual properties:

@Codable
@SnakeCase
struct Person {
    var firstName: String  // decoded from "first_name" or encoded to "first_name"

    @KebabCase
    var lastName: String   // decoded from "last-name" or encoded to "last-name"
}

5. Custom Coding Container

Use @CodingContainer to customize the container path for encoding and decoding, typically used when dealing with heavily nested JSON structures while wanting the model declaration to directly match a sub-level structure:

ReerCodable

@Codable
@CodingContainer("data.info")
struct UserInfo {
    var name: String
    var age: Int
}

JSON

{
    "code": 0,
    "data": {
        "info": {
            "name": "phoenix",
            "age": 33
        }
    }
}

6. Encoding-Specific Key

Different key names can be specified for the encoding process. Since @CodingKey may have multiple parameters and can use @SnakeCase, KebabCase, etc., decoding may use multiple keys, then encoding will use the first key, or @EncodingKey can be used to specify the key:

@Codable
struct User {
    @CodingKey("user_name")      // decoding uses "user_name", "name"
    @EncodingKey("name")         // encoding uses "name"
    var name: String
}

7. Default Value Support

Default values can be used when decoding fails. Native Codable throws an exception for non-Optional properties when the correct value is not parsed, even if an initial value has been set, or even if it's an Optional type enum:

@Codable
struct User {
    var age: Int = 33
    var name: String = "phoenix"
    // If the `gender` field in the JSON is neither `male` nor `female`, native Codable will throw an exception, whereas ReerCodable won't and instead set it to nil. For example, with `{"gender": "other"}`, this scenario might occur when the client has defined an enum but the server has added new fields in a business context.
    var gender: Gender?
}

@Codable
enum Gender: String {
    case male, female
}

8. Ignore Properties

Use @CodingIgnored to ignore specific properties during encoding/decoding. During decoding, non-Optional properties must have a default value to satisfy Swift initialization requirements. ReerCodable automatically generates default values for basic data types and collection types. For other custom types, users need to provide default values:

@Codable
struct User {
    var name: String

    @CodingIgnored
    var ignore: Set<String>
}

9. Base64 Coding

Automatically handle conversion between base64 strings and Data, [UInt8] types:

@Codable
struct User {
    @Base64Coding
    var avatar: Data

    @Base64Coding
    var voice: [UInt8]
}

10. Collection Type Decoding Optimization

Use @CompactDecoding to automatically filter null values when decoding arrays, same meaning as compactMap:

@Codable
struct User {
    @CompactDecoding
    var tags: [String]  // ["a", null, "b"] will be decoded as ["a", "b"]
}

At the same time, both Dictionary and Set also support the use of @CompactDecoding for optimization.

11. Date Coding

Support various date format encoding/decoding:

@Codable
class DateModel {
    @DateCoding(.timeIntervalSince2001)
    var date1: Date

    @DateCoding(.timeIntervalSince1970)
    var date2: Date

    @DateCoding(.secondsSince1970)
    var date3: Date

    @DateCoding(.millisecondsSince1970)
    var date4: Date

    @DateCoding(.iso8601)
    var date5: Date

    @DateCoding(.formatted(Self.formatter))
    var date6: Date

    static let formatter: DateFormatter = {
        let dateFormatter = DateFormatter()
        dateFormatter.locale = Locale(identifier: "en_US_POSIX")
        dateFormatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ss.SSS"
        dateFormatter.timeZone = TimeZone(secondsFromGMT: 0)
        return dateFormatter
    }()
}

JSON

{
    "date1": 1431585275,
    "date2": 1731585275.944,
    "date3": 1731585275,
    "date4": 1731585275944,
    "date5": "2024-12-10T00:00:00Z",
    "date6": "2024-12-10T00:00:00.000"
}

12. Custom Encoding/Decoding Logic

Implement custom encoding/decoding logic through @CustomCoding. There are two ways to customize encoding/decoding:

Through closures, using decoder: Decoder, encoder: Encoder as parameters to implement custom logic:

@Codable
struct User {
    @CustomCoding<Double>(
        decode: { return try $0.value(forKeys: "height_in_meters") * 100.0 },
        encode: { try $0.set($1 / 100.0, forKey: "height_in_meters") }
    )
    var heightInCentimeters: Double
}

Through a custom type implementing the CodingCustomizable protocol to implement custom logic:

// 1st 2nd 3rd 4th 5th  -> 1 2 3 4 5
struct RankTransformer: CodingCustomizable {

    typealias Value = UInt

    static func decode(by decoder: any Decoder, keys: [String]) throws -> UInt {
        var temp: String = try decoder.value(forKeys: keys)
        temp.removeLast(2)
        return UInt(temp) ?? 0
    }

    static func encode(by encoder: Encoder, key: String, value: Value) throws {
        try encoder.set(value, forKey: key)
    }
}

@Codable
struct HundredMeterRace {
    @CustomCoding(RankTransformer.self)
    var rank: UInt
}

During custom implementation, the framework provides methods that can make encoding/decoding more convenient:

public extension Decoder {
    func value<Value: Decodable>(forKeys keys: String...) throws -> Value {
        let container = try container(keyedBy: AnyCodingKey.self)
        return try container.decode(type: Value.self, keys: keys)
    }
}

public extension Encoder {
    func set<Value: Encodable>(_ value: Value, forKey key: String, treatDotAsNested: Bool = true) throws {
        var container = container(keyedBy: AnyCodingKey.self)
        try container.encode(value: value, key: key, treatDotAsNested: treatDotAsNested)
    }
}

13. Inheritance Support

Use @InheritedCodable for better support of subclass encoding/decoding. Native Codable cannot parse subclass properties, even if the value exists in JSON, requiring manual implementation of init(from decoder: Decoder) throws:

@Codable
class Animal {
    var name: String
}

@InheritedCodable
class Cat: Animal {
    var color: String
}

14. Enum Support

Provide rich encoding/decoding capabilities for enums:

Support for basic enum types and RawValue enums:

@Codable
struct User {
    let gender: Gender
    let rawInt: RawInt
    let rawDouble: RawDouble
    let rawDouble2: RawDouble2
    let rawString: RawString
}

@Codable
enum Gender {
    case male, female
}

@Codable
enum RawInt: Int {
    case one = 1, two, three, other = 100
}

@Codable
enum RawDouble: Double {
    case one, two, three, other = 100.0
}

@Codable
enum RawDouble2: Double {
    case one = 1.1, two = 2.2, three = 3.3, other = 4.4
}

@Codable
enum RawString: String {
    case one, two, three, other = "helloworld"
}

Support using CodingCase(match: ....) to match multiple values or ranges:

@Codable
enum Phone: Codable {
    @CodingCase(match: .bool(true), .int(10), .string("iphone"), .intRange(22...30))
    case iPhone

    @CodingCase(match: .int(12), .string("MI"), .string("xiaomi"), .doubleRange(50...60))
    case xiaomi

    @CodingCase(match: .bool(false), .string("oppo"), .stringRange("o"..."q"))
    case oppo
}

For enums with associated values, support using AssociatedValue to match associated values, use .label() to declare matching logic for labeled associated values, use .index() to declare matching logic for unlabeled associated values. ReerCodable supports two JSON formats for enum matching:

The first is also supported by native Codable, where the enum value and its associated values have a parent-child structure:

@Codable
enum Video: Codable {
    /// {
    ///     "YOUTUBE": {
    ///         "id": "ujOc3a7Hav0",
    ///         "_1": 44.5
    ///     }
    /// }
    @CodingCase(match: .string("youtube"), .string("YOUTUBE"))
    case youTube

    /// {
    ///     "vimeo": {
    ///         "ID": "234961067",
    ///         "minutes": 999999
    ///     }
    /// }
    @CodingCase(
        match: .string("vimeo"),
        values: [.label("id", keys: "ID", "Id"), .index(2, keys: "minutes")]
    )
    case vimeo(id: String, duration: TimeInterval = 33, Int)

    /// {
    ///     "tiktok": {
    ///         "url": "https://example.com/video.mp4",
    ///         "tag": "Art"
    ///     }
    /// }
    @CodingCase(
        match: .string("tiktok"),
        values: [.label("url", keys: "url")]
    )
    case tiktok(url: URL, tag: String?)
}

The second is where enum values and their associated values are at the same level or have custom matching structures, using CaseMatcher with key path for custom path value matching:

@Codable
enum Video1: Codable {
    /// {
    ///     "type": {
    ///         "middle": "youtube"
    ///     }
    /// }
    @CodingCase(match: .string("youtube", at: "type.middle"))
    case youTube

    /// {
    ///     "type": "vimeo",
    ///     "ID": "234961067",
    ///     "minutes": 999999
    /// }
    @CodingCase(
        match: .string("vimeo", at: "type"),
        values: [.label("id", keys: "ID", "Id"), .index(2, keys: "minutes")]
    )
    case vimeo(id: String, duration: TimeInterval = 33, Int)

    /// {
    ///     "type": "tiktok",
    ///     "media": "https://example.com/video.mp4",
    ///     "tag": "Art"
    /// }
    @CodingCase(
        match: .string("tiktok", at: "type"),
        values: [.label("url", keys: "media")]
    )
    case tiktok(url: URL, tag: String?)
}

15. Lifecycle Callbacks

Support encoding/decoding lifecycle callbacks:

@Codable
class User {
    var age: Int

    func didDecode(from decoder: any Decoder) throws {
        if age < 0 {
            throw ReerCodableError(text: "Invalid age")
        }
    }

    func willEncode(to encoder: any Encoder) throws {
        // Process before encoding
    }
}

@Codable
struct Child: Equatable {
    var name: String

    mutating func didDecode(from decoder: any Decoder) throws {
        name = "reer"
    }

    func willEncode(to encoder: any Encoder) throws {
        print(name)
    }
}

16. JSON Extension Support

Provide convenient JSON string and dictionary conversion methods:

let jsonString = "{\"name\": \"Tom\"}"
let user = try User.decode(from: jsonString)

let dict: [String: Any] = ["name": "Tom"]
let user2 = try User.decode(from: dict)

17. Basic Type Conversion

Support automatic conversion between basic data types:

@Codable
struct User {
    @CodingKey("is_vip")
    var isVIP: Bool    // "1" or 1 can be decoded as true

    @CodingKey("score")
    var score: Double  // "100" or 100 can be decoded as 100.0
}

18. AnyCodable Support

Implement encoding/decoding of Any type through AnyCodable:

@Codable
struct Response {
    var data: AnyCodable  // Can store data of any type
    var metadata: [String: AnyCodable]  // Equivalent to [String: Any] type
}

19. Generate Default Instance

@Codable
@DefaultInstance
struct ImageModel {
    var url: URL
}

@Codable
@DefaultInstance
struct User5 {
    let name: String
    var age: Int = 22
    var uInt: UInt = 3
    var data: Data
    var date: Date
    var decimal: Decimal = 8
    var uuid: UUID
    var avatar: ImageModel
    var optional: String? = "123"
    var optional2: String?
}

Will generate the following instance:

static let `default` = User5(
    name: "",
    age: 22,
    uInt: 3,
    data: Data(),
    date: Date(),
    decimal: 8,
    uuid: UUID(),
    avatar: ImageModel.default,
    optional: "123",
    optional2: nil
)

⚠️ Note: Properties with generic types are NOT supported with @DefaultInstance:

@Codable
struct NetResponse<Element: Codable> {
    let data: Element?
    let msg: String
    private(set) var code: Int = 0
}

20. Generate Copy Method

Use Copyable to generate copy method for models:

@Codable
@Copyable
public struct Model6 {
    var name: String
    let id: Int
    var desc: String?
}

@Codable
@Copyable
class Model7<Element: Codable> {
    var name: String
    let id: Int
    var desc: String?
    var data: Element?
}

Generates the following copy methods. As you can see, besides default copy, you can also update specific properties:

public func copy(
    name: String? = nil,
    id: Int? = nil,
    desc: String? = nil
) -> Model6 {
    return .init(
        name: name ?? self.name,
        id: id ?? self.id,
        desc: desc ?? self.desc
    )
}

func copy(
    name: String? = nil,
    id: Int? = nil,
    desc: String? = nil,
    data: Element? = nil
) -> Model7 {
    return .init(
        name: name ?? self.name,
        id: id ?? self.id,
        desc: desc ?? self.desc,
        data: data ?? self.data
    )
}

21. Use `@Decodable` or `@Encodable` alone

@Decodable
struct Item: Equatable {
    let id: Int
}

@Encodable
struct User3: Equatable {
    let name: String
}

These examples demonstrate the main features of ReerCodable, which can help developers greatly simplify the encoding/decoding process, improving code readability and maintainability.

About Performance

ReerCodable theoretically has the same performance as native Codable, but early Foundation JSONDecoder performance wasn't good, so the community created the following frameworks:

ZippyJSON (Implemented Decoder, Encoder in C++)
Ananda (Based on yyjson)
IkigaJSON (Implemented Decoder, Encoder in Swift)

From ZippyJSON's homepage description, it seems Apple optimized decoding performance in iOS17+ and surpassed ZippyJSON:

Note: JSONDecoder is faster than ZippyJSON for iOS 17+. The rest of this document describes the performance difference pre-iOS 17.

I used ReerCodable to annotate models and their properties, comparing the decoding performance of Foundation JSONDecoder, ZippyJSON, and IkigaJSON:

name                                     time           std        iterations
-----------------------------------------------------------------------------
JSON解码性能对比.创建 Foundation JSONDecoder          83.000 ns ±  95.19 %    1000000
JSON解码性能对比.创建 IkigaJSONDecoder                41.000 ns ±  96.06 %    1000000
JSON解码性能对比.创建 ZippyJSONDecoder                41.000 ns ±  77.25 %    1000000

JSON解码性能对比.Foundation JSONDecoder - 标准数据  313791.000 ns ±   3.63 %       4416
JSON解码性能对比.IkigaJSONDecoder - 标准数据        377583.000 ns ±   6.30 %       3692
JSON解码性能对比.ZippyJSONDecoder - 标准数据        310792.000 ns ±   3.62 %       4395

JSON解码性能对比.Foundation JSONDecoder - 小数据集   88334.000 ns ±   4.35 %      15706
JSON解码性能对比.IkigaJSONDecoder - 小数据集         98333.000 ns ±   4.96 %      14095
JSON解码性能对比.ZippyJSONDecoder - 小数据集         87625.000 ns ±   5.34 %      15747

JSON解码性能对比.Foundation JSONDecoder - 大数据集 5537916.500 ns ±   1.61 %        252
JSON解码性能对比.IkigaJSONDecoder - 大数据集       6445166.000 ns ±   2.30 %        217
JSON解码性能对比.ZippyJSONDecoder - 大数据集       5376375.000 ns ±   1.68 %        259

JSON解码性能对比.Foundation JSONDecoder - 嵌套结构    9167.000 ns ±   8.38 %     149385
JSON解码性能对比.IkigaJSONDecoder - 嵌套结构         10375.000 ns ±  13.73 %     131397
JSON解码性能对比.ZippyJSONDecoder - 嵌套结构          8458.000 ns ±  10.45 %     161606

JSON解码性能对比.Foundation JSONDecoder - 数组解析 2562250.000 ns ±   2.08 %        542
JSON解码性能对比.IkigaJSONDecoder - 数组解析       3620500.000 ns ±   1.63 %        385
JSON解码性能对比.ZippyJSONDecoder - 数组解析       2503709.000 ns ±   1.94 %        555

As seen above, ZippyJSONDecoder still has the best performance, with Foundation JSONDecoder very close behind, much better than older versions of JSONDecoder.

Additionally, native Foundation.JSONDecoder decoding performance still hasn't surpassed Ananda, according to AnandaBenchmark. The following benchmark data shows Ananda's performance is about twice that of Foundation.JSONDecoder, so if you have very high performance requirements, consider using Ananda. It also uses Swift macros for some convenient encapsulation, but generally speaking, native Codable no longer has performance issues:

name                       time        std        iterations
------------------------------------------------------------
Codable decoding           5125.000 ns ±  14.92 %     271764
Ananda decoding            2541.000 ns ±  38.26 %     541187
Ananda decoding with Macro 2541.000 ns ±  64.55 %     550339

Conclusion

ReerCodable greatly simplifies the use of Codable through a series of carefully designed Swift Macros, significantly reducing boilerplate code and improving development efficiency and code readability. It not only covers most scenarios of native Codable but also provides more powerful and flexible features such as multi-key decoding, name conversion, custom containers, robust default value handling, powerful enum support, and convenient auxiliary tools.

If you're still troubled by the tedious implementation of Codable, try ReerCodable, and it will surprise you!

GitHub address: https://github.com/reers/ReerCodable

Welcome to try it out, star the repository, submit issues or pull requests! Let's write Swift code in a more modern and elegant way together!

This article was mainly generated by AI, please refer to the GitHub readme for specifics.

DEV Community: phoenix

How to Gracefully Use OC +load Timing in Swift

Introducing! Rhea - Unlocking +load Timing in Swift

Wait, Is Using load Extensively in Swift Really "Graceful"?

+load and Application Startup Time

Other Potential Issues

Conclusion: Use with Caution, Not Abuse

Summary

Codable Macros Make Swift Serialization So Simple!

Codable Macros Make Swift Serialization So Simple!

Practical Application Example

The "Pain" of Native Codable

Community Status

1. Frameworks Based on Custom Protocols

2. Frameworks Based on Runtime Reflection

3. Frameworks Based on Property Wrappers

4. Frameworks Based on Macros

Why are Macros the Most Elegant Solution?

ReerCodable: Magic that Simplifies Complexity

1. Custom CodingKey

2. Nested CodingKey

3. Multiple Keys for Decoding

4. Name Style Conversion

5. Custom Coding Container

6. Encoding-Specific Key

7. Default Value Support

8. Ignore Properties

9. Base64 Coding

10. Collection Type Decoding Optimization

11. Date Coding

12. Custom Encoding/Decoding Logic

13. Inheritance Support

14. Enum Support

15. Lifecycle Callbacks

16. JSON Extension Support

17. Basic Type Conversion

18. AnyCodable Support

19. Generate Default Instance

20. Generate Copy Method

21. Use @Decodable or @Encodable alone

About Performance

Conclusion

Introducing! Rhea - Unlocking `+load` Timing in Swift

21. Use `@Decodable` or `@Encodable` alone