Question 1

A custom camera view wrapped via UIViewControllerRepresentable leaks memory and fails to release its delegate when navigating away in a SwiftUI NavigationStack. How do you structure the Coordinator lifecycle and makeUIViewController / dismantleUIViewController methods to prevent retain cycles?

Accepted Answer

The leak here almost always comes from one of two places: the Coordinator holding a strong reference back to the SwiftUI view or its bound values, or the UIViewController's delegate property being a strong reference to the Coordinator (or vice versa) so the two keep each other alive after the representable is torn down.

Structure it so the Coordinator holds `weak var` references to anything that points back up the ownership chain, and use `dismantleUIViewController(_:coordinator:)` to explicitly break the wiring - set the view controller's delegate to nil and stop any pending capture session - rather than relying on ARC to figure it out when the NavigationStack pops the view.

```swift
final class CameraRepresentable: UIViewControllerRepresentable {
    final class Coordinator: NSObject, CameraDelegate {
        weak var controller: CameraViewController?
        func cameraDidCapture(_ image: UIImage) { /* ... */ }
    }
    func makeCoordinator() -> Coordinator { Coordinator() }
    func makeUIViewController(context: Context) -> CameraViewController {
        let vc = CameraViewController()
        vc.delegate = context.coordinator
        context.coordinator.controller = vc
        return vc
    }
    static func dismantleUIViewController(_ vc: CameraViewController, coordinator: Coordinator) {
        vc.delegate = nil
        vc.stopSession()
    }
}
```

The key insight is that `dismantleUIViewController` is the only lifecycle hook SwiftUI guarantees will run before the controller is deallocated, so manual teardown (stopping AVCaptureSession, invalidating timers, nilling delegates) belongs there, not in a class `deinit` SwiftUI doesn't fully control.

Question 2

Migrating a shared app state class from @Published properties on an ObservableObject to the Swift @Observable macro causes certain view subtrees to stop updating while others re-render excessively. Explain how property-access tracking differs between Combine publishers and the @Observable observation framework.

Accepted Answer

`@Published` on an `ObservableObject` works at the object level: any mutation fires `objectWillChange`, and every view holding that object as `@ObservedObject`/`@StateObject` re-evaluates its body, even if the view only reads one property that didn't change. `@Observable` instead instruments each stored property individually - SwiftUI's rendering engine tracks which specific properties a view's `body` actually accessed on the last render, and only invalidates that view when one of those exact properties changes.

Views that stop updating after migrating usually read the property somewhere access-tracking can't see - inside a closure passed to `.task` or `.onAppear`, or a nested non-view helper function that doesn't run during body evaluation - so `@Observable` never registers the dependency. The fix is to read the property directly inside `body`, not indirectly through a captured closure evaluated outside rendering.

```swift
@Observable
final class SessionStore {
    var user: User?
    var isSyncing = false
}

struct ProfileHeader: View {
    var store: SessionStore
    var body: some View {
        Text(store.user?.name ?? "Guest") // only this property is tracked
    }
}
```

Views that over-render after migrating are usually reading the whole object rather than a property (e.g. passing `store` into a function that returns a view without touching a property inside `body`), which reintroduces coarse-grained invalidation despite using `@Observable`.

Question 3

Placing a GeometryReader inside a dynamic ScrollView with a child view that modifies parent state based on scroll offset causes an infinite layout loop and UI freeze. How do you implement non-intrusive scroll offset tracking using View.preference(key:value:) and coordinateSpace?

Accepted Answer

The loop happens because `GeometryReader` computes its geometry during SwiftUI's layout pass, and if you use that geometry to mutate `@State` synchronously inside the view's body, you're mutating state while SwiftUI is still laying out this render pass - which invalidates it and triggers another layout pass with the same problem, forever.

The fix is `View.preference(key:value:)`: instead of writing to state from inside the layout pass, you publish the offset up as a preference value, and read it back with `.onPreferenceChange` on an ancestor, which runs after layout completes as a separate step. Combine that with a named `coordinateSpace` so the offset is measured relative to the scroll container, not the window.

```swift
struct ScrollOffsetKey: PreferenceKey {
    static var defaultValue: CGFloat = 0
    static func reduce(value: inout CGFloat, nextValue: () -> CGFloat) { value = nextValue() }
}

ScrollView {
    GeometryReader { geo in
        Color.clear.preference(
            key: ScrollOffsetKey.self,
            value: geo.frame(in: .named("scroll")).minY
        )
    }
    .frame(height: 0)
    // content...
}
.coordinateSpace(name: "scroll")
.onPreferenceChange(ScrollOffsetKey.self) { offset = $0 }
```

Question 4

Design a programmatic navigation architecture using SwiftUI's NavigationStack and NavigationPath that can serialize its path state to disk upon app backgrounding, restore the deep navigation hierarchy after process death, and cleanly route incoming push notification deep links.

Accepted Answer

Model the navigation state as a `Codable` enum of route cases (e.g. `.productDetail(id: String)`, `.settings`) rather than pushing raw view structs, and drive `NavigationStack(path:)` off an array of these routes stored in an `@Observable` router object. `NavigationPath` itself is `Codable` when every element you push conforms to `Codable` and `Hashable`, but keeping your own typed route enum is more robust than relying on `NavigationPath`'s type-erased storage across app versions.

On `scenePhase == .background`, encode the current route array to `Data` and persist it (UserDefaults for small state, disk for larger). On launch, decode it back and rebuild the path before the first render, guarding against a route referencing content that no longer exists (e.g. a deleted product) by validating each route against current data before restoring it.

```swift
enum Route: Codable, Hashable {
    case productDetail(id: String)
    case settings
}

@Observable
final class Router {
    var path: [Route] = []
    func handle(deepLink url: URL) {
        if let id = parseProductID(from: url) {
            path = [.productDetail(id: id)]
        }
    }
}
```

For push notification deep links, route the notification's userInfo through the same `Router.handle(deepLink:)` entry point used for URL schemes/universal links, so there's one place that decides how to translate an external trigger into a `Route` array - don't special-case push notifications with their own navigation logic.

Question 5

A custom UIKit UIView embedded in a SwiftUI list calculates its size dynamically via intrinsicContentSize, but truncates multi-line text when the parent SwiftUI frame expands. How do you configure Content Hugging, Compression Resistance, and systemLayoutSizeFitting to bridge layout negotiations properly?

Accepted Answer

