MediumTechnical

56 practiced

Compare and contrast the delegate pattern, NotificationCenter, and closure callbacks for object-to-object communication on iOS. For each approach discuss coupling, one-to-one vs one-to-many semantics, lifetime and retain-cycle concerns, thread-safety, and testability. Give typical use-cases for each.

EasyTechnical

71 practiced

Explain how NotificationCenter (NSNotificationCenter) works on iOS. Describe how to add an observer and post notifications in Swift, discuss thread delivery semantics, and explain common pitfalls such as observer leak and race conditions. Provide a short example using the block-based token API.

Sample Answer

**How NotificationCenter works (high level)**- Central pub/sub within a process. You post a Notification (name, optional object, userInfo) to NotificationCenter.default; registered observers receive it synchronously on the posting thread unless you request delivery on a queue.

**Add observer / post (Swift)**- Selector-based: - NotificationCenter.default.addObserver(self, selector: #selector(handle(_:)), name: .MyNotification, object: nil) - NotificationCenter.default.post(name: .MyNotification, object: self, userInfo: ["k": "v"])- Block-based (token API) — preferred for safe removal and capture control:

swift

// block-based observer with token
let token = NotificationCenter.default.addObserver(
    forName: .MyNotification,
    object: nil,
    queue: OperationQueue.main // deliver handler on main thread
) { [weak self] notification in
    guard let self = self else { return }
    // handle notification, safe to update UI
}

// later, remove
NotificationCenter.default.removeObserver(token)

**Thread delivery semantics**- By default delivery is synchronous on the posting thread.- If you pass an OperationQueue, the block is scheduled on that queue (e.g., .main for UI).- Always dispatch to main for UI updates if posting happened off-main.

**Common pitfalls**- Observer leak / retain cycle: selector-based observers must be removed (do in deinit); block-based tokens must be removed or stored and removed — token is retained by center; capture self weakly in blocks to avoid cycles.- Race conditions: posting before observer registration means missed notifications; consider state checks or using other patterns (delegates, completion handlers) when ordering matters.- Thread-safety: avoid long work on Notification handlers; coordinate with locks if notifications mutate shared state.

Use block-based API with weak captures and explicit removeObserver for robust, modern code.

HardTechnical

68 practiced

Your app leaks memory when navigating repeatedly between view controllers. Heap snapshots show many NSTimer and CADisplayLink instances and view controllers not deallocated. Diagnose the root cause and propose code-level fixes, including alternatives to timers that avoid retaining the target and best practices for invalidation and cleanup.

Sample Answer

**Diagnosis (root cause)** NSTimer and CADisplayLink both retain their target (and the run loop retains the timer). If a view controller is the target or captures self strongly in a block, the timer/display link keeps the VC alive — causing leaked view controllers when you navigate away without invalidating.

**Fixes — principles**- Don’t let timers/display links strongly retain view controllers.- Always invalidate/stop them (and remove from run loop) during teardown (viewWillDisappear / deinit).- Prefer timers that use weak references or GCD timers that you can cancel.

**Code-level fixes**

1) Weak-proxy pattern for CADisplayLink / Timer:

swift

// WeakProxy.swift
final class WeakProxy: NSObject {
  weak var target: AnyObject?
  init(target: AnyObject) { self.target = target }
  override func forwardingTarget(for aSelector: Selector!) -> Any? { target }
  override func responds(to aSelector: Selector!) -> Bool { target?.responds(to: aSelector) ?? false }
}

swift

// In ViewController
let displayLink = CADisplayLink(target: WeakProxy(target: self), selector: #selector(tick))
displayLink.add(to: .main, forMode: .common)
deinit { displayLink.invalidate() }

2) Timer with block and [weak self] or GCD timer:

swift

// Using Timer with block
timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { [weak self] _ in
  guard let self = self else { return }
  self.updateUI()
}
RunLoop.main.add(timer!, forMode: .common)

swift

// Using DispatchSourceTimer
let queue = DispatchQueue(label: "com.app.timer")
let dsTimer = DispatchSource.makeTimerSource(queue: queue)
dsTimer.schedule(deadline: .now(), repeating: 1.0)
dsTimer.setEventHandler { [weak self] in DispatchQueue.main.async { self?.updateUI() } }
dsTimer.resume()
deinit { dsTimer.cancel() }

**Invalidation & cleanup best practices**- Invalidate in viewWillDisappear(_:), viewDidDisappear(_:), or deinit depending on lifecycle. Use deinit as a safety net.- For controllers reused (navigation push/pop), invalidate in viewWillDisappear when moving from parent.- Remove observers and display link from run loop.- Add assertion/logging in deinit to ensure deallocation during debugging.

**Extras / trade-offs**- WeakProxy keeps CADisplayLink API but adds indirection.- DispatchSourceTimer avoids runloop retention semantics and is cancelable, but manage resume/cancel carefully (balance resume/cancel).- Timer with block is simpler but be careful to capture self weakly.

This approach eliminates strong retain cycles from NSTimer/CADisplayLink and ensures controllers deallocate when navigated away.

MediumTechnical

81 practiced

