Interview guides / ios

UIKit Interview Questions for iOS Engineers

UIKit interview questions on view controller lifecycle, table/collection views, Auto Layout, and performance, with example answers.

Even on SwiftUI-heavy teams, UIKit literacy still matters. Lifecycle, reuse, layout performance, and UIKit interoperability come up constantly.

Strong answers connect API knowledge to hitch-free scrolling and leak-free observer cleanup.

1. 1.Walk through the UIViewController lifecycle and where you would load data, configure UI, and clean up observers.

   loadView → viewDidLoad (one-time setup) → viewWillAppear → viewIsAppearing → viewDidAppear → viewWillDisappear → viewDidDisappear → deinit. Load remote data after first appear or via a dedicated loader; remove NotificationCenter/KVO observers in deinit or viewDidDisappear depending on scope; cancel in-flight tasks when the screen disappears if results are no longer needed.

2. 2.When do you pick delegate patterns vs completion closures?

   Delegates suit multi-method ongoing relationships (tableView). Closures suit one-shot results. Avoid retain cycles: weak delegates, weak self captures.

3. 3.What are common NotificationCenter bugs and how do you avoid them?

   Forgetting to remove observers (pre-block API), posting on wrong threads, overusing global events. Prefer Combine publishers, delegates, or scoped observers; always consider lifecycle.

4. 4.What is KVO and what replaced it in many Swift codebases?

   KVO observes Obj-C property changes. Prefer Combine, Observation/@Observable, delegates, or closures for Swift-first code. KVO still appears with AVFoundation and legacy APIs.

5. 5.How does cell reuse work and what bugs does it cause?

   Cells dequeue from a reuse pool; configure every visible field in cellForRow or configure methods. Stale images/text appear if you don’t reset state; cancel image loads on prepareForReuse.

6. 6.When do you choose a struct over a class in Swift?

   Prefer structs for value semantics, thread-safer copies, and simple data. Use classes for identity, inheritance, Objective-C interop, or shared mutable references. Many modern models are structs; UIKit types remain classes.

7. 7.Explain Automatic Reference Counting (ARC). When do retain cycles happen, and how do you break them with weak and unowned references?

   ARC tracks strong references and frees objects at zero. Cycles usually appear in closures capturing self, or parent↔child object graphs. Use weak for optional back-references (delegates, closures that may outlive the object) and unowned when the reference is non-optional and guaranteed to outlive the capture. Always capture lists in escaping closures: `[weak self]`.

8. 8.Compare GCD (DispatchQueue) with async/await and actors. When would you still reach for GCD?

   GCD is queue-based concurrency; Swift Concurrency models tasks, structured cancellation, and actor isolation for data races. Prefer async/await for new code, MainActor for UI, and actors for shared mutable state. GCD still helps for fine-grained QoS tuning, integrating C APIs, or migrating legacy code incrementally.

9. 9.What problem do Coordinators solve?

   They own navigation flow so view controllers don’t push/present each other directly—improving reuse and testability of routing. Useful in UIKit; SwiftUI often uses NavigationPath/Router instead.

10. 10.Compare MVC, MVVM, and VIPER for iOS apps.

    MVC is UIKit default but Massive VC risk. MVVM moves logic to ViewModels, testable with bindings. VIPER splits responsibilities heavily—good for large teams, often overkill for small features.

11. 11.Name common UIBackgroundModes and when you’d enable them.

    audio, location, voip, processing, fetch, remote-notification, bluetooth-central, etc. Only enable what you need—App Review checks misuse; prefer BGTaskScheduler for deferred work.

12. 12.What is AsyncSequence and where would you use it on iOS?

    AsyncSequence yields values over time (notifications, bytes, SSE). for await loops consume them. Useful for streaming APIs, NotificationCenter bridging, and URLSession bytes.

13. 13.How did UIScene change app lifecycle vs AppDelegate-only apps?

    Scenes support multi-window; scene delegate handles UI lifecycle per window scene. AppDelegate still handles process-level events. State restoration and dual entry points matter.

14. 14.How do you wrap UIKit views in SwiftUI safely?

    Implement makeUIView/updateUIView; use Coordinator for delegates. Avoid recreating views unnecessarily; sync state carefully to prevent feedback loops.

15. 15.Explain device token flow and rich notifications briefly.

    App registers, receives device token, sends to backend; backend pushes via APNs. Notification Service Extension for mutable content; Content Extension for custom UI. Handle authorization status carefully.

16. 16.What Auto Layout practices hurt scroll performance?

    Excessive constraint changes per frame, ambiguous layouts, deep hierarchies, offscreen measurement thrash. Prefer simpler hierarchies, intrinsic sizes, and self-sizing carefully profiled with Instruments.

17. 17.Compare default, ephemeral, and background URLSessionConfiguration.

    default uses disk cookies/cache; ephemeral is in-memory/private; background enables out-of-process downloads/uploads that continue when app suspends. Background needs delegate-based APIs.

18. 18.How should an app respond to memory warnings?

    Drop caches, purge image pipelines, release rebuildable resources, and avoid big allocations. In SwiftUI/UIKit, observe warnings and verify with Memory Graph Debugger.

19. 19.What is protocol-oriented programming and when is it better than class inheritance?

    Define behavior via protocols + extensions, compose capabilities, and prefer generics/PAT constraints. Better than deep class hierarchies for testability and reuse without fragile base classes.

20. 20.Why annotate UI updates with @MainActor? What happens if you don’t?

    UIKit/SwiftUI require main-thread UI access. @MainActor enforces that at compile time with isolation. Skipping it risks crashes/races; use Task { @MainActor in } or MainActor.run for hops.