iOS Development (Swift and Objective-C) Questions

What ARC is
Automatic Reference Counting (ARC) is the compile-time memory management used by Swift and modern Objective-C: the compiler inserts retain/release calls so objects are deallocated when no strong references remain.

How ARC manages lifetimes

• Each object has a reference count incremented by strong references.
• When count reaches zero the object is deallocated.
• Strong references keep objects alive; breaking strong links lets ARC free memory.

Retain-cycle examples

• Closure capturing self strongly:

class ViewController {
  var onDone: (() -> Void)?

  func setup() {
    onDone = {
      print(self.view) // captures self strongly -> retain cycle
    }
  }
}

Use capture list to break it:

onDone = { [weak self] in
  guard let self = self else { return }
  print(self.view)
}

• Delegate pattern (Objective‑C/Swift): if delegate property is strong, object A -> delegate B and B retains A -> cycle. Make delegate weak/unowned.
  Objective‑C:

@property (nonatomic, weak) id<MyDelegate> delegate;

weak vs unowned

• weak: optional, becomes nil when target deallocates. Use when referenced object can become nil.
• unowned: non-optional, expected to outlive the holder; accessing after deallocation causes crash. Use when lifetime is guaranteed (e.g., child -> parent).

Capture lists in closures

• Syntax: { [weak self, unowned other] in ... }
• Prefer [weak self] for UI controllers to avoid crashes; use unowned when you know lifecycle ordering.

This knowledge is essential for stable iOS apps and avoiding memory leaks in view controllers, delegates, and async closures.

What is a closure?
A closure in Swift is a self-contained block of functionality that can be passed around and used in your code — like a lightweight function. Closures capture references to variables/constants from their surrounding context.

Escaping vs non-escaping

• Non-escaping (default): closure is executed before the function returns. Compiler can optimize captures and doesn't require @escaping.
• Escaping: closure may be stored and executed after the function returns (e.g., stored in a property, used in async work). Must be annotated with @escaping.

What @escaping means & when required
Marking a parameter @escaping tells the compiler the closure can outlive the call frame. Required when you:

• Assign the closure to a property
• Use it in async/completion handlers (DispatchQueue, network callbacks)
• Append it to a collection for later use

How it affects captures
Escaping closures may outlive the caller, so captured references become long-lived. This often causes retain cycles when capturing self strongly.

Example (must be @escaping) and avoiding strong self

class APIClient {
  var completionHandlers: [() -> Void] = []

  func register(handler: @escaping () -> Void) { // @escaping required — stored
    completionHandlers.append(handler)
  }

  func finishAll() {
    completionHandlers.forEach { $0() }
  }
}

class ViewController {
  let api = APIClient()

  func start() {
    api.register { [weak self] in
      guard let self = self else { return }
      self.updateUI() // safe — avoids strong self capture
    }
  }

  func updateUI() { /* update views */ }
}

Use [weak self] (or [unowned self] when safe) to avoid retain cycles in escaping closures.

What KVO is (brief)
Key-Value Observing lets an object observe changes to a property of another object and get notified when it changes. It’s built on Key-Value Coding (KVC) and the Objective-C runtime.

How it works under the hood

• At runtime, when you add an observer for a key path, ObjC dynamically creates an NSKVONotifying_ subclass of the observed object's class.
• The setter for the observed property is overridden to call willChangeValueForKey:/didChangeValueForKey:, which triggers notifications to observers.
• This relies on ObjC runtime method swizzling and KVC-compliant setters.

Requirements for observability

• Property must be KVC-compliant (use a setter or manual KVC notifications).
• In Swift: the property and its owner must be exposed to ObjC: mark the property as @objc and usually dynamic (or inherit from NSObject and use @objc dynamic) so the runtime can swizzle. Example:

class Person: NSObject {
  @objc dynamic var name: String = ""
}

Common pitfalls in Swift

• Forgetting @objc/dynamic: Swift-native properties without these won’t be observable.
• Observing non-NSObject classes or pure Swift structs won’t work.
• Removing observers: prior to iOS 11 you must manually remove observers or risk crashes; use NSKeyValueObservation returned by observe(_:options:changeHandler:) in modern Swift to auto-manage lifecycle. Example:

var obs: NSKeyValueObservation?
obs = person.observe(\.name, options: [.old, .new]) { obj, change in
  print(change.newValue ?? "")
}

• Threading: notifications occur on the thread where the change happens — handle UI updates on main thread.
• Over-observing or key-path typos: use key-paths (.prop) in Swift to catch errors at compile time.

Use KVO for interoperability with ObjC APIs or when observing model changes; prefer Swift-native patterns (Combine, Property Observers) when possible.

Approach (brief)
Show correct lifecycle sequence and view handling when embedding and switching children: call addChild, add child.view to hierarchy and set frame/constraints, then call didMove(toParent:). When removing: call willMove(toParent: nil), remove view, then removeFromParent(). Use UIViewController.transition(from:to:...) for animated swap.

Example implementation (Swift)

class ParentViewController: UIViewController {
  private var current: UIViewController?

  func embed(_ child: UIViewController) {
    addChild(child)                         // 1. inform child it's about to be added
    child.view.frame = view.bounds          // layout frame
    child.view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
    view.addSubview(child.view)             // add view to hierarchy
    child.didMove(toParent: self)           // 2. inform child it moved to parent
    current = child
  }

  func removeCurrent() {
    guard let child = current else { return }
    child.willMove(toParent: nil)           // 1. inform child it's about to be removed
    child.view.removeFromSuperview()        // remove view
    child.removeFromParent()                // 2. remove from parent VC
    current = nil
  }

  func switch(to newVC: UIViewController, duration: TimeInterval = 0.35) {
    let fromVC = current
    addChild(newVC)                          // add new child before transition
    newVC.view.frame = view.bounds
    newVC.view.autoresizingMask = [.flexibleWidth, .flexibleHeight]

    if let from = fromVC {
      transition(from: from, to: newVC, duration: duration, options: [.transitionCrossDissolve]) {
        // optional animations block
      } completion: { finished in
        newVC.didMove(toParent: self)       // finalize add
        from.willMove(toParent: nil)        // start removal
        from.removeFromParent()             // finalize removal
        self.current = newVC
      }
    } else {
      // no current, just add
      view.addSubview(newVC.view)
      newVC.didMove(toParent: self)
      current = newVC
    }
  }
}

Key notes / reasoning

• Always call addChild before touching child lifecycle and call didMove after view is in hierarchy.
• For removal call willMove(toParent: nil) before removing view, then removeFromParent after.
• Ensure frames/constraints are set before/inside transition so layout is correct.
• transition(from:to:...) handles view containment animations but you still must manage child VC lifecycle calls.

Overview
As an iOS mobile developer I pick the mechanism that fits the work (short refresh vs long processing) and battery constraints. Below I compare Background Fetch, BGTaskScheduler (BGAppRefreshTask / BGProcessingTask), silent pushes, and background URLSession.

Background Fetch

• Constraints: Opportunistic; system wakes app ~every few hours; ~30s of runtime; no guaranteed schedule.
• Scheduling: Set minimumFetchInterval in AppDelegate; system decides exact timing based on usage, battery, and user behavior.
• Testing: In Simulator → Debug → Trigger Background Fetch; on device use Xcode’s Debug > Simulate Background Fetch or use Console logs to observe didFinishLaunching/didReceiveRemoteNotification.

BGTaskScheduler (iOS 13+)

• BGAppRefreshTask: short work (like fetch new data). BGProcessingTask: long work, allowed when device is idle/charging (requires background processing capability).
• Constraints: System decides execution windows; use earliestBeginDate to hint timing. Background time varies; BGProcessing may run longer but requires entitlement for longer CPU time.
• Scheduling: Register identifiers, submit requests after task completion to keep recurring; provide expiration handlers.
• Testing: Use Xcode’s Debug > Simulate Background Fetch / Simulate Background Processing or run in Terminal:
  bash

  ectl bgtest launch <your.bundle.id>
  

  and check logs.

Silent Push Notifications

• Constraints: Delivery not guaranteed; rate-limited; device may drop if app restricted; limited CPU time on wake (~30s).
• Scheduling: Server-driven — send content-available:1 payload to wake app; best for near-real-time updates.
• Testing: Use APNs from server or tools (curl with JWT) and watch app delegate’s didReceiveRemoteNotification:fetchCompletionHandler.

background URLSession

• Constraints: Upload/download continues even if app is suspended; system handles transfers; delegate wakes app when finished; good for large transfers.
• Scheduling: Start tasks with URLSession(configuration: .background(identifier:)); system schedules and resumes across reboots.
• Testing: Use real device (Simulator has limitations); start transfer, then kill app; observe delegate callbacks when transfer completes via AppDelegate’s handleEventsForBackgroundURLSession.

Recommendation

• For periodic lightweight refresh: BGAppRefreshTask (iOS13+) with fallback to Background Fetch for older iOS.
• For server-driven near-real-time: silent push (with caution about reliability).
• For large uploads/downloads: background URLSession.
• Always implement graceful expiration handlers, retry/backoff, and monitor via logs and analytics to tune scheduling.