Recently, I came across an interesting concurrency challenge on LinkedIn, specifically about Structured Concurrency in Swift. Structured Concurrency The challenge was to predict the order in which the following prints would appear in the console: Print 1, Print 2, Print 3, and Print 4. The challenge was to predict the order in which the following prints would appear in the console: Print 1 Print 2 Print 3 Print 4 class TaskManager {
    @TaskLocal static var message = "Hello"
    
    static func run() {
        Self.$message
            .withValue("Bye") {
                print("Print 1: \(Self.message)")
                
                Task {
                    print("Print 2: \(Self.message)")
                }
                
                Task.detached {
                    print("Print 3: \(Self.message)")
                }
            }
        
        print("Print 4: \(Self.message)")
    }
} class TaskManager {
    @TaskLocal static var message = "Hello"
    
    static func run() {
        Self.$message
            .withValue("Bye") {
                print("Print 1: \(Self.message)")
                
                Task {
                    print("Print 2: \(Self.message)")
                }
                
                Task.detached {
                    print("Print 3: \(Self.message)")
                }
            }
        
        print("Print 4: \(Self.message)")
    }
} What Is @TaskLocal? What Is @TaskLocal? @TaskLocal allows you to define a value that is accessible only within a specific task and its child tasks. Here’s a simple example: @TaskLocal @TaskLocal static var userID: String?

func printUserID() async {
    if let id = userID {
        print("User ID: \(id)")
    } else {
        print("No user ID")
    }
}

Task {
    await Self.userID.withValue("12345") {
        await printUserID() // User ID: 12345
    }
    
    await printUserID() // No user ID
} @TaskLocal static var userID: String?

func printUserID() async {
    if let id = userID {
        print("User ID: \(id)")
    } else {
        print("No user ID")
    }
}

Task {
    await Self.userID.withValue("12345") {
        await printUserID() // User ID: 12345
    }
    
    await printUserID() // No user ID
} Expected Behavior Expected Behavior I expected the following print order: Print 1, Print 4, Print 2, Print 3. Print 1 Print 4 Print 2 Print 3 This seemed reasonable because Task.detached runs with .medium priority by default, so it might execute after the regular Task. However, the actual behavior depends on the context in which TaskManager.run() is called. the context in which TaskManager.run() is called Playground Experiment Playground Experiment I first ran the code in Playground. Most of the time, I got this output: Print 1, Print 2, Print 3, Print 4. Print 1 Print 2 Print 3 Print 4 Occasionally, the order changed to: Print 1, Print 2, Print 4, Print 3. Print 1 Print 2 Print 4 Print 3 This behavior seemed strange, so I decided to check how it performs in more realistic conditions. XCTest Verification I wrote a test to run TaskManager.run() 1000 times: TaskManager.run() final class TaskManagerTests: XCTestCase {
    func test_taskManager() async {
        for i in 1...1000 {
            print("\n--- Run \(i) ---")
            TaskManager.run()
            try? await Task.sleep(nanoseconds: 500_000_000)
        }
    }
} final class TaskManagerTests: XCTestCase {
    func test_taskManager() async {
        for i in 1...1000 {
            print("\n--- Run \(i) ---")
            TaskManager.run()
            try? await Task.sleep(nanoseconds: 500_000_000)
        }
    }
} The behavior matched my expectations: Print 1, Print 4, Print 2, Print 3. Print 1 Print 4 Print 2 Print 3 I also noticed occasional variations where Print 2 and Print 3 would switch places. Print 2 Print 3 To better understand the behavior, I decided to inspect task priorities by adding logs for Task.currentPriority. task priorities Task.currentPriority Investigating Task Priorities To better understand this behavior, I added Task.currentPriority logging inside both Task { } and Task.detached { }. Task.currentPriority Task { } Task.detached { } In XCTest, the priority turned out to be .medium, resulting in stable and predictable behavior. XCTest .medium In Playground, the priority was .high, which explains why Task.detached (with its default .medium priority) consistently ran later. Playground .high Task.detached .medium However, Print 4 also consistently appeared last, and while the exact reason remains unclear, it seems to be specific to how execution is managed in Playground. Print 4 Playground In more realistic environments like XCTest, the behavior was more consistent and aligned with expectations. XCTest Experiment with Lower Priority Next, I decided to wrap the test in a low-priority root task to see how that would affect the execution order: func test_that_run_executesCorrectly_multipleTimes() async {
    await Task.detached(priority: .background) {
        for i in 1...1000 {
            print("\n--- Run \(i) ---")
            TaskManager.run()
            try? await Task.sleep(nanoseconds: 500_000_000)
        }
    }.value
} func test_that_run_executesCorrectly_multipleTimes() async {
    await Task.detached(priority: .background) {
        for i in 1...1000 {
            print("\n--- Run \(i) ---")
            TaskManager.run()
            try? await Task.sleep(nanoseconds: 500_000_000)
        }
    }.value
} With this change, the output shifted slightly, producing: Print 1, Print 4, Print 3, Print 2. This shows that lowering the priority of the root task consistently causes Print 3 to appear before Print 2. shifted slightly Print 1 Print 4 Print 3 Print 2 lowering the priority of the root task consistently causes Print 3 Print 2 Conclusion The behavior of tasks in Playground and in a real application differs. In Playground, tasks run with a .high priority by default, which affects their execution order. Playground Playground .high In XCTest, tasks run with .medium priority, resulting in more stable and predictable behavior. The actual execution order in a production app depends on the execution context - whether it’s Task, Task.detached, or other contexts. XCTest .medium Task Task.detached @TaskLocal correctly isolates values for tasks, but you should always verify behavior in environments that closely resemble production, not just in Playground. @TaskLocal Playground If you want to ensure your code behaves as expected — test it not only in Playground but also in your actual app or test suite. This will help you avoid misleading results and unexpected behavior in production. Playground actual app

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

AI Alone Won’t Replace Engineers, But AI-Driven Engineers Will

Mastering Swift Structured Concurrency: Dive into Task and Asynchronous/Await

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

What Swift’s Playground Won’t Tell You About Concurrency

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

AI Alone Won’t Replace Engineers, But AI-Driven Engineers Will

105 Stories To Learn About Ios App Development

10 Things You Didn't Know You Could Do With Google Keep

118 Stories To Learn About Mobile

The Noonification: Craig Wright Is NOT Satoshi Nakamoto (12/19/2023)

AI Alone Won’t Replace Engineers, But AI-Driven Engineers Will

105 Stories To Learn About Ios App Development

10 Things You Didn't Know You Could Do With Google Keep

118 Stories To Learn About Mobile

The Noonification: Craig Wright Is NOT Satoshi Nakamoto (12/19/2023)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps