DEV Community: Nick Vasilev

Swift Concurrency: Part 2

Nick Vasilev — Fri, 07 Nov 2025 10:38:21 +0000

Introduction

In the previous article we consider the foundation of Swift Concurrency: a multithreading technique which lies underlying Swift Concurrency, definition of the Task, the difference between Task and Task.detached, and managaning priorities. If you haven't read this, check it out here. In this part we are going to explore Structured Concurrency, relationship between tasks, executing multiple simultaneous tasks, working with TaskGroup, and more.

Lightweight Structured Concurrency

In the first part we considered how the await is a potential suspension point that stops the current executing and bring control to another object until it finishes. But if operations are independent and can be run simultaneously.

The Swift Concurrency provides with a simple solution for this case. Let's image that we need to perform multiple requests which aren't dependent on each other, for this we can use async let construction.

func loadData() async throws {
    async let profile = try await userService.profile()
    async let configuration = try await configurationService.configuration()

    dashboardService.load(await profile, await configuration)
}

In this case, these two operations will run simultaneously. The dashboardService will wait for the results of the previous requests before proceeding.

Task Cancellation

One important aspect of working with concurrency is the ability to cancel operations. Swift Concurrency provides built-in support for cancelling tasks, allowing developers to efficiently manage resources and respond to changing program conditions. In this section, we will explore how task cancellation works in Swift.

If one of these operations runs into an error, all of them will be cancelled. If you want to manually cancel these operations, you can call the cancel() method on Task.

let task = Task { [weak self] in
  self?.loadData()
}
task.cancel()

The cancel() method doesn’t immediately stop an operation. It works similarly to cancel in OperationQueue: it marks a task as cancelled, but you must handle this case manually.

Task {
    let task = Task {
        if Task.isCancelled {
            print("Task is cancelled, \(Thread.currentThread)")
        }

        print("Starting work on: \(Thread.currentThread)")
        try? await Task.sleep(nanoseconds: NSEC_PER_SEC)
        print("Still running? Cancelled: \(Task.isCancelled)")
    }

    task.cancel()
}

// Task is cancelled, <_NSMainThread: 0x600000ff0580>{number = 1, name = main}
// Starting work on: <_NSMainThread: 0x600000ff0580>{number = 1, name = main}
// Still running? Cancelled: true

To handle task cancellation, you can either check the Task.isCancelled property or call try Task.checkCancellation(), which throws a general cancellation error that can be propagated to the user.

Task {
  let task = Task {
    print("Task is cancelled: \(Task.isCancelled), \(Thread.current)")
    if Task.isCancelled {
      print("Task was cancelled sorry, \(Task.isCancelled)")
    } else {
      try? await Task.sleep(nanoseconds: NSEC_PER_SEC * 1)
      print("Job done \(Thread.current)")
    }
  }

  task.cancel()

// Task is cancelled: true, <_NSMainThread: 0x600002164580>{number = 1, name = main}
// Task was cancelled sorry, true
}

Task {
  let task = Task {
    print("Task is cancelled: \(Task.isCancelled), \(Thread.current)")
    do {
      try Task.checkCancellation()
      try? await Task.sleep(nanoseconds: NSEC_PER_SEC * 1)
      print("Job done \(Thread.current)")
    } catch {
      print("\(error), \(Thread.current) ")
    }
    print("end of task \(Thread.current)")
  }

  task.cancel()

// Task is cancelled: true, <_NSMainThread: 0x600000ec4580>{number = 1, name = main}
// CancellationError(), <_NSMainThread: 0x600000ec4580>{number = 1, name = main} 
// end of task <_NSMainThread: 0x600000ec4580>{number = 1, name = main}
}

In this example, the inner task does not automatically respond to cancellation:

Task {
  let parentTask = Task {
    print("Parent is cancelled: \(Task.isCancelled), \(Thread.currentThread)")

    Task {
      print("Nested task is cancelled: \(Task.isCancelled), \(Thread.currentThread)")
    }
  }

  parentTask.cancel()
}

// Parent is cancelled: true, <_NSMainThread: 0x600001960580>{number = 1, name = main}
// Nested task is cancelled: false, <_NSMainThread: 0x600001960580>{number = 1, name = main}

Here, we create a task and launch another Task inside it. When we call task.cancel(), the outer task is marked as cancelled, but the inner task continues to run. This happens because cancellation does not automatically propagate to nested tasks.

Task {
    let task = Task {
        await withTaskCancellationHandler {
            try? await Task.sleep(nanoseconds: NSEC_PER_SEC * 1)
            print("Print job done: \(Task.isCancelled), \(Thread.currentThread)")
        } onCancel: {
            print("Task cancelled: \(Task.isCancelled), \(Thread.currentThread)")
        }
    }

    task.cancel()
}

// Task cancelled: true, <_NSMainThread: 0x600003d80580>{number = 1, name = main}
// Print job done: true, <_NSMainThread: 0x600003d80580>{number = 1, name = main}

TaskLocal

Task-local values allow you to store and access data within the scope of specific tasks. This can be useful when you need to propagate contextual information — for example, tracking a user role, request ID, or configuration setting across a chain of tasks without explicitly passing it as a parameter.

Just like task priorities, detached tasks do not inherit the task context. That’s why task-local values revert to their default state when accessed from a detached task.

private enum Context {
  @TaskLocal static var locale: String = "en_US"
}

func performTask() async {
  print("Outer locale: \(Context.locale)")

  Task {
    print("Before change: \(Context.locale)")

    Context.$locale.withValue("fr_FR") {
      print("Within withValue: \(Context.locale)")

      Task.detached {
        print("Detached locale: \(Context.locale)")
      }
    }
  }
}

// Outer locale: en_US
// Before change: en_US
// Within withValue: fr_FR
// Detached locale: en_US

In this example, the task-local variable locale initially has the value "en_US".

When the value is temporarily overridden with "fr_FR" using withValue(_:), the new value is visible only within that specific task hierarchy. However, when a detached task is created, it doesn’t inherit this context and therefore prints the default "en_US" role again.

Task Group

Task groups are useful when dealing with a dynamic number of tasks.

Unlike async let, which is designed for a fixed number of concurrent tasks known at compile time, task groups allow you to create and manage tasks dynamically — for example, when processing a collection of items or running parallel network requests of unknown count.

Conceptually, a TaskGroup is similar to a DispatchGroup, but with native support for Swift concurrency features such as structured cancellation, error propagation, and task priorities.
All child tasks in the group inherit the priority of their parent task, unless explicitly overridden.

Task(priority: .background) {
  await withTaskGroup(of: Void.self) { group in
    for i in 0..<5 {
      let p: TaskPriority = i % 2 == 0 ? .high : .low

      group.addTask(priority: p) {
        print("\(i), p: \(Task.currentPriority), base: \(Task.basePriority)")
      }
    }
  }
}

// 0, p: TaskPriority.background, base: Optional(TaskPriority.high)
// 1, p: TaskPriority.background, base: Optional(TaskPriority.low)
// 2, p: TaskPriority.background, base: Optional(TaskPriority.high)
// 3, p: TaskPriority.background, base: Optional(TaskPriority.low)
// 4, p: TaskPriority.background, base: Optional(TaskPriority.high)

In this example, a parent task with .background priority creates several child tasks inside a group.
Each child task explicitly sets its own priority (.high or .low), which can be observed through Task.currentPriority and Task.basePriority.

This demonstrates how task groups provide flexible and dynamic control over concurrent workloads, while maintaining structured task management and cancellation behavior.

Conclusion

In this article, we explored the core ideas behind Structured Concurrency in Swift from lightweight parallelism with async let, to advanced techniques like TaskGroup, TaskLocal, and cooperative cancellation.

Swift’s concurrency model provides not only performance and safety, but also a clean, declarative way to reason about concurrent code. Each feature — whether it’s Task, TaskGroup, or @TaskLocal — is designed to work seamlessly together under the same structured model, ensuring that your asynchronous operations remain predictable and maintainable.

Swift Concurrency: Part 1

Nick Vasilev — Fri, 08 Aug 2025 10:07:58 +0000

Introduction

Swift 6 introduced a new approach to concurrency in apps. In this article, we will explore the problems it aims to solve, explain how it works under the hood, compare the new model with the previous one, and take a closer look at the Actor model. In the upcoming parts, we will also break down executors, schedulers, structured concurrency, different types of executors, implement own executor, and more.

Swift Concurrency Overview: Problems and Solutions

Concurrency has long been one of the most challenging aspect of software development. Writing code that runs tasks simultaneously can improve performance and responsivness, but it often introduces complexity and subtle bugs as a race condition, deadlocks, and thread-safety issues.

Swift Concurrency, introduced in Swift 6, aims to simplify concurrent programming by providing a clear, safe, and efficient model for handling asynchronous tasks. It helps developers to avoid common pitfalls by enforcing strict rules around data access and execution order.

💡If you use Swift 5.x and plan to migrate to Swift 6, you can enable Swift Concurrency checks in your project settings. This allows you to gradually adopt the new concurrency model while maintaining compatibility with existing code. Enabling these checks helps catch potential concurrency issues early, making the transition smoother and safer. As you update your codebase, you can start integrating async/await syntax and other Swift Concurrency features incrementally without a full rewrite.

Enable Swift Concurrency Checking

Select the project in the Project navigator.

Go to the Build Settings tab.

In the search bar, the Strict Concurrency Checking.

Set the option from the list:

Minimal. This level performs only the basic concurrency checks. It helps to catch the most obvious concurrency issues without enforcing strict rules on all code. It's useful for gradual adoption and initial migration phases.

Targeted. At this level, concurrency checking is applied more selectively and deeply in parts of your code that interact with concurrency features. It helps to identify more subtle bugs while allowing some flexibility in legacy code areas.

Completed. This is the strickiest level, enabling full concurrency checking across your entire codebase. It enforces all concurrency safety rules and ensures maximum protection against data races, thread-unsafe access, and other concurrency-related bugs.

Choosing the appropriate level depends on your project's maturity and your migration strategy. Starting with Minimal or Targeted can make the transition smoother, while Completed offers the strongest guarantee once your code fully embraces Swift Concurrency.

Some of the key problems Swift Concurrency addresses include:

Race Conditions: Preventing simultaneous access to shared mutable state that can cause unpredictable behaviour.
Callback hell: Simplifying asynchronous code that used to rely heavily on nested callbacks or completion handlers, making code easier to read and maintain.
Thread management complexity: Abstracting away low-level creation and synchronization, allowing developers to focus on the logic rather than thread handling.
Coordinating concurrent tasks: Structured concurrency enables clear hierarchies of tasks with proper cancellation and error propagation.

By leveraging new language features like async/await, Actors, and structured concurrency, Swift 6 provides a more intuitive and robust way to write concurrent code, improving both developer productivity and app stability.

Multitasking

Modern operating systems and runtimes use multitasking to execute units of work concurrently. Swift Concurrency adopts cooperative multitasking, which differs fundamentally from the preemptive multitasking model used by OS-level threads. Understending the difference is key to writing performant and safe asynchronous Swift code.

Preemptive Multitasking

Preemptive multitasking is the model used by operating systems to manage threads and processes. In this model, a system-level scheduler can forcibly interrupt any thread at virtually any moment to perform a context switch and allocate CPU time to another thread. This ensures fairness across the system and allows for responsive applications — especially when handling multiple user-driven or time-sensitive tasks.

Preemptive multitasking enables true parallelism across multiple CPU cores and prevents misbehaving or long-running threads from monopolizing system resources. However, this flexibility comes at a cost. Because threads can be interrupted at any point in their execution — even in the middle of a critical operation — developers must use synchronization primitives such as mutexes, semaphores, or atomic operations to protect shared mutable state. Failing to do so may result in data races, crashes, or subtle bugs that are often difficult to detect and reproduce.

This model offers greater control and raw concurrency, but it also places a significantly higher burden on developers. Ensuring thread safety in a preemptive environment is error-prone and may lead to non-deterministic behavior — behavior that varies from run to run — which is notoriously difficult to reason about or reliably test.

From a technical perspective, preemptive multitasking relies on the operating system to handle thread execution. The OS can interrupt a thread at almost any point — even in the middle of a function — and switch to another. To do this, the system must perform a context switch, which involves saving the entire execution state of the current thread (such as CPU registers, the instruction pointer, and stack pointer), and restoring the previously saved state of another thread. This process may also require flushing CPU caches, invalidating the Translation Lookaside Buffer (TLB), and transitioning between user mode and kernel mode.

These operations introduce significant runtime overhead. Each context switch takes time and consumes system resources — especially when context switches are frequent or when many threads compete for limited CPU cores. Additionally, preemptive multitasking forces developers to write thread-safe code by default, increasing overall complexity and the risk of concurrency bugs.

While this model provides maximum flexibility and true parallelism, it’s often excessive for asynchronous workflows, where tasks typically spend most of their time waiting for I/O, user input, or network responses rather than actively using the CPU.

Cooperative Multitasking

In contrast, Swift’s concurrency runtime uses cooperative multitasking. In this model, a task runs until it voluntarily yields control — typically at an await point or via an explicit call to Task.yield(). Unlike traditional threads, cooperative tasks are never forcibly preempted. This results in predictable execution: context switches occur only at clearly defined suspension points.

Swift’s cooperative tasks are scheduled onto a lightweight, runtime-managed cooperative thread pool—separate from Grand Central Dispatch queues. Tasks running in this pool are expected to be “good citizens,” yielding control when appropriate, especially during long-running or CPU-intensive work. To support this, Swift provides Task.yield() as a manual suspension point, ensuring other tasks have a chance to execute.

However, cooperative multitasking comes with a caveat: if a task never suspends, it can monopolize the thread it’s running on, delaying or starving other tasks in the system. Therefore, it is the developer’s responsibility to ensure that long-running operations include suspension points.