`intrinsicContentSize` only tells UIKit's own Auto Layout engine a view's preferred size - it doesn't automatically negotiate with SwiftUI's layout system, which asks the wrapped `UIViewRepresentable` for a size via `sizeThatFits(_:uiView:context:)`. If the label's Content Hugging Priority is too high (it doesn't want to grow) or Compression Resistance is too low (it's willing to shrink/truncate) relative to the SwiftUI parent's proposed width, the label truncates instead of wrapping.

The fix is to set `.setContentCompressionResistancePriority(.required, for: .vertical)` on the label so it refuses to compress vertically and instead reports the full multi-line height, and to implement `sizeThatFits` in your `UIViewRepresentable` to call `systemLayoutSizeFitting(_:)` with the proposed width fixed and height compressed, which asks Auto Layout to solve for the height that fits the given width - this is what correctly communicates the needed size back to SwiftUI.

```swift
func sizeThatFits(_ proposal: ProposedViewSize, uiView: UILabel, context: Context) -> CGSize? {
    let width = proposal.width ?? UIView.layoutFittingCompressedSize.width
    return uiView.systemLayoutSizeFitting(
        CGSize(width: width, height: UIView.layoutFittingCompressedSize.height),
        withHorizontalFittingPriority: .required,
        verticalFittingPriority: .fittingSizeLevel
    )
}
```

Question 6

A Swift actor manages an in-memory document cache. When multiple tasks concurrently call an async method that fetches remote data across an await suspension point, the cache gets corrupted with duplicate entries. Explain how actor re-entrancy causes this race condition and how to design state validation around suspension points.

Accepted Answer

Actors serialize access to their own state, but `await` inside an actor method is a genuine suspension point - the actor is free to run other calls to itself while your method is suspended waiting on the network. If your method reads some state, awaits a fetch, and then writes based on that stale pre-await read, another task can have interleaved a write in between, and your post-await write clobbers or duplicates it. That's re-entrancy: the actor guarantees mutual exclusion between synchronous chunks of code, not across an `await`.

The fix is to never trust state you read before an `await` once you're past it - re-check the authoritative state after resuming, or restructure so the decision to fetch happens atomically before any suspension.

```swift
actor DocumentCache {
    private var storage: [String: Document] = [:]
    private var inFlight: Set<String> = []

func document(for id: String) async throws -> Document {
        if let cached = storage[id] { return cached }
        if inFlight.contains(id) {
            // another task is already fetching; wait/poll or share the task
        }
        inFlight.insert(id)
        defer { inFlight.remove(id) }
        let doc = try await fetchRemote(id)
        storage[id] = doc // safe: not decided from stale pre-await state
        return doc
    }
}
```

Question 7

An unstructured Task spawned from a @MainActor UI component performs heavy cryptographic hashing on an image, causing noticeable frame drops during animations. Why does Task inherit the caller's actor context by default, and how do you explicitly offload work to cooperative background thread pools using Task.detached or non-isolated async functions?

Accepted Answer

`Task { ... }` created inside a function isolated to `@MainActor` inherits that actor's isolation for its body by default - it's not "inherits thread priority," it's "inherits the actor context of wherever it was created," so a plain `Task` launched from a MainActor-isolated view or view model runs its work on the main actor unless the code inside is itself not actor-isolated. That's why CPU-heavy work dropped into an unstructured `Task` from the main thread still causes frame drops: it never actually left the main actor.

To offload real work, either use `Task.detached { ... }`, which does not inherit the calling actor's isolation (but also drops task-local values and inherited priority, so use it deliberately), or call into a `nonisolated` function or a dedicated actor from inside the `@MainActor` Task, and only hop back to `@MainActor` for the final UI update.

```swift
@MainActor
func handleCapturedImage(_ image: UIImage) {
    Task {
        let hash = await Self.hash(image) // hops off MainActor internally
        self.hashLabel.text = hash // back on MainActor automatically
    }
}

nonisolated static func hash(_ image: UIImage) async -> String {
    await Task.detached(priority: .utility) { computeSHA256(image) }.value
}
```

Question 8

A legacy data-sync manager using GCD DispatchGroup crashes with an unbalanced dispatch_group_leave() or blocks the main thread with group.wait(timeout:), triggering a watchdog termination. How do you refactor this workflow into modern structured concurrency using withThrowingTaskGroup?

Accepted Answer

`DispatchGroup` requires every `enter()` to be matched by exactly one `leave()`, and it's easy for an early-return, an error branch, or a retry path to skip the matching `leave()` - which either crashes immediately (over-release) or leaves the group permanently unbalanced so a later `wait()` blocks forever. Calling `group.wait(timeout:)` on the main thread compounds this by risking a watchdog kill if the network calls take too long.

`withThrowingTaskGroup` replaces this entirely: each child task's completion (success or thrown error) is tracked automatically, there's no manual enter/leave bookkeeping to get wrong, and you `await` results asynchronously instead of blocking a thread.

```swift
func syncAll(_ ids: [String]) async throws -> [SyncResult] {
    try await withThrowingTaskGroup(of: SyncResult.self) { group in
        for id in ids {
            group.addTask { try await syncItem(id) }
        }
        var results: [SyncResult] = []
        for try await result in group {
            results.append(result)
        }
        return results
    }
}
```

If one child task throws, the group cancels the remaining children automatically and propagates the error - behavior you'd otherwise have to hand-roll with `DispatchGroup` and an error-collection array.

Question 9

Enabling Swift Strict Concurrency Checking flags hundreds of warnings where non-Sendable reference types and mutable closures cross actor isolation boundaries. Walk through your strategy to resolve these warnings using @Sendable, immutability, synchronization wrappers, or @unchecked Sendable.

Accepted Answer

Strict concurrency checking flags every place a value could plausibly be accessed from two threads at once without proven safety. The practical triage is: for plain data (structs/enums with only `Sendable` members), the compiler usually just needs the conformance added explicitly. For reference types that really do need to cross isolation boundaries, prefer wrapping their mutable state in an `actor` so access is serialized by construction, rather than fighting the checker.

For closures, capture only `Sendable` values and mark the closure `@Sendable` where the API requires it - usually this means removing captured mutable class references and passing immutable snapshots instead. Reach for `@unchecked Sendable` only as a documented last resort on a type you've manually verified is thread-safe, and leave a comment explaining why the compiler's static check doesn't apply.

```swift
final class LegacyCache: @unchecked Sendable {
    private let lock = NSLock()
    private var storage: [String: Data] = [:]
    func get(_ key: String) -> Data? {
        lock.lock(); defer { lock.unlock() }
        return storage[key]
    }
}
```

Question 10

A long-running iterative image filtering loop spawned in a Swift Concurrency Task continues executing and consuming CPU even after the user dismisses the presenting view. How do you implement cooperative cancellation using Task.isCancelled and Task.checkCancellation() inside tight compute loops?

Accepted Answer

Cancelling a `Task` only flips a flag - it does not forcibly stop execution. If your loop body never checks that flag, the task runs to completion regardless, still burning CPU on filtering frames nobody will see.

You need to check cooperatively at reasonable intervals: `Task.isCancelled` for a non-throwing check-and-break, or `try Task.checkCancellation()` inside a `throws` function to bail out with `CancellationError` immediately.

```swift
func applyFilters(to frames: [CVPixelBuffer]) async throws -> [CVPixelBuffer] {
    var output: [CVPixelBuffer] = []
    for frame in frames {
        try Task.checkCancellation() // throws CancellationError if cancelled
        output.append(try await filter(frame))
    }
    return output
}
```

Checking once per outer loop iteration (rather than deep inside a single filter operation) is usually the right granularity - fine enough to respond quickly, coarse enough not to add per-pixel overhead.

Question 11

A background parsing thread fetches Core Data entities and passes NSManagedObject instances directly to the main thread for UI rendering, causing sporadic crashes. How do you properly use performBackgroundTask, NSManagedObjectID, and merge policies across contexts to guarantee thread safety?

Accepted Answer

`NSManagedObject` instances are bound to the `NSManagedObjectContext` that created them and are not thread-safe to touch from any other thread/context - even just reading a property off the wrong thread can crash or silently corrupt data.

The correct pattern is to do the fetch inside `container.performBackgroundTask { bgContext in ... }`, extract only the `NSManagedObjectID` (which is safe to pass across threads), hop back to the main context, and re-fetch the object there via `mainContext.object(with: objectID)`. Set a `mergePolicy` (typically `NSMergeByPropertyObjectTrumpMergePolicy`) on contexts that might race on the same rows, and observe `NSManagedObjectContextDidSave` to merge changes between a background save and the main context's view of the same data.

```swift
container.performBackgroundTask { bgContext in
    let items = try? bgContext.fetch(request)
    let ids = items?.map(\.objectID) ?? []
    DispatchQueue.main.async {
        let mainItems = ids.compactMap { try? self.mainContext.existingObject(with: $0) }
        self.tableView.reloadData()
    }
}
```

Question 12

A fitness tracking application must record accurate GPS waypoints for a 4-hour marathon while the device screen is locked. How do you configure CLLocationManager background capabilities, deferred location updates, and handle thermal throttling states without having the OS terminate the app for battery drain?

Accepted Answer

Set `CLLocationManager.allowsBackgroundLocationUpdates = true` alongside the `location` background mode in Info.plist, request `.requestAlwaysAuthorization`, and set `activityType = .fitness` so the system's motion heuristics tune accuracy/power for a running workout rather than, say, automotive navigation. Use `desiredAccuracy = kCLLocationAccuracyBest` only while actively recording, and leave `pausesLocationUpdatesAutomatically` at its default `true` unless you have a specific reason to override it.

For a multi-hour session, `allowDeferredLocationUpdates(untilTraveled:timeout:)` lets the GPS chip batch fixes and wake your app less often, trading a little precision for significant battery savings. Watch `ProcessInfo.processInfo.thermalState`: if it climbs to `.serious`/`.critical`, drop `desiredAccuracy` and update frequency proactively rather than waiting for the OS to kill background execution - the OS will suspend location delivery or terminate the app if it decides the app is misbehaving thermally or draining battery disproportionately to the value it delivers, and there's no way to override that from app code.

Question 13

An authentication token stored in Keychain with a biometry-bound access control flag becomes permanently unreadable when a user adds a new fingerprint or updates their Face ID enrollment. How do you configure Keychain access control flags and handle biometric-change recovery flows gracefully?

Accepted Answer

`kSecAccessControlBiometryCurrentSet` deliberately invalidates the protected keychain item the moment the enrolled biometric set changes - this is Apple's intentional security behavior: it assumes the previous enrollment might have been compromised, so the old key becomes permanently unrecoverable rather than silently trusting a new biometric identity.

If your access control flag is `.biometryCurrentSet`, you must design for this: catch the specific authentication failure path, detect that it's due to an enrollment change (not just a failed attempt), and re-run your normal re-authentication flow (e.g. re-login with password/token) to regenerate and re-store a fresh Keychain item. If you don't need protection against biometric changes specifically, using `.biometryAny` instead avoids this class of failure entirely, at the cost of not invalidating the item when enrollment changes.

```swift
let access = SecAccessControlCreateWithFlags(
    nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
    .biometryCurrentSet, nil
)
// On read failure with errSecAuthFailed after enrollment change:
// fall back to forcing the user through full re-login, then re-store the token.
```

Question 14

An active camera scanning session freezes when the user receives an incoming cellular phone call or when the app enters Split View on iPad. How do you observe the capture session interruption notification, handle interruption reasons (such as audio-in-use or thermal pressure), and resume the capture pipeline?

Accepted Answer

Register for `.AVCaptureSessionWasInterrupted` and `.AVCaptureSessionInterruptionEnded` on `NotificationCenter`. The interruption notification carries an `AVCaptureSession.InterruptionReason` (`.audioDeviceInUseByAnotherClient`, `.videoDeviceNotAvailableWithMultipleForegroundApps` for Split View, `.videoDeviceNotAvailableDueToSystemPressure` for thermal issues) so you can show the right message instead of a generic error.

On `.AVCaptureSessionInterruptionEnded`, check whether `session.isRunning` is still `false` (some reasons, like Split View, don't auto-resume) and call `session.startRunning()` yourself on a background queue.

```swift
NotificationCenter.default.addObserver(
    forName: .AVCaptureSessionWasInterrupted, object: session, queue: .main
) { note in
    if let reasonValue = note.userInfo?[AVCaptureSessionInterruptionReasonKey] as? Int,
       let reason = AVCaptureSession.InterruptionReason(rawValue: reasonValue) {
        self.showInterruptionUI(for: reason)
    }
}
NotificationCenter.default.addObserver(
    forName: .AVCaptureSessionInterruptionEnded, object: session, queue: .main
) { _ in
    self.sessionQueue.async { if !self.session.isRunning { self.session.startRunning() } }
}
```

Question 15

A messaging app uses a Notification Service Extension to decrypt incoming end-to-end encrypted push payloads and download rich media attachments. How do you manage the strict 30-second execution window, handle network timeouts, and implement fallback payload presentation before the system kills the extension?

Accepted Answer

A Notification Service Extension gets roughly 30 seconds before iOS kills it, and if it dies without calling the `contentHandler`, the system shows the original (often generic/encrypted-looking) payload instead. The safe pattern is to override `serviceExtensionTimeWillExpire()`, which iOS calls shortly before the hard kill, and use it to immediately call the stored `contentHandler` with whatever best-effort content you have rather than nothing at all.

Structure the work so decryption happens first and fast (it's local), and treat the media download as optional/best-effort with its own short timeout - if the download hasn't finished when time is nearly up, ship the notification with the text content and skip the attachment.

```swift
override func didReceive(_ request: UNNotificationRequest, withContentHandler handler: @escaping (UNNotificationContent) -> Void) {
    contentHandler = handler
    bestAttemptContent = decrypt(request.content)
    downloadAttachment(timeout: 20) { attachment in
        self.bestAttemptContent?.attachments = attachment.map { [$0] } ?? []
        handler(self.bestAttemptContent ?? request.content)
    }
}

override func serviceExtensionTimeWillExpire() {
    if let content = bestAttemptContent { contentHandler?(content) }
}
```

Question 16

During rapid navigation transitions between a video player and a feed, memory increases continuously. Walk through your profiling workflow using Xcode Instruments (Allocations, Leaks, and Memory Graph Debugger) to distinguish between abandoned memory, caching overhead, and closure retain cycles.

Accepted Answer

The three tools answer different questions. Leaks specifically flags memory that's become unreachable but wasn't freed - classic retain cycles, e.g. two closures capturing each other strongly. Allocations shows the raw growth curve over time and lets you mark generations, which is how you tell abandoned memory (objects still technically reachable, so Leaks won't flag them, but nothing actually needs them anymore) from legitimate caching overhead that's supposed to grow and then plateau.

Memory Graph Debugger gives you the actual object graph at a point in time, with purple exclamation marks on objects it suspects are part of a cycle - usually the fastest way to actually find which two objects are holding each other. The typical workflow: reproduce the growth in Allocations with generation markers before/after the navigation loop, if the delta doesn't return to baseline check Leaks for confirmed cycles, then open Memory Graph Debugger at that point to identify the exact two objects and which property is the strong reference to break.

Question 17

An iOS application suffers from a 4-second cold launch time before the app delegate's launch callback is reached. Profiling reveals excessive pre-main binding and rebasing costs across 45 embedded dynamic frameworks. How do you optimize launch times by converting to static linking and mergeable libraries?

Accepted Answer

Every dynamic framework your app links has to be located, mapped, and have its symbols rebased and bound by `dyld` before `main()` runs - and this cost scales with the number of dynamic libraries, not just their combined size, because each one is a separate file-system lookup and a separate symbol-resolution pass. 45 embedded frameworks means 45x that fixed per-library overhead, which is exactly the pre-main time Instruments' App Launch template attributes to dyld.

Converting shared internal frameworks to static libraries (or a single static framework) merges their code into the main binary at build time, so there's one Mach-O to load instead of 46 - eliminating most of that rebasing/binding overhead, at the cost of losing separate framework modularity. Xcode 15's mergeable libraries (`MERGEABLE_LIBRARY` build setting) give a middle ground: you keep frameworks as separate build targets during development (incremental builds, clean module boundaries) but the linker merges them into the app binary for the shipped build, getting static-linking launch performance without giving up the dynamic-framework development workflow.

Question 18

Scrolling through a table of user cards drops frames to 30fps. The Core Animation instrument highlights intense yellow offscreen rendering passes caused by cornerRadius, masksToBounds, and dynamic shadow rendering. How do you eliminate offscreen render passes using shadowPath and rasterization caching?

Accepted Answer

Setting `cornerRadius` together with `masksToBounds = true` forces Core Animation to composite that layer off-screen - clipping to a rounded rect isn't expressible in the normal on-screen compositing path, so the GPU renders the layer to an intermediate buffer, masks it, then composites it back, redoing this every frame the layer's contents change. Dynamic shadows are separately expensive because by default `shadowPath` is nil, so Core Animation computes the shadow's shape from the layer's actual bounds every frame.

Fix the shadow first: give it an explicit `shadowPath` (a fixed `CGPath`), which changes the cost from recomputing the shape every frame to just rendering a fixed path, eliminating that offscreen pass entirely. For the corner radius + masking case, if the cell's content doesn't change while scrolling, `shouldRasterize = true` with `rasterizationScale = UIScreen.main.scale` caches the composited bitmap after the first render instead of recompositing every frame - but only use it on genuinely static content, since rasterizing a layer that changes every frame makes things slower, not faster.

```swift
layer.shadowPath = UIBezierPath(roundedRect: bounds, cornerRadius: 12).cgPath
layer.shouldRasterize = true
layer.rasterizationScale = UIScreen.main.scale
```

Question 19

Your team is automating CI/CD builds with Fastlane. How do you configure fastlane match using an encrypted Git repository and App Store Connect API keys to manage provisioning profiles and code signing certificates across multiple development teams without manual certificate sharing?

Accepted Answer

`fastlane match` centralizes your team's signing certificates and provisioning profiles in a private Git repo, encrypted with a passphrase, so every machine that needs to build/sign the app pulls the same certs instead of each developer generating their own (which is what causes too-many-certificates errors and mismatched profiles).

For CI specifically, authenticate with an App Store Connect API key (a `.p8` key plus issuer ID and key ID) instead of an Apple ID with 2FA - API keys don't require interactive 2FA approval and can be scoped with limited permissions, which is exactly what a CI runner needs since there's no human available to approve a prompt. Configure this via `app_store_connect_api_key` in the Fastfile, and store the key file and match repo passphrase as CI secrets so `fastlane match` can decrypt the repo and Fastlane can authenticate fully non-interactively.

```ruby
app_store_connect_api_key(
  key_id: ENV["ASC_KEY_ID"],
  issuer_id: ENV["ASC_ISSUER_ID"],
  key_content: ENV["ASC_KEY_CONTENT"]
)
match(type: "appstore", readonly: is_ci, git_url: ENV["MATCH_GIT_URL"])
```

Question 20

What is the difference between a strong, weak, and unowned reference in Swift's ARC, and when would you use each?

Accepted Answer

A strong reference is the default - it increments the retain count and keeps the referenced object alive as long as the reference exists. A weak reference doesn't increase the retain count, must be declared as an Optional, and is automatically set to nil by the runtime the moment the referenced object is deallocated - this is what you use for a delegate or any back-reference where the other object might legitimately outlive or not outlive the holder, and you can't guarantee which. An unowned reference also doesn't increase the retain count and doesn't require Optional, but it assumes the referenced object will always be alive when accessed - accessing it after deallocation is undefined behavior (a crash in practice), so it's only appropriate when you can prove the lifetimes are tied together.

```swift
class Order {
    weak var delegate: OrderDelegate? // delegate may or may not outlive Order
}

class CreditCard {
    unowned let customer: Customer // a card can never exist without its customer
    init(customer: Customer) { self.customer = customer }
}
```

The classic closure case is `[weak self]` in a completion handler stored by an object that also owns the closure (breaks a retain cycle safely), versus `[unowned self]` inside a closure whose lifetime is strictly shorter than or equal to self's (e.g. a closure passed synchronously and not stored).

Question 21

Explain the iOS app lifecycle and the difference between UIApplicationDelegate and UISceneDelegate.

Accepted Answer

`UIApplicationDelegate` handles process-level events that apply to the whole app regardless of how many windows/scenes it has: initial launch (`application(_:didFinishLaunchingWithOptions:)`), registering for remote notifications, and responding to the process being about to terminate. It's still the entry point every app has, but since iOS 13 it delegates per-window UI lifecycle to scenes.

`UISceneDelegate` (specifically `UIWindowSceneDelegate`) manages one window's/scene's lifecycle independently - `sceneDidBecomeActive`, `sceneWillResignActive`, `sceneDidEnterBackground` - which matters on iPad where a single app can have multiple scenes open side by side (Stage Manager, external display, multiwindow). A scene's state (foreground active, foreground inactive, background) is tracked per-scene, while the app-level delegate only knows about overall process state like whether any scene exists at all.

In practice: put anything that must happen exactly once regardless of window count (push token registration, setting up shared services) in the app delegate, and put anything about a specific window's UI state (restoring that window's navigation, responding to that window becoming key) in its scene delegate.

Question 22

What is the difference between a struct and a class in Swift?

Accepted Answer

A struct is a value type: when you assign it to a new variable or pass it to a function, you get an independent copy, so mutating the copy never affects the original. A class is a reference type: assignment copies a pointer to the same underlying instance, so mutating it through any reference is visible through every other reference to that same instance. Structs also can't inherit from another struct and have no deinitializers, while classes support inheritance and ARC-managed deallocation via `deinit`.

```swift
struct Point { var x = 0 }
var a = Point()
var b = a
b.x = 5
// a.x is still 0 - b was an independent copy

class Counter { var value = 0 }
let c1 = Counter()
let c2 = c1
c2.value = 5
// c1.value is also 5 - c1 and c2 point to the same object
```

Apple's own guidance is to default to structs for models and prefer classes only when you need reference semantics, identity, or inheritance - most SwiftUI view state and simple data models should be structs.

Question 23

What are optionals in Swift, and what are the different ways to safely unwrap them?

Accepted Answer

An optional represents a value that might be present or might be absent (`nil`) - it's Swift's type-safe alternative to null pointers, where the absence of a value is encoded in the type system (`Int?` versus `Int`) so the compiler forces you to handle the missing case before using the value.

The safe ways to unwrap: `if let name = optionalName { ... }` for a conditional branch, `guard let name = optionalName else { return }` to unwrap and exit early if nil, the nil-coalescing operator `optionalName ?? "default"` to substitute a fallback, and optional chaining `user?.address?.city` which short-circuits to nil at the first nil link instead of crashing. Force-unwrapping with `!` skips all of this and crashes immediately if the value is nil, so it should only be used when you can prove (not just hope) the value is present, such as right after you just assigned it.

```swift
func greet(name: String?) -> String {
    guard let name else { return "Hello, stranger" }
    return "Hello, \(name)"
}
```

Question 24

What are the differences between MVC, MVVM, and VIPER architecture patterns in iOS, and when would you choose each?

Accepted Answer

MVC is Apple's default for UIKit: Model holds data, View displays it, and the View Controller mediates between them - simple to start with, but the view controller tends to absorb networking, formatting, and business logic over time, leading to the well-known "Massive View Controller" problem in larger apps. MVVM adds a ViewModel layer between the model and the view/controller: the ViewModel exposes formatted, observable state (via Combine, @Published, or @Observable) and handles presentation logic, so the view controller becomes a thin binder, and the ViewModel is unit-testable without touching UIKit at all.

VIPER splits things further - View, Interactor (business logic), Presenter (presentation logic, replaces the ViewModel role), Entity (data), and Router (navigation) - giving each responsibility its own protocol-defined boundary. This buys strong testability and clear ownership on large teams working on the same module simultaneously, at the cost of significant boilerplate (five+ files per screen) that's overkill for a small app or a solo developer.

In practice: MVC is fine for genuinely simple screens, MVVM is the sweet spot for most SwiftUI/Combine-era apps, and VIPER earns its cost mainly on large teams where strict module boundaries matter more than development speed.

Question 25

Explain the delegation pattern in iOS with an example.

Accepted Answer

Delegation is a one-to-one pattern where an object hands off a specific responsibility - usually deciding what to do in response to an event - to another object, without knowing anything concrete about that object beyond a protocol it conforms to. This keeps the delegating object generic and reusable, since it doesn't hardcode what happens; it just calls out through the protocol.

UIKit uses this everywhere - `UITableViewDataSource`/`UITableViewDelegate` are the canonical example, where the table view asks its delegate for cell content and reacts to selection without knowing anything about your view controller. The delegate reference is almost always `weak` to avoid a retain cycle, since the delegating object typically owns (or is owned in the same direction as) the delegate.

```swift
protocol DownloadTaskDelegate: AnyObject {
    func downloadDidFinish(_ task: DownloadTask, data: Data)
    func downloadDidFail(_ task: DownloadTask, error: Error)
}

class DownloadTask {
    weak var delegate: DownloadTaskDelegate?
    func start() {
        // on completion:
        delegate?.downloadDidFinish(self, data: receivedData)
    }
}
```

Question 26

What's the difference between Grand Central Dispatch (GCD) and OperationQueue?

Accepted Answer

GCD is the lower-level C-based API: you submit closures onto serial or concurrent `DispatchQueue`s and the system schedules them on a thread pool, using quality-of-service (QoS) to prioritize. It's lightweight and great for straightforward fire-and-forget or synchronization work, but it has no built-in concept of a task's identity, dependencies, or cancellation once submitted.

`OperationQueue` is Foundation's object-oriented wrapper: each unit of work is an `Operation` object (or a `BlockOperation`) that's KVO-observable (`isExecuting`, `isFinished`, `isCancelled`), can declare dependencies on other operations so B doesn't start until A finishes, supports actual cancellation you check for cooperatively, and can cap `maxConcurrentOperationCount`.

```swift
let queue = OperationQueue()
let fetchOp = FetchImageOperation(url: imageURL)
let processOp = ProcessImageOperation()
processOp.addDependency(fetchOp)
queue.addOperations([fetchOp, processOp], waitUntilFinished: false)
```

Use GCD for simple, independent async work; reach for `OperationQueue` when you need dependencies between tasks, need to cancel in-flight work, or want to reuse a configurable `Operation` subclass across the app.

Question 27

How does Auto Layout resolve constraints, and what causes an 'ambiguous layout' warning?

Accepted Answer

Auto Layout treats each constraint as a linear equation relating two attributes (e.g. `view1.leading == view2.trailing + 8`), and at layout time it solves the full system of equations for every view's frame simultaneously. For a view's frame to be fully determined, there need to be enough constraints to pin down its x position, y position, width, and height (directly or via constraints on sibling/superview views that transitively fix them).

An "ambiguous layout" warning means the system is underconstrained - there are multiple valid frames that satisfy every constraint you gave it, so Auto Layout picks one somewhat arbitrarily (and it may differ between runs or devices) rather than there being one unique answer. This is different from an "unsatisfiable constraints" error, which means constraints directly conflict (two required constraints demanding different values for the same attribute) - Auto Layout resolves that by breaking whichever constraint has the lowest priority and logging which ones it broke.

A common ambiguous case: pinning a view's leading and top, giving it no width/height constraint, and its content has no intrinsic size (a plain `UIView`, not a `UILabel`) - there's nothing telling Auto Layout how big the view should be, so its size is ambiguous until you add a width/height constraint or something with a real intrinsic content size.

Question 28

How do you use Codable to handle custom JSON keys and non-standard date formats?

Accepted Answer

For renaming fields, declare a nested `CodingKeys` enum conforming to `CodingKey` that maps your Swift property names to the JSON key names - the compiler auto-synthesizes `Codable` using those mappings instead of exact name matches. For transformations that go beyond renaming (nested/flattened JSON, computed properties), implement `init(from:)` and `encode(to:)` manually using a keyed container.

For dates, `JSONDecoder`'s default `dateDecodingStrategy` is `.deferredToDate` (a raw timestamp), which rarely matches a real API - set it to `.iso8601` for standard ISO-8601 strings, or supply a `.formatted(DateFormatter)` / `.custom { decoder in ... }` closure for a nonstandard format the built-in strategies don't cover.

```swift
struct Article: Codable {
    let title: String
    let publishedAt: Date
    enum CodingKeys: String, CodingKey {
        case title
        case publishedAt = "published_at"
    }
}

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
```

Question 29

How does UITableView cell reuse work, and what problem does UITableViewDiffableDataSource solve?

Accepted Answer

`UITableView` keeps a pool of off-screen cells per reuse identifier instead of creating a new cell object for every row; `dequeueReusableCell(withIdentifier:)` recycles one of those instead of allocating, which is what makes scrolling through thousands of rows cheap. Because the cell is recycled, any per-cell state you set (image, selection state, accessory views) has to be reset or reassigned every time in `cellForRowAt` or in `prepareForReuse`, or leftover state from a previous row bleeds into the new one - the classic "wrong image flashes briefly" bug from an async image load landing on a cell that's since been reused for a different row.

`UITableViewDiffableDataSource` solves a different problem: manually calling `reloadData()` or `insertRows`/`deleteRows` with hand-computed index paths is error-prone and crashes if your counts and the data don't agree exactly. Diffable data sources instead work off `NSDiffableDataSourceSnapshot`, a value type describing the desired sections/items by stable identifier; you apply a new snapshot and the data source computes the minimal diff and animates the correct inserts/deletes/moves automatically, eliminating the class of crash caused by manual index-path math being out of sync with the actual data.

```swift
var snapshot = NSDiffableDataSourceSnapshot<Section, Item>()
snapshot.appendSections([.main])
snapshot.appendItems(newItems, toSection: .main)
dataSource.apply(snapshot, animatingDifferences: true)
```

Question 30

Explain the differences between @State, @Binding, @StateObject, @ObservedObject, and @EnvironmentObject in SwiftUI.

Accepted Answer

`@State` is for value-type data a view owns and is the source of truth for locally - SwiftUI persists it across body re-evaluations for that view's identity. `@Binding` doesn't own data; it's a reference to state owned elsewhere, letting a child view read and write a parent's value without copying it (e.g. a custom `Toggle` needs a `Binding<Bool>`, not a `Bool`).

`@StateObject` and `@ObservedObject` both wrap a reference-type `ObservableObject`, but differ in ownership: `@StateObject` tells SwiftUI "create and own this instance for the view's whole lifetime" - it survives the view being recreated by a parent's re-render. `@ObservedObject` assumes the object is owned and created elsewhere and just observes it - if you accidentally create the object inline with `@ObservedObject`, it gets recreated (losing its state) every time the parent redraws, which is the most common bug in this area.

`@EnvironmentObject` is for objects that many views deep in the hierarchy need without threading them through every intermediate view's initializer - it's injected once via `.environmentObject()` on an ancestor and implicitly available to every descendant, at the cost of that dependency being invisible at the call site (you can't tell a view needs it just from how it's constructed).

Question 31

How does Combine's publisher-subscriber model work?

Accepted Answer

A `Publisher` declares a stream of values (and eventually a completion or failure) over time, but nothing happens until a `Subscriber` attaches to it - Combine is pull-driven via backpressure: the subscriber requests a certain demand (how many values it's ready to receive), and the publisher only sends that many, which prevents an unbounded producer from overwhelming a slow consumer. Operators (`map`, `filter`, `debounce`, `combineLatest`, etc.) are themselves publishers that wrap an upstream publisher, letting you build a declarative transformation pipeline instead of manually chaining callbacks.

Subscribing returns a `AnyCancellable` you must retain (usually in a `Set<AnyCancellable>`) - if you let it deallocate, the subscription is cancelled automatically, which is a common source of "my Combine pipeline just stopped firing" bugs when the cancellable wasn't stored anywhere.

```swift
NotificationCenter.default.publisher(for: .textDidChange)
    .debounce(for: .milliseconds(300), scheduler: RunLoop.main)
    .sink { [weak self] _ in self?.performSearch() }
    .store(in: &cancellables)
```

Question 32

What's the difference between async/await and completion handler-based asynchronous code in Swift?

Accepted Answer

A completion-handler API takes a closure that gets called later with the result, which means the calling code's flow is inverted - error handling goes through a `Result` or a separate `(data, error)` pair you have to check manually, and chaining several async steps nests closures inside closures ("callback hell"), making control flow (loops, early returns, try/catch) awkward or impossible to express directly.

`async`/`await` lets you write the same sequence of steps as ordinary linear code: `let data = try await fetch()` reads top-to-bottom, errors propagate with normal `throws`/`catch`, and the compiler enforces that every suspension point is marked with `await` so you always know where control could yield. It also plugs into structured concurrency - cancellation, task priority, and parent/child task relationships are handled by the language rather than something you build yourself with flags and checks.

```swift
// completion handler
fetchUser(id) { result in
    switch result {
    case .success(let user): self.render(user)
    case .failure(let error): self.showError(error)
    }
}

// async/await
do {
    let user = try await fetchUser(id)
    render(user)
} catch {
    showError(error)
}
```

Question 33

How do closures cause retain cycles in Swift, and how do capture lists fix this?

Accepted Answer

A closure captures any external variables it references, and by default it captures `self` strongly if the closure calls a method or reads a property on self. If an object also holds a strong reference to that closure - for example, storing a completion handler as a property, or a `Timer` retained by the object whose closure captures self - you get two strong references pointing at each other: the object keeps the closure alive, and the closure keeps the object alive, so neither is ever deallocated.

A capture list fixes this by specifying how a variable should be captured instead of the default strong capture: `[weak self]` captures self as a weak optional reference (won't keep it alive, becomes nil if it deallocates), and `[unowned self]` captures it without the optional wrapper but assumes self will always outlive the closure.

```swift
class ViewModel {
    var onUpdate: (() -> Void)?
    func startTimer() {
        Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [weak self] _ in
            guard let self else { return }
            self.refresh()
        }
    }
}
```

Question 34

What is dependency injection, and why is it useful in iOS app architecture?

Accepted Answer

Dependency injection means a type receives the objects it depends on (a network client, a persistence layer, a clock) from the outside - via its initializer or a settable property - instead of constructing them internally. The dependent type only knows about a protocol, not a concrete implementation, so the caller decides what actually gets used.

This matters most for testability: without injection, a `ViewModel` that calls `URLSession.shared` directly can only be tested against the real network, but a `ViewModel` that takes a `NetworkClient` protocol in its initializer can be tested with a fake that returns canned responses instantly and deterministically. It also decouples modules so you can swap implementations (a mock during development, a different backend, a cached wrapper) without touching the consumer's code.

```swift
protocol NetworkClient { func fetch(_ url: URL) async throws -> Data }

final class ProfileViewModel {
    private let client: NetworkClient
    init(client: NetworkClient = URLSessionClient()) { self.client = client }
}

// in tests:
ProfileViewModel(client: MockNetworkClient(stubbedData: fixtureJSON))
```

Question 35

How do you write unit tests with XCTest, including mocking network calls?

Accepted Answer

A test target subclasses `XCTestCase`, uses `setUpWithError()`/`tearDownWithError()` for per-test setup/teardown, and each test method (prefixed `test`) asserts expectations with `XCTAssertEqual`, `XCTAssertTrue`, `XCTAssertThrowsError`, etc. For code that's already `async`, you write the test function itself as `async throws` and just `await` the call directly - no `XCTestExpectation` needed for that case; expectations are still the right tool for testing older delegate/notification-based async APIs that don't use async/await.

To avoid hitting the real network in tests, the code under test should depend on a protocol (see dependency injection) rather than `URLSession` directly, so the test can substitute a mock that returns fixed data instantly.

```swift
final class ProfileViewModelTests: XCTestCase {
    func testLoadProfile_success() async throws {
        let mock = MockNetworkClient(stubbedData: sampleProfileJSON)
        let viewModel = ProfileViewModel(client: mock)
        try await viewModel.load()
        XCTAssertEqual(viewModel.name, "Jane Doe")
    }
}
```

Question 36

When would you choose Core Data vs SwiftData vs a third-party solution like Realm for local persistence in an iOS app?

Accepted Answer

Core Data is the mature, battle-tested option - it works back to very old iOS versions, gives you full control over the object graph, migrations, and performance tuning, but its API (NSManagedObject subclassing, contexts, fetch requests) has a real learning curve and a lot of boilerplate for simple cases. SwiftData (iOS 17+) is Apple's modern macro-based layer that drastically cuts that boilerplate - `@Model` classes and simple `#Predicate` queries - and integrates cleanly with SwiftUI, but it requires a recent minimum OS target and, being newer, has had rough edges (performance and migration behavior) that a team should validate for their specific use case before betting the whole persistence layer on it.

Realm is a third-party alternative with a simpler object model and good cross-platform story (shared code with Android), but it adds a real external dependency with its own release cadence, and migrating away from it later is nontrivial since its storage format and API are proprietary, unlike Core Data/SwiftData which stay within Apple's own tooling and both support CloudKit sync natively.

In practice: for a new app targeting iOS 17+ with simple-to-medium data needs, SwiftData is usually the pragmatic default; for apps needing deep customization, a lower minimum deployment target, or an existing Core Data investment, staying with Core Data is often the lazier and safer choice than a risky migration.

Question 37

What is App Transport Security (ATS), and when would you need to configure exceptions to it?

Accepted Answer

App Transport Security is an iOS-enforced default that requires all your app's network connections to use HTTPS with TLS 1.2 or higher and modern cipher suites (including forward secrecy) - plain HTTP requests are blocked outright unless you explicitly opt out for specific cases. You'd configure an exception via `NSAppTransportSecurity` / `NSExceptionDomains` in Info.plist when you genuinely can't avoid a non-compliant endpoint - a legacy internal API mid-migration to HTTPS, or a third-party SDK/ad network still serving over plain HTTP. Scope the exception to the specific domain that needs it rather than the blanket `NSAllowsArbitraryLoads`, since App Store review scrutinizes broad ATS exceptions and can reject an app that disables the protection app-wide without clear justification. ```xml NSAppTransportSecurity NSExceptionDomains legacy-internal-api.example.com NSExceptionAllowsInsecureHTTPLoads ```

Question 38

What are some common reasons for App Store rejection, and how do you avoid them?

Accepted Answer

Guideline 2.1 (App Completeness) covers crashes, obvious bugs, and broken links found during review - the most avoidable category, caught by actually testing a clean install on a real device before submitting. Guideline 5.1.1 (Privacy) rejections happen when an app requests camera, location, or contacts access without a clear, honest `NSUsageDescription` string explaining why, or when it tracks users across apps without showing the App Tracking Transparency prompt first.

Guideline 3.1.1 (In-App Purchase) trips up apps that sell digital content or subscriptions through an external payment link instead of StoreKit - Apple requires digital goods to go through their in-app purchase system. Guideline 4.3 (Spam) can flag an app that's a thin reskin of another app already in the Store, or that duplicates functionality with no meaningful differentiation.

Avoiding these mostly comes down to: test on a clean device before submitting, fill in every privacy usage string honestly and match it to what the app actually does, route digital purchases through StoreKit, and follow the Human Interface Guidelines rather than shipping placeholder/incomplete screens.

Question 39

What are the requirements for integrating Sign in with Apple, and when is it mandatory?

Accepted Answer

Per App Store Review Guideline 4.8, if your app offers any third-party login option (Google, Facebook, etc.) as a way to create or access an account, you must also offer Sign in with Apple as an equivalent option - it doesn't have to be your only login method, but it can't be missing when other social logins are present.

Technically, you integrate it via `ASAuthorizationAppleIDProvider` and `ASAuthorizationController`, requesting the user's name and email scopes; Apple lets the user choose to hide their real email behind a private relay address that still forwards mail to them, so your backend needs to handle emails in that relay format like any other. Because the user can later revoke access to your app from their Apple ID settings, you should periodically check `ASAuthorizationAppleIDProvider.credentialState(forUserID:)` and sign the user out locally if the credential has been revoked, rather than assuming a successful sign-in at one point in time remains valid forever.

```swift
let provider = ASAuthorizationAppleIDProvider()
provider.getCredentialState(forUserID: storedUserID) { state, _ in
    if state == .revoked { self.signOutLocally() }
}
```

Question 40

What's the difference between a UIView's frame and its bounds?

Accepted Answer

`frame` describes a view's position and size in its superview's coordinate system - it's how the parent sees the child. `bounds` describes the view's size in its own internal coordinate system, and its origin is normally `(0, 0)` unless something changes it - most notably a `UIScrollView`, where `bounds.origin` actually represents the current content offset as the user scrolls.

Applying a rotation or scale `transform` to a view changes its `frame` (the bounding box of the transformed shape as seen by the superview) while its `bounds` size stays exactly the same, since bounds describes the view's own untransformed content space, not how it appears to its parent.

```swift
let view = UIView(frame: CGRect(x: 10, y: 10, width: 100, height: 50))
print(view.bounds) // (0, 0, 100, 50) - always starts at origin for a plain view
view.transform = CGAffineTransform(rotationAngle: .pi / 4)
print(view.frame) // a larger bounding box after rotation
print(view.bounds) // still (0, 0, 100, 50) - unchanged
```

Question 41

Explain how push notifications work end-to-end via APNs.

Accepted Answer

The app registers for remote notifications (`UIApplication.shared.registerForRemoteNotifications()`), and iOS contacts Apple's servers to mint a unique device token, which is handed back to your app in `didRegisterForRemoteNotificationsWithDeviceToken`. Your app sends that token to your own backend, which stores it against the user's account - the token is the addressing information your server needs to target that specific device later.

When your backend wants to send a notification, it authenticates to Apple Push Notification service (APNs) - typically with a `.p8` authentication key over HTTP/2, or historically a certificate - and posts a JSON payload addressed to that device token. APNs is the only party that can actually deliver to the device; it holds a persistent connection to every online device and routes the payload down that connection.

On the device, if the app isn't running or is backgrounded, iOS displays the notification banner directly (or, for a mutable-content payload, first runs it through a Notification Service Extension for decryption/attachment handling); if the app is foregrounded, the system instead calls your `UNUserNotificationCenterDelegate`'s `willPresent` method so you decide whether/how to show it while the user is already looking at the app.

Question 42

How does dynamic dispatch differ between classes and protocols in Swift, and what role do protocol witness tables play?

Accepted Answer

Class methods that can be overridden are dispatched through a vtable - each class has an array of function pointers, one slot per overridable method, and calling the method looks up the slot at runtime so a subclass's override is found even when called through a superclass-typed reference. Marking a method `final` or a class as non-overridable lets the compiler skip this and call directly (static dispatch), which is faster.

Protocols use a different mechanism: a witness table, generated once per concrete type that conforms to the protocol, mapping each protocol requirement to that specific type's implementation. When you call a method through a generic parameter constrained to a protocol (`func process<T: Drawable>(_ item: T)`), the compiler can often specialize the call at compile time for the concrete type actually passed in, giving static dispatch. But calling through an existential (`any Drawable`) requires looking up the right implementation via the witness table at runtime, since the concrete type is erased and could be anything conforming to the protocol - this is dynamically dispatched, similar in cost to a class vtable call but with an extra indirection through the existential container.

Question 43

What's the difference between `some` and `any` for protocol types in Swift, and why does it matter for performance?

Accepted Answer

`some Protocol` is an opaque type: the function returning it commits to one specific concrete underlying type, decided at compile time, even though the caller only sees the protocol interface. Because the compiler knows the real type, it can use static dispatch and avoid boxing the value, and it's why `some View` in SwiftUI is efficient even though every screen is technically a different concrete struct type.

`any Protocol` is an existential: it can hold any type conforming to the protocol, decided at runtime, which is genuinely more flexible (you can put different concrete types into the same array) but comes at a cost - the runtime needs an existential container to store the value (which may heap-allocate if the value is larger than the container's small inline buffer), and calls go through the protocol's witness table dynamically rather than being resolved statically.

```swift
func makeRow() -> some View { Text("Hi") } // one concrete type, static dispatch, no boxing

let shapes: [any Shape] = [Circle(), Square()] // heterogeneous, needs existential boxing
```

Use `some` whenever a function commits to a single underlying type (the vast majority of SwiftUI view-building code); reach for `any` only when you genuinely need heterogeneity, like a mixed-type collection.

Question 44

How does Swift's copy-on-write (COW) work for Array and Dictionary, and how would you implement it for a custom type?

Accepted Answer

Under the hood, `Array` and `Dictionary` are structs that hold a reference to a heap-allocated buffer class. Assigning one array variable to another just copies that reference - cheap, no data duplication - so two variables can briefly point at the same underlying buffer while behaving as if they're independent value types. The actual copy only happens lazily, at the moment either variable tries to mutate: the mutating method checks `isKnownUniquelyReferenced(&buffer)`, and if the buffer is shared (reference count > 1), it allocates a fresh copy of the storage before applying the mutation; if it's uniquely referenced already, it mutates in place with no copy at all. To implement COW for your own type, wrap your storage in a private reference type and check uniqueness in every mutating method: ```swift final class Storage { var elements: [T]; init(_ elements: [T]) { self.elements = elements } } struct MyCollection { private var storage: Storage init(_ elements: [T]) { storage = Storage(elements) } mutating func append(_ element: T) { if !isKnownUniquelyReferenced(&storage) { storage = Storage(storage.elements) // clone before mutating } storage.elements.append(element) } } ``` This gives value semantics (independent copies from the caller's point of view) while avoiding the cost of actually duplicating data on every assignment - only on the assignments that are followed by a real mutation while shared.

Question 45

What's the difference between ABI stability and module stability in Swift, and why do they matter for distributing binary frameworks?

Accepted Answer

ABI stability (locked in with Swift 5.0) means the compiled binary interface - calling conventions, how types are laid out in memory, name mangling - is fixed going forward, so a binary compiled with one Swift compiler version can call into and be called by code compiled with a later compiler version, and apps can link against the Swift runtime that ships with the OS instead of bundling their own copy of it (which is why apps got smaller and why old apps still run on newer OS versions without embedding libswiftCore).

Module stability (Swift 5.1) is a separate, higher-level guarantee: it lets a framework ship a `.swiftinterface` file - a textual description of its public API - that any future Swift compiler version can read reliably, rather than requiring the exact compiler version used to build the framework. This is specifically what makes distributing a closed-source binary `.xcframework` viable: without module stability, a framework built with one Xcode/Swift version might not be safely consumable by a project using a different Swift compiler version, even though ABI stability alone guarantees the binaries can call each other correctly at runtime.

Question 46

What is Swift's memory exclusivity enforcement, and when does it cause a runtime trap?

Accepted Answer

Swift's law of exclusivity states that you cannot have two overlapping accesses to the same storage location where at least one of them is a mutation - the compiler and runtime need this guarantee to safely optimize value-type mutation (like the in-place COW mutation described above) without worrying that another part of the program is reading or writing the same memory mid-mutation. Some violations are caught at compile time; others - typically involving global variables, class instance properties, or closures capturing `inout` parameters - are only detectable at runtime and trigger a trap with a message like "Simultaneous accesses to 0x..., but modification requires exclusive access."

A classic example is passing a global variable as `inout` to a function that also reads that same global from inside a closure it calls internally:

```swift
var counter = 0
func increment(_ value: inout Int) {
    value += readCounterSomehowInternally() // reads global `counter` while it's exclusively borrowed above
}
increment(&counter) // traps at runtime: overlapping access
```

The practical takeaway is to avoid capturing and mutating the same property/global from two different call paths that could be active simultaneously - restructure so a value is either passed explicitly or accessed through one clear path, not both an `inout` parameter and a captured reference at once.

Question 47

How would you diagnose and fix a priority inversion caused by a low-QoS serial queue being blocked while a high-QoS task waits on it?

Accepted Answer

Priority inversion happens when a high-QoS thread ends up waiting - via a lock, semaphore, or `DispatchQueue.sync` - on work that's scheduled on a low-QoS queue, and the OS scheduler doesn't give that low-priority work enough CPU time to finish quickly, so the high-priority caller is effectively stuck behind lower-priority work indefinitely, even though its own QoS says it should be running soon. GCD does propagate QoS automatically in many cases (submitting high-QoS work to a queue temporarily boosts that queue's priority for the duration), but manual synchronization primitives like a raw `pthread_mutex` or an older `NSLock` don't automatically boost the priority of whoever's holding the lock, so a low-priority lock holder can stall a high-priority waiter.

Diagnose it with Instruments' Time Profiler / Thread State tracks, which explicitly flag threads in a "priority inverted" state, showing you exactly which lower-priority thread is holding up a higher-priority one. The fix is either to avoid the high-priority thread blocking synchronously on low-priority work at all (restructure to async), or to use a synchronization primitive with priority inheritance (`os_unfair_lock` implements priority inheritance on supported OS versions) instead of a plain lock that doesn't.

Question 48

Why are `indirect` enums needed for recursive data structures in Swift, and how are they represented in memory?

Accepted Answer

An enum's storage size must be knowable at compile time - the compiler needs to reserve enough space to hold the largest case's associated values inline. A case that contains another instance of the same enum (like a binary tree node holding two more tree nodes as children) would require infinite size to store fully inline, since expanding one level always reveals another level needing the same amount of space. `indirect` (applied to the whole enum or to just the recursive case) tells the compiler to store that case's associated values behind a hidden heap allocation instead of inline - conceptually similar to a class reference, which is always a fixed-size pointer no matter what it points to. This breaks the infinite-size problem: the enum itself only needs to store a fixed-size box reference for the recursive case. ```swift indirect enum Tree { case leaf(T) case node(Tree, Tree) } let t = Tree.node(.leaf(1), .node(.leaf(2), .leaf(3))) ``` The cost is an extra heap allocation and pointer indirection for every recursive case, which is why you only mark the specific recursive case `indirect` rather than the whole enum when only one case actually needs it, keeping the non-recursive cases stored inline for free.

Question 49

What's the difference between `as!`, `unsafeDowncast`, and `unsafeBitCast` in Swift, and when (if ever) would you use the unsafe variants?

Accepted Answer

`as!` performs a runtime-checked forced downcast - if the cast is invalid, it fails with a clear, catchable-in-debugging trap message telling you exactly what type mismatch happened. This is the right default any time correctness matters more than the small overhead of the runtime check, which is almost always.

`unsafeDowncast` skips that runtime check for class-hierarchy casts - it's purely a compiler hint that says "trust me, this is definitely that type," saving the check's overhead. It's only valid when you can prove externally that the cast always succeeds (e.g. you just created every object in a loop as that exact type), because an incorrect `unsafeDowncast` is undefined behavior, not a clean crash - it can silently corrupt memory instead of failing loudly.

`unsafeBitCast` is far more dangerous still: it reinterprets the raw bits of one type as another with zero validation of any kind, ignoring both runtime checks and whether the two types even have compatible memory layouts. Legitimate uses are extremely rare - low-level C interop or reinterpreting function pointer types in specific bridging scenarios - and it's essentially never appropriate in ordinary app code; reaching for it to work around a type-system disagreement is almost always solving the wrong problem.

Question 50

How does the Objective-C runtime's message dispatch interoperate with Swift's `@objc dynamic`, and what does method swizzling actually change at runtime?

Accepted Answer

A normal Swift method is resolved at compile time (static dispatch) or via a Swift-native vtable (class dispatch) - the call target is fixed by the time the binary runs. Marking a method `@objc dynamic` forces it through the Objective-C runtime's message-sending mechanism instead: every call becomes `objc_msgSend(receiver, selector, args...)`, which looks up the selector in the receiving class's method table (a dictionary from selector to implementation, or IMP) at the moment the call happens, not ahead of time.

This indirection is exactly what makes a method swizzlable and KVO-observable, because both features work by mutating that selector-to-IMP mapping at runtime - KVO dynamically creates a subclass that overrides the setter's IMP, and swizzling directly swaps which IMP a selector points to using `method_exchangeImplementations` (or `class_replaceMethod` for more control), rerouting every future call to that selector to a different implementation without touching the original source file.

```swift
extension UIViewController {
    @objc dynamic func swizzled_viewWillAppear(_ animated: Bool) {
        AnalyticsLogger.logScreenView(String(describing: type(of: self)))
        swizzled_viewWillAppear(animated) // calls the original, now-swapped implementation
    }
}
// swap viewWillAppear(_:) <-> swizzled_viewWillAppear(_:) once at app launch
```

The cost is the `objc_msgSend` dispatch overhead on every call (negligible for most UI code) and losing the compiler's ability to devirtualize or inline the call, since the actual target is only known at runtime.

iOS Interview Questions & Answers

Ready to practice these live?