Swift Concurrency is one of the most transformative additions to Swift since the language launched. It promises safer, more readable asynchronous workflows compared to the callback‑heavy days of Grand Central Dispatch (GCD).

But when moving existing code from GCD to Swift Concurrency, it’s not just replacing DispatchQueue calls with async/await and actor isolation, resolving all the compiler warnings and errors (like the official migration guide suggests). The migration comes with subtle differences in execution at runtime, missing equivalents, and API pitfalls.

In this post, I’ll share real-world gotchas from my own migration journey — plus side-by-side code comparisons so you can see exactly how to translate old patterns into modern concurrency.

We will start with a simple GCD based bank account implementation and see the migration to Swift Concurrency:

class BankAccount {
    private var balance: Int
    let queue = DispatchQueue(label: "com.bank.account")

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(amount: Int) {
        queue.async {
            self.balance -= amount
        }
    }

    func deposit(amount: Int) {
        queue.async {
            self.balance += amount
        }
    }
}

1️⃣ Execution Order Isn’t the Same

GCD guarantees FIFO execution order for tasks queued on the same serial queue. Even for concurrent queue, the work items are started in the order of submission. Swift Concurrency schedules tasks onto a cooperative thread pool — the order is not guaranteed (even though your work share the same priority level).

Following snippet in GCD, always executes in order:

let queue = DispatchQueue(label: "serial")
queue.async { print("First") }
queue.async { print("Second") }
// Always prints First then Second

While the common suggested Swift Concurrency approach can print out of order:

Task { print("First") }
Task { print("Second") }
// Order is not guaranteed

Why is this important?

In common migration guide it is suggested to use continuations to create async versions of methods with completion handler and replace call to the older method with Task wrapped async method.

The following conversion for our GCD code is invalid as Tasks created in withdraw and deposit functions can be executed out of order unless being invoked from an actor that guarantees serial execution:

actor BankAccount {
    var balance: Int

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) {
        balance -= amount
    }

    func deposit(_ amount: Int) {
        balance += amount
    }

    nonisolated func withdraw(amount: Int) {
        Task {
            await bankAccount.withdraw(amount)
        }
    }

    nonisolated func deposit(amount: Int) {
        Task {
            await bankAccount.deposit(amount)
        }
    }
}

The subtle state difference in the new async method execution to the older one can cause data races and hard to reproduce bugs.

What should be done?

To maintain execution order call the asynchronous function directly. While this will require adding async to the parent method now, entire method chain should be migrated.

If you have to use Task use a TaskExecutor or a GlobalActor. Make sure to use DispatchQueue as the executor in these cases to avoid execution order differences.

Our GCD code equivalent becomes:

actor BankAccount {
    var balance: Int

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) {
        balance -= amount
    }

    func deposit(_ amount: Int) {
        balance += amount
    }

    nonisolated func withdraw(amount: Int) {
        Task { @MyGlobalActor in
            await bankAccount.withdraw(amount)
        }
    }

    nonisolated func deposit(amount: Int) {
        Task { @MyGlobalActor in
            await bankAccount.deposit(amount)
        }
    }
}

This isn’t the complete migration, we will discuss the issues with this code in next sections.

2️⃣ Actors aren’t DispatchQueues

When migrating from GCD to Swift Concurrency, you might be tempted to think of an actor as a drop‑in replacement for a serial DispatchQueue.

While both ensure mutually exclusive access to the data they protect, actors are not queues — they are part of the structured concurrency model and have different semantics. The key difference being the order of execution by actors compared to DispatchQueues when dealing with task priority. Consider the following example:

actor SomeActor {
    var counter = 0

    func log(external: Int) {
        if counter != external {
            print("Counter \(counter) with \(external)")
        }
        counter += 1
    }
}


await withTaskGroup { group in
    let act = SomeActor()
    for index in 0..<1000 {
        let task = Task.immediate(priority: (index % 2 == 0) ? .high : .low) {
            await act.log(external: index)
        }
        group.addTask {
            await task.value
        }
    }
}

// Unordered output

Why is this important?

While migrating you might be replacing all the shared mutation access with DispatchQueues to actors. But without considering the task priority at these actor call site you might introduce data races.

The final snippet in our GCD migrated code in the above section still has this issue.

What should be done?

Fortunately, actors allow to customize their execution with custom SerialExecutor. Using DispatchQueue as underlying executor preserves the existing behaviour while migrating.

actor SomeActor {
    var counter = 0

    let queue = DispatchSerialQueue(label: "cusomQueue")
    nonisolated var unownedExecutor: UnownedSerialExecutor { 
        queue.asUnownedSerialExecutor()
    }

    func log(external: Int) {
        if counter != external {
            print("Counter \(counter) with \(external)")
        }
        counter += 1
    }
}

The correct migration for out GCD equivalent becomes:

actor BankAccount {
    var balance: Int

    let queue = DispatchSerialQueue(label: "cusomQueue")
    nonisolated var unownedExecutor: UnownedSerialExecutor { 
        queue.asUnownedSerialExecutor()
    }

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) {
        balance -= amount
    }

    func deposit(_ amount: Int) {
        balance += amount
    }

    nonisolated func withdraw(amount: Int) {
        Task { @MyGlobalActor in
            await bankAccount.withdraw(amount)
        }
    }

    nonisolated func deposit(amount: Int) {
        Task { @MyGlobalActor in
            await bankAccount.deposit(amount)
        }
    }
}

3️⃣ assumeIsolated and Older iOS Versions

Before Swift 6, dispatch didn’t work well with Actor.assumeIsolated. It can report false negatives — where you are actually on the correct queue but assumeIsolated doesn’t know it. Such cases can result in random crashes.

The fix for this requires a new version of the Swift runtime, for older systems we need a hack to emulate the new assumeIsolated for Dispatch.

nonisolated func assumeIsolatedHack<T>(
    _ block: (isolated SomeActor) throws -> T
) rethrows -> T where T: Sendable {
    if #available(macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, *) {
        return try self.assumeIsolated(block)
    } else {
        dispatchPrecondition(condition: .onQueue(queue))
        // for nonescaping closures, storing as local variable
        // inside function not supported. Use this approach
        // to temorarily store them as local variables.
        return try withoutActuallyEscaping(block) {
            // remove isolation and execute
            let isolationStripped = unsafeBitCast($0, to: ((SomeActor) throws -> T).self)
            return try isolationStripped(self)
        }
    }
}

Why is this important?

This might not affect you if you are targeting iOS 18 and above (or equivalent versions for other Apple platforms) or you don’t use DispatchQueues as executors. But if your codebase qualify for these criteria, you might get random crashes during migration, that are hard to debug and explain.

What should be done?

Use the assumeIsolatedHack to unsafely assume isolation instead of the default assumeIsolated.

4️⃣ DispatchGroup Has No Actual Equivalent

Swift Concurrency offers TaskGroup and async let for running tasks in parallel, but these API behave fundamentally different than the DispatchGroup usages.

Consider a simple use-case of DispatchGroup:

let group = DispatchGroup()
// first work
group.enter()
firstWork { group.leave() }
// second work
group.enter()
secondWork { group.leave() }
// completion
group.notify { /* completed */ }

In the above snippet both firstWork and secondWork are already started (in order) by the end of the current execution context. But for the Swift Concurrency equivalents:

async let result1 = await firstWork() // not started immidiately
async let result2 = await secondWork() // not started immidiately
// started out of order

await withTaskGroup { group in // not started immidiately
    group.addTask { // not started immidiately
        await firstWork()
    }
    group.addTask { // not started immidiately
        await secondWork()
    }
}

are not started immediately. While in case of TaskGroup execution order can be customized with a TaskExecutor or a GlobalActor, same is not possible yet for async let.

Why is this important?

These execution difference might cause subtle state differences when your concurrent tasks are being started causing hard to reproduce data races and bugs.

What should be done?

If you are targeting iOS 26 and above (or equivalent versions for other Apple platforms) the actual equivalent of DispatchGroup would be:

let task1 = Task.immediate { await firstWork() } // started immidiately
let task2 = Task.immediate { await secondWork() } // started immidiately
await [task1.value, task2.value]
// or
await withTaskGroup { group in
    group.addTask {
        await task1.value
    }
    group.addTask {
        await task2.value
    }
}

If you are targeting below these versions, consider separating the synchronous parts that perform state access into separate functions and then use TaskGroup and async let to perform concurrent work. i.e. synchronously build your network requests first and then concurrently execute the network calls.

🏁 Final Thoughts

Swift Concurrency gives us:

✅ Better structure
✅ Automatic order reasoning via await
✅ Cleaner bridging to async code
✅ Compile time data race checks

…but it is not full proof. There are:

• Changes in execution semantics
• OS version compatibility considerations
• Gaps where GCD still fits better

A realistic migration strategy often means running hybrid code — adopt Swift Concurrency for new APIs & critical paths, while keeping some GCD constructs where their flexibility still wins. While migrating think on the impact on the execution order and state access order.

Stay subscribed for next post on how to approach migration step by step.

Deployment Pipeline for Apple SDKs

In Part 1 and Part 2 of this series, we touched on the importance of implementing deployment pipelines and the rationale for our selection of tech stack, with a walkthrough of the Android SDK pipeline.

Now, let’s delve into the significant steps that were involved in building the deployment pipeline for Apple SDKs at MoEngage. We’ll also share the goals we set for ourselves, the challenges we faced in achieving those, and the strategies we adopted to overcome them.

Goals for Apple SDK Release Process

• Wider ecosystem support: We wanted to support all the popular dependency management tools available for development on Apple platforms.
• Seamless SDK integration: We wanted SDK version management to be as seamless, performant, and secure as possible for customers’ apps.
• Efficient and Reliable Release Process: We want the process to be as cost and time-efficient while minimizing failures.

Wider ecosystem support

As an SDK vendor, we want our customers to be able to use our SDK with their favourite dependency management tools. Currently Apple ecosystem has two major dependency managers: CocoaPods and Swift Package Manager. While CocoaPods is a legacy dependency manager in Apple eco-system and is soon going to be sunset, it is still popular in older apps and hybrid platforms like Flutter and React Native.

Supporting these two dependency managers is challenging because both dependency managers are different in their fundamental philosophy and management process.

Centralized vs de-centralized: While CocoaPods acts as a centralized dependency manager, where each dependencies are pods and publish to a central repository, SPM acts as a de-centralized dependency manager, allowing authors to specify version with tags in their own repository.

Due to de-centralized nature of SPM, the dependency manager has to clone the entire dependency repository to know supported versions. To make this cloning as efficient as possible, we decided to keep the repository size minimal with only essential files. Large files like XCFrameworks are published in the GitHub releases while being referred by URL in the SPM Package manifest and separate podspec files (this introduced additional challenges, explored further in the next section).

Package vs Podspec: CocoaPods allows dependency configuration with podspec files, allowing only one target to be defined per podspec. This differs from SPM, which allows only one Package.swift per repo containing multiple products and targets as dependencies. Since we expose multiple XCFrameworks withthe ability for our customers to pick and choose based on desired functionalities, this introduced additional challenges for us.

We decided to avoid separate repositories for each XCFramework due to:

• Maintenance overhead and complexity of managing and publishing to multiple repositories
• Each repository will have independent versioning, causing conflicts with version resolution.
• For SPM, integrating each new repository introduces one additional step of specifying the URL and version.

Supporting both from a single repository requires multiple podspec files, each representing a single XCFramework and a single Package.swift file with each product representing an XCFramework. This setup introduced an additional challenge of managing tagging as CocoPods requires each podspec version to be represented by a separate tag, while SPM only allows one version tag. We decided to use a version tag for SPM (i.e. 9.23.1), while using a prefixed version tag (i.e. module-6.5.0) for CocoaPods.

Avoiding tooling limitations: CocoaPods has a bug with the implementation of XCFramework integrations, where multiple XCFrameworks in a single podspec will not allow dSYM file being copied to application ipa. This was one of the driving factor of using separate podspecs for each XCFrameworks.

SPM has limitation with regarding to XCFrameworks where targets declaring XCFrameworks can’t depend on other targets. We used the current workaround for this to create a wrapper target with dummy source file to declare dependency.

// swift-tools-version:5.5
// The swift-tools-version declares the minimum version of Swift required to build this package.
// This file generated from post_build script, modify the script instead of this file.

import PackageDescription

let package = Package(
    name: "iOS-SDK",
    platforms: [.iOS(.v11), .tvOS(.v11)],
    products: [], dependencies: [], targets: [],
    swiftLanguageVersions: [.v5]
)

struct PackageProduct {
    let name: String
    let targets: [Target]
}

extension Collection where Element == Target.Dependency {
    static var `default`: [Target.Dependency] {
        return [
            "Analytics", "Core", "Messaging",
            "ObjCUtils", "SDK", "Security",
        ]
    }

    static func additional(dependency: Target.Dependency) -> [Target.Dependency] {
        var dependencies = Self.default
        dependencies.append(dependency)
        return dependencies
    }
}

let products: [PackageProduct] = [
    .init(
        name: "InApps",
        targets: [
            .binaryTarget(name: "InApps", url: "https://github.com/user/apple-sdk/releases/download/9.23.0/InApps.xcframework.zip", checksum: "bc73edbb6438af435272c9f699e995d1d30ff4c11a2efbd5cd741d7e614b6b13"),
            // wrapper target containing dummy surce file for dependency declaration
            .target(name: "InAppSPM", dependencies: .additional(dependency: "TriggerEvaluator")),
        ]
    ),
]

for product in products {
    for target in product.targets {
        package.targets.append(target)
    }
    package.products.append(
        .library(name: product.name, targets: product.targets.map { $0.name })
    )
}

Maintaining Consistency: To make the dependencies consistent across dependency managers, we decided to use a single package.json file to maintain common configurations, i.e., XCFramework name, download URL, version, and podspec tag prefix, etc.

{
  "name": "iOS-SDK",
  "version": "9.23.1",
  "tagPrefix": "all-",
  "postBuild": "Utilities/post_build.rb",
  "packages": [
    {
      "name": "SDK",
      "version": "9.20.0",
      "tagPrefix": "sdk-",
      "hash": "25994092c82b0ce008eaf08fefe6964338b9652c93e28087a7adbb752f59fe37",
      "url": "https://github.com/user/iOS-SDK/releases/download/9.21.0/SDK.xcframework.zip"
    },
    {
      "name": "InApps",
      "version": "6.05.0",
      "tagPrefix": "inapp-",
      "hash": "bc73edbb6438af435272c9f699e995d1d30ff4c11a2efbd5cd741d7e614b6b13",
      "url": "https://github.com/user/apple-sdk/releases/download/9.23.0/InApps.xcframework.zip"
    }
}

Since podspec Files are written in Ruby, we were able to parse this JSON data to define podspecs:

require 'fileutils'
require 'json'
require 'ostruct'

module ReleaseSDK
  @@config = JSON.parse(File.read('package.json'), {object_class: OpenStruct})
  def self.config
    @@config
  end

  module Spec
    def define()
      podspec_path = caller.find do |trace|
        File.extname(trace.split(":")[0]).eql?('.podspec')
      end.split(":")[0]

      podspec = File.basename(podspec_path, File.extname(podspec_path))
      package_index = ReleaseSDK.config.packages.find_index { |package| package.name == podspec }
      package = ReleaseSDK.config.packages[package_index] if package_index

      self.name              = podspec
      self.version           = package&.version || ReleaseSDK.config.version

      if package
        self.source       = { :http => package.url, :sha256 => package[:hash] }
      else
        self.source       = {
          :git => 'https://github.com/user/apple-sdk.git',
          :tag => "#{ReleaseSDK.config.tagPrefix}#{self.version.to_s}"
        }
      end

      self.ios.deployment_target = '11.0'
      self.requires_arc = true
      self.preserve_paths = "*.md", "LICENSE" unless package
    end
  end
end

For SPM, this becomes challenging as SPM package manifest file isn’t allowed file system access. To circumvent this limitation, we decided to create a custom script as part of the release process to update the Package.swift file:

#!/usr/bin/ruby

# Usage:
# Update Package.swift file according to package.json

require 'fileutils'
require 'json'
require 'ostruct'

config = JSON.parse(File.read('package.json'), {object_class: OpenStruct})
config_map = Hash[ *config.packages.collect { |package| [ package.name, package ] }.flatten ]

def binary_target(package)
  ".binaryTarget(name: \"#{package.name}\", url: \"#{package.url}\", checksum: \"#{package[:hash]}\")"
end

package_swift = <<PACKAGE
// swift-tools-version:5.5
// The swift-tools-version declares the minimum version of Swift required to build this package.
// This file generated from post_build script, modify the script instead of this file.

import PackageDescription

let package = Package(
    name: "#{config.name}",
    platforms: [.iOS(.v11), .tvOS(.v11)],
    products: [], dependencies: [], targets: [],
    swiftLanguageVersions: [.v5]
)

struct PackageProduct {
    let name: String
    let targets: [Target]
}

extension Collection where Element == Target.Dependency {
    static var `default`: [Target.Dependency] {
        return [
            "Analytics", "Core", "Messaging",
            "ObjCUtils", "SDK", "Security",
        ]
    }

    static func additional(dependency: Target.Dependency) -> [Target.Dependency] {
        var dependencies = Self.default
        dependencies.append(dependency)
        return dependencies
    }
}

let products: [PackageProduct] = [
    .init(
        name: "iOS-SDK",
        targets: [
            #{binary_target(config_map['Core'])},
            #{binary_target(config_map['Messaging'])},
            #{binary_target(config_map['SDK'])},
        ]
    ),
    .init(
        name: "TriggerEvaluator",
        targets: [
            #{binary_target(config_map['TriggerEvaluator'])},
            .target(name: "TriggerEvaluatorSPM", dependencies: .default),
        ]
    ),
    .init(
        name: "InApps",
        targets: [
            #{binary_target(config_map['InApps'])},
            .target(name: "InAppSPM", dependencies: .additional(dependency: "TriggerEvaluator")),
        ]
    ),
]

for product in products {
    for target in product.targets {
        package.targets.append(target)
    }
    package.products.append(
        .library(name: product.name, targets: product.targets.map { $0.name })
    )
}

PACKAGE

File.open('Package.swift', 'w') do |file|
  file.write(package_swift)
end

Seamless SDK version management

MoEngage provides different functionalities that are distributed across multiple dependencies. This allows customers to integrate features of their choosing without additional cost in terms of app size. Due to the independent development and release of these packages, it becomes a development overhead for our customers in terms of maintaining dependency constraints across different packages.

We have solved this by shipping the entire SDK with a single version, each package being exposed as a feature that customers can include/exclude. We use subspecs in CocoaPods and package products in Swift Package Manager to achieve this.

require 'fileutils'
require 'json'
require 'ostruct'

module ReleaseSDK
  @@config = JSON.parse(File.read('package.json'), {object_class: OpenStruct})
  def self.config
    @@config
  end

  module SubSpec
    def dependency_pod(name, proxy = nil)
      dependency = ReleaseSDK.config.packages.find { |package| package.name.eql?(name) }
      if proxy
        self.send(proxy).dependency name, dependency.version
      else
        self.dependency name, dependency.version
      end
    end
  end
end

Pod::Spec.new do |s|
  s.define

  s.tvos.deployment_target = '11.0'
  s.default_subspec = 'Core'
  s.subspec 'Core' do |ss|
    ss.extend ReleaseSDK::SubSpec
    ss.dependency_pod 'SDK'
    ss.dependency_pod 'Core'
    ss.dependency_pod 'Messaging'
  end

  s.subspec 'InApps' do |ss|
    ss.extend ReleaseSDK::SubSpec
    ss.dependency 'iOS-SDK/Core'
    ss.dependency_pod 'TriggerEvaluator'
    ss.dependency_pod 'InApps'
  end
end

// swift-tools-version:5.5
// The swift-tools-version declares the minimum version of Swift required to build this package.
// This file generated from post_build script, modify the script instead of this file.

import PackageDescription

let package = Package(
    name: "iOS-SDK",
    platforms: [.iOS(.v11), .tvOS(.v11)],
    products: [], dependencies: [], targets: [],
    swiftLanguageVersions: [.v5]
)

struct PackageProduct {
    let name: String
    let targets: [Target]
}

extension Collection where Element == Target.Dependency {
    static var `default`: [Target.Dependency] {
        return [
            "Analytics", "Core", "Messaging",
            "ObjCUtils", "SDK", "Security",
        ]
    }

    static func additional(dependency: Target.Dependency) -> [Target.Dependency] {
        var dependencies = Self.default
        dependencies.append(dependency)
        return dependencies
    }
}

let products: [PackageProduct] = [
    .init(
        name: "iOS-SDK",
        targets: [
            .binaryTarget(name: "Core", url: "https://github.com/user/apple-sdk/releases/download/9.23.1/Core.xcframework.zip", checksum: "bded0a602e5ee8a5bc3705dc2acf115f6f6244014b72f2a476666d0f4bd99d07"),
            .binaryTarget(name: "Messaging", url: "https://github.com/user/apple-sdk/releases/download/9.23.0/Messaging.xcframework.zip", checksum: "a6d33373f24669462ebac6db35bd7befa077587399ffd1b14143ba453f52c819"),
            .binaryTarget(name: "SDK", url: "https://github.com/user/iOS-SDK/releases/download/9.21.0/SDK.xcframework.zip", checksum: "25994092c82b0ce008eaf08fefe6964338b9652c93e28087a7adbb752f59fe37"),
        ]
    ),
    .init(
        name: "TriggerEvaluator",
        targets: [
            .binaryTarget(name: "TriggerEvaluator", url: "https://github.com/user/iOS-SDK/releases/download/9.21.0/TriggerEvaluator.xcframework.zip", checksum: "547854ceed99693bede020e18987de36bba56b7334b5ddb0e518b7e6de363e71"),
            .target(name: "TriggerEvaluatorSPM", dependencies: .default),
        ]
    ),
    .init(
        name: "InApps",
        targets: [
            .binaryTarget(name: "InApps", url: "https://github.com/user/apple-sdk/releases/download/9.23.0/InApps.xcframework.zip", checksum: "bc73edbb6438af435272c9f699e995d1d30ff4c11a2efbd5cd741d7e614b6b13"),
            .target(name: "InAppSPM", dependencies: .additional(dependency: "TriggerEvaluator")),
        ]
    ),
]

for product in products {
    for target in product.targets {
        package.targets.append(target)
    }
    package.products.append(
        .library(name: product.name, targets: product.targets.map { $0.name })
    )
}

SPM consumers can include products with a name iOS-SDK, InApps In their app, they target to consume the dependency while having to declare a single repository and version as a dependency constraint. CocoaPods consumers can declare the version once, and use additional subspecs to include additional features:

pod 'iOS-SDK','~> 9.23.1'
pod 'iOS-SDK/InApps'

We publish all our code as XCFrameworks, so our customers’ build performance won’t be impacted. As we support integration both from application target and application extension targets (i.e., notification service extension), we publish the libraries as dynamically linked libraries to avoid an application binary size increase.

Since customers can’t see or verify the code being integrated, integrating XCFrameworks introduces security risks. To avoid malicious XCFramework being integrated, we follow a two-step verification process.

• For the first step, to allow malicious XCFrameworks being rejected by dependency managers, by specifying SHA256 hash of our XCFramework archive in both SPM and CocoaPods.

.binaryTarget(name: "InApps", url: "https://github.com/user/apple-sdk/releases/download/9.23.0/InApps.xcframework.zip", checksum: "bc73edbb6438af435272c9f699e995d1d30ff4c11a2efbd5cd741d7e614b6b13"),

self.source = { :http => package.url, :sha256 => package[:hash] }

The SHA256 hash is generated during our release process from the built xcframework archives:

package[:hash] = `shasum -a 256 "XCFramework/#{archive}"`.scan(/\S+/)[0]

• For the second step, we rely on the verification by the Xcode build system itself. For this, we sign our XCFrameworks using codesign:

system("codesign --timestamp -s \"#{ENV['CERTIFICATE_IDENTITY']}\" \"#{xcframework}\"", out: STDOUT, exception: true)

The signature can be verified by clicking on the XCFramework file and viewing File Inspector in Xcode:

Efficient and Reliable Release Process

As last part of our goal, we want the release process to as much cost and time efficient while being extremely reliable and less prone to errors. To increase efficiency and reliability, we identified key release processes to optimize and gracefully handle failures:

• Create XCFrameworks
• Publish to CocoaPods

Create XCFrameworks: Since we publish multiple XCFrameworks with inter-dependencies, building XCFrameworks per target resulted in dependency modules being built repeatedly causing higher build time.

We decided to go with a shared scheme that builds all the XCFrameworks together, resulting in significantly less build time. But this resulted in unnecessary XCFrameworks being built without any code changes. We decided to convert each target into CocoaPods podspecs. This gave usthe benefit of re-using already released XCFrameworks with released pods.

require 'fileutils'
require 'net/http'
require 'json'
require 'ostruct'

module SDK
  XCARCHIVE = 'XCArchive'
  XCFRAMEWORK = 'XCFramework'
  EXAMPLES = 'Examples'
  PACKAGE_CONFIG = 'package.json'
  DERIVED_DATA = File.expand_path('~/Library/Developer/Xcode/DerivedData')
  XCArchive = Struct.new(:scheme, :destination, :path, :ios)
end

# Set up `pods.rb` file for source of pods.
#
# Use cache for frameworks not to be built
#
# @param [Array] Frameworks to be built from source.
# @param [Array] Cached Frameworks to be used.
def setup_pods(build_frameworks, cached_frameworks)
  build_framework_pod = proc do |framework|
    "pod '#{framework.name}', :path => '../'"
  end

  cached_framework_pod = proc do |framework|
    "pod '#{framework.name}', '#{framework.version}'"
  end

  ios_pods = build_frameworks.map(&build_framework_pod) + cached_frameworks.map(&cached_framework_pod)
  extension_pods, ios_pods = ios_pods.partition { |syntax| syntax.include?('RichNotification') }
  tv_pods = build_frameworks.select(&:common).map(&build_framework_pod) + cached_frameworks.select(&:common).map(&cached_framework_pod)
  injected_pods = <<EOF
def use_custom_pods
  #{ios_pods.join("\n  ")}
end

def use_custom_extension_pods
  #{extension_pods.join("\n  ")}
end

def use_custom_tv_pods
  #{tv_pods.join("\n  ")}
end
EOF
  File.open(File.join(SDK::EXAMPLES, 'pods.rb'), 'w') do |file|
    file.write(injected_pods)
  end
  Dir.chdir(SDK::EXAMPLES) { system('pod install', out: STDOUT, exception: true) }
end

# Create XCArchives to extract XCFrameworks.
#
# @param [Bool] Whether to build for tvOS as well.
def create_archives(tv)
  workspace_dir = File.join(SDK::EXAMPLES, 'Examples.xcworkspace')
  archives = [
    SDK::XCArchive.new('All iOS', 'generic/platform=iOS', File.join(SDK::XCARCHIVE,'All-iOS.xcarchive'), true),
    SDK::XCArchive.new('All iOS', 'generic/platform=iOS Simulator', File.join(SDK::XCARCHIVE,'All-iOS-Sim.xcarchive'), true),
  ]
  # only builds tvOS archive if any framework supports tvOS
  archives.push(
    SDK::XCArchive.new('All tvOS', 'generic/platform=tvOS', File.join(SDK::XCARCHIVE,'All-tvOS.xcarchive'), false),
    SDK::XCArchive.new('All tvOS', 'generic/platform=tvOS Simulator', File.join(SDK::XCARCHIVE,'All-tvOS-Sim.xcarchive'), false)
  ) if tv
  archives.each do |archive|
    system("xcodebuild archive -workspace \"#{workspace_dir}\" -scheme \"#{archive.scheme}\" -destination \"#{archive.destination}\" -archivePath \"#{archive.path}\" SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES", out: STDOUT, exception: true)
  end
  return archives
end

# Build XCFrameworks for provided frameworks.
#
# @param [Array] Frameworks to build for.
def build_xcframeworks(frameworks)
  # cleanup previous XCFrameworks and XCArchives
  [SDK::XCFRAMEWORK, SDK::XCARCHIVE].each { |dir| FileUtils.rm_rf(dir) if File.directory?(dir) }

  # create XCFramework and XCArchive directories
  FileUtils.mkdir_p(SDK::XCARCHIVE)
  FileUtils.mkdir_p(SDK::XCFRAMEWORK)

  # get frameworks to be built metadata
  package = JSON.parse(File.read(SDK::PACKAGE_CONFIG), {object_class: OpenStruct})
  build_framework_names = frameworks.map { |arg| arg.strip }
  build_frameworks, cached_frameworks = package.frameworks.partition do |framework|
    build_framework_names.include?(framework.name)
  end

  if build_frameworks.empty?
    puts "No framework passed to build: #{frameworks}"
    return
  end

  # optimize build using cached frameworks
  setup_pods(build_frameworks, cached_frameworks)

  # create XCArchives and XCFrameworks
  create_xcframeworks(build_frameworks)

  # print SHA256 for generated zips
  Dir.glob("#{SDK::XCFRAMEWORK}/**/*.xcframework.zip").each do |zip|
    system("shasum -a 256 \"#{zip}\"", out: STDOUT, exception: true)
  end
end

# Create XCFrameworks for provided frameworks.
#
# Builds, signs and zips XCFrameworks.
#
# @param [Array] Frameworks to create for.
def create_xcframeworks(frameworks)
  # delete derived data
  FileUtils.rm_rf(SDK::DERIVED_DATA) if File.directory?(SDK::DERIVED_DATA)

  archives = create_archives(frameworks.any?(&:common))
  frameworks.each do |framework|
    # create flags for create-xcframework command
    flags = archives.map do |archive|
      next nil if !framework.common && !archive.ios
      framework_file = File.join(archive.path, 'Products', 'Library', 'Frameworks', "#{framework.name}.framework")
      dsym = File.join(Dir.pwd, archive.path, 'dSYMs', "#{framework.name}.framework.dSYM")
      "-framework \"#{framework_file}\" -debug-symbols \"#{dsym}\""
    end.compact

    # create xcframework
    xcframework = File.join(SDK::XCFRAMEWORK, "#{framework.name}.xcframework")
    system("xcodebuild -create-xcframework #{flags.join(' ')}  -output \"#{xcframework}\"", out: STDOUT, exception: true)

    # sign xcframework
    system("codesign --timestamp -s \"#{ENV['MO_CERTIFICATE_IDENTITY']}\" \"#{xcframework}\"", out: STDOUT, exception: true)

    # create xcframework zip
    Dir.chdir(SDK::XCFRAMEWORK) {
      xcframework_name = File.basename(xcframework)
      system("zip -r #{xcframework_name}.zip #{xcframework_name}/ -x \"*.DS_Store\"", out: STDOUT, exception: true)
    }
  end
end

Similar to our distribution model discussed above sections, we created a package.json file to store common configurations regarding the frameworks i.e., target name, target tag prefix, and current release version, target supported platforms etc. This file is used in individual podspec files, which in turn are used as local pods:

source = {:path => '../'}
project_dir = File.dirname(__FILE__)

abstract_target 'Workspace' do
  platform :ios, '13.0'

  # Pods for Workspace
  if File.file?(File.join(project_dir, 'pods.rb')) # use CI/CD specific sources
    require_relative File.join(project_dir, 'pods.rb')
    use_custom_pods
  else # use default local sources
    pod 'Core', :testspecs => ['Tests'], **source
  end

  target 'Test' do
    use_frameworks!

    # Pods for MoETest
    pod 'SwiftLint', '0.57.0'
  end

  target 'SwiftUITest' do
    use_frameworks!

    # Pods for MoESwiftUITest
    pod 'SwiftLint', '0.57.0'
  end

  target 'NotificationContent' do
    use_frameworks!
    inherit! :search_paths

    # Pods for NotificationContent
    if File.file?(File.join(project_dir, 'pods.rb')) # use CI/CD specific sources
      require_relative File.join(project_dir, 'pods.rb')
      use_custom_extension_pods
    else # use default local sources
      pod 'RichNotification', :testspecs => ['Tests'], **source
    end
  end

  target 'NotificationService' do
    use_frameworks!
    inherit! :search_paths

    # Pods for NotificationService
    if File.file?(File.join(project_dir, 'pods.rb')) # use CI/CD specific sources
      require_relative File.join(project_dir, 'pods.rb')
      use_custom_extension_pods
    else # use default local sources
      pod 'RichNotification', :testspecs => ['Tests'], **source
    end
  end
end

With this change our XCFramework build pipeline was optimized to only build frameworks that contain code changes, using released version of frameworks that doesn’t have any change and hence require no release.

Publish to CocoaPods: As last part of our release process we have to publish new pods to CocoaPods trunk. In CocoPods publish process, CocoPods validates the pod is valid and its dependencies are already available in CocoaPods trunk. To pass this validation, we publish the dependency pods first and then switching to dependent pods. CocoPods recommends — synchronous flag when publishing pod that has dependency pod published immediately before.

The temporary projects created by CocoaPods for pod validations consume higher amount of storage as the number of pods published increases. We decided to clear derived data and temporary directories after each pod is published to not hit GitHub runners’ storage limit.

CocoaPods also has internal data race where pods get partially published making the pod unusable for consumers. We added handling to remove and retry publishing such pods after a certain cooldown when such a failure happens:

#!/usr/bin/ruby

# Usage:
# Publish pods to CocoaPods

require 'fileutils'
require 'json'
require 'ostruct'

podspec = "#{package.name}.podspec"
info = `pod trunk info #{package.name}`
next if !File.exist?(podspec) || info.include?(" #{package.version} ")
puts "::group::Publishing #{podspec}"
begin
  FileUtils.rm_rf(derived_data) if File.directory?(derived_data)
  system("pod trunk push \"#{podspec}\" --verbose --synchronous --allow-warnings", out: STDOUT, exception: true)
  sleep 10 # even with --synchronous flag push might fail for depending pods
rescue => error
  sleep 60 # wait for timeout error
  info = `pod trunk info #{package.name}`
  next if info.include?(" #{package.version} ") # skip if pod is already published
  puts "::warning::Pod published failed with #{error&.message}, trying publish again"
  begin
    # remove pod to avoid conflict with existing pod
    # https://github.com/CocoaPods/trunk.cocoapods.org/issues/207
    system("pod trunk delete #{package.name} #{package.version} --verbose", out: STDOUT, exception: false)
  rescue => error
    puts "::warning::Pod delete failed with #{error&.message}, trying publish again"
  end
  system("pod trunk push \"#{podspec}\" --verbose --synchronous --allow-warnings", out: STDOUT, exception: true)
  sleep 10 # even with --synchronous flag push might fail for depending pods
end
puts "::endgroup::"

With the recent CocoaPods trunk read only plan, we added to our own custom specs repo to our publish action. We share lot of code between podspecs, these reusable code are split into multiple files. We publish the podspecs as JSON to avoid any import errors due to relative path mismatch:

repo_info = `pod repo list`
if !repo_info.include?('specs')
  system("pod repo add specs https://github.com/user/PodSpecs.git", out: STDOUT, exception: true)
end

puts "::group::Publishing #{podspec} to specs"
system("pod repo push specs \"#{podspec}\" --verbose --allow-warnings --skip-import-validation --use-json", out: STDOUT, exception: true)
puts "::endgroup::"

Even after CocoaPods trunk is made read-only, our customers can still use our pods just by adding a single line to their Podfile:

source 'https://github.com/user/PodSpecs.git'

In this article, we have explored the fundamentals of creating Apple SDK deployment pipelines.

Building Deployment Pipelines for Mobile SDKs — Part 3 was originally published in MoEngage on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you suspect an iOS app is behaving unexpectedly due to an invalid storage state — such as corrupted files, stale caches, unusual high storage space, or leftover temporary data — one of the most direct ways to investigate is to take a backup of the device and inspect your app’s sandbox from that backup.

Apple iOS backups made via Finder or iTunes contain all the files from each app’s sandbox — but arranged in a special hashed folder structure. With some SQLite queries, you can extract and inspect exactly what’s in your app without needing third‑party tools. This approach allows you to view app-group directory contents as well, which the Xcode’s Download container… doesn’t show.

Why Backup-Based Inspection Helps

On a physical iOS device, the app’s sandbox contains Documents, Library, Caches, and other directories, but they aren’t easily accessible without jailbreaking. The simulator’s environment is different and might not reflect your production storage usage.

By taking an unencrypted backup, you can navigate the actual app container from a real device and identify what’s causing your app to misbehave.

1. Prepare the Device

Reproduce the storage issue on your test or user device so the backup will include the state you want to debug.

2. Take an Unencrypted Backup

Use Finder or iTunes:

• Connect your device via USB.
• In Finder/iTunes, select your device.
• Select Back up all the data on your iPhone to this Mac.
• Choose Back Up Now.
• Ensure “Encrypt local backup” is unchecked.

Encrypted backups store data in a different way and require extra steps to inspect.

3. Locate the Backup Folder

Once done, the backup is stored in:

• macOS: ~/Library/Application Support/MobileSync/Backup/
• Windows: \Users\<username>\AppData\Roaming\Apple Computer\MobileSync\Backup\

Inside you’ll see one or more directories named with long hex strings (the device UDID). Each directory represents a backup session. You can directly navigate to particular backup by:

• Click on Manage Backups…
• Right click on individual backup.
• Click Show in Finder.

📂 Understanding iOS Backup Folder Structure

Unlike normal file systems, Apple’s backup folders do not store files with their original paths or names. Instead, every original file path is mapped to a SHA1-like hash name.

The mapping is stored in a SQLite database file called Manifest.db at the root of the backup folder. Backup folder contents typically look like this:

<UDID>/
├── Info.plist
├── Manifest.db
├── Manifest.plist
├── Status.plist
├── 0a/0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a
├── 0b/0b0b0b…
├── …

The subfolders (0a, 0b, etc.) are based on the first two characters of the hashed filename.

📑 Inside Manifest.db

Manifest.db is a SQLite database that maps original file paths inside the app sandbox to backup filenames.

The main table of interest is Files. Typical columns include:

• fileID — The hashed filename used in backup storage (this is the actual file in subfolders).
• domain — The logical container name, typically AppDomain-<bundle-id> for your app.
• relativePath — Path within the app’s sandbox, e.g., Library/Caches/image.png.
• flags — Indicators for file type and attributes.

🔍 Querying Manifest.db with SQLite

You can use the sqlite3 command-line tool (macOS has it built in).

Example: Find a specific file in the backup from app’s sandbox
Replace com.yourcompany.yourapp with your app bundle id

sqlite3 Manifest.db "SELECT fileID, relativePath FROM Files WHERE domain = 'AppDomain-com.yourcompany.yourapp' AND relativePath LIKE '%mydatabase.sqlite%';"

Example: Find a specific file in the backup from app group location
Replace group.com.yourcompany.yourappgroup with your app group

sqlite3 Manifest.db "SELECT fileID, relativePath FROM Files WHERE domain = 'AppDomainGroup-group.com.yourcompany.yourappgroup' AND relativePath LIKE '%mydatabase.sqlite%';"

In case you are running into access issue while querying Manifest.db, you can copy the Manifest.db file to folder you already have access to and run sqlite3 commands from there:

cp "~/Library/Application Support/MobileSync/Backup/<UDID>/Manifest.db" "~/Documents/Manifest.db"
cd ~/Documents
sqlite3 Manifest.db "<query>"

🗂 Extracting and Viewing File Content

Once you have the fileID from your query:

1. The backup file is stored in a subfolder named after the first two characters of fileID.
2. The file’s name in the backup is exactly the fileID string.

Example:

FILEID="0a123456789abcdef…"
cp "$(echo $FILEID | cut -c1-2)/$FILEID" ~/Desktop/extracted_file

The copied file is now in its raw form and can be opened with the appropriate viewer:

• .sqlite — open with DB Browser for SQLite
• .jpg / .png — open in Preview
• .json / .plist — view with a text editor or Xcode

Automating the Process

You can script extraction of all files in your app:

APPDOMAIN="AppDomain-com.yourcompany.yourapp"
sqlite3 Manifest.db "SELECT fileID, relativePath FROM Files WHERE domain = '$APPDOMAIN';" | while IFS='|' read FILEID RELATIVEPATH; do
  SUBDIR=$(echo $FILEID | cut -c1-2)
  SOURCE="$SUBDIR/$FILEID"
  DEST="~/Desktop/backup_extract/$RELATIVEPATH"
  if [ -f "$SOURCE" ]; then
    mkdir -p "$(dirname "$DEST")"
    cp "$SOURCE" "$DEST"
  fi
done

This will recreate your app’s sandbox folder on your Desktop from the backup data.

In case you are running into access issue, you can copy the backup folder to a folder you already have access to and run the script from this new folder location.

⚠️ Security Notes

• Backups contain sensitive user files: handle with care.
• Only debug using test devices or data with user consent.
• Avoid uploading extracted data to cloud storage unless anonymized.

Conclusion

Inspecting iOS backups via Manifest.db gives you full visibility into how your app is using storage on a real device. By linking the hashed filenames in the backup to their original paths, you can extract caches, databases, and media files to understand and fix excessive storage usage.

This method is fully native — no third‑party tools required, only Finder/iTunes and SQLite — and is a key skill for iOS developers debugging storage-related issues.

When we think about “debugging” we often imagine compiling our own source code in Xcode, setting breakpoints, and stepping through methods line-by-line.

But sometimes you’ll need to debug build not generated by you or without access to the original project source code — you might only have the compiled binary.

This is common in scenarios such as:

• Investigating an edge case bug that is only reproducible in an existing developer or QA installation.
• Debugging an .xcframework/.framework that has separate code base from your app.

A binary in this context is machine code generated by Xcode or another compiler, packaged for execution. Examples:

• .ipa: Packaged iOS application, containing the compiled executable and resources.
• .xcframework/.framework: Bundle containing multiple/single binary slices for different architectures (e.g., arm64 for device, x86_64 and arm64 for Simulator).
• Mac .app bundle or .dylib dynamic library.

Why debug a binary? You can inspect runtime conditions, test logic paths, and identify faults without rebuilding and reinstalling — as long as the app is correctly signed and you have the matching source files.

Attaching debugger to process

Xcode gives you multiple ways to connect its debugger to a process that is already running on your device or simulator.

This is essential when you:

• Launch the app outside Xcode (e.g. from App Library, or the command line).
• Start a background process or extension manually.
• Attach to a helper daemon or secondary executable.

Method 1: Attach to Process (GUI)

1. Open Xcode.
2. Select device on which process is running.

3. From the top menu, select Debug > Attach to Process.

4. A list of currently running processes will appear (on your connected device or Mac).

5. Click the target process name to attach.

Method 2: Attach to Process by PID or Name

1. From the menu, choose Debug > Attach to Process by PID or Name.

2. Enter either:

— PID: numeric process ID visible via ps command or Instruments.
 — Name: executable name (case-sensitive).

3. Xcode will connect to the process if code-signing and entitlements allow.

• Pro Tip: Use executable name to attach to a process that will be launched in future. Give your process unique name to avoid conflict with other app or extension processes.

Setting breakpoints

Once attached, breakpoints let you pause execution at specific points and inspect variables, call stacks, registers, and more. Even without access to source code or gutter you can still set breakpoints via Xcode or LLDB command line interface.

Symbolication & dSYMs

A symbolicated binary has mappings from compiled machine instructions back to human-readable names and source locations. These mappings are stored in dSYM files generated during compilation.
Without proper symbol files:

• Function names appear as raw memory addresses.
• You can still debug, but you’ll rely on disassembly and manual symbol demangling.

Breakpoints in Xcode

After attaching, you can create symbolic breakpoint:

1. Navigate to Breakpoint Navigator (⌘8)
2. Click on the Create a Breakpoint action button at the bottom
3. Click on Symbolic Breakpoint or other well known breakpoints (e.g. Swift Error Breakpoint)

Breakpoints via LLDB

LLDB gives fine-grained control over breakpoint creation through its command line interface:

(lldb) breakpoint set — name MyFunction

(lldb) breakpoint set — file MyClass.swift — line 42

(lldb) breakpoint set — address 0x1045a3b20

This is useful when debugging partial source or third-party code where only certain files are available or you need line/column based breakpoints instead of symbolic ones.

Pro Tip: Even without source, you can place breakpoints on symbol names extracted via:

(lldb) image lookup -n MyFunction

or

(lldb) image dump symtab MyFramework

Bonus Tip: You can also debug source code that Xcode doesn’t support. (e.g. Kotlin native in Kotlin Multi-platform use-cases)

Map to your source code

While you don’t necessarily need access to source code to debug, but having access to code does make debugging and possible fix simpler.

When a binary is built, dSYMs record absolute paths to source files from the build environment.

If your local paths differ from those recorded, Xcode/LLDB can’t open files when a breakpoint is hit.

Use LLDB’s target.source-map to remap locations for this session:

(lldb) settings set target.source-map /Users/buildmachine/workspace/project/ ~/projects/debug/

This tells LLDB:
“Whenever you look for files under /Users/buildmachine/workspace/project/, actually look in ~/projects/debug/ instead."

Pro Tip: Add your target.source-map in your .lldbinit file to automatically run these commands when lldb is started.

Why this matters: Without remapping, you can only debug disassembly instead of source code. Correct mapping restores full source view in Xcode.

Reference: LLDB Source Remapping

Conclusion

Debugging binaries is a powerful skill for diagnosing production issues or analyzing third-party code.

By using Xcode’s attach capabilities, mastering LLDB breakpoints, and remapping source paths, you can get deep insight into how an app is executing — even without the original project.

Pair that with secure entitlement management and you’ll have the ultimate reverse-debugging toolkit.

💬 What’s your most challenging “debug without source” moment? Share in the comments!

The evolution of Swift has brought swifter lanes for testing, with Swift Testing opening a new set of possibilities for unit, integration, and even functional testing in your apps. However, making the leap from XCTest to Swift Testing isn’t always straightforward. While Apple provides an official Migration Guide, this post isn’t here to rehash what’s outlined there. Instead, I focus on practical tips and insights I’ve gathered during my own migration journey — things that the official guide doesn’t dive into.

If you’re planning or are midway through migrating from XCTest to Swift Testing, this post is for you. By the end, you’ll better understand how Swift Testing operates under the hood, and how to navigate some of the intricacies and quirks that come with its adoption.

Swift Testing: Discovering and Executing Tests

Before we dive into the migration gotchas, it’s important to understand how Swift Testing discovers and executes its tests. XCTest follows a class-based approach, where each XCTestCase subclass serves as a container for test methods. XCTest framework discovers the tests by collecting all the XCTestCase classes and their methods with test prefix, all this are done with the help of objective-C runtime features. Swift Testing, on the other hand, takes a more Swift based approach of using macros to generate test description.

Test execution also differs in XCTest and Swift Testing. XCTest executes all the tests serially one by one, starting the next test only after the previous one is finished. This behaviour is applicable to async test methods as well. Swift Testing takes an approach based on Swift’s structured concurrency. Each test method under Swift Testing are executed concurrently, by creating a new @Suite instance each time and calling the test method on it inside a new task.

While these approaches align well with Swift’s evolution toward a functional and composable design, it introduces several challenges — challenges you are likely to encounter during the migration. Let’s explore some of them.

Challenge #1: Assertions Don’t Work Outside of a Task Context

One of the most significant changes in Swift Testing is that each test is executed as part of a separate task, hence assertions are only valid if any test is associated to the task context that the assertion is invoked on. Hence, any assertions that is done outside of test task context in XCTest, needs to be moved to test task itself. XCTest doesn’t have this limitation as there is only one test that is executed at any time in a single process, while Swift Testing prioritises in-process concurrent test execution.

For example, following code under XCTest:

func testExample() {
    DispatchQueue.main.async {
        // Testing a method that needs to be executed on a specifc queue
        let result = systemUnderTest()
        XCTAssertEqual(result, 4) // ERROR: Assertion outside of a task context.
    }
}

needs to be migrated to this under Swift Testing:

@Test
func example() async {
    let result = await withCheckedContinuation { continuation in
        DispatchQueue.main.async {
            // Testing a method that needs to be executed on a specifc queue
            let result = systemUnderTest()
            // #expect(result == 4) ❌ Outside of test task context
            continuation.resume(returning: result)
        }
    }
    #expect(result == 4) // ✅ Valid as back in test task context
}

Why This Matters

This requirement can feel cumbersome, especially when migrating tests for code that hasn’t been migrated to Swift Structured Concurrency. Plan to refactor your test structure to ensure assertions occur within the proper task-boundary.

Recommendation

• Avoid using concurrency paradigms, that are not in aligned with Swift’s Structured Concurrency in Swift Testing. Make sure all the Swift Testing APIs are used in the test task context.

Challenge #2: Shared Mutable State Issues

In Swift Testing, concurrency is a first-class citizen. While this is great for testing modern async-heavy codebases, it can lead to subtle issues with shared mutable state if you’re not careful.

Consider a shared resource being accessed by multiple tests:

actor Counter {
    static let shared = Counter()

    var count = 0
    func increment() { count += 1 }
    func decrement() { count -= 1 }
}

@Test("Test increment")
func inrement() async throws {
    print("Started increment check")
    await Counter.shared.increment()
    print("Sleeping increment check")
    try await Task.sleep(nanoseconds: 3_000_000_000)
    print("Completed Sleeping increment check")
    await #expect(Counter.shared.count == 1)
    print("Finished increment check")
}

@Test("Test decrement")
func decrement() async throws {
    print("Started decrement check")
    print("Sleeping decrement check")
    try await Task.sleep(nanoseconds: 1_000_000_000)
    await Counter.shared.decrement()
    print("Completed Sleeping decrement check")
    await #expect(Counter.shared.count == -1)
    print("Finished decrement check")
}

Why This Matters

By default, test tasks are not serialized, leading to the possibility of data races or undefined shared state behaviour. This is less common in XCTest, where tests often run sequentially, even when enabling parallel runs tests are run in parallel with separate processes where they won’t be able to access state of another process.

Recommendation

• Create a .serialized tagged parent test suite that contains child test suites with tests that are required to be run sequentially. This will make sure tests that can be run concurrently, an be executed concurrently.

@Suite(.serialized)
struct SerializedTests {
    struct Suite1 {
        @Test
        func stuff() async throws {
            // Execute test code
        }
    }
}

extension SerializedTests {
    struct Suite2 {
        @Test
        func stuff() async throws {
            // Execute test code
        }
    }
}

• Avoid shared state. Make state modifications local to each test. If you must use shared resources, use @TaskLocal with Test Scoping. This ensures each test have their own copy of mutable state. To use this you will have to migrate the code that accesses this state to Swift Structured Concurrency. You can migrate test suites one by one from the serialized suites created in above step.

class APICredentials {
    // Step-1: Apply @TaskLocal to static field
    @TaskLocal static var current = APICredentials()
}

// Step-2: Migrate code that uses the static field to Swift Concurrency

// Step-3: Create Test Scope for mocking shared state
struct MockAPICredentialsTrait: TestTrait, SuiteTrait, TestScoping {
    func provideScope(for test: Test, testCase: Test.Case?, performing function: @Sendable () async throws -> Void) async throws {
        let mockCredentials = APICredentials(apiKey: "...")
        try await APICredentials.$current.withValue(mockCredentials) {
            try await function()
        }
    }
}

// Step-3: Define tag name for the test scope usage
extension Trait where Self == MockAPICredentialsTrait {
    static var mockAPICredentials: Self {
        Self()
    }
}

// Step-4: Use the test scope as tag with tests and test suites
@Test(.mockAPICredentials)
func example() {
    // ...validate API usage, referencing `APICredentials.current`...
}

Challenge #3: Inheriting Suites Doesn’t Inherit Its Tests

In XCTest, if you subclass a XCTestCase, the inherited test methods are automatically part of the subclassed XCTestCase. This is because test methods are defined as part of class and can be discovered easily with class inheritance hierarchy. In Swift Testing, even if you declare tests as methods in class, they are actually definitions generated by @Test macro, not tied to class definition in any actual sense:

@available(*, deprecated, message: "This function is an implementation detail of the testing library. Do not use it directly.")
@Sendable private static func $s22SwiftTestingUsageTests12CounterSuiteV8inrement4TestfMp_9Z181b5ab3fMu_() async throws -> Void {
  let $s22SwiftTestingUsageTests12CounterSuiteV8inrement4TestfMp_7__localfMu_ = try await Testing.__requiringTry(Testing.__requiringAwait(CounterSuite()))
  _ = try await Testing.__requiringTry(Testing.__requiringAwait($s22SwiftTestingUsageTests12CounterSuiteV8inrement4TestfMp_7__localfMu_.inrement()))
}

@available(*, deprecated, message: "This type is an implementation detail of the testing library. Do not use it directly.")
enum $s22SwiftTestingUsageTests12CounterSuiteV8inrement4TestfMp_38__🟠$test_container__function__181b5ab3fMu_: Testing.__TestContainer {
  static var __tests: [Testing.Test] {
    get async {
      return [
  .__function(
    named: "inrement()",
    in: CounterSuite.self,
    xcTestCompatibleSelector: nil,
    displayName: "Test increment",traits: [],sourceLocation: Testing.SourceLocation(fileID: "SwiftTestingUsageTests/SwiftTestingUsageTests.swift", filePath: "/Users/soumya.mahunt/Documents/moengage/pocs/swift-testing-usage/Tests/SwiftTestingUsageTests/SwiftTestingUsageTests.swift", line: 22, column: 6),
    parameters: [],
    testFunction: $s22SwiftTestingUsageTests12CounterSuiteV8inrement4TestfMp_9Z181b5ab3fMu_
  )
]
    }
  }
}

Why This Matters

In your XCTest suite you might rely on test inheritance, to assert same behaviours with multiple configurations.

class FeatureAWithConfigX: XCTestCase {
    override setup() {
        // setup config X
    }

    // Test behaviour
    func testStuff() {}
}

class FeatureAWithConfigY: FeatureAWithConfigX {
    override setup() {
        // setup config Y
    }

    // No need to write tests for same behaviours
}

You could miss important tests during the migration.

@Suite
class FeatureAWithConfigX {
    init() {
        // setup config X
    }

    // Test behaviour
    @Test
    func stuff() {}
}

@Suite
class FeatureAWithConfigY: FeatureAWithConfigX {
    override init() {
        // setup config Y
    }

    // Write the tests again?
}

Swift Testing as of now doesn’t support such test organization, this may require restructuring your test hierarchy.

Recommendation

• If you have smaller number of tests and these tests can be migrated to Swift Parametrized Testing, opt for that.
• Otherwise currently, you can combine XCTests and Swift Testing in the same target. Wait for test inheritance to be available in Swift Testing before migrating these type of tests.

Wrapping Up: A Mindful Migration

Migrating from XCTest to Swift Testing is not a mere mechanical process. It’s an opportunity to rethink your test design and embrace modern Swift paradigms like structured concurrency and immutability. However, it also comes with its own challenges, including the need to adapt to task contexts for assertions, deal with concurrency issues, missing test inheritance and absence of UI testing and performance testing APIs.

By keeping in mind the issues outlined here — and planning ahead — you can ensure a smoother migration. And remember, don’t just rely on the official migration guide. Your own experience and insights, coupled with community knowledge, will be your best tools.

What challenges have you faced while migrating to Swift Testing? Drop your thoughts in the comments below!

Happy testing! 🚀

Bonus

Swift testing common conversion scenario script.

With the introduction of macros in Swift 5.9, removing common boilerplate from code has never been easier in Swift. However, the development of macros is more closely tied to Swift Package Manager, and depending on your use cases this might be a limitation to you, whether you are a macro library author losing out on CocoaPods users, or you are planning to introduce macro to an existing code base that hasn’t adopted SwiftPM.

In this article, we will discover how to create CocoaPods macro library from a Swift macro package and distribute it similar to any other CocoaPods library.

Basics of SwiftPM Macro library

Xcode 15 supports creating macro library with SwiftPM right out of the box with custom template Swift Package template:

When you create a a macro package, you will notice following things in your Package.swift manifest:

• A macro target containing macro implementation which uses swift-syntax as dependency.
• A library target containing macro definition and uses macro target as dependency.

When going into macro target you will find a type that conforms to CompilerPlugin with all the macros provided inprovidingMacros property, and has the @main attribute attached:

You might have noticed this @main attribute before to declare application execution entry point. In fact, a macro is also an application/program, that generates some code output based on input. The only difference is that macros run on the host platform (i.e. macOS, the platform that builds application) not on the target platform (i.e. iOS, tvOS etc. the platform application will run on). This allows macros to not introduce additional overhead when user is running the application.

In the next section, we will see how Swift allows macro executables to be passed directly without SwiftPM usage.

Macros outside SwiftPM

Swift exposes two input options for macros to be injected directly from command line:

-load-plugin-executable <path>#<module-names>
Path to an executable compiler plugins and providing module names such as macros
-load-plugin-library <path>
Path to a dynamic library containing compiler plugins such as macros

From the previous section we know that macro is a simple program and now we can build it as an executable and provide executable path and macro module name to Swift in -load-plugin-executable to use the macro executable:

Now that we have the macro executable ready, we can move to creating the podspec for our CocoaPods macro library.

Create CocoaPods macro library

Now we can create macro library podspec, that will provide the macro executable to Swift:

Few things to note here in the podspec:

• Macro definition files are added to source_files.
• The path to macro executable is added to preserve_paths so that CocoaPods doesn’t delete it after pod install.
• The macro executable path and module name argument are provided to user_target_xcconfig as OTHER_SWIFT_FLAGS, the executable must be provided to user/app target not to our library target.

While this will work just like other CocoaPods library, the major limitation of this approach is you need the macro executable beforehand. As a library author, this introduces additional challenge of building executable as part of Continuous Deployment workflow, choosing additional host for distributing with CocoaPods or to add the executable among source files itself (making the package cloning for SwiftPM slower). In the next section, we will see how we don’t need to have pre-built executable and distribute macro implementation source files just like we do in SwiftPM.

Bringing CocoaPods macro library to SwiftPM level

The only approach to use macro outside SwiftPM is to provide the macro product from command line, but we don’t have to build the macro product before hand, we can add the macro product building task as script_phase and provide the built executable to Swift.

While you can use other tools like cmake, here we will use SwiftPM to build our macro executable using the same Package.swift manifest, and update the podspec with new details:

Additional things to note in our new podspec:

• Package.swift manifest and macro source files are added to preserve_paths instead to make sure these files don’t get deleted by CocoaPods after pod install.
• Xcode build environment variables are not passed to Swift build task using command env -i PATH=”$PATH” “$SHELL” -l -c, to allow Swift building for our host platform not target platform.
• In the Swift build task:
  - Macro executable product MyMacroMacros is built with release configuration.
  - Path to host machine SDK is provided with xcrun — show-sdk-path, as macro will be built to run on host machine.
  - The path to Package.swift manifest directory is provided with — package-path option and the location of macro target build files provided with — scratch-path option.
• In the script_phase, Package.swift manifest and macro source files are provided as input_files and built macro executable is provided as output_files. This allows the build task to only run if there is change in source files or the executable product hasn’t been built yet, optimizing the build process.
• The script_phase runs before compiling allowing the macro executable to be provided to Swift build process.
• The new macro executable path and module name argument are provided to user_target_xcconfig as OTHER_SWIFT_FLAGS, the executable must be provided to user target/app not to our library target.

Advantages over SwiftPM

The subtle advantages of distributing macros with CocoaPods in this approach over SwiftPM are :

• The deployment target needs to be set higher to allow swift-syntax usage, in case of SwiftPM. By separating macro definitions from the implementation, we can set lower deployment target for our macro library.
• In case of SwiftPM, swift-syntax version will be resolved to a common version, thereby introducing chances of version conflicts. While here, since macro implementation is separate, each CocoaPods macro library can use separate swift-syntax version independently.

Conclusion

By following these steps, now macro libraries can also be distributed as CocoaPods library, same as we can already distribute as Swift package. The library can be included by Xcode targets in the same way as any other CocoaPods library. For more concrete example, you can have a look at my Codable macro library MetaCodable‘s Package.swift manifest and podspecs.

In the first part of this series, we saw building dynamic UI leveraging loose coupling of IB-built UIs. If you have not read it, go through it first. This article will build up on the major limitations it had. The main one cannot add or update controller logic code or event triggers/actions. This article will leverage JavaScript for dynamic logic and our dynamic UI from Interface Builder.

We will dive deeper into Objective-C runtime and advanced features like dynamic method resolution and message invocations while using Swift. We will also bridge types between JavaScript and Swift, establishing two-way communication between these runtimes.

Why JavaScript?

The goal we are trying to accomplish here is to enable dynamic logic populated by the remote server without updating the app. Due to iOS security limitations, it is not possible to add and load the random dynamic library after the app’s published to the store:

To protect the system and other apps from loading third-party code inside their address space, the system performs a code signature validation of all the dynamic libraries that a process links against at launch time.

This prevents us from using compiled languages like Swift. The workaround is to use interpreted languages like JavaScript and Python. Since iOS already has a JavaScript interpreter bundled with the system browser and with the help of JavaScriptCore, we can establish Swift-JavaScript communication easily. We are going to use JavaScript for this example.

Bridging Swift-JavaScript

JavaScriptCore framework allows us to establish a two-way communication bridge between JavaScript and Swift, sharing data, invoking methods, and passing callbacks. We must create a JSContext to execute JavaScript code to achieve this communication. Since we want to allow UI modification from this context, we must create the JSVirtualMachine to host this context from the main thread. This will allow JSVirtualMachine to inherit the main thread’s run-loop for code execution.

We are passing the Swift controller instance to JavaScript to allow direct modification. Since we need to keep string reference of this context to ensure the lifetime is the same as the controller, the controller instance is passed as a weak reference wrapped inside a closure to avoid retaining the cycle.

Passing the object to JavaScript doesn’t allow access to all the instance methods or properties. We have to manually export them by confirming them to JSExport. We must create an export protocol that inherits JSExport for each class and add the desired properties and methods to export. For this example, we will expose the IBOutlets of the controller and text property for UILabel.

Now, we are ready to consume JavaScript code from the server and execute it in created context. The file will be provided with the same approach as the nib files used by the server in the previous article. We can extract the content of the downloaded file and execute it in our context.

Now that we have the JS bridge set up, in the next sections, we will discuss how to expose all the IBOutlets dynamically and forward action events to JavaScript.

Dynamic IBOutlets

IBOutlets are used to keep a reference of UI objects to modify their behaviour later, i.e., changing text, colour, etc. Typically, one IBOutlet can be attached to one property, or multiple IBOutlets can be attached as a group to an array property. In this section, we will store outlets as key-value pairs, with the key being the property name defined in xib or storyboard.

Adding @IBOutlet to the property field achieves the following things:

• Expose the field name to IB to give feedback in Xcode on whether the outlet is attached.
• In the case of Swift, the property is exposed to Obj-C similar to @objc attribute, and makes the property accessible via key-value coding.

During the initialization of the controller from nib, all such outlets are assigned with key-value coding using setValue(_:forKey:), where the UI object is passed as value and the outlet field name as the key. In our case, since the field doesn’t exist, setValue(_:forUndefinedKey:) is invoked, which by default raises an exception.

Terminating app due to uncaught exception ‘NSUnknownKeyException’, reason: ‘[<{controllerClass} {address}> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key {outletName}.’

where controllerClass is the controller class name, address represents memory address, and, most importantly, outletName represents the outlet that is not attached. This exception is being raised since we don’t have any property with the outlet name exposed.

To avoid exceptions and accomplish our task, we can override this method to store the objects in our own dictionary. Similarly, we have to override value(forUndefinedKey:) to allow getting the properties from our custom dictionary.

Now that we have exposed outlets to JavaScript, we can set exported properties from JavaScript code. Let’s see the label’s text live update after attaching Safari Web Inspector to our JSContext and setting the label’s text.

Dynamic IBActions

Similar to IBOutlets, IBActions are just Obj-C methods that can be invoked via messaging. When the associated event is triggered, the message is passed with the attributes specified. The absence of methods causes exceptions on the event trigger.

Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[{controllerClass} {actionSelector}]: unrecognized selector sent to instance {address}’

To resolve this for our use case, we can forward the method invocation to the JavaScript object that contains the implementation. There are multiple ways of adding message forwarding in Obj-C:

• Dynamic method resolution: After getting a call back in resolveInstanceMethod(_:) for an unimplemented method class_addMethod(_:_:_:_:) can be used to provide a dynamic implementation.
• Message Forwarding: Messages related to unimplemented methods can be forwarded to another object that handles the message. Forwarding has two approaches:
  - Using forwardInvocation: which is only available in Obj-C.
  - Using the less expensive forwardingTarget(for:) available in Swift.

In this example, we will use the first approach, supporting up to two arguments. Since the direct conversion of Swift variadic methods to C variadic methods is impossible, we must implement multiple methods based on the arguments count approach. The advantage of resolveInstanceMethod(_:) is it is invoked once for a selector and class type combination. Subsequent message passing will pick up the selector implemented in the first instance.

Note that resolveInstanceMethod(_:) will also be invoked for dynamic IBOutlets, but since we already have a specific implementation in place for them, we can only provide an implementation for IBActions. In the snippet provided above, we are detecting selectors beginning with action as our dynamic IBActions.

With the client implementation complete, we can create our JavaScript file that initializes our dynamic page with some data, implements dynamic IBActions that handle the callback from our dynamic view, and uses dynamic IBOutlets to update data in the dynamic page.

Let’s see our work in action

Our sample app with a simple counter is now ready and completely functional, with all the user actions being reflected on UI timely and properly. The beauty of this is our dynamic UI is completely native, and our controller logic is completely dynamic. Finally, we have achieved a completely server-driven UI and server-driven state and user-action management.

Now we can modify our controller logic and page UI by modifying their corresponding js and xib file, respectively. After rerunning our server to publish the latest changes, we can refresh our implemented dynamic page (by trying to land on the page again) to see our latest UI changes and user interaction effect without redeploying or restarting our iOS client app.

Conclusion

Although this example built is pretty simple, this can be extended to build a fully functional app.

• Using caching for better page load performance
• Using versioning to tie nib/storyboard files with their js counterpart and avoid runtime exceptions possible due to IBActions mismatch.
• Using native code that can be populated with data from the JavaScript layer to perform complex UI modifications, i.e., animations, etc.

This, in principle, works like a website while behaving like a native app. You can build a complete server-driven app solution with a completely native UI and customisable state, user-action, and routing management.

The one side effect of using this approach is that since view-controllers are being passed to JavaScript, JavaScript memory management rules also apply to them. The controller will be deallocated once JavaScript’s GC releases its reference. Unlike Swift’s ARC uses a different GC algorithm which releases memory periodically, and hence there will be some delay in deinit invocation after popping back from a controller.

Let me know if you are using any other approaches for your server-driven app. Also, let me know if you see any drawbacks to this approach. The complete implementation can be found at:

GitHub - SwiftyLab/DynamicNib: Dynamically load nibs in ios app

The following are the resources used for this article. You can delve deeper into these for more details:

• App code signing process in iOS and iPadOS
• About Key-Value Coding
• Messaging
• Dynamic Method Resolution
• JavaScriptCore | Apple Developer Documentation
• Memory management - JavaScript | MDN

Combining Interface Builder With JavaScript for Server-driven Apps was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is huge debate among iOS developers regarding different approaches of building application user interface, the approaches being categorized as: Interface Builder (Storyboards/XIBs/NIBs), Code (Custom/SwiftUI) with each having their pros and cons that this article won’t go deep into. With the advent of SwiftUI building UI with code has become lot easier while allowing a lot more reusability. I read lots of posts comparing all these approaches, and none mentioned this particular advantage of building UI with Interface Builder due to the clear separation of UI from logic.

Typically when adding dynamic UI that needs to be consistent across app versions and can be updated without updating the app itself, UI is built with web frameworks while displayed using web-view. Similarly, while building third party framework or SDKs i.e. payments SDK, consumers can customize the UI without having access to data or state. In this article, we will see this use case being fulfilled by using completely native UI stack with the help of Interface Builder.

Interface Builder mechanics

Before diving into the use case and the advantage of Interface Builder, let’s first understand how IB works. The visual diagram built with IB is stored in XML format in xib or storyboard files. In fact, XIB stands for XML Interface Builder which is the oldest file format for IB. During build phase, the xib and storyboard files are compiled into nib and storyboardc by ibtool and copied inside the app directory or a specified bundle.

These files can then be loaded into memory by using UINib and UIStoryboard initializer or UIViewController initializer for view controllers defined in a XIB, and subsequently view objects can be created. Due to this separation of UI in a separate file, building UI with code performs better as no file load is needed. But this kind of separation has the following benefits:

• Smaller update package when only xibs or storyboards are modified in newer version, i.e. only the nib or storyboardc files are updated.
• Sharing same view object code across multiple nibs, i.e. using the same UITableViewCell sub-class for multiple cell nibs.
• Independently update UI of the app without modifying underlying control logic.

While updating UI of the app dynamically without pushing app updates can be done in building UI with code approaches as well, but that requires establishing custom serialization and deserialization framework that takes some data from remote server to build dynamic UI. But with IB the unarchiving part is already provided by iOS, we just have to take advantage of it after implementing fetching data from remote server. In the subsequent part, we will implement a POC showcasing this use case in action.

Providing dynamic UI from server

To test the length of loosely coupling of UI built with IB and controlling logic, we will not add the nib files in the distributed app. Rather we will build a sample server that provides all the nib files. We will use vapor to build our server in Swift, that provides requested nib files to our iOS client.

Since our xib files aren’t included in an iOS product, they won’t be compiled to nib automatically by Xcode. But we can write a build tool Swift package plugin that compiles these files to nib by using ibtool as part of our server build process:

Now that in the nib files are generated as part of our build process and copied to server app’s bundle, we can provide these file to our iOS clients depending on the file name specified in the request made by client:

Building client with dynamic UI

With the changes our server is now ready to provide nib files to our iOS client, now, we just have to implement downloading these files and loading into memory to unarchive UI objects. But just downloading the file isn’t enough as to load file in the memory we need to specify the bundle that provides the file. If we look at any bundle, it is just a directory ending in .bundle. For our use case, we can just create such directory and store our IB files:

Now, with that out of the way, we can implement downloading the nib files and storing inside our newly created bundle directory. We can pass the file name and bundle instance to controller initializer, and display the dynamic page in our app.

We can use the same approach to register and display dynamic table view cells in our app as well. For tableview cells, we have to take extra care to not invoke the cell display logic in case the nib file isn’t downloaded already, doing so will prevent runtime exceptions.

The moment of truth

Now we can modify our controller and cell UI by modifying their corresponding xib file and rerunning our server to publish the latest changes. We can refresh our implemented dynamic page (by trying to land on the page again) to see our latest UI changes without having to redeploy or restart our iOS client app.

One caveat with this is, as long as all the IBOutlets and IBActions are intact in the xib or storyboard file, the controller logic will work without any impact. Otherwise there is possibility of runtime exceptions with this approach. Additionally, in controller logic some IBOutlets can be declared optional to allow removal of such elements without causing exceptions in client iOS app.

Conclusion

Although the UI change shown here is only for xib file and pretty simple, this can be extended to storyboard file and complete UI revamp can be done by keeping IBOutlets and IBActions with the controller logic. Additionally, caching can be introduced for better page load performance and versioning of dynamic nibs can be implemented to link with controller logic present with multiple client app versions, preventing exceptions with missing IBOutlets and IBActions.

Let me know if you are using this approach in your app or are planning to build something like this. Also, if you are using any different approach for such use cases, let me know what drawback you foresee with this approach. The complete implementation can be found at:

GitHub - SwiftyLab/DynamicNib: Dynamically load nibs in ios app

Following are the resources used for this article, you can delve deeper into these for more customized use cases:

• XCode: Using Storyboards and Xibs Versus Creating Views Programmatically
• Create Swift Package plugins - WWDC22 - Videos - Apple Developer
• Vapor Docs

In the next part of this series, we will discuss making controller logic dynamic as well allowing to circumvent IBOutlets and IBActions limitations, allowing us to onboard completely new user journeys without any app update.

Superpower of Interface Builder no one talks about was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Swift Structured Concurrency is a relatively new feature introduced with Swift 5.5. It is an innovative approach to managing asynchronous tasks that prevents task leaks, ensures cooperative cancellation, and makes the control flow more reasonable in a concurrent context rather than the earlier approach of passing callbacks. While this idea is constantly evolving with new features, one feature that is sorely missing is the simpler management (i.e cancellation) of unstructured tasks.

In this post, we will explore managing unstructured tasks in Swift Structured Concurrency and handling cancellation for unstructured tasks. We will look into other languages’ approaches and how we can do something similar in Swift.

Why do we need unstructured tasks?

Swift provides ways of creating structured tasks with async let keyword and TaskGroup which simplifies error propagation, cooperative cancellation, and execution from an asynchronous context by managing the hierarchy of tasks. These approaches should be preferred to creating unstructured tasks. However, for some scenarios, where there is no clear hierarchy of tasks, it is absolutely necessary to use unstructured tasks:

• Launching tasks from non-async code, i.e. fetching content from a server to display on UI.
• Managing the lifetime of tasks based on some events, i.e terminating some account-specific async work when the user logs out of the account.

Unstructured tasks can be created by using Task APIs, with an option to whether created task inherits actor context or not. To manage the cancellation of such tasks, we have to store the task instance and invoke the cancel method when such a need arises. But in such cases, we also have to take an accounting not invoking cancel method for tasks that are completed successfully.

Exploring other structured concurrency runtimes

Kotlin has the concept of CoroutineScope using which newly spawned coroutines/asynchronous work can be canceled by canceling the scope. While CoroutineScope has other functionalities as well we will only consider the cancellation mechanism in this post:

.NET takes this cancellation mechanism one step further with CancellationToken and CancellationTokenSource by allowing linking external CancellationToken with CancellationTokenSource. When canceling a single source instance all the linked instances are also canceled:

Implementing unstructured tasks cancellation handling

While Swift doesn’t have any such built-in construct, we can create our own using the built-in cooperative cancellation mechanism. Using built-in TaskGroup we can register tasks to be canceled with the built-in cancellation handler:

By using this mechanism we can cancel all the tasks that aren’t completed by canceling the group. Some caveats we have to take into account:

• TaskGroup can’t be used outside of tasks where it was created, hence we have to use AsyncStream for submitting tasks to TaskGroup. And since Task is a generic type, our AsyncStream’s element type should be an existential type to handle all variations:

• Awaiting Task's result increases the priority of the task to the caller task’s priority. Hence we have to use the least priority for our cancellation task to avoid this side effect.

Keeping these in mind, the implementation of our CancellationSource looks something like this:

We are using AsyncStream's continuation to register tasks for cancellation and terminating the stream in the event of cancellation. Note that, tasks are canceled instantly if submitted after cancellation has already been triggered.

We can even go one step further and allow registration of CancellationSources to be canceled. We can implement Cancellable protocol for CancellationSource with the help of waiting for the cancellation task’s result:

We can apply this implementation in an UIKit controller instance. We can keep two CancellationSource one that is canceled when the instance is deallocated and another canceled when the controller goes out of the user’s view. By keeping two cancellation sources, we can reason about whether an asynchronous work should be performed as long as the instance is alive on memory i.e. updating the view based on the app’s central state, or whether asynchronous work only needs to be performed when the controller instance is on user’s view i.e. fetching some data asynchronously to display user.

Further improvements

There are certain limitations to this type of cancellation handling:

• When linking multiple CancellationSource there might be a possibility of circular linking. In such cases, the cancellation task will leak and never finish. This can be handled by only allowing linking during the initialization of a CancellationSourceand preventing registration after initialization.
• TaskGroup stores results of submitted tasks, and since these results are not consumed by the cancellation task, long usage of CancellationSource might leak child tasks. Fortunately by using upcoming DiscardingTaskGroup such leaks could be prevented.

Conclusion

Swift Structured Concurrency is evolving with every new version of Swift with the goal of being feature complete by Swift 6. With this article, I want to start a series of posts filling the feature gaps with other concurrency runtimes during the initial adoption phases. Managing unstructured tasks is an essential aspect of Swift Structured Concurrency, and developers should follow best practices to ensure that they manage unstructured tasks effectively. Let me know in the comments what other methods you are using to manage unstructured tasks and any other feature gaps you perceive in the new concurrency features.

The final implementation along with other primitives that might ease adoption are available below.

• AsyncObjects/CancellationSource.swift at main · SwiftyLab/AsyncObjects
• GitHub - SwiftyLab/AsyncObjects: Several synchronization primitives and task synchronization mechanisms introduced to aid in modern swift concurrency.

Further reading

• Explore structured concurrency in Swift - WWDC21 - Videos - Apple Developer
• Swift concurrency: Behind the scenes - WWDC21 - Videos - Apple Developer
• swift-evolution/0381-task-group-discard-results.md at main · apple/swift-evolution

How to manage unstructured tasks with Swift’s structured concurrency was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Providing dynamic content in your app requires communicating with an external service to fetch data. The most common format that is used nowadays is JSON and the common way of handling JSON data in swift is to convert it to swift types with help of Codable. In the majority of the use cases, the data can be represented with a concrete swift type having a static list of properties.

In other cases, when the content in your app is highly dynamic with a wide range of scope, the response data may vary between a wide range of formats. Some common examples are:

• Building dynamic server-driven UI with CMS.
• Display a wide range of products on an e-commerce website.
• Dynamic content feed in a social network.

In this post, we will see the typical way of handling decoding these kinds of responses, and how DynamicCodableKit makes it seamless to handle dynamic responses by building on top of Swift’s Codable.

Current State

Following is Amazon’s suggestion response data when a user types any text in the search box, in this scenario “microwave”:

The suggestions property contains a list of dynamic results for the search, with each result containing a field type representing the actual type of result. In the above response, KEYWORD and WIDGET type results are received, with each type containing some additional metadata, which in turn is used to present the additional option to users like this:

One approach is to use a single struct with optional fields. Although this approach seems simpler, with this approach you can use default synthesized Codable implementation. The drawback of this approach is you have to pollute your business logic with data validation code and for cases where the same property can have a different type you are out of luck with this approach.

Another and much-preferred approach is to use an enum with associated values. It addresses the shortcoming of the previous approach of removing nil property requirements and solving property type conflicts by adding separate cases for each type to decode. Custom init(from:) implementation for the enum can be provided that will decode the underlying case/type.

In our example, we can check the type field for each object and decode the suggestion accordingly:

Using DynamicCodableKit

While the above approach works for responses with a smaller level of dynamism, it becomes much harder to maintain all this boilerplate. The major drawback is you have to do some additional work to access common properties across all cases and with enums, you have to update all the switch cases each time you add a new type.

This is where DynamicCodableKit shines by using generic property wrappers instead. It handles dynamic decoding based on DynamicDecodingContext which is a type erasure that decodes a specific DynamicDecodable type and casts it to its generic type. You can customize DynamicDecodingContext in different scenarios to dynamically decode multiple types. DynamicCodableKit also provides multiple configurations for collection decoding, to customize what happens when invalid data is encountered, i.e. you can choose to decode only valid data while ignoring invalid data instead of just throwing an error.

For our current example, we can create a Suggestion protocol type that will provide access to common properties and methods for underlying actual Suggestions, i.e. KeywordSuggestion, WidgetSuggestion. SuggestionType and SuggestionTypeCodingKey can implement DynamicDecodingContextIdentifierKey and DynamicDecodingContextIdentifierCodingKey respectively to decode the actual types. Compared to the previous approach, adding new types only requires changing SuggestionType's associatedContext implementation:

NOTE: By default, DynamicDecodable only supports down casting, if you want to cast to an unrelated type, you have to provide a custom implementation.

Conclusion

Besides the above example, DynamicCodableKit provides several property wrappers and associated protocols to handle various dynamic decoding scenarios, all of them explained in detail in the documentation making dynamic decoding a lot simpler to use with minimal boiler-plate.

GitHub - SwiftyLab/DynamicCodableKit: Implement dynamic JSON decoding within the constraints of Swift's sound type system by working on top of Swift's Codable implementations.

Decoding Dynamic JSON with Swift Codable was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.