In cooperative multitasking, the fundamental unit of execution is not a thread, but a chunk of work, often called a continuation. A continuation is a suspended segment of an asynchronous function. When an async function suspends at an await, the Swift runtime captures the current execution state into a heap-allocated continuation. This continuation represents a resumption point and is enqueued for future execution.

Instead of associating a thread with a long-running task, the Swift runtime treats a thread as a pipeline of continuations. Each thread executes one continuation after another. When a continuation finishes or suspends again, the thread picks up the next ready continuation from the queue.

As mentioned above, this model avoids traditional OS-level context switches. There is no need to save and restore CPU registers or thread stacks; the runtime simply invokes the next closure-like continuation. This makes task switching very fast and lightweight, though it involves increased heap allocations to store the suspended async state.

The key trade-off: you use a bit more memory but gain dramatically lower overhead for task management. Cooperative scheduling gives tight control over when suspensions happen, which improves predictability and makes concurrency easier to reason about.

Introducing to `Task`

In Swift Concurrency, a Task provides a unit of asynchronous work. Unlike simply calling an async function, a Task is a managed object that runs concurrently with other tasks in cooperative thread pool.

💡 Tasks are managed by a cooperative thread pool. The cooperative thread pool is designed to manage concurrency efficiently by allowing tasks to yield the CPU while waiting for asynchronous operations to complete. This is achieved through the use of async functions and tasks, which are the fundamental units of concurrency in Swift. Read More

Tasks can be created to run concurrently, and they can also be awaited or canceled. They provide fine-grained control over asynchronous behavior and are an integral part of structured concurrency in Swift.

Creating a `Task`

A task can be created using the Task initializer, which immediately launches the provided asynchronous operation:

Task(priority: .userInitiated) {
  await fetchData()
}

When you create a Task using the standard initializer (i.e. not detached), it inherits the surrounding actor context, priority, and task-local values. This behavior is crucial for structured concurrency and safety in concurrent code.

💡 Swift 6.2 introduces a significant change to how concurrency is handled: by default, all code runs on MainActor. To run code on a background, Swift 6.2 adds a new attribute @concurrent. You can also use nonisolated if the code doesn’t require access to the main actor. WWDC Embracing Swift Concurrency

Under the hood, in earlier versions of Swift Concurrency, the Swift runtime used an internal mechanism called @_inheritActorContext to track which actor a task was associated with. Although this property wasn't part of the public API, it played a key role in ensuring that tasks created inside actor-isolated code would execute on the same actor, preserving data race safety.

With advancements in Swift, the runtime has started transitioning from @_inheritActorContext to a new mechanism known as sending, which is now more explicitly handled by the compiler and runtime.

💡 What is sending? sending is a new keyword introduced in Swift 6 as a part of language's move toward safer and more explicit concurrency. It's used to mark function parameters and return values that are moved across concurrency boundaries. It works especially well noncopyable types, ensuring memory safety and preventing use-after-move errors. When a parameter is marked with sending, the compiler enforces that the original instance is no longer accessed after the transfer.
func process(_ data: sending MyNonCopyableType) async {
   // `data` is moved here and can’t be used elsewhere after the call
}

When you launch a Task.detached, you must ensure that any values captured by the task are Sendable. The compiler now enforces this at compile-time using Sendable protocol and the @Sendable function type.

Failing to conform to Sendable may result in a compile-time error, particularly in strict concurrency mode.

Tasks also support priorities, similar to how Grand Central Dispatch queues handle them.

`Task` vs `Task.detached`

When working with Swift Concurrency, it's important to understand the difference between Task and Task.detached, as they define how and where asynchronous work is executed.

`Task`

Task inherits the current actor context (such as MainActor or any custom actor) and priority. It's commonly used when you want to spawn a new asynchronous operation that still respects the current structured concurrency tree or actor isolation. This is especially useful for UI updates or working inside specific concurrency domains.

Task {
  await updateUI()
}

In the example above, if called from the main actor, the Task will also run on the main actor unless explicitly moved elsewhere.

`Task.detached`

Task.detached creates a completely independent task. It doesn't inherit the current actor context or priority. This means it starts in a global concurrent context and requires manage safety, especially when accessing shared data.

Task.detached {
  await performBackgroundWork()
}

Use Task.detached when you need to run background operations outside the current structured context, such as long-running computations or escaping an actor's isolation.

Cooperative Thread Pool

A Cooperative Thread Pool in Swift Concurrency is a mechanism that manages the execution of asynchronous tasks by scheduling them onto a limited number of threads, typically matching the number of CPU cores.

Swift Concurrency operates using cooperative thread pool designed for efficient scheduling and minimal thread overhead. Unlike traditional thread-per-task executing model, Swift's approach emphasizes structured concurrency and resource-aware scheduling.

A common oversimplification is to say that Swift Concurrency uses one thread per core, which aligns with its goal to reduce context switching and maximize CPU utilization. While not strictly false, this view omits important nuances about quality-of-service buckets, task priorities, and Darwin scheduler behavior.

Thread Count: Not So Simple

On a 16-core Mac, it's possible to observe up to 64-threads managed by Swift Concurrency alone - without GCD involvement. This is because Swift's cooperative thread pool maps not just per-core, but per core per QoS bucket.

Formally:

Max threads = (CPU cores) × (dedicated quality-of-service buckets)

Thus, on a 16-core system:

16 cores × 4 QoS buckets = 64 threads

Each QoS bucket is essentially a dedicated thread lane for a group of tasks sharing similar execution priority. These are managed internally by Darwin's thread scheduling mechanism and are not the same as GCD queues.

QoS Buckets and Task Priority

Although TaskPriority exposes six constants, some of them are aliases:

usedInitiated → high
utility → low
default → already mapped to medium

For the kernel's perspective, this simplifies to 4 core priority levels, each mapped to a QoS bucket, which influences thread allocation in the cooperative thread pool.

When Does Overcommit Happen?

Under normal load, Swift Concurrency respects the cooperative pool limits. However, under contention (e.g. high-priority tasks waiting on low-priority ones), the system may overcommit threads to preserve responsivness. This dynamic adjustment ensures that time-sensitive tasks aren't blocked indefinitely behind lower-priority work.

This behavior is managed by the Darwin kernel via Mach scheduling policies and high-priority pthreads lanes - not something controlled explicitly by your code.

Task Priority

Swift provides a priority system for tasks, similar to Grand Central Dispatch (GCD), but more semantically integrated into the structured concurrency model. You can set a task's priority via the Task initializer:

Task(priority: .userInitiated) {
  await loadUserData()
}

The available priorities are defined by the TaskPriority enum:

Priority	Description
`.high` / `.userInitiated`	For tasks initiated by user interaction that require immediate feedback.
`.medium`	For tasks that the user is not actively waiting for.
`.low` / `.utility`	For long-running tasks that don't require immediate results, such as copying files or importing data.
`.background`	For background tasks that the user is not directly aware of. Primarily used for work the user cannot see.

Creating Tasks with Different Priorities

When you create a Task inside another task (default .medium priority), you can explicitly set a different priority for each nested task. Here, one child task is .low, and the other is .high. This demonstrates that priorities can be individually set regardless of the parent.

Task { // .medium by default
  Task(priority: .low) {
    print("\(1), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
  }

  Task(priority: .high) {
    print("\(2), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
  }
}

// 1, thread: <_NSMainThread: 0x6000017040c0>{number = 1, name = main}, priority: TaskPriority.low
// 2, thread: <_NSMainThread: 0x6000017040c0>{number = 1, name = main}, priority: TaskPriority.high

If you don't explicitly set a priority for a nested task, it inherits the priority of its immediate parent. In this example, the anonymous tasks inside .high and .low blocks inherit those respective priorities unless overridden.

Task Priorities Can Be Inherited

Task {
  Task(priority: .high) {
    Task {
      print("\(1), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
    }
  }

  Task(priority: .low) {
     print("\(2), "thread: \(Thread.current)", priority: \(Task.currentPriority)")

     Task {
      print("\(3), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
     }

     Task(priority: .medium) {
      print("\(4), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
     }
  }
}

// 2, thread: <_NSMainThread: 0x600001708040>{number = 1, name = main}, priority: TaskPriority.low
// 1, thread: <_NSMainThread: 0x600001708040>{number = 1, name = main}, priority: TaskPriority.high
// 3, thread: <_NSMainThread: 0x600001708040>{number = 1, name = main}, priority: TaskPriority.low
// 4, thread: <_NSMainThread: 0x600001708040>{number = 1, name = main}, priority: TaskPriority.medium

If you don't explicitly set a priority for a nested task, it inherits the priority of its immediate parent. In this example, the anonymous tasks inside .high and .low blocks inherit those respective priorities unless overridden.

Task Priority Escalation

Task(priority: .high) {
  Task {
     print("\(1), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
  }

  await Task(priority: .low) {
    print("\(2), "thread: \(Thread.current)", priority: \(Task.currentPriority)")

    await Task {
      print("\(3), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
    }.value

    Task(priority: .medium) {
      print("\(4), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
    }
  }.value
}

// 1, thread: <_NSMainThread: 0x6000017000c0>{number = 1, name = main}, priority: TaskPriority.high
// 2, thread: <_NSMainThread: 0x6000017000c0>{number = 1, name = main}, priority: TaskPriority.high
// 3, thread: <_NSMainThread: 0x6000017000c0>{number = 1, name = main}, priority: TaskPriority.high
// 4, thread: <_NSMainThread: 0x6000017000c0>{number = 1, name = main}, priority: TaskPriority.medium

This mechanism is called priority escalation — when a task is awaited by a higher-priority task, the system may temporarily raise its priority to avoid bottlenecks and ensure responsiveness.

As a result:

Task 2, which is .low, is escalated to .high while being awaited.
Task 3, which doesn't have an explicit priority, inherits the escalated priority from its parent (Task 2) and is also executed with .high priority.
Task 4 explicitly sets its priority to .medium, so it is not affected by escalation.

`Task.detached` Does Not Inherit Priority

Detached tasks (Task.detached) run independently and do not inherit the priority of their parent task. They behave like global tasks with their own scheduling. This is useful for isolating background work, but can also lead to unexpected priority mismatches if not set manually.

Task(priority: .high) {
  Task.detached {
    print("\(1), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
  }

  Task(priority: .low) {
    print("\(2), "thread: \(Thread.current)", priority: \(Task.currentPriority)")

    Task.detached {
      print("\(3), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
    }

    Task(priority: .medium) {
      print("\(4), "thread: \(Thread.current)", priority: \(Task.currentPriority)")
    }
  }
}

// 1, thread: <NSThread: 0x60000174dec0>{number = 4, name = (null)}, priority: TaskPriority.medium
// 2, thread: <_NSMainThread: 0x600001708180>{number = 1, name = main}, priority: TaskPriority.low
// 3, thread: <NSThread: 0x60000174dec0>{number = 4, name = (null)}, priority: TaskPriority.medium
// 4, thread: <_NSMainThread: 0x600001708180>{number = 1, name = main}, priority: TaskPriority.medium

Suspension Points and How Swift Manages Async Execution

In Swift, any call to an async function using await is a potential suspension point - a place in the function where executing might pause and resume latter. It's a transformation that involves saving the state of the function so it can be resumed latter, after awaited operation completes.

Here's an example:

func fetchData() async -> String {
  let result = await networkClient.load()
  return result
}

In this case, await networkClient.load() is a suspension point. When the function reaches this line, it may pause execution, yield control to the system, and later resume once load() finishes. Behind the scenes, the compiler transforms this function into a state machine that tracks its progress and internal variables.

Under the Hood: Continuations and State Machines

Every async function in Swift is compiled into a state machine. Each await marks a transition point. Before reaching an await, Swift:

Saves the current state of the function - including local variables and the current instruction pointer.
Suspends execution and schedules a continuation.
Once the async operation completes, it resumes the function from where it left off.

This is similar to the continuation-passing style (CPS) used in many functional programming systems. In Swift's concurrency model, this is orchestrated by internal types like ParticialAsyncTask and the concurrency runtime scheduler.

Suspension != Blocking

When you await something in Swift, the current thread is not blocked, instead:

The current task yields control back to the executor
Other tasks can run while waiting
When the awaited operation completes, the suspended task resumes on the appropriate executor.

This makes async/await fundamentally more efficient and scalable than thread-based blocking operations like DispatchQueue.sync.

`Task.yield()`: letting other tasks run

Task.yield() is a static method provided by Swift's concurrency system that voluntarily suspends the current task, giving the system opportunity to run other enqueued tasks. It's especially useful in long-running asynchronous operations or tight loops that don't naturally contains suspension points.

func processLargeBatch() async {
    for i in 0..<1_000_000 {
        if i % 10_000 == 0 {
            await Task.yield()
        }
    }
}

Without await, this loop would monopolize the executor. By inserting await Task.yield() periodically, you're cooperating with Swift's concurrency runtime, allowing to maintain responsivness and fairness.

Under the Hood

Calling await Task.yield() suspends the current task and re-enqueues it at the end of the queue for its current executor (e.g., main actor or a global concurrent executor). This allows other ready-to-run tasks to take their turn.

It’s part of Swift’s cooperative multitasking model: tasks run to the next suspension point and are expected to yield fairly. Unlike preemptive systems (e.g., threads), Swift tasks don’t get forcibly interrupted — they must voluntarily yield control.

Summary

Swift 6 marks a significant step forward in how concurrency is handled, offering developers more control, predictability, and safety. While the learning curve may be steep at first, understanding these concepts opens the door to building highly responsive and robust applications. As we continue exploring the deeper aspects of Swift's new concurrency model, it's clear that these changes lay the groundwork for the future of safe and scalable app development.

Trunk-Based Development

Nick Vasilev — Fri, 16 May 2025 15:26:55 +0000

In large development teams, managing feature branches and core reviews can become a bottleneck, especially when pull requests grow large and require approval from multiple reviewers or development teams. This often leads to delayed integrations, increased changes of merge conflicts, and longer feedback loop. Trunk-based development (TBD) enabling faster feedback, better collaboration, and a more stable codebased. In this article, we'll explore what trunk-based development is, why it matters, and how it can be effectively adopted in iOS development workflows.

Introduction

In large development teams developing new features often comes with significant challenges. When a task is carried out in a separate branch over the course of several days or even weeks, changes accumulate, and by the time code review happens, the following problems typically arise:

Large pull requests are hard to understand and review, especially if multiple subsystem are affected.
A high number of reviewers increases review time: while one person is reviewing the code, another might be busy, and a third may request changes.
Merge conflicts become common, as other developers are simultaneously modifying related parts of the project.
The risk of bugs increases: integrating large changes always carriers a higher chance of missing an error.

As a result, new features reach users more slowly, and developers spend more time dealing with complex integrations instead of delivering value.

One solution to this problem is Trunk-based development (TBD) - an approach where small increments are integrated directly into the main branch. To safely introduce unfinished or partially completed features, TBD heavy relies on feature toggles - switches that allows functionallity to be enabled or disabled on the fly without requiring the code to be "production ready" at the moment of commit.

Problems TBD Aims to Solve

The traditional workflow of developing features in isolated branches often leads to hidden inefficiencies. Long-lived branches and delayed merges create a fragile integration process where:

Code reviews pile up, causing bottlenecks.
Merge conflicts become harder to resolve and more time-consuming.
Developers are blocked, waiting for reviewers or fixes instead of moving forward.
Risk of regression grows, as large changes are harder to validate properly.

These problmes don't just affect individual productivity - they slow down the entire team's ability to innovate, respond to user feedback, and ship improvement quickly.

The TBD's goal is to remove these hidden costs by changing how and when code is integrated, not just what is being developed.

A High-Level Overview of Trunk-Based Development

Trunk-based development is a development approach where all developers work in a shared main branch (the "trunk") and integrate small, incremental changes continously.

The philosophy is the longer your branch lives, the greater the rish.

Key practicies of TBD:

Short-lived branches of direct commits: Developes wotk in very small increments and integrate changes daily - sometimes multiple times per day.
Features toggles: Incomplete features are hidden behind flags, allowing unfinished code to exist safely in production without impacting users.
Continuous integration: Every commit triggers automatic tests, ensuring that the main branch remains stable at all times.
Team discipline: Collaboration, communication, and frequent integration become part of the team's everyday routine, not an afterthought at the end of the feature.

TBD shifts the focus from isolated delivery to continuous collaboration, reducing integration risks, speeding up feedback, and enabling a halthier, faster development cycle.

Core Principles of Trunk-Based Development

Trunk-based development is a version control management practice where developers merge small, frequent updates to a core "trunk" or main branch. Atlassian

Trunk-based development is built around a few fundamental principles that shape how teams collaborate and deliver software:

Frequent integration: Developers integrate small, incremental changes into the main branch ("trunk") multiple times per day.
Short Feedback Loops: Each change is tested and validate quickly, allowing issues to surface early when they are cheaper and easier to fix.
Feature Toggles: Unfinished or experimental features are controlled via feature flags, enabling safe deployment without impacting users.
Always-Deployable Main Branch: The trunk remains stable and deployable at all times, supported by automated testing and continuous integration.
Collaborative Development: Teams work closely together, favouring direct communication and early alignment instead of long periods of isolated development.

The goal of these principles is to create a flow where integration is continuous and natural, rather than a painful, risky event at the end of a features's lifecycle.

How TBD Differs from GitFlow

At first glance, GitFlow and TBD might seem similar - both involve branching and merging - but their philosophies are fundamentally different.

Aspect	GitFlow	Trunk-Based Development
Branching Model	Heavy use of long-lived feature, release, and hotfix branches.	Minimal branching, frequent commits to trunk (main).
Integration Timing	Features are integrated after they are fully completed.	Features are integrated in very small increments throughout development.
Release Management	Separate release branches are maintained.	Main branch is always production-ready; releases are cut directly from main.
Risk Level	High risk during late-stage integrations.	Low risk through continuous integration.
Developer Workflow	Developers work independently for long periods.	Developers collaborate and integrate continuously.

In GitFlow, merging a large feature can feel like a "big event" that requires careful planning and testing. In TBD, merging is a daily routine — it’s quick, safe, and largely uneventful.

Working with Short-Lived Branches

The core principle is that changes should be integrated into the main branch frequently and in small increments. There are two main approaches for achieving this: short-lived branches and direct commits to main. Both approaches aim to reduce the risks associated with large, long-lived feature branches and increase the speed of development.

Short-Lived Branches

Short-lived branches are typically used for a few hours or up to a day, never staying open for more than a couple of days. These branches are focused on specific tasks, and the goal is to integrate them back into the main branch as quickly as possible.

When to use short-lived branches:

Logical unit of work: If a task requires several commits to be completed (e.g. implementing a new feature, fixing a bug), it might be easier to keep that work in a temporary branch until it's ready.
Code review feedback: When developing a new feature or fix that requires feedback and multiple iterations, a short-lived branch allows the developer to work independetly while receiving the feedback from reviewers.
Avoiding distractions: If you're implementing a change that's dependent on other parts of the codebase or requires some coordination with others, short-lived branches can allow you to focus without interruptions. This is especially helpful when the integration is complex or you need to refactor a significant part of the code.

How to manage short-lived branches:

Commit early and often: The branch should contain only small, incremental changes, each commit building upon the last. This makes it easier to integrate, test, and review.
Frequent merge from main: Pull in changes from the main branch frequently to avoid drift and merge conflicts when you're ready to integrate. Keeping your branch up to day ensures you're always working with the latest code, reducing integration problems.
Merge back in main as soon as possible: Once the work is done and tested, merge the short-lived branch back into the main branch. Don't let the branch live too long - the quicker you merge, the easier it is to keep the codebase clean and stable.

Direct Commits to Main

In Trunk-based development, commiting directly to the main branch is considered the best practice for smaller, self-contained changes. This approach is quicker and helps maintain the stability of the trunk, as it avoids the overhead of creating and merging branches.

Small, independent changes: These can include bug fixes, UI tweaks, perfomance optimizations, or refactoring tasks. Since these changes are often isolated, there's no need for a separate branch, and they can quickly intagrated into the main branch.
Continuous improvements: If the change you're making is a part of an ongoing effort (e.g. improving code quality, adding minor new features, or enhancing existing functionality), commiting directly to main ensures the codebase stays current and deployable.
Low-risk changes: Direct commits should be reserved for changes that won't introduce significant risk to the system or require testing in isolation.

Best practices for commiting directly to main:

Small, manageable commits: Each commit should address a single logical change, making it easier to review and understand.
Automated testing: Make sure you have sufficient unit tests and automated tests in place. Since you're commiting directly to the main branch, these tests are essential to ensuring that the changes don't break anything.
Frequent commits: Commit your changes frequently to reduce the risk of large, difficult to manage commits. The more frequent your commits, the easier it is to track progress and fix any potential issues.
Ensure stability: Every commit to the main branch should be stable. The goal is for the main branch to always be in a deployable state. If a change can't be immediately validated, use feature toggles to hide the incomplete functionality while still deploying the code.

Balancing Short-Lived Branches and Direct Commits

Choosing between short-lived branches and direct commits to main depends on the size and scope of the change. For larger changes or when collaborating with other developers, short-lived branches might make sense. However, for smaller, independent changes that can be tested quickly, direct commits to main are often faster and more efficient.

In practice, developers ofter use a mix of both approaches:

For small fixes, features, or incremental changes, direct commits to the main branch are encouraged. This keeps the main branch current, reduces merge conflicts, and ensures the system is always deployable.
For larger features, cross-cutting changes, or tasks requiring extended testing, developers create short-lived branches, integrate them quickly into the main branch, and merge frequently to avoid long periods of isolation.

Ultimately, the key to success in TBD is integration over isolation. Whether you're commiting directly to the main branch or using short-lived branches, the goal is always to keep codebase moving forward with minimal delay and maximum stability.

How to Safely Deploy Features

One of the core principles of Trunk-based development is maintaining stability of the main branch at all times.

Every commit to main must be safe and should not break the production version of the app. This requires discipline, careful testing, and proper feature isolation technique. Without this approach, even small changes can cause: unexpected bugs or crashes, user-facing problems (user may encountered broken interfaces, missing features, or crahses, which can damage their trust in the app), difficult rollback process (if the code hasn't been properly tested and isolated, reverting changes can become a complicated and risky task, especially when a new feature interacts with multiple components of the system).

To avoid these issues, new features should be deployed in a controlled and safe manner using techniques like feature toggles and other strategies that allow for enabling and disabling functionality without risking the stability of the code.

The Practice of Dark Launching

Dark launching is a strategy where new features or functionality are deployed to production but remain hidden from end users until they are fully tested and ready. This allows team to deploy the feature in a real-world environment without affecting the user experience.

With dark launching, teams can:

Test features in production with minimal risks to users.
Gradually roll out features and gather feedback (e.g., though A/B testing) before fully enabling them.
Catch bugs that might appear only in production environments but not in testing environments.

How it works in practice:

Commits to main: The feature is merged into the main branch with toggle that keeps in hidden from users by default.
Testing in production: The feature is available only to developres or a small subset of users (e.g., beta testers).
Enabling the feature for all users: Once the feature is fully tested and stable, the toggle is flipped, making it accessable to all users.

Example:
Imagine you're adding a new filtering screen into the app. You write the code for the screen but don't want users to see it until it's fully finished. You deploy the code with a feature flag (for example, using Firebase Remote Config or server-side flags) that keeps the feature hidden. You can then test the feature in production environment by enabling it only for a small group of beta testers or developers. Once the feature is polished , you can easily roll it out to all users by flipping the feature flag.

Benifits of dark launching:

Safety: You can test new features without risking your production environment.
Flexibility: It allows you to gather feedback and test features in real-world conditions before the official launch.
Gradual rollouts: You can progressively enable features for different user segments, reducing risks and improving user experience.

Using feature toggles and dark launching strategies enables safe and controlled feature deployment without breaking production. These practicies are essential in TBD, ensuring a smoother development process and quicker integration of new features with minimal risks.

In the next section, we will discuss how to practically implement feature flags for deploying new features in iOS projects and how this works within the iOS ecosystem.

Feature Toggles as a Foundation of TBD

In Trunk-based development, the ability to safely commit incomplete or experimental code to main without affecting end users is crucial. This is achieved primarly through the use of feature toggles. Feature toggles allow teams to merge work early and often, maintain a stable production-ready branch, and control feature visibility dynamically without needing hotfixes or emergency rollbacks.

There are two main types of feature toggles commonly used in development: Local Feature Toggles and Remote Feature Toggles.

Local Feature Toggles

Local feature toggles are controlled entirely within the app itself, without depending on external servers.

Using UserDefaultsor other local storage. A simple and effective way to implement local toggles in iOS is by leveraging UserDefaults, in-memory configurations, or app settings.

For example:

struct FeatureFlags {
    static var isNewFilterScreenEnabled: Bool {
        return UserDefaults.standard.bool(forKey: "isNewFilterScreenEnabled")
    }
}

In development builds, engineers can easily toggle features on or off via UserDefaults, hidden developer settings, or even custom debug menus.

There are possible alternatives to UserDefaults:

Property list files (.plist) bundled with the app.
In-memory variables for extremely short-lived feature toggles during a single app session.
Hidden settings screens available only in debug or beta builds.

Example usage:

if FeatureFlags.isNewFilterScreenEnabled {
  showNewFilterScreen()
} else {
  showOldFilterScreen()
}

Pros	Cons
Extremely fast setup.	No ability to change behavior remotely after release.
No external dependencies or network calls.	Requires an app update to toggle features in production.
Useful for development, debugging, or QA testing.	Less effective for real user experimentation (no A/B testing).

Local toggles are ideal for development and early internal testing but are limited when it comes to controlling features post-release.

Remote Feature Toggles

Remote feature toggles are controlled by external servers or configuration management platforms, such as Firebase Remote Config, LaunchDarkly, Optimizely, or custom backend solutions.

With remote feature flags, the app fetches configuration values from the server to determine feature availability at runtime.

For example:

import FirebaseRemoteConfig

let remoteConfig = RemoteConfig.remoteConfig()
remoteConfig.fetch { status, error in
    if status == .success {
        remoteConfig.activate()
        let isNewFeatureEnabled = remoteConfig["isNewFilterScreenEnabled"].boolValue
        if isNewFeatureEnabled {
            showNewFilterScreen()
        }
    }
}

This enables dynamic control over features without requiring a new app release.

Remote toggles are especially powerful because they support:

A/B Testing: Present different feature variations to different user groups to gather real-world performance and engagement data.
Gradual rollouts: Slowly enabled features for a small percentage of users before fully rolling out to everyone.
Targeted releases: Enable features based on specific criteria, such an app version, geography, device type, or user segments.

This approach helps catch critical bugs early with limited exposure and gather analytics to inform product decisions.

Example: Enable a new onboarding flow for 5% of new users in a specific region before scaling it worldwide.

Remote feature toggles embody the philosophy of "release early, control remotely". You can deploy your code to production as soon as it's technically ready, even if the business decision to fully launch the feature hasn't been made yet.

This gives the team flexibility to decouple code deployment from feature branches, speed to merge and deliver code continuously, safety to react quickly if something goes wrong(just disable the feature remotely).

Feature toggles are a critical enabler of Trunk-based development. Local feature toggles are great for development and internal testing phases. Remote toggles provide production-grade control, allowing for safe launches, fast experimentation, and quick responses to issues.

CI/CD and Automation

In Trunk-based development, rapid integration is a key. To make it safe and efficient, teams must rely heavily on Continuous Integration and Continuous Deployment pipelines that automatically verify every change before it is merged into main.

Automation ensures that every commit is validated quicly and reliably, reducing the risk of introduction regressions or breaking the app.

In TBD, developers commit quickly to main frequently - sometimes multiple times per day. Without strong CI processes in place, the risk of introducing bugs grows rapidly. That is why immediate feedback on every commit is crucial.

A good CI system will:

Run tests automatically for every pull request and direct push to main.
Perform static code analysis and enforce code style rules.
Build the app to catch integration or configuration issues early.
Fail fast: if something goes wrong, the system should notify the developer immediately to fix it before the issue reaches the production.

Essentially, CI becomes the team's safety net. It allows fast-moving development without sacrificing code quality.

To maintain stability and quality when practicing TBD, your CI must enforce several key cheks:

Unit Tests
- Run all unit tests on each commit.
- Ensure high test coverage, especially for core logic and critical systems.
- Fast feedback - unit tests should complete within minutes.
UI Tests (Optional but Recommended)
- For major user flows, use tools like XCUITest to simulate and verify UI behaviour.
- These tests are usually slower, so it's common to run them on nightly builds or specific pull requests.
Static Analysis and Linters
- SwiftLint: Enforce consistent code style and catch simple errors.
- SwiftFormat: Automatically formats code according to the project's rules.
Build Validation
- Ensure that every branch and every commit to main can successfully build.
- Optionally, verify the build for multiple targets (e.g., different configurations like Debug and Release).

Example setup for XCode

Fastlane is a popular open-source automation tool used to simplify many tasks in iOS development, such as:

Building the app
Running unit and UI tests
Uploading builds to TestFlight
Managing screenshots, certificates, and provisioning profiles

default_platform(:ios)

platform :ios do
  desc "Run tests"
  lane :test do
    scan(
      workspace: "YouExampleApprApp.xcworkspace",
      scheme: "ExampleApp",
      clean: true,
      code_coverage: true
    )
  end

  desc "Build the app"
  lane :build do
    gym(
      workspace: "ExampleApp.xcworkspace",
      scheme: "ExampleApp",
      clean: true
    )
  end
end

A minimal .github/workflows/ci.yml file for running tests might look like:

name: iOS CI

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  build-and-test:
    runs-on: macos-latest

    steps:
      - uses: actions/checkout@v3

      - name: Install dependencies
        run: bundle install

      - name: Run tests
        run: bundle exec fastlane test

This configuration will automatically:

Check out the code
Install Ruby gems
Build and test the app on each pull request and on every push to main

For developers practicing Trunk-Based Development, choosing the right CI/CD platform is important to ensure fast feedback, easy scaling, and reliability.

There are many CI/CD solutions available for iOS development, such as GitHub Actions, Xcode Cloud, Bitrise, or self-hosted setups like Jenkins. Each offers different levels of flexibility, automation, and integration:

Tool	Description
GitHub Actions	Provides a flexible, GitHub-native way to define workflows using simple YAML files. It allows you to automate builds, tests, and deployments directly from your repository with minimal setup.
Xcode Cloud	A CI/CD service built by Apple, tightly integrated into Xcode and App Store Connect. It simplifies building, testing, and distributing iOS, macOS, watchOS, and tvOS apps without needing third-party tools.
Bitrise	A mobile-focused CI/CD platform offering prebuilt steps for typical iOS workflows such as installing dependencies, running tests, building apps, and deploying to TestFlight. It’s a managed solution that minimizes setup effort.
Self-hosted (e.g., Jenkins)	Gives teams full control over the CI/CD infrastructure. Beneficial for large organizations with custom requirements, but requires maintaining servers and build environments.

A typical TBD-friendly CI pipeline for iOS projects usually includes:

Checking out the code from the repository.
Installing dependencies (e.g., via Swift Package Manager or CocoaPods).
Running static analysis tools and linters (e.g., SwiftLint).
Executing unit and UI tests.
Building and archiving the app.
Optionally distributing builds to TestFlight or internal testers.

Well-configured CI/CD pipelines are the backbone of an efficient TBD workflow, allowing teams to maintain a high development velocity while ensuring that every change is safe to ship.

Managing the Lifecycle of Feature Toggles

Feature toggles are a core part of Trunk-based development, but managing them properly is critical to avoid technical debt and maintain a clean codebase over time.

When introducing a feature toggle, it's important to clearly define its purpose: whether it is meant for a dark launch, an A/B test, a staged rollout, or as a kill switch. Teams should also agree on whether the toggle is intended to be temporary or permanent, and assign clear ownership to ensure someone is responsible for monitoring and removing it later.

In the implementation phase, toggles should be kept simple, localized, and easy to find. If dynamic control over the feature is needed after release, server-side toggles using services like Firebase Remote Config or LaunchDarkly are preferable. For features still in development or for local testing, simpler approaches like UserDefaults-based toggles are usually sufficient. Regardless of the method, maintaining consistency in naming and documentation helps future developers quickly understand the toggle’s role.

After a toggle is deployed, it’s important to actively monitor how the feature behaves. Teams should track usage metrics, collect logs, and watch for errors or performance regressions tied to the feature. Remote toggles allow features to be turned off quickly if any critical issues arise, reducing the risk of widespread impact.

Once the feature behind a toggle is fully rolled out, tested, and stable, it’s essential to remove the toggle and the associated conditional code as soon as possible. Keeping old toggles around bloats the codebase, complicates testing, and increases the risk of introducing bugs during future development. Regularly scheduled reviews of existing toggles can help keep the code clean and maintain the fast iteration speed that Trunk-based development relies on.

In short, disciplined feature toggle management is key to maintaining a healthy and agile development process. Feature flags should be treated as part of the product's lifecycle: planned carefully, monitored actively, and cleaned up aggressively once their purpose has been fulfilled.

How to Introduce TBD in an Existing Team

Switching to Trunk-Based Development (TBD) in an established team can be a big shift, but it’s absolutely doable with the right approach. It’s not just about changing how we write code — it’s about adapting the way we work together as a team. Here’s how you can make the transition smoother:

Gradual Transition. You don’t have to jump in all at once. If your team is used to working with long-lived feature branches, moving to TBD can feel like a big change. It’s better to ease into it. Start by making smaller, more frequent commits to main and integrating incomplete features using feature toggles. Once the team gets used to this, you can gradually eliminate long-lived branches and rely more on TBD. This way, you don’t overwhelm anyone, and the transition feels more natural.

Working with the Review Culture and Trust. One of the biggest changes with TBD is how we approach code reviews. In a typical workflow, you might be used to waiting for one big review at the end of a feature. But with TBD, we commit to main much more frequently, and reviews happen faster but more often. This means the review process will change: instead of one big review, there will be many smaller ones. It requires trust — trust that your code can be reviewed quickly, and trust in your teammates to provide feedback in real-time. As a team, you’ll need to get comfortable with this faster pace and shift your mindset from “perfecting before committing” to “iterating fast and improving with every commit.”

Minimizing Feature Branch Lifespan. With TBD, feature branches should be as short-lived as possible. Ideally, no feature branch should live longer than 1-2 days. This is because the longer a branch stays open, the more likely it is to cause conflicts and drift away from main. Keeping branches short and integrating changes frequently makes everything more manageable. You’ll find that the more often you commit, the less stress you’ll have around merging, and the more stable main will be.

Code Owners and Automating Reviews. To make reviews even faster and more efficient, consider using code owners and automation tools. Code owners are developers who are responsible for specific parts of the codebase, so they can quickly review changes in their area of expertise. Tools like GitHub Actions, Bitrise, or Xcode Cloud can automate many aspects of the process, such as running tests, linters, or static analysis on every commit. This means you catch basic issues right away, and your review process can focus on higher-level feedback rather than fixing small bugs.

By making these small but impactful changes, your team can smoothly transition to TBD without the stress. The key is to take it step by step, embrace the fast feedback cycle, and trust that automation and shorter branches will keep things running smoothly.

Potential Pitfalls

Despite all the benefits of Trunk-Based Development, there are some potential pitfalls you should be aware of. These challenges usually stem from inadequate planning or tooling, and they can slow down your progress or create technical debt if not addressed properly. Let’s look at a couple of key issues that might arise when adopting TBD.

TBD encourages frequent commits to main, but this only works if the codebase is continuously tested and stable. Without a solid testing foundation, committing often can result in broken builds or bugs sneaking into production. High-quality, comprehensive tests (unit, integration, UI) are absolutely crucial for this approach to succeed. If your test coverage is insufficient, you might face a situation where fast commits lead to unstable code and a messy main branch. It’s essential to invest in automated testing to catch issues early and maintain the quality of the code as you commit more frequently. Without reliable tests, TBD could do more harm than good.

Another common pitfall when using TBD is neglecting to properly manage feature toggles. While feature flags are essential for controlling unfinished or experimental features, they can quickly turn into technical debt if not handled well. For example, if your team relies on custom-built solutions for feature flags without using a more robust tool, it can lead to confusion and messy code. Over time, forgotten or outdated flags can clutter the codebase, making it harder to maintain and potentially causing bugs. It's important to choose the right tools for managing feature flags, whether that’s Firebase Remote Config, LaunchDarkly, or a self-hosted solution. A poor or nonexistent feature flag strategy can easily lead to accumulating technical debt, especially if flags are not removed after they’ve outlived their purpose.

Final Thoughts

Trunk-Based Development is a powerful methodology, but it’s important to remember that it’s not a one-size-fits-all solution. It’s a tool that can greatly improve your development speed, integration process, and code quality when implemented correctly, but it’s not the cure for every challenge a team might face. It requires a shift in mindset, a commitment to continuous testing, and good tool support, such as feature flag management. When these elements are in place, TBD can help your team move faster, minimize merge conflicts, and create a more stable codebase. However, if you’re missing some of these pieces, the transition might be harder, and the benefits may be harder to realize.

Key Takeaways and Recommendations:

Frequent, small commits to main are at the core of TBD. This reduces merge conflicts and helps maintain a more stable, up-to-date codebase.
Feature flags are crucial for controlling incomplete features and ensuring that you can deploy frequently without breaking production.
Automation through CI/CD tools like GitHub Actions, Xcode Cloud, or Bitrise is vital to keep the review and testing processes fast and reliable.
Gradual transition is key when moving to TBD. You don’t need to fully commit to TBD overnight; start with smaller changes and work your way toward full integration.
Make sure your testing pipeline is strong. The faster you commit, the more you rely on automated testing to catch potential issues early.

By following these principles, TBD can be a huge advantage for teams looking to streamline their development processes and deliver features faster without sacrificing stability.

While TBD works well for many teams, it’s not always the best fit for every situation. There are a few scenarios where TBD might not be ideal:

Large teams with complex workflows: If you have a very large team working on different parts of a project, with lots of cross-functional dependencies, frequent commits to main can sometimes lead to bottlenecks or unnecessary conflicts.
Projects with infrequent releases: If your project doesn’t require frequent releases or your features have long development cycles, the overhead of constant integration may not be worth it.
Lack of automated testing: If your team hasn’t invested in automated testing or doesn’t have a solid CI/CD pipeline in place, implementing TBD can lead to problems with unstable code or buggy releases.
Feature-heavy apps requiring extensive experimentation: If your app involves a lot of A/B testing or large feature rollouts that require separate branches to test different variations, TBD might not be the most practical approach.

Ultimately, TBD can work wonders for many teams, but it’s essential to evaluate your team’s needs and infrastructure before diving in. When implemented thoughtfully, it can lead to faster delivery, better collaboration, and a more robust codebase.

Design Patterns: Facade

Nick Vasilev — Thu, 06 Mar 2025 17:06:22 +0000

Introduction

The Facade design pattern serves as a front-facing interface for a complex set of classes, a library, or a framework. This article will explain its applications in iOS development and the types of problems it can solve.

Definition

The Facade design pattern is a structural pattern that provides a simplified interface to a framework, library, or a set of related classes.

What kind of problems can the Facade design pattern solve?

Complexity of subsystems. Large systems often consist of multiple interconnected classes and components, making them difficult to use and understand. A client that interacts directly with multiple components may require extensive knowledge of their implementation details.
Tight coupling. When clients are directly dependent on multiple components, changes in the subsystem can lead to widespread modifications in client code, increasing maintenance costs.
Difficulties in migration or refactoring. If a system's implementation changes, all clients interacting with its components must be updated accordingly, leading to high development effort.

What solutions does the Facade design pattern describe?

Provide a unified interface. The Facade design pattern introduces a higher-level interface that encapsulates complex interactions between multiple subsystem components, exposing a simple and easy-to-use API.
Decouple the client from the subsystem. Clients only interact with the facade, reducing their dependencies on specific subsystem implementations. This improves maintainability and allows for modifications to the underlying system.
Encapsulate complexity. The facade acts as a mediator, handling interactions between subsystem components internally, so clients do not need to manage multiple dependencies.

UML Diagram

The Client does not access the subsystem components directly. Instead, the Client works through a Facade class that provides a simplified interface. The Client depends only on the Facade interface and doesn't know anything about the subsystem components or their relationships.

Examples

Let's imagine that the system has three classes:

AuthManager is responsible for the authentication process and handling all tasks related to authentication. For the sake of simplicity, it exposes only a single method: login(username:password).
PaymentProcessor is responsible for processing a payment transaction.
NotificationService is responsible for sending a notification to observers that the order has been placed.

If a client wants to work with these objects, it would need to communicate with each object directly, which leads to the problems described above. It's better to create a facade object that serves as a front-facing interface for the client and hides the communication complexity between objects.

protocol IAuthManager {
  func login(username: String, password: String)
}

final class AuthManager: IAuthManager {
  func login(username: String, password: String) {
    print("User logged in")
  }
}

protocol IPaymentProcessor {
  func processPayment(amount: Double)
}

final class PaymentProcessor: IPaymentProcessor {
  func processPayment(amount: Double) { print("Payment processed: $\(amount)") }
}

protocol INotificationService {
  func sendNotification(message: String)
}

final class NotificationService: INotificationService {
  func sendNotification(message: String) { print("Notification sent: \(message)") }
}

Define an IECommerceFacade protocol that exposes a single method for placing an order, and an ECommerceFacade class that implements this protocol and sets up communication between subsystem objects, which are hidden from the client.

protocol IECommerceFacade {
  func placeOrder(username: String, password: String, amount: Double)
}

final class ECommerceFacade: IECommerceFacade {
    private let authManager: IAuthManager
    private let paymentProcessor: IPaymentProcessor
    private let notificationService: INotificationService

    init(authManager: IAuthManager, paymentProcessor: IPaymentProcessor, notificationService: INotificationService) {
      self.authManager = authManager
      self.paymentProcessor = paymentProcessor
      self.notificationService = notificationService
    }

    func placeOrder(username: String, password: String, amount: Double) {
        authManager.login(username: username, password: password)
        paymentProcessor.processPayment(amount: amount)
        notificationService.sendNotification(message: "Your order has been placed.")
    }
}

let authManager = AuthManager()
let paymentProcessor = PaymentProcessor()
let noticationService = NotificationService()

let ecommerceFacade = ECommerceFacade(
  authManager: authManager, 
  paymentProcessor: paymentProcessor, 
  notificationService: notificationService
)

ecommerceFacade.placeOrder(username: "JohnDoe", password: "1234", amount: 99.99)

This example demonstrates the Facade pattern by providing a single ECommerceFacade class that simplifies the process of placing an order, while internally managing authentication, payment, and notifications.

Summary

The Facade design pattern simplifies complex systems by providing a unified interface that encapsulates interactions between multiple subsystem components. It solves problems related to system complexity, tight coupling, and high maintenance costs by decoupling clients from the internal workings of the system. This pattern improves code readability, maintainability, and flexibility.

By adopting the Facade pattern, developers can create modular, maintainable, and user-friendly systems, making it an essential tool in software design and architecture.

Design Patterns: Adapter

Nick Vasilev — Thu, 06 Mar 2025 16:58:50 +0000

Introduction

The Adapter design pattern helps objects with incompatible interfaces to collaborate. It's useful when integrating existing components into a new system, working with legacy code, or combining third-party libraries that have different interface requirements. By acting as a bridge, the Adapter allows otherwise incompatible classes to communicate without modifying their original code, promoting reusability and flexibility in software design.

Definition

The Adapter design pattern is a structural design pattern that allows object with incompatible interfaces collaborate.

What kind of problems can the Adapter design pattern solve?

How can classes with incompatible interfaces work together?
How can an alternative interface be provided to the class?
How can a class be used if it doesn't provide the interface that a client requests?

The existing class can't be used because its interface is incompatible with the interface required by the client.

What solutions does the Adapter design pattern describe? b

Define a separate adapter object that converts the incompatible interface of a class into the interface required by the client.
Work with the adapter object for classes that don't have the required interface.

In this case, clients don't know whether they are working with the adapter object or the real object, because the adapter converts the incompatible interface into the required interface.

This pattern is similar to other design patterns, such as Facade, Decorator, and Proxy. You can read more about the differences in the Proxy article.

UML Diagram

The client requires the Target interface. However, this interface cannot reuse the Adaptee object because they have incompatible interfaces. Instead, the client works through the Adapter objects, which transform the Adaptee object to match the required protocol.

Examples

Let's imagine that we have legacy code in the project, and we need to reuse some functionality from the legacy codebase.

We have a class that defines how to fetch a user from the database. Let's imagine that we don't have access to the source code of the UserFetcher class and can't modify it.

final class UserFetcher {
  func user(_ userID: UUID, completion: @escaping (Result<User, Error>)) {
    // Fetches user data in some way and returns a result
    // Example: Fetch user from a legacy database or API
    completion(.success(User(id: userID, name: "John Doe", email: "john.doe@example.com")))
  }
}

There is a new implementation that requires the use of Swift Concurrency with async/await.

protocol IUserFetcherAdapter {
  func user(_ userID: UUID) async throws -> User
}

Here is the adapter class that uses the legacy implementation under the hood, thereby converting the incompatible interface into the interface required by the client.

final class UserFetcherAdapter: IUserFetcherAdapter {
  // MARK: Properties

  private let legacyUserFetcher: UserFetcher

  // MARK: Initialization

  init(legacyUserFetcher: UserFetcher) {
    self.legacyUserFetcher = legacyUserFetcher
  }

  // MARK: IUserDatabaseService 

  func user(_ userID: UUID) async throws -> User {
    try await withCheckedThrowingContinuation { continuation in
      legacyUserFetcher.user(userID) { result in
        switch result {
        case let .success(user):
          continuation.resume(returning: user)
        case let .failure(error):
          continuation.resume(throwing: error)
        }
      }
    }
  }
}

Summary

The Adapter design pattern allows objects with incompatible interfaces to work together by acting as a bridge between them. It transforms the interface of an existing class into one that the client expects, enabling seamless integration without modifying the original code. This pattern is particularly useful when integrating legacy systems, third-party libraries, or different components within a software project. In this article, we explored the principles of the Adapter pattern, its implementation, and real-world use cases.

Design Patterns: Proxy

Nick Vasilev — Sun, 02 Mar 2025 13:53:59 +0000

Introduction

The proxy object serves as an interface to the original object and can be applied to various resources, such as a network connection, a large file, or other resources that are expensive or difficult to duplicate. Simply put, the proxy object is a specialized wrapper for the original object that can control access to it and perform additional actions either before or after forwarding a request to the original object.

In other words, the Proxy pattern can significantly simplify the design of an application. If an object requires additional responsibilities, it must be wrapped in a special wrapper that encapsulates this extra functionality. This pattern is very similar to the Decorator design pattern, but there are some key differences that will be explained later.

Definition

The Proxy design pattern is a structural design pattern that allows you to provide a placeholder object for the original object. The proxy object can control access to the original object and may perform actions either before or after forwarding a request to the original object.

What kind of problems can the Proxy design pattern solve?

We want to control access to the original object and perform actions before or after forwarding a request to it.

What solutions does the Proxy design pattern describe?

Define a separate proxy object that implements the same interface as the original object.
Implement additional functionality to control access to the original object.

This makes it possible to work with the proxy object when the original interface is applied. For example, the proxy object may contain the behavior for checking the user's rights to perform certain actions.

SRP & OCP

The Proxy design pattern follows the SRP and OCP principles. The Proxy object usually has only one responsibility: controlling access to the original object or adding additional behavior without modifying the original class.

This is achieved by implementing the same interface as the original object, allowing the Proxy object to act as a substitute. Proxies are commonly used for purposes such as lazy initialization, access control, logging, caching, or remote object representation.

When applied to the Proxy design pattern, the OCP ensures that the behavior of a system can be extended by introducing new proxies without altering the behavior of the existing code of the real object or other components.

Similarity with Other Design Patterns

Design Pattern	Description
Adapter	Converts one interface into another, enabling these interfaces to collaborate.
Facade	Provides a simplified interface for the client.
Decorator	Dynamically adds responsibilities to the wrapped object without altering its original structure.

UML Diagram

The proxy object implements the Subject interface and can act as a placeholder for Subject objects. It maintains a reference to the original object and can forward requests to it.

Examples

Sensitive Operations

Since the Proxy design pattern can control access to the original object, it enables granting conditional access to the wrapped resource.

protocol IExampleService {
  func operation()
}

final class ExampleService: IExampleService {
  func operation() {
    // Perform the opertation
  }
}

final class ExampleServiceProxy: IExampleService {
  // MARK: Properties

  private let isAdmin: Bool
  private let service: ExampleService

  // MARK: Initialization

  init(service: IExampleService, isAdmin: Bool) {
    self.service = service
    self.isAdmin = isAdmin
  }

  // MARK: IExampleService

  func operation() {
    guard isAdmin else { return }
    service.operation()
  }
}

let service = ExampleService()
let serviceProxy = ExampleServiceProxy(service: service, isAdmin: true)

Logging

Using the Proxy design pattern, the logging mechanism can be added easily.

protocol ExampleProtocol {
  func operation()
}

final class ExampleService: ExampleProtocol {
  func operation() {
    // Implement the operation.
  }
}

final class ProfilingExampleService: ExampleProtocol {
  // MARK: Properties

  private let service: ExampleProtocol

  // MARK: Initialization

  init(service: ExampleProtocol) {
    self.service = service
  }

  // MARK: ExampleProtocol

  func operation {
   let startingTime = Date()

   service.operation()

   let endingTime = Date()

   print("operation: startingTime: \(startingTime), endingTime: \(endingTime)")
  }
}

let exampleService = ExampleService()
let profilingExampleService = ProfilingExampleService(service: exampleService)

Cache

Imagine that you need to download something from the internet and want to cache the downloaded data. This can be achieved using the Proxy design pattern. Since the original object and the proxy object conform to the same interface, these objects are interchangeable. This allows you to implement a new proxy object with additional caching functionality.

protocol IImageDownloadService {
  func download(url: URL) throws async -> UIImage
}

final class ImageDownloadService: IImageDownloadService {
  func download(url: URL) throws async -> UIImage {
    // Implementation of downloading an image.
  }
}

final class CacheImageDownloadService: IImageDownloadService {
  // MARK: Types

  private enum Error: Swift.Error {
    case downloadAlreadyStarted
  }

  // MARK: Properties

  private let service: IImageDownloadService

  private var isLoading = Set<String>()

  // MARK: Initialization

  init(service: IImageDownloadService) {
    self.service = service
  }

  // MARK: IImageDownloadService

  func download(url: URL) throws async -> UIImage {
    guard !isLoading.contain(url) else {
      throw Error.downloadAlreadyStarted
    }

    isLoading.insert(url)

    do {
      return try await service.download(url)
    } catch {
      throw error
    }
  }
}

let imageDownloadService = ImageDownloadService()
let cacheImageDownloadService = CacheImageDownloadService(service: imageDownloadService)

On Demand Initialization

Behavior similar to the lazy keyword in Swift can be implemented using the Proxy design pattern.

protocol IExampleOperation {
  func operation()
}

final class DefaultOperation: IExampleOperation {
  func operation() {
    // Implement the operation.
  }
}

final class LazyDefaultOperation: IExampleOperation {
  // MARK: Properties

  private var operation: DefaultOperation?

  // MARK: IExampleOperation

  func operation() {
    if operation == nil {
      operation = DefaultOperation()
    }

    operation?.operation()
  }
}

Summary

In this article, we explored the Proxy design pattern, a structural pattern that provides a placeholder for another object to control access to it. We discussed various use cases, including access control, caching, and lazy initialization, demonstrating how proxies act as intermediaries to add functionality without altering the original object's code.

Design Patterns: Strategy

Nick Vasilev — Sun, 02 Mar 2025 13:42:49 +0000

Introduction

In software development, creating flexible and maintainable code is a constant challenge, especially when dealing with various requirements and behaviors. The Strategy design pattern offers a powerful solution by enabling developers to define a family of algorithms, encapsulate each algorithm into a separate class, and make their objects interchangeable. This design pattern not only promotes adherence to the Open/Closed Principle (OCP) but also enhances code readability and scalability.

In this article, we'll explore the core concepts of the Strategy design pattern, understand its real-world applications, and walk through an example to see how it simplifies complex problems.

Definition

The Strategy design pattern is a behavioral design pattern that lets you create a family of algorithms, place each one into a separate class, and make their objects interchangeable.

The Strategy design pattern is used when an object performs a specific task in many different ways. In this case, these functionalities can be extracted into several separate classes called strategies.

The original object that works with the strategy is called the Context. The Context object is not responsible for selecting the appropriate strategy to delegate a task. Instead, the client should pass the desired strategy to the Context.

This way, the context stays independent of how the strategies are created, and a new strategy can be added without modifying the existing ones. The context is not aware of what kind of strategy is used because it works with the interface of the strategy.

What kind of problems can the Strategy design pattern solve?

Diverse Algorithm Selection: When you need to choose between different algorithms to perform a task, but the choice of algorithm depends on runtime data or conditions. In this case, you can define a family of interchangeable algorithms, allowing the client to select an appropriate one at runtime. This ensures that an object's behavior can change dynamically without modifying the algorithm itself.
Encapsulating Behavioral Variations: An object may need to perform similar actions in different ways depending on the context or environment. The Strategy design pattern encapsulates these variations into separate strategy classes, enabling the object to stay focused on its core responsibilities while delegating specific behaviors to the appropriate strategy.
Easily Adding New Behaviors: Anticipating the addition of new behaviors or algorithms in the future can be challenging without disrupting the existing system. By defining behavior through strategies, adding new functionality only requires creating new strategy classes. This avoids modifying the existing codebase, making the system easier to scale and extend.

What solutions does the Strategy design pattern describe?

Implement the interface for the algorithm to make the algorithms interchangeable.
Develop the algorithms based on this interface.

UML Diagram

The client is not aware of which concrete algorithm it uses. Instead, it must have a field to store a reference to the desired strategy. The Strategy interface is common to all concrete strategies. Strategy1 and Strategy2 implement different variations of the same algorithm.

Example

Very often, we need to send data to analytics systems such as Amplitude, Firebase, AppsFlyer, or others.

To handle different analytics systems in a flexible way, we start by defining a protocol IAnalyticsStrategy. This protocol ensures that all analytics strategies implement a logEvent method, which takes an event name and an optional dictionary of parameters. The strategy pattern allows us to easily switch between different implementations without changing the code that uses the analytics system.

protocol IAnalyticsStrategy {
    func logEvent(name: String, parameters: [String: Any]?)
}

Let's implement sending analytics data to two analytics systems, such as Amplitude and Firebase.

final class AmplitudeAnalytics: IAnalyticsStrategy {
    func logEvent(name: String, parameters: [String: Any]?) {
        print("Logging event to Amplitude: \(name), with parameters: \(parameters ?? [:])")
    }
}

final class FirebaseAnalytics: IAnalyticsStrategy {
    func logEvent(name: String, parameters: [String: Any]?) {
        print("Logging event to Firebase: \(name), with parameters: \(parameters ?? [:])")
    }
}

The AnalyticsManager class acts as the context for using the different analytics strategies. It holds a reference to a strategy (IAnalyticsStrategy) and delegates the task of logging events to the current strategy. The updateStrategy method allows dynamically switching the strategy at runtime, making it flexible and extensible.

final class AnalyticsManager {
    // MARK: Properties
    private var strategy: IAnalyticsStrategy

    // MARK: Initialization

    init(strategy: IAnalyticsStrategy) {
        self.strategy = strategy
    }

    func updateStrategy(_ newStrategy: IAnalyticsStrategy) {
        self.strategy = newStrategy
    }

    func trackEvent(name: String, parameters: [String: Any]? = nil) {
        strategy.logEvent(name: name, parameters: parameters)
    }
}

In this final part, we instantiate the AmplitudeAnalytics and FirebaseAnalytics strategies. Initially, we pass the AmplitudeAnalytics strategy to the AnalyticsManager, and track an event. After switching to the FirebaseAnalytics strategy using updateStrategy, we track a new event. This demonstrates how easily we can switch between different analytics services without modifying the core logic of tracking events.

let amplitudeAnalytics = AmplitudeAnalytics()
let firebaseAnalytics = FirebaseAnalytics()

let analyticsManager = AnalyticsManager(strategy: amplitudeAnalytics)

analyticsManager.trackEvent(name: "User Signed Up", parameters: ["method": "email"])

analyticsManager.updateStrategy(firebaseAnalytics)
analyticsManager.trackEvent(name: "User Logged In", parameters: ["platform": "iOS"])

Summary

The Strategy design pattern is a powerful tool for promoting flexibility and maintainability in software development. By decoupling algorithms from the context in which they are used, it enables dynamic behavior changes and reduces the complexity of code. This pattern is especially valuable when an application requires multiple approaches to solve a problem or when algorithms evolve over time. While it introduces some additional complexity due to the need for extra classes, the benefits of cleaner, more modular, and easily testable code far outweigh the drawbacks.

Design Patterns: Decorator

Nick Vasilev — Sun, 02 Mar 2025 13:35:13 +0000

Introduction

Design patterns help make our codebase cleaner, maintainable, and easy to understand. In this article, we will dive into the Decorator design pattern, which helps alter an object's behavior without modifying existing classes.

Definition

The Decorator is a structural design pattern that allows you to add extra functionality to an object without changing its structure. This enables you to wrap an existing object inside a special wrapper that contains the new behavior.

The Decorator pattern follows the SRP (Single Responsibility Principle) as it allows functionality to be divided among different classes, each with a unique area of concern. At the same time, it adheres to the OCP (Open/Closed Principle), which states that a class should be open for extension but closed for modification, as the decorator doesn’t change existing classes but adds new behavior using a wrapper class.

The Decorator design pattern allows adding extra functionality dynamically at runtime. The pattern suggests that the object may execute additional logic before or after forwarding a request to the original object.

What kinds of problems can the Decorator design pattern solve?

Adding extra functionallity dynamically at run-time.
Let's imagine a situation where an object should alter its behavior based on different factors that are not known at compile time. How can we achieve this? We could put all the code inside the object and use if/else or switch statements to handle them.

If the object has many different behaviors, and all of these behaviors are contained within the object, it will be difficult to maintain this object. Moreover, this approach violates the SRP and OCP principles.
Avoiding Class Explosion.
Multiple combinations of behaviors can be achieved through inheritance, but this often leads to the creation of numerous subclasses, making the system harder to maintain and scale. The Decorator pattern avoids this by composing behaviors at runtime.

When using subclassing, different subclasses extend a class in various ways. However, these extensions are fixed at compile-time and cannot be modified at runtime.
Reusing Functionality.
Common functionality can be reused across different decorators instead of being duplicated multiple times.

What solution does the Decorator design pattern describe?

Implement the interface of the extended object and forward all requests to it.
Implement new logic to be performed before or after forwarding a request to the original object.

UML Diagram

The abstract Decorator class holds a reference to the decorated object and forwards all requests to it. This ensures that the Decorator remains transparent to the clients of the Component.

Subclasses such as ConcreteDecorator1 and ConcreteDecorator2 add specific behavior to the Component, either before or after forwarding a request.

Real World Example

The Flare in-app purchase framework uses the decorator pattern to cache retrieved products if required by the configuration, and another one to sort the products. Let's take a look at how it works behind the scenes. I will skip some implementation details to focus only on the use of the decorator pattern.

The Flare framework defines an interface that describes a typical product provider:

/// A type that is responsible for retrieving StoreKit products.
protocol IProductProvider {
    /// Retrieves localized information from the App Store about a specified list of products.
    func fetch(productIDs: some Collection<String>, requestID: String, completion: @escaping ProductsHandler)

    /// Retrieves localized information from the App Store about a specified list of products.
    @available(iOS 15.0, tvOS 15.0, watchOS 8.0, macOS 12.0, *)
    func fetch(productIDs: some Collection<String>) async throws -> [StoreProduct]
}

The ProductProvider object conforms to this protocol and implements methods to retrieve the requested products by their IDs.

final class ProductProvider: NSObject, IProductProvider {
    func fetch(productIDs: some Collection<String>, requestID: String, completion: @escaping ProductsHandler) {
        // implementation
    }

    @available(iOS 15.0, tvOS 15.0, watchOS 8.0, macOS 12.0, *)
    func fetch(productIDs: some Collection<String>) async throws -> [StoreProduct] {
        // implementation
    }
}

The ProductProvider object only retrieves products and doesn’t perform any specific operations, such as sorting or caching them, as described above. This is exactly where decorators come in.

Since, the retrieved products should be sorted and cached, the Flare framework uses two decorator objects SortingProductsProviderDecorator and CachingProductsProviderDecorator. Let’s take a closer look at their interfaces:

/// Type that caches retrieved products.
protocol ICachingProductsProviderDecorator: IProductProvider {}

/// Type that sorts retrieved products.
protocol ISortingProductsProviderDecorator: IProductProvider {}

Both protocols inherit from the base IProductProvider protocol, which means that objects conforming to these protocols can be used in the same places as the original object.

Next, two objects implement these interfaces to provide additional functionality according to their names. Each of these objects must hold a reference to the base IProductProvider object.

Some technical details unrelated to the pattern have been omitted in this piece of code to simplify understanding.

/// `CachingProductsProviderDecorator` is a decorator class that adds caching functionality to an `IProductProvider`.
final class CachingProductsProviderDecorator: ICachingProductsProviderDecorator {
    /// Atomic property for thread-safe access to the cache dictionary.
    @Atomic
    private var cache: [String: StoreProduct] = [:]

    /// Creates a `CachingProductsProviderDecorator`instance.
    init(productProvider: IProductProvider, configurationProvider: IConfigurationProvider) {
        self.productProvider = productProvider
        self.configurationProvider = configurationProvider
    }

    // MARK: IProductProvider

    func fetch(productIDs: some Collection<String>, requestID: String, completion: @escaping ProductsHandler) {
        let cachedProducts = cachedProducts(ids: productIDs)
        let missingProducts = Set(productIDs).subtracting(cachedProducts.keys)

        if missingProducts.isEmpty {
            completion(.success(Array(cachedProducts.values)))
        } else {
            productProvider.fetch(productIDs: missingProducts) { 
                // Some logic for storing retrieved products.
             }
        }
    }

    @available(iOS 15.0, tvOS 15.0, watchOS 8.0, macOS 12.0, *)
    func fetch(productIDs: some Collection<String>) async throws -> [StoreProduct] {
        let cachedProducts = cachedProducts(ids: productIDs)
        let missingProducts = Set(productIDs).subtracting(cachedProducts.keys)

        if missingProducts.isEmpty {
            return Array(cachedProducts.values)
        } else {
            return try await productProvider.fetch(productIDs: missingProducts)
        }
    }

    // MARK: Private

    /// Caches the provided array of products.
    private func cache(products: [StoreProduct]) {
        products.forEach { _cache.wrappedValue[$0.productIdentifier] = $0 }
    }

    /// Retrieves cached products for the given set of product IDs.
    private func cachedProducts(ids: some Collection<String>) -> [String: StoreProduct] {
        let cachedProducts = _cache.wrappedValue.filter { ids.contains($0.key) }
        return cachedProducts
    }
}

There is an implementation of a sorting decorator. This decorator retrieves a collection of products and sorts them in a specific order.

// MARK: - SortingProductsProviderDecorator

final class SortingProductsProviderDecorator: ISortingProductsProviderDecorator {
    // MARK: Properties

    private let productProvider: IProductProvider

    // MARK: Initialization

    init(productProvider: IProductProvider) {
        self.productProvider = productProvider
    }

    // MARK: ISortingProductsProviderDecorator

    func fetch(
        productIDs: some Collection<String>,
        requestID: String,
        completion: @escaping ProductsHandler
    ) {
        productProvider.fetch(productIDs: productIDs, requestID: requestID) { [weak self] result in
            guard let self = self else { return }

            switch result {
            case let .success(products):
                let sortedProducts = self.sort(productIDs: productIDs, products: products)
                completion(.success(sortedProducts))
            case let .failure(error):
                completion(.failure(error))
            }
        }
    }

    @available(iOS 15.0, tvOS 15.0, watchOS 8.0, macOS 12.0, *)
    func fetch(productIDs: some Collection<String>) async throws -> [StoreProduct] {
        let products = try await productProvider.fetch(productIDs: productIDs)
        return sort(productIDs: productIDs, products: products)
    }

    // MARK: Private

    private func sort(productIDs: some Collection<String>, products: [StoreProduct]) -> [StoreProduct] {
        // The implementation of the sorting algorithm.
    }
}

Currently, all of these can be combined in the following way:

let productProvider = ProductProvider()
let sortingDecorator = SortingProductsProviderDecorator(productProvider: productProvider)
let cachingDecorator = CachingProductsProviderDecorator(productProvider: sortingDecorator, configuration: /* some configuration */)

The cachingDecorator can sort and cache products. This way, we can create different combinations and add new functionality without modifying existing ones.

If you’re interested in more details, feel free to check the repository.

Summary

The Decorator design pattern allows adding new functionality to objects dynamically without altering their structure, promoting flexibility. By wrapping objects in independent decorators, it simplifies maintenance and enables scalable solutions compared to subclassing.

Thread Explosion in iOS: GCD and Swift Concurrency

Nick Vasilev — Sat, 01 Mar 2025 11:35:42 +0000

Introduction

Thread explosion is a situation where multiple threads run simultaneously, causing performance degradation and memory overhead. In this article, we explore how to eliminate thread explosions and how Swift Concurrency helps prevent them.

Thread Explosion in GCD

Foundation

The system doesn’t provide an exact answer to how many threads we have. Based on WWDC Swift Concurrency Behind the Scenes, we can conclude that there are 16 threads per CPU core.

Let's consider the following code:

import Foundation

let queue = DispatchQueue(label: "com.nsvasilev.concurrent-queue", attributes: .concurrent)

for _ in 0...127 {
  queue.async {
    sleep(5)
  }
}

The queue is a concurrent queue, and it schedules 128 tasks concurrently without limiting the number of active threads. Each task is simulating a real-world heavy operation. Due to concurrent execution, the system might spawn numerous threads, causing performance degradation and increased CPU usage.

The output is separated into two groups, each containing 64 elements, due to a thread limit of 64. These 64 operations can be executed in any order because we are dealing with a concurrent queue.

Grand Central Dispatch (GCD) doesn’t have a built-in mechanism to prevent thread explosion. Next, we examine thread explosion in concurrent and serial GCD queues.

Deadlocks in Concurrent Queues

The thread explosion may lead to deadlocks in concurrent queues. Let's consider the following example:

import Foundation

let queue1 = DispatchQueue(label: "com.nsvasilev.concurrent-queue1", attributes: .concurrent)
let queue2 = DispatchQueue(label: "com.nsvasilev.concurrent-queue2", attributes: .concurrent)
let dispatchSemaphore = DispatchSemaphore(value: 0)

(0..<64).forEach { _ in
    queue1.async {
        dispatchSemaphore.wait()
    }
}

(0..<64).forEach { _ in
    queue2.async {
        dispatchSemaphore.signal()
    }
}

It may not be obvious that this code will cause a deadlock. The first concurrent queue schedules 64 tasks, each waiting on a semaphore. In this particular case, the thread limit is 64, meaning all available threads are occupied by these tasks. However, none of the tasks can proceed because they are all blocked, waiting for a signal from the second queue. Meanwhile, the second queue is also trying to run its tasks, which involve signaling the semaphore.

But, since all threads are blocked by the first queue’s wait() calls, none of the signals from queue2 can be processed, resulting in a deadlock where both queues are waiting for each other indefinitely.

There are three possible solutions.

Use OperationQueue to limit simultaneous tasks.

let operationQueue = OperationQueue()
operationQueue.maxConcurrentOperationCount = 5
operationQueue.qualityOfService = .background

let queue = DispatchQueue(label: "com.nsvasilev.concurrent-queue2", attributes: .concurrent)
let dispatchSemaphore = DispatchSemaphore(value: 0)

(0..<64).forEach { _ in
  operationQueue.addOperation {
    dispatchSemaphore.wait()
  }
}

(0..<64).forEach { _ in
  queue.async {
    dispatchSemaphore.signal()
  }
}

Use DispatchSemaphore to limit simultaneous tasks.

let queue = DispatchQueue(label: "com.nsvasilev.concurrent-queue", attributes: .concurrent)
let dispatchSemaphore = DispatchSemaphore(value: 3)


(0..<128).forEach { index in
  dispatchSemaphore.wait()
  queue.async {
    dispatchSemaphore.signal()
  }
}

DispatchSemaphore controls access to the queue and does not allow performing more than 3 operations at a time.

Use Swift Concurrency to prevent thread explosion.

Swift Concurrency can manage thread explosion. We will explore how it prevents thread explosion later in this article.

Deadlocks in Serial Queues

Deadlocks can occur in serial queues as well. The GCD thread limit for both concurrent and serial queues is capped at 512.

let dispatchSemaphore = DispatchSemaphore(value: 0)

for _ in 0...511 {
  let queue1 = DispatchQueue(label: "com.nsvasilev.concurrent-queue1")
  queue1.async {
    dispatchSemaphore.wait()
  }
}

for _ in 0...511 {
  let queue2 = DispatchQueue(label: "com.nsvasilev.concurrent-queue2")
    queue2.asyncAfter(deadline: .now() + 1.0) {
      dispatchSemaphore.signal()
  }
}

The inner for-loop creates 512 serial queues, consuming all available threads. As a result, the first loop occupies all threads, causing a deadlock because there are no threads left to execute the second loop’s queue operations.

Swift Concurrency

Swift Concurrency prevents thread explosion, and in this part, we are going to take a look at how it works. Let's explore how Swift Concurrency manages tasks efficiently and avoids creating excessive threads.

Priorities

In Swift Concurrency, we have only threee task priorities: .userInitiated, .utility, .background.

.userInitiated is a high-priority task for user-initiated actions.
.utility is a medium-priority task for background processing.
.background is for low-priority tasks that can run in the background.

Let's consider some examples:

// The high-priority task for user-initiated actions.
Task(priority: .userInitiated) {
  await loadSomeData()
}

// The medium-priority task for background processing.
Task(priority: .utility) {
  await processDataInBackground()
}

// The low-priority tasks that can run in the background.
Task(priority: .background) {
  await performBackgroundCleanup()
}

In this example, await loadSomeData() is assigned the highest priority with .userInitiated, indicating that it is a user-focused task requiring prompt execution. Background tasks, such as cleanup, are set to .background priority, allowing them to run without blocking critical operations.

How Swift Concurrency Is Managing Threads

Let's consider examples that convert the cases from the previous section but using Swift Concurrency. The task will perform a "heavy" operation, and we will run it with different priorities.

Tasks With the Same Priority Level

Let's consider the following example:

func runTask(seconds: UInt32) {
  Task(priority: .userInitiated) {
    print("User Initiated: \(Date())")
    sleep(seconds)
  }
}

for _ in 0...127 {
  runTask(seconds: 2)
}

We can see that only 6 tasks are performed simultaneously, which is equal to the number of CPU cores on my device.

If you pause the execution, you may get a clearer picture of what happens behind the scenes.

We may notice that all of these operations are performed inside com.apple.root.user-initiated-qos.cooperative, which limits the number of threads so that it doesn't exceed the number of CPU cores.

Based on this observation, it's clear that Swift Concurrency prevents thread explosion and doesn't create more threads than there are CPU cores on the device.

Tasks With All Priority Levels at Once.

Let's look at another example. In this case, we'll run tasks with different priorities and observe what happens.

func runUserInitiatedTask(seconds: UInt32) {
  Task(priority: .userInitiated) {
    print("User Initiated: \(Date())")
    sleep(seconds)
  }
}

func runUserUtilityTask(seconds: UInt32) {
  Task(priority: .utility) {
    print("Utility: \(Date())")
    sleep(seconds)
  }
}

func runUserBackgroundTask(seconds: UInt32) {
  Task(priority: .background) {
    print("Background: \(Date())")
    sleep(seconds)
  }
}

for _ in 0...127 {
  runUserInitiatedTask(seconds: 2)
}

for _ in 0...127 {
  runUserUtilityTask(seconds: 2)
}

for _ in 0...127 {
  runUserBackgroundTask(seconds: 2)
}

As we can see, the .utility and .background queues are limited to 1 thread when there's a higher-priority queue (.userInitiated).

In this specific scenario, the maximum number of threads is 8.

The Last Example

What if we add some delays before starting each group of tasks?

In this example, we demonstrate how introducing delays before starting each group of tasks can impact their execution. We have three types of tasks, each with a different priority: .background, .utility, and .userInitiated. Each task sleeps for a specified duration, and tasks are executed in three groups, with a 2-second delay between each group.

func runUserBackgroundTask(seconds: UInt32) {
  Task(priority: .background) {
    print("Background: \(Date())")
    sleep(seconds)
  }
}

func runUserUtilityTask(seconds: UInt32) {
  Task(priority: .utility) {
    print("Utility: \(Date())")
    sleep(seconds)
  }
}

func runUserInitiatedTask(seconds: UInt32) {
  Task(priority: .userInitiated) {
    print("User Initiated: \(Date())")
    sleep(seconds)
  }
}

for _ in 0...127 {
  runUserBackgroundTask(seconds: 2)
}

sleep(2)

for _ in 0...127 {
  runUserUtilityTask(seconds: 2)
}

sleep(2)

for _ in 0...127 {
  runUserInitiatedTask(seconds: 2)
}

We can see that all three queues—background, utility, and user-initiated are processing multiple threads simultaneously. Interestingly, if the lower-priority queue is started first and given some time to run, the higher-priority queue doesn’t seem to negatively impact the performance of the lower-priority queue. This suggests that the system is capable of handling tasks with different priorities efficiently, maintaining a balance even when tasks run concurrently.

Conclusion

While GCD doesn’t inherently prevent thread explosion, it offers tools for managing concurrency, such as task queues and dispatch groups. However, thread explosion can occur if tasks are dispatched incorrectly or in excess. In contrast, Swift Concurrency improves upon this by offering a more structured and efficient approach to concurrency management. By prioritizing tasks and limiting concurrency based on available resources, Swift Concurrency reduces the risk of thread explosion and optimizes performance, ensuring that multiple tasks can run concurrently without overwhelming the system.

Memory Management With Swift: ARC, Strong, Weak, and Unowned Explained

Nick Vasilev — Mon, 11 Sep 2023 14:42:27 +0000

Introduction

Memory management is a key part of any programming language. Numerous articles provide a fundamental explanation of how memory management operates, this particular article delves into a more in-depth exploration of the topic.

In this article we consider:

What is the memory management?
What is automatic reference counting?
How strong, weak, and unowned references are implemented?
What is the life cycle of an object?
What are Side Tables?

Defining Memory Management

In simply words, memory is a collection of bytes, where each byte has own address. If we talk in terms of programming then, we have to deal with address space. An address space can consist of following components:

text is a segment that contains an executable instructions.
data is a portion of the virtual address space of a program, which contains the global and static variables that are initialised by the developer.
stack is used for storing local variables.
heap is used for storing dynamically allocated objects.

Memory management is the process of controlling and coordinating a computer's main memory. It's critical to understand how it works, otherwise it may lead to random crashes and increased memory consumption.

In some cases classes may be stored on the stack, and struct may be stored on the heap.

In Swift 5.6, the any keyword was introduced. If you use the any keyword, it signifies that the object will be enclosed within an existential container. If the object can fit within three machine words, it will be stored inside the existential container; otherwise, it will be allocated on the Heap, and the existential container will only store a reference to the object.

The Swift compiler may allocate reference types on the stack when their size is fixed, or their lifetime can be predicted. This is called "Stack Promotion." This optimization occurs during the SIL generation phase.

If a value type is a part of a reference type, it saves on the Heap.

Defining ARC

Memory management in Swift is very tightly coupled with automatic reference cycle.

Automatic Reference Counting (ARC) is a memory management attribute used to monitor and manage an application's memory usage.

Reference counting applies only to instances of classes. Structures and enumerations are value types, not reference types, and aren’t stored and passed by reference.

Every time when we create a new class instance, ARC allocates a chunk of memory, which contains an information about the created object along with a type of the instance and values that stored in this object.

To make sure that the instances don't be deallocated while they are still needed, ARC tracks how many variables, constants, properties point out to this instance. The object won't be deallocated as long as least there is one reference exists.

Understanding Strong, Weak, and Unowned

If we are working with structs or enums, ARC isn't managing the memory of those types and we don't need to worry about specifying weak or unowned for those constants or variables.

When we have to deal with classes, we can potentially run into a retain cycle. A retain cycle is a situation in which two objects keep strong references to each other indefinitely. To solve this kind of problem we can using weak or unowned keywords.

strong keeps a firm hold on the instance and doesn't allow it to be deallocated for as long as that strong reference exists.
weak doesn't keep a strong hold on the instance it refers to. A weak reference returns nil, when an object it points to is no longer alive.
unowned as a weak one doesn't keep a strong hold. Access to unowned references with a zero counter leads to a crash.

Swift conceptually have several counters for strong, weak, and unowned references. These counters are stored either along with an object right after isa pointer or in a side table, which be explained a lit bit later.

Defining Swift Runtime

Swift Runtime represents every dynamically allocated object with HeapObject struct. It encompasses all the data components that constitute an object in Swift, including reference counts and type metadata.

Within its internal structure, each Swift object possesses three reference counts, corresponding to distinct types of references. During the SIL (Swift Intermediate Language) generation phase, the swiftc compiler strategically incorporates invocations to the swift_retain() and swift_release() methods. This integration occurs at points deemed suitable, achieved by capturing the initialization and destruction instances of HeapObjects.

Introducing Side Tables

Side Tables are mechanism for implementing weak references.

Side Tables was introduced in Swift 4. Let's dive in a little bit history and take a closer look how it worked before Swift 4.

Before Swift 4

Let's imagine that we have a class like this:

class Object {
    let id: Int
    let name: String
}

The next picture represents an object into memory:

The class properties and reference counters are stored in a single object. It helps to get a quicker access that storing it at the other chunk of memory.

After creating a weak reference to an object, the reference count for the weak reference is incremented. Now, consider a scenario where there are no remaining strong references to the object. In such a situation, the object is essentially labeled as a zombie. It remains in memory until another object attempts to access it through the weak reference. This means that the zombie object could occupy memory for an extended period.

Another significant issue here: the process of loading an object through a weak link lacked thread safety.

class Object {}

class WeakHolder {
   weak var weak: Object?
}

for i in 0..<1000000 {
   let holder = WeakHolder()
   holder.weak = Object()
   dispatch_async(dispatch_get_global_queue(0, 0), {
       let _ = holder.weak
   })
   dispatch_async(dispatch_get_global_queue(0, 0), {
       let _ = holder.weak
   })
}

This piece of code may potentially result in a crash. Two threads have the potential to simultaneously access an object through a weak reference. Before acquiring the object, both threads verify whether the object is marked as a zombie. If both threads receive a positive response, they will both attempt to decrement the count and release memory. One of them will succeed in doing so, while the second thread will trigger a crash by attempting to free memory that has already been deallocated.

Understanding Swift Tables

The Side Table is a separate chunk of memory which store additional objects information. It's optional, meaning that the object may have a side table, or it may not. Objects which have week pointers to itself can incur the extra cost, and objects which don't need it don't pay for it.

Side Table is created only one the following things happen:

Weak reference to the object is created
strong and unowned counter overflows

Weak references now point directly to the Side Table, whereas strong and unowned references ones point directly to the object. In this case the object can be fully deallocated.

Utilizing unowned carries a lower overhead compared to employing weak. The reason behind this lies in how weak variables reference the object via a side table, which introduces an additional pointer hop to access the object.

In contrast, unowned references establish a direct link to the object, eliminating this overhead.

Swift Object Life Cycle

The object life cycle is well described in the source code here

Swift object have their own life cycle. There are five states:

Live
Deallocating
Deallocated
Freed
Dead

In live state object is alive. Its reference counters are initialized to 1 strong, 1 weak, 1 unowned. Despite on 1 weak reference the Side Table is not created here. It's needed that the state machine is working properly.

From live state, object moves to deiniting state once strong reference counter reaches zero. The deiniting state means that deinit() is in progress. At this point weak references will return nil, if there is an associated side table. unowned reads trigger an assertion failure. New unowned can be stored. From this point, object has two destinations:

If there are no weak and unowned references, the will move to the dead state.
Otherwise, the object moves to deinited state.

In deinited state the deinit() has been completed and the object has outstanding unowned references. The object can have two destinations from this point:

If there is no weak references, the object immediately go to the dead state.
Otherwise, the object moves to freed state.

In freed state the object is deallocated and only the side table is exist in the memory. During this phase the weak reference count reaches to zero and the side table destroyed. The object transitions into the final state.

In dead state there is nothing left from the object, expect for the pointer to it. The pointer to the HeapObject is freed from Heap, leaving no traces of the object in the memory.

Summary

Automatic reference counting isn't a mystical process; the more we delve into its internal workings, the more we can reduce the likelihood of memory management errors in our code.

Key points to remember:

Weak objects refer to the side table instead of referring to an object.
ARC is implemented on compiler level. Swift compiler inserts calls of retain and release wherever appropriate.
Swift object are not destroyed immediately. Instead, they have 5 phases in their life cycle.

Links

[1] Automatic Reference Counting Documentation
[2] Discover Side Tables
[3] Object Life Cycle. Swift Repo

Algorithms Complexity: All You Should Know About It

Nick Vasilev — Wed, 05 Jul 2023 14:22:52 +0000

Introduction

Algorithm complexity is a measure of how long it would take an algorithm to complete given an input of size $n$ . If an algorithm has to scale, it should complete the result within a finite and practical time bound even for large values of $n$ . For this reason, complexity calculated asymptotically as $n$ approaches infinity.

In this article we are going to take a look at

Asymptotic notations
How to compare two functions using limits?
Master theorem
How to solve recurrence relations?

Asymptotic Notations

Calculation number of operations allows you to compare the efficiency of algorithms. As we’ve mentioned in the Introduction section, the analysis is carried out with the expectation of a sufficiently large amount of processed data where $\rightarrow \infin$ , therefore, the growth rate is a key of importance, not the exact number of operations.

At this moment, we are ready to deep dive into details. Let’s define the function classes and consider asymptotic notations that describe the running time for a particular program or algorithm:

$O (n)$ - functions whose growth is faster than $g$
$Ω(n)\Omega(n)$ - functions whose growth is slower than $g$
$Θ(n)\Theta(n)$ - functions whose growth is the same as $g$

For a given function $g (n)$ the notation $Θ(g(n))\Theta(g(n))$ denotes:

0≤c1g(n)≤f(n)c2g(n),∀n≥n0\Theta(g(n)) = { f(n): \exist \space c_1 \ge \space 0 \space \exists \space c_2 \space \ge \space 0 \space \exist \space n_0 \space \ge 0 \space | \space 0 \le c_1g(n) \le f(n) c_2g(n), \forall n \ge n_0 }

For a given function $g (n)$ the notation $O (g (n))$ denotes:

\exist \space c \ge 0 \space | \space 0 \le f(n) \le cg(n), \forall n \ge n_0 }

For a given function $g (n)$ the notation $Ω(g(n))\Omega(g(n))$ denotes:

0≤cg(n)≤f(n),∀n≥n0\Omega(g(n)) = {f(n): \exist \space c \ge 0 \space | \space 0 \le cg(n) \le f(n), \forall n \ge n_0}

Comparing Functions

When we deal with complex algorithms, we are able to consider the limit of the ratio of the functions complexity:

limn→∞fngnlim_{n \rightarrow \infin} \frac{f_n}{g_n}

Based on the limit result, we can calculate the growth rate of the function:

The limit is equal to constant and it’s not equal to zero. It means that the functions growth the same: $f(n)=Θ(g(n))f(n)=\Theta(g(n))$
The limit is equal to zero. It means that the $g (n)$ ’s growth is faster than $f (n) : f (n) = O (g (n))$
The limit is equal to infinity. It means that the $g (n)$ ’s growth is slower than $f(n)=\Omega(g(n))$

Also, we can consider a ratio of the derivatives of the function, like this:

limn→∞fngn=fn′gn′lim_{n \rightarrow \infin}\frac{f_n}{g_n}=\frac{f_n'}{g_n'}

if functions have the following properties:

$limn→∞=fngn=00lim_{n \rightarrow \infin} = \frac{f_n}{g_n} = \frac{0}{0}$ or $limn→∞=fngn=∞∞lim_{n \rightarrow \infin} = \frac{f_n}{g_n} = \frac{\infin}{\infin}$
$f (n)$ and $g (n)$ are differentiable
$\neq0$ when $\rightarrow \infin$
$limn→∞f(n)g(n)\exist\space lim_{n \rightarrow \infin} \frac{f(n)}{g(n)}$

Example

Compare two functions $f(n)=n\log_2{n}$ and $g(n)=\log_2{n}^{2019}$

Proof:

limn→∞f(n)g(n)=limn→∞(nlog⁡2n)′(log⁡2n2019)′=limn→∞log2+12019log⁡22018nn=limn→∞nlog⁡2n+12019∗log⁡22018n=∞⇒nlog⁡2n=Ω(log2n2019)lim_{n \rightarrow \infin}\frac{f(n)}{g(n)}=lim_{n \rightarrow \infin}\frac{(n\log_2{n})'}{(\log_2{n^{2019}})'} \\ =lim_{n \rightarrow \infin}\frac{log_2+1}{\frac{2019\log_{2}^{2018}n}{n}} \\ =lim_{n \rightarrow \infin}\frac{n\log_2n+1}{2019*\log_{2}^{2018}n}=\infin \\ \Rightarrow n\log_2{n} = \Omega(log_2{n^{2019}})

Master Theorem

Defenition

Let us have a recurrence relation of the following form:

1\begin{equation}T(n) = \begin{cases} a*T(\frac{n}{b})+O(n^c), &\text{n > 1} \\ O(1) &\text{n = 1} \end{cases}\end{equation}

where $\in \mathbb{N}, b \in \mathbb{R}, b > 1, c \in \mathbb{R}^{+}$ . Then the solution of the given recurrence relation has the form:

If $c>\log_b{a}$ , then $T(n)=Θ(n)T(n)=\Theta(n)$
If $c = \log_ba$ , then $T(n)=Θ(nclog⁡bn)T(n)=\Theta(n^c \log_bn)$
If $c < \log_ba$ , then $T(n)=Θ(nlogba)T(n)=\Theta(n^{log_ba})$

Proof:

Let’s consider the recursion tree. It has $log_bn$ levels where each $k$ -level has $a^k$ vertexes each of them costs $(nbk)c(\frac{n}{b^k})^c$ .

Let’s summarize the cost of the tree at all levels:

T(n)=∑k=0logbnak∗(nbk)c=nc∑k=0logbn(abc)kT(n)=\sum_{k=0}^{log_bn}a^k* \big( \frac{n}{b^k} \big)^c=n^c \sum_{k=0}^{log_bn} \big( \frac{a}{b^c} \big)^k

We get the tree cases:

If $c > \log_ba$ , then $∑(abc)k\sum(\frac{a}{b^c})^k$ is the sum of a decreasing geometric progression (where $abc<1\frac{a}{b^c} < 1$ ), which doesn’t depend on $n$ . It means that the sum is just a constant. $T(n)=Θ(n)T(n)=\Theta(n)$
If $c = \log_ba$ , then $T(n)=nc∑k=0logbn(abc)k=nc∑k=0logbn1k=Θ(nclog⁡bn)T(n)=n^c\sum_{k=0}^{log_bn}(\frac{a}{b^c})^k=n^c\sum_{k=0}^{log_bn}1^k=\Theta(n^c\log_bn)$
If $c < \log_ba$ , then since the sum of a progression is asymptotically equivalent to its leading element, we have the following: $T(n)=nc∑k=0log⁡bn(abc)k=Θ(nc(abc)log⁡bn)=Θ(nc∗alog⁡bnnc)=Θ(alog⁡bn)=Θ(nlog⁡ba)T(n)=n^c\sum_{k=0}^{\log_bn}(\frac{a}{b^c})^k=\Theta(n^c(\frac{a}{b^c})^{\log_{b}{n}})=\Theta(n^c*\frac{a^{\log_{b}{n}}}{n^c})=\Theta(a^{\log_{b}{n}})=\Theta(n^{\log_{b}{a}})$

Recurrence Relations

There are three main methods for solving recurrence relations: substitution method, recursion tree and master theorem. Let’s consider them.

Substitution method

In order to solve a recurrence relation using the substitution method it's necessary to complete two steps:

Make an assumption about the solution;
Use the mathematical induction to prove the assumption’s correctness.

Example

Show that the solution of $T(n)=T(⌈n2⌉)+1T(n)=T(\lceil \frac{n}{2} \rceil)+1$ is $O(lg⁡n)O(\lg n)$

Proof:

Assume that $\le c*\lg{(n-a)}$ (we used a definition of big- $O$ from the Asymptotic Notations part), where $a$ is a number which will be selected later. Now, we are ready to substitute it into initial recurrence.

Then,

\le c* \lg{(\lceil \frac{n}{2})\rceil - a} + 1 \le \\ c*\lg{(n+1-2a)}+1-c*\lg{2} \le \\ c*\lg{(n+1-2a)} \le \\ c*\lg{(n-a)}

We proved that $O(\lg{n})$ is a solution for the given relation when $\ge 1, \space c \ge 1$ .

Let’s see another example.

Show that the solution of $T (n) = T (n - 1) + n$ is $O(n^2)$

Proof:

Assume, that $\le c*n^2$ . Let’s substitute this inequality to a given recurrence.

Then,

\le c*(n-1)^2+n =cn^2-2cn+c+n= \\ cn^2+n(1-2c)+c \le \\ cn^2

The last step completes when $\ge \frac{1}{2}$ .

Recursion Tree

Another way to find a solution for relation recursion is using a Recursion Tree.

In this method, a recurrence relation is converted into recursive tree. Each node represents the cost incurred at various levels of recursion. To find the total cost, cost of all levels are summed up.

Example

Use a recursion tree to determine a good asymptotic upper bound on the recurrence $T(n)=4T(n2+2)+n)T(n)=4T(\frac{n}{2} + 2)+n)$ . Use the substitution method to verify your answer.

Proof:

The tree has $log_2{n}$ levels. The subproblem size for a node at depth $i$ is $n2i\frac{n}{2^i}$ . The subproblem’s size reach $1$ when $n2i=1⇒i=log⁡2n\frac{n}{2^i}=1 \Rightarrow i=\log_2{n}$ .

The last level of depth $log_2{n}$ contains $4^{\log_2{n}}=n^2$ .

The total cost over all nodes:

∑i=0log⁡n−1(4i∗n2+2))+Θ(n2)=∑i=0log⁡n−1(2in+4i∗2)+Θ(n2)=∑i=0log⁡n−12in+∑i=0log⁡n−14i∗2+Θ(n2)=2log⁡n−12−1n+2∗4log⁡n4−1+Θ(n2)=(2log⁡n−1)n+23(4log⁡n−1)+Θ(n2)=(n−1)n+23(n2−1)+Θ(n2)=Θ(n2)\sum_{i=0}^{\log{n-1}}(4^i*\frac{n}{2}+2)) + \Theta(n^2)= \\ \sum_{i=0}^{\log{n-1}}(2^in+4^i*2) + \Theta(n^2) = \\ \sum_{i=0}^{\log_{n-1}}2^in+\sum_{i=0}^{\log{n-1}}4^i*2+\Theta(n^2)= \\ \frac{2^{\log{n}}-1}{2-1}n+\frac{2*4^{\log{n}}}{4-1}+\Theta(n^2)= \\ (2^{\log{n}}-1)n+\frac{2}{3}(4^{\log{n}}-1)+\Theta(n^2) = \\ (n-1)n+\frac{2}{3}(n^2-1)+\Theta(n^2)=\Theta(n^2)

Verifying by using substitution method:

Assume that $\leq c(n^2-dn)$ . Let’s substitute this inequality to a given recurrence.

Then,

\leq4c((\frac{n}{2}+2)^2)-d(\frac{n}{2}+2)+n = \\ 4c(\frac{n^2}{2}+2n+4-\frac{dn}{2}-2d)+n= \\ cn^2+8cn+16c-2dnc-8dc+n= \\ cn^2-cdn+8cn+16c-cdn-8cd+n= \\ c(n^2-dn)-(cd-8c-1)n+(d-2)8c \leq \\ c(n^2-dn)

The last step completes when $\ge 0$ .

Master Theorem

Use the master theorem to give tight asymptotic bounds for the following recurrences:

a.) $T(n)=2T(n4)+1T(n)=2T(\frac{n}{4})+1$
b.) $T(n)=2T(n4)+nT(n)=2T(\frac{n}{4})+\sqrt{n}$
c.) $T(n)=2T(n4)+nT(n)=2T(\frac{n}{4})+n$

Proof:

a.) $a = 2, b = 4, c = 1$ . Hence, $T(n)=Θ(n)T(n)=\Theta(\sqrt{n})$

b.) $a=2,b=4,c=12a=2,b=4,c=\frac{1}{2}$ . Hence, $T(n)=Θ(nlog⁡4n)T(n)=\Theta(\sqrt{n}\log_4{n})$

c.) $a = 2, b = 4, c = 1$ . Hence, $T(n)=Θ(n)T(n)=\Theta(n)$

DEV Community: Nick Vasilev

Swift Concurrency: Part 2

Introduction

Lightweight Structured Concurrency

Task Cancellation

TaskLocal

Task Group

Conclusion

Swift Concurrency: Part 1

Introduction

Swift Concurrency Overview: Problems and Solutions

Multitasking

Preemptive Multitasking

Cooperative Multitasking

Introducing to Task

Creating a Task

Task vs Task.detached

Task

Task.detached

Cooperative Thread Pool

Thread Count: Not So Simple

QoS Buckets and Task Priority

When Does Overcommit Happen?

Task Priority

Creating Tasks with Different Priorities

Task Priorities Can Be Inherited

Task Priority Escalation

Task.detached Does Not Inherit Priority

Suspension Points and How Swift Manages Async Execution

Under the Hood: Continuations and State Machines

Suspension != Blocking

Task.yield(): letting other tasks run

Under the Hood

Summary

Trunk-Based Development

Introduction

Problems TBD Aims to Solve

A High-Level Overview of Trunk-Based Development

Core Principles of Trunk-Based Development

How TBD Differs from GitFlow

Working with Short-Lived Branches

Short-Lived Branches

Direct Commits to Main

Balancing Short-Lived Branches and Direct Commits

How to Safely Deploy Features

The Practice of Dark Launching

Feature Toggles as a Foundation of TBD

Local Feature Toggles

Remote Feature Toggles

CI/CD and Automation

Example setup for XCode

Managing the Lifecycle of Feature Toggles

How to Introduce TBD in an Existing Team

Potential Pitfalls

Final Thoughts

Design Patterns: Facade

Introduction

Table of contents

Definition

UML Diagram

Examples

Summary

Design Patterns: Adapter

Introduction

Definition

UML Diagram

Examples

Summary

Design Patterns: Proxy

Introduction

Definition

SRP & OCP

Similarity with Other Design Patterns

UML Diagram

Examples

Sensitive Operations

Logging

Cache

On Demand Initialization

Summary

Introducing to `Task`

Creating a `Task`

`Task` vs `Task.detached`

`Task`

`Task.detached`

`Task.detached` Does Not Inherit Priority

`Task.yield()`: letting other tasks run