Describe and provide Swift code snippets to implement a UITableView with cells of dynamic height that rely on Auto Layout. Include necessary tableView settings (rowHeight, estimatedRowHeight), cell contentView constraint rules, and performance tips to avoid jitter during scrolling.

Sample Answer

**Approach (brief)** Use UITableView.automaticDimension for dynamic heights, set a good estimatedRowHeight, and ensure the cell's contentView has an unbroken vertical chain of constraints to its subviews so Auto Layout can compute intrinsic content size. Avoid expensive work during scrolling to prevent jitter.

**TableView setup**

swift

tableView.rowHeight = UITableView.automaticDimension
tableView.estimatedRowHeight = 120 // realistic estimate for smoother scroll

**Custom UITableViewCell (constraints & rules)**

swift

class DynamicCell: UITableViewCell {
  let label = UILabel()
  override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
    super.init(style: style, reuseIdentifier: reuseIdentifier)
    label.numberOfLines = 0
    contentView.addSubview(label)
    label.translatesAutoresizingMaskIntoConstraints = false
    NSLayoutConstraint.activate([
      label.topAnchor.constraint(equalTo: contentView.layoutMarginsGuide.topAnchor),
      label.leadingAnchor.constraint(equalTo: contentView.layoutMarginsGuide.leadingAnchor),
      label.trailingAnchor.constraint(equalTo: contentView.layoutMarginsGuide.trailingAnchor),
      label.bottomAnchor.constraint(equalTo: contentView.layoutMarginsGuide.bottomAnchor)
    ])
    // Important: ensure contentView has bottom constraint to last subview
  }
  required init?(coder: NSCoder) { fatalError() }
}

**Key implementation notes**- Always pin subviews to contentView (use layoutMarginsGuide or safeArea).- Ensure at least one vertical constraint from top to bottom (no ambiguous height).- Avoid calling layoutIfNeeded in cellForRow unless necessary.

**Performance tips to avoid jitter**- Use a realistic estimatedRowHeight (not too small) so table can allocate correctly.- Move heavy work off main thread (image decoding, text measurement).- Use prefetchDataSource (UITableViewDataSourcePrefetching) for async content.- Cache calculated sizes if you have complex measurement logic.- Reuse cells properly and avoid adding constraints repeatedly in cellForRow.

This produces smooth auto-sizing cells driven by Auto Layout while minimizing runtime layout churn.

HardSystem Design

78 practiced

Design a modular architecture for a large iOS app maintained by multiple teams. Explain module boundaries, shared core frameworks, strategies to reduce compile/build times (binary frameworks, Swift packages), dependency management, and techniques to enforce API boundaries and ownership (code reviews, CI gates).

Sample Answer

**Clarify goals & constraints**- Multiple teams, parallel work, fast iteration, clear ownership, safe public APIs, minimize iOS build times.

**High-level modular architecture**- App Shell (thin host): launches, feature routing, composition.- Core frameworks (shared, stable): Networking, Auth, Models, Utilities, Design System (UI components).- Feature modules (team-owned): Encapsulate UI + business logic (e.g., Payments, Messaging). Expose minimal public API.- Integration modules: glue code that composes features into flows.

**Module boundaries & responsibilities**- Core frameworks: no UI behavior; provide protocols, data models, serialization, and platform services.- Feature modules: depend on core; own screens, local persistence, tests.- Rules: no feature → feature imports; communicate via protocols/events or Core-defined interfaces.

**Build-time / compilation strategies**- Use binary XCFrameworks for stable core frameworks to avoid recompiling shared code.- Publish stable artifacts to internal artifact repo (Artifactory/S3) with semantic versions.- Use Swift Package Manager for feature modules that change frequently — supports incremental builds and per-module compilation.- Enable Whole Module Optimization selectively; use module-based builds in Xcode; compile frameworks with bitcode stripped for CI to reduce size.- Parallelize CI builds and cache derived data and SPM/checkouts (CocoaPods cache if used).

**Dependency management**- Prefer SPM for internal and external packages; lock versions via Package.resolved and strict CI checks.- Private package registry or binary artifact store for XCFrameworks.- Avoid transitive coupling: define small interface packages to break cycles.

**Enforcing API boundaries & ownership**- Enforce access control: public/internal/fileprivate; keep most symbols internal.- Code owners and branch protection: require PR review from owning team.- CI gates: automated checks that reject changes to public API without a special process (API diff check).- Tools: SwiftLint, SwiftFormat, SourceKit LSP rules, Danger to enforce PR size and labels.- API stability: run API-breaking detection (swift-api-digester) in CI; require a changelog entry and cross-team approval for breaking changes.- Tests & contract checks: unit tests, snapshot tests for UI components, contract tests for core interfaces.

**Operational practices**- Define module ownership and SLAs in docs. Versioning policy for internal frameworks (semver).- Regular cross-team syncs and dedicated "integration sprint" windows for coordinated breaking changes.

Why this works: clear separation reduces compile blast radius, binary frameworks speed everyday devs, SPM enables modular incremental builds, and CI + code ownership protect API stability while allowing teams independent velocity.

IOS Development Fundamentals (Swift/Objective C) Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank