Swift engineer interview questions

As asked

An iOS screen is dismissed but its view model and network task never deallocate. How would you find and fix the retain cycle?

Sample answer outline

Start with the memory graph debugger or Instruments to identify the ownership chain keeping the object alive. Common causes are closures capturing self strongly, delegates not marked weak, Combine subscriptions retained by the same object they capture, and tasks that outlive the view lifecycle. The fix is not blindly adding weak self everywhere, but deciding which object owns the work and when cancellation should happen. A view model should usually cancel outstanding tasks in deinit or when the lifecycle ends. Strong candidates explain ARC as deterministic reference counting with cycles that need explicit weak or unowned links.

Expect these follow-ups

• When is unowned safe and when is it dangerous?
• How do async Task closures capture self?
• How would you test that a screen deallocates?

As asked

How does Automatic Reference Counting work in Swift, and what are the three most common patterns that produce retain cycles in real iOS codebases? Walk me through how you detect and fix each one.

Sample answer outline

A strong answer explains that ARC inserts retain/release calls at compile time rather than runtime, then covers delegate cycles (strong delegate property), closure captures (capturing self strongly inside a stored closure on self), and parent-child object graphs (two objects holding strong references to each other). Candidate should name weak and unowned, explain when each is safe, and mention the Memory Graph Debugger or Instruments Allocations to detect leaking objects.

Expect these follow-ups

• When is unowned safer than weak, and what crashes can unowned produce?
• How does capture list syntax change when you have multiple captured variables?

As asked

You have a codebase that uses DispatchQueue heavily. A colleague wants to migrate to async/await. What are the concrete differences in thread ownership, stack suspension, and error propagation, and what would you actually migrate versus leave alone?

Sample answer outline

A strong answer covers: async/await suspends the logical call stack without blocking a thread (cooperative threading), GCD blocks an OS thread while waiting, structured concurrency with TaskGroup vs. DispatchGroup, and how async/await throws propagates naturally while GCD needs Result callbacks or semaphores. The migration advice should flag callback-heavy networking and URLSession as easy wins, while noting that code relying on DispatchQueue-specific ordering guarantees or C interop may be better left alone.

Expect these follow-ups

• How does Task cancellation propagate in an async/await tree vs. manual DispatchWorkItem cancellation?
• What does withCheckedContinuation let you do and what pitfall does the checked variant catch?

As asked

A user reports your app's memory climbs every time they navigate to a detail screen and back. Walk me through exactly how you use Xcode's Memory Graph Debugger to find the leak, from launching the app to pinpointing the retain cycle.

Sample answer outline

A strong answer covers: profile in debug build with MALLOC_STACK_LOGGING, navigate the leaking path several times, tap the memory graph icon in the debug bar, filter by class name, inspect the reference graph to find the cycle, hover over edges to see reference kinds (strong/weak), and correlate with the call stack from the allocation backtrace. Candidate should mention that dismissing a view controller that stays alive is the classic symptom.

Expect these follow-ups

• When would you use Instruments Allocations Heapshot analysis instead of the Memory Graph Debugger?
• How do you find a closure-based retain cycle in the graph when the closure has no visible name?

As asked

Why does UIKit require all view updates to happen on the main thread, what actually goes wrong at the framework level if you violate this, and how do you audit a large codebase for accidental background UIKit calls?

Sample answer outline

A strong answer explains that UIKit's internal data structures are not thread-safe (no locks), that concurrent mutations cause crashes or rendering artifacts rather than clean errors, and that the run loop and CoreAnimation transaction commits are tied to the main thread's display link. Auditing options: Main Thread Checker in Xcode diagnostics (catches at runtime), static analysis, or wrapping UIView subclasses with a custom assertion in debug builds.

Expect these follow-ups

• How does SwiftUI's @MainActor attribute handle this requirement at compile time?
• Can CoreImage and CoreGraphics rendering happen off the main thread safely?

As asked

A label and an image view sit side-by-side in a horizontal stack. Sometimes the label truncates and sometimes the image shrinks. Explain content compression resistance and content hugging priorities and walk me through exactly which priority values you would set to fix this layout.

Sample answer outline

A strong answer defines compression resistance as resistance to being squished below intrinsic size (default 750) and hugging as resistance to growing beyond intrinsic size (default 250). To keep the image at its natural size and let the label compress: raise the image's compression resistance above the label's (e.g. 751 vs 750) or lower the label's. To prevent the image from stretching: raise the image's hugging priority. Candidate should mention that equal priorities cause ambiguity warnings at runtime.

Expect these follow-ups

• How do you debug Auto Layout constraint conflicts without reading the cryptic runtime log?
• When would you choose compositional layout over Auto Layout for a complex list?