iOS Developer interview prep

Short answer: ARC manages strong references automatically: the compiler inserts and optimizes retain/release operations, which run during program execution. When the last strong reference is released, the object can be destroyed. ARC does not search for unreachable cycles, so strong cycles require explicit ownership fixes.

In depth:

	ARC	Tracing GC
Mechanism	compiler-arranged strong-reference counting	traversal of the reachable graph during collection
Reclamation	on final release; its position depends on lifetime and optimization	collector policy after unreachability is established
Latency	retain/release and synchronous deinit cascades can take time	implementation-dependent: pauses, incremental, or concurrent work
Cycles	an unreachable strong cycle is not collected automatically	unreachable cycles can be collected

1. Lifetime — the last source line of a scope need not coincide with the final release. The optimizer may adjust lifetimes within language rules; use withExtendedLifetime when appropriate.
2. Resources — deinit is useful for final cleanup, but explicit close/cancel/unsubscribe operations, with defer where suitable, better express required timing. A retain cycle may prevent deinit from running at all.
3. Weak references — weak does not retain and becomes nil; unowned requires the object to remain alive whenever accessed. Choose from the ownership model.

⚠️ Common mistake: “ARC only works at compile time and has no pauses.” Reference counting and reclamation still cost runtime work, and an expensive deinit can delay a thread.

Short answer: A queue is a "list of tasks" abstraction, not a thread: GCD multiplexes queues over a shared thread pool. A serial queue runs tasks strictly one at a time in FIFO order; a concurrent one runs several in parallel. Main is the only queue with the contract "I execute on the main thread"; global queues are system concurrent queues, one per QoS class.

In depth:

Queue	Kind	What's special
DispatchQueue.main	serial	bound to the main thread; all UI
DispatchQueue.global(qos:)	concurrent	system-owned, shared app-wide
DispatchQueue(label:)	serial by default	your own; attributes: .concurrent makes it parallel

QoS	What it's for
.userInteractive	animations, gesture response — "right now"
.userInitiated	the user is waiting for a result (opening a screen)
.utility	long work with progress (file download)
.background	invisible work: sync, indexing

1. Queue ≠ thread — a serial queue doesn't own a thread: its tasks may run on different pool threads, just never simultaneously.
2. QoS drives scheduling — QoS tells the system how much CPU and energy to grant: .userInteractive jumps the line, .background can wait.

⚠️ Common mistake: "creating a queue creates a thread." No: thousands of queues are served by a dozen pool threads. But blocking many threads with sync waits is the road to thread explosion.

Short answer: loadView creates the view → viewDidLoad — one-time setup (no geometry yet!) → viewWillAppear — refresh before every presentation → viewWillLayoutSubviews/viewDidLayoutSubviews — the only places where frames are valid → viewDidAppear — animations and expensive starts → viewWillDisappear/viewDidDisappear.

In depth:

loadView ─► viewDidLoad ─► viewWillAppear ─► viewWillLayoutSubviews
 (create     (once)         (every show)            │ layout pass
  view)                                             ▼
viewDidDisappear ◄─ viewWillDisappear ◄─ viewDidAppear ◄─ viewDidLayoutSubviews
                                          (on screen)      (frames are valid!)

1. viewDidLoad — once per view controller's life: add subviews, constraints, subscriptions. The view has no real size yet.
2. viewWillAppear — every presentation: refresh data, bar state.
3. viewDidLayoutSubviews — bounds are current: corner rounding, CAShapeLayer paths, size-dependent layout. Called many times — keep it cheap.
4. viewDidAppear — the view is on screen: start animations, expensive work, analytics.
5. viewWillDisappear/viewDidDisappear — stop timers, save state.

⚠️ Common mistake: reading view.bounds in viewDidLoad — you get the storyboard size or zeros, not the device's real geometry. Anything size-dependent belongs in viewDidLayoutSubviews.

Short answer: A View is not a view in the UIKit sense but a lightweight value-description: a blueprint of what to show. Structs are cheap to create and throw away, so SwiftUI freely recreates them on every body recomputation. The long-lived part — the render tree (attribute graph) — lives behind the scenes; that's where state and identity are kept.

In depth:

1. Blueprint, not instance — a UIView is a heavyweight object with a lifecycle and a layer; a View struct is a couple of fields plus body, holding no resources.
2. State lives outside — @State is stored by the framework and attached to the view's identity in the tree, not to the struct: the struct dies, the value survives.
3. Diffing — SwiftUI compares the new description with the old one and minimally mutates the persistent tree; only the difference reaches the pixels.

body → View values (cheap, recreated every time)
            │ diff
            ▼
attribute graph / render tree (long-lived:
@State, identity, animations)

⚠️ Common mistake: equating "recreating structs" with "redrawing the UI." Producing descriptions costs pennies; rendering is what can be expensive, and it happens only where the diff found a change.

Short answer: Because in UIKit the view controller is the default assembly point for everything: view lifecycle, layout, the table's data source, navigation and network calls. You slim it by extracting responsibilities into separate objects — no architecture change required.

In depth:

1. Diagnosis — Apple's MVC isn't bad per se; the problem is that the "C" happily accepts any code, and without discipline the view controller grows to thousands of lines.
2. What to extract:

Responsibility	Where it goes
UITableViewDataSource / delegate	a dedicated data source object
A screen section with its own logic	a child view controller
Networking, cache, analytics	plain service objects
Subview configuration	the views themselves (configure(with:))

3. Result — the view controller stays a conductor: it wires services, views and navigation together but doesn't do all the work itself.

⚠️ Common mistake: answering "MVC is a bad architecture, that's why everyone moved to MVVM." What's bad is an undisciplined implementation: without extracting responsibilities the same overload happens to a ViewModel too.