iOS Developer interview prep

Short answer: ARC is automatic reference counting: the compiler inserts retain/release calls around strong-reference operations at compile time. An object dies exactly when its reference count hits zero — deterministically and with no pauses. The price: ARC cannot collect reference cycles.

In depth:

	ARC	Tracing GC
Who decides	compiler: inserts retain/release	runtime: traverses the object graph
Moment of release	deterministic: count = 0	non-deterministic, at collection time
Pauses	none	stop-the-world / incremental
Cycles	not collected — needs weak/unowned	collected automatically
Overhead	atomic count increments	heap headroom + CPU for tracing

1. Compiler, not runtime — a retain is inserted when a new strong reference appears, a release when it leaves scope; the optimizer removes redundant matched pairs.
2. Deterministic deinit — the resource is freed immediately, which is why deinit is suitable for closing files, invalidating timers, unsubscribing.
3. The price — retain cycles remain the programmer's responsibility.

⚠️ Common mistake: calling ARC "a garbage collector, just faster." ARC doesn't scan memory at runtime — all the work is placed by the compiler ahead of time, which is why there are no pauses and why cycles don't get found on their own.

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.