Bird
Raised Fist0
Swiftprogramming~5 mins

Escaping closures (@escaping) in Swift - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Escaping closures (@escaping)
O(n)
Understanding Time Complexity

When using escaping closures in Swift, it's important to understand how the program's work grows as input changes.

We want to see how the time to run the code changes when the number of tasks inside the closure changes.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.


func performTasks(tasks: [@escaping () -> Void], completion: @escaping () -> Void) {
    for task in tasks {
        DispatchQueue.global().async {
            task()
        }
    }
    DispatchQueue.main.async {
        completion()
    }
}

This code runs a list of tasks asynchronously and then calls a completion closure after scheduling all tasks.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Looping through the array of tasks to schedule each one.
  • How many times: Once for each task in the input array.
How Execution Grows With Input

As the number of tasks grows, the number of times the loop runs grows the same way.

Input Size (n)Approx. Operations
1010 task schedules
100100 task schedules
10001000 task schedules

Pattern observation: The work grows directly with the number of tasks.

Final Time Complexity

Time Complexity: O(n)

This means the time to schedule tasks grows in a straight line as the number of tasks increases.

Common Mistake

[X] Wrong: "Because tasks run asynchronously, the time complexity is constant no matter how many tasks there are."

[OK] Correct: Scheduling each task still takes time, so the total scheduling work grows with the number of tasks, even if the tasks run in parallel later.

Interview Connect

Understanding how escaping closures and asynchronous calls affect time helps you explain how your code scales and performs in real apps.

Self-Check

"What if the completion closure was called only after all tasks finished? How would that affect the time complexity?"

Practice

(1/5)
1. What does the @escaping keyword indicate in Swift closures?
easy
A. The closure can be called after the function returns
B. The closure is executed immediately within the function
C. The closure cannot capture variables from the surrounding scope
D. The closure is only used for synchronous tasks

Solution

  1. Step 1: Understand closure execution timing

    Closures without @escaping run inside the function before it returns.
  2. Step 2: Role of @escaping

    Marking a closure @escaping means it can be stored and called later, after the function ends.
  3. Final Answer:

    The closure can be called after the function returns -> Option A
  4. Quick Check:

    @escaping means delayed closure call [OK]
Hint: Escaping closures run later, not immediately [OK]
Common Mistakes:
  • Thinking @escaping closures run immediately
  • Confusing @escaping with synchronous execution
  • Believing @escaping closures cannot capture variables
2. Which of the following is the correct syntax to declare a function parameter as an escaping closure in Swift?
easy
A. func fetchData(completion: () -> Void) {}
B. func fetchData(completion: escaping () -> Void) {}
C. func fetchData(@escaping completion: () -> Void) {}
D. func fetchData(completion: @escaping () -> Void) {}

Solution

  1. Step 1: Identify correct placement of @escaping

    The @escaping keyword must appear before the closure type in the parameter list.
  2. Step 2: Check each option's syntax

    func fetchData(completion: @escaping () -> Void) {} correctly places @escaping before the closure type. Options A, C, and D have incorrect syntax.
  3. Final Answer:

    func fetchData(completion: @escaping () -> Void) {} -> Option D
  4. Quick Check:

    Correct syntax = func fetchData(completion: @escaping () -> Void) {} [OK]
Hint: Put @escaping before the closure type in parameters [OK]
Common Mistakes:
  • Placing @escaping before parameter name
  • Omitting @escaping for delayed closures
  • Writing 'escaping' without @ symbol
3. What will be the output of the following Swift code?
func performTask(completion: @escaping () -> Void) {
    DispatchQueue.main.async {
        completion()
    }
    print("Task started")
}

performTask {
    print("Task completed")
}
medium
A. Task started
B. Task completed\nTask started
C. Task started\nTask completed
D. Task completed

Solution

  1. Step 1: Understand async dispatch behavior

    The closure passed to DispatchQueue.main.async runs later, after the current function finishes.
  2. Step 2: Trace print statements order

    "Task started" prints immediately. Then the closure runs and prints "Task completed".
  3. Final Answer:

    Task started\nTask completed -> Option C
  4. Quick Check:

    Async closure runs after print [OK]
Hint: Async closures run after current code finishes [OK]
Common Mistakes:
  • Assuming closure runs before print
  • Ignoring async dispatch delay
  • Confusing order of print statements
4. Identify the error in this Swift function using an escaping closure:
func saveData(completion: () -> Void) {
    DispatchQueue.global().async {
        // Save operation
        completion()
    }
}
medium
A. Missing @escaping before closure parameter
B. Closure parameter should be optional
C. DispatchQueue.global() cannot be used here
D. Completion closure must return a value

Solution

  1. Step 1: Analyze closure usage inside async block

    The closure is called asynchronously after the function returns, so it must be marked @escaping.
  2. Step 2: Check function parameter declaration

    The parameter lacks @escaping, causing a compile error.
  3. Final Answer:

    Missing @escaping before closure parameter -> Option A
  4. Quick Check:

    Async closure needs @escaping [OK]
Hint: Async closure parameters must be @escaping [OK]
Common Mistakes:
  • Forgetting @escaping for async closures
  • Assuming closure is synchronous by default
  • Adding unnecessary optional to closure
5. You want to store a closure to call later after a network request finishes. Which is the correct way to declare and use this escaping closure in Swift?
class NetworkManager {
    var completionHandler: (() -> Void)?

    func requestData(completion: ???) {
        self.completionHandler = completion
        // Simulate network delay
        DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
            self.completionHandler?()
        }
    }
}
hard
A. completion: () -> Void
B. completion: @escaping () -> Void
C. completion: @autoclosure () -> Void
D. completion: @escaping @autoclosure () -> Void

Solution

  1. Step 1: Understand closure storage and delayed call

    The closure is saved in a property and called later asynchronously, so it must be @escaping.
  2. Step 2: Evaluate options for closure parameter

    Only completion: @escaping () -> Void correctly marks the closure as @escaping. Options A, B, and D are incorrect or unnecessary here.
  3. Final Answer:

    completion: @escaping () -> Void -> Option B
  4. Quick Check:

    Stored closures must be @escaping [OK]
Hint: Store closures? Use @escaping keyword [OK]
Common Mistakes:
  • Omitting @escaping when storing closures
  • Using @autoclosure unnecessarily
  • Marking closure without @escaping for delayed call
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard