iOS Development (Swift and Objective-C) Questions

Approach / summary
Given control of platform minimums, I would choose Combine for a modern iOS app that does complex real-time streaming. It balances native performance, testability, and ergonomics while minimizing dependencies. I’d consider RxSwift only if I needed cross-team parity with Objective-C/Android teams or require some niche operators missing from Combine.

Trade-offs

• Expressiveness & operators

  • Combine: expressive, declarative; most common operators available; some advanced operators (e.g., certain buffering/windowing) require small helpers.
  • RxSwift: richest operator set out of the box; battle-tested operator semantics.
  • Delegates/closures: verbose for complex pipelines; composition becomes error-prone.

• Performance

  • Combine: native, low overhead; benefits from Swift optimizations.
  • RxSwift: optimized but additional runtime/ABI cost; comparable in many scenarios.
  • Delegates/closures: minimal overhead per call but hard to compose without allocations.

• Interop with Objective-C

  • Combine: Swift-native; interop with Obj-C is awkward—hard to expose publishers directly.
  • RxSwift: better for mixed Obj‑C teams because Subjects/Observables can be bridged more easily.
  • Delegates/closures: best for Obj‑C APIs.

• Learning curve & team adoption

  • Combine: moderate if team knows Swift; idiomatic ownership and backpressure concepts to learn.
  • RxSwift: steeper due to many operators and different naming.
  • Delegates/closures: lowest friction.

• Testability

  • Combine/RxSwift: excellent—virtual schedulers, marble-style tests, deterministic timing.
  • Delegates/closures: testable but requires bespoke synchronization and stubbing.

Why Combine

• Native framework reduces dependency and maintenance risk.
• Sufficient operator surface; gaps are usually easy to implement as small extensions.
• Strong testability via TestScheduler patterns and XCTest integration.
• Native performance and future-proofing with Swift concurrency alignment.

When I'd pick RxSwift

• Need for a very specific operator set or team relies heavily on Rx across platforms.
• Large existing Rx codebase where migration cost is high.

When to use delegates/closures

• Simple async flows, tight Obj‑C integration, or when introducing reactive abstractions adds unnecessary complexity.

Implementation note
Start by modeling streams as Publishers, compose transforms (map/filter/retry/catch), and unit-test with schedulers. Keep edge reconnection logic in a small, well-tested layer to simplify UI integration.

Brief comparison

• Struct: value type — copied on assignment/passing; no inheritance; mutation requires mutating methods; generally thread-safer because copies avoid shared mutable state.
• Class: reference type — shared reference; copying copies reference unless explicitly cloned; supports inheritance, deinit, and identity (===); mutability controlled by var/let for reference and stored properties; concurrent access can cause data races.

Memory & copying

• Structs are stack/inline (or heap via copy-on-write optimization). Assignment produces independent copy.
• Classes are heap-allocated; variables point to same instance; multiple references observe same state.

Mutability rules

• For struct: methods that modify self must be marked mutating. A let instance cannot call mutating methods.
• For class: methods can mutate properties regardless of method signature; if instance is let, its properties can still change (unless properties are declared let).

Thread-safety implications

• Structs reduce shared mutable state—safer by default. Large structs should use copy-on-write to avoid performance cost.
• Classes require synchronization (DispatchQueues, locks, or actor in Swift concurrency) when shared across threads.

Guidelines for iOS data model

• Choose struct when: small, value-like data (Point, Color, Network DTOs), immutable or passed around without sharing, easy unit-testable.
• Choose class when: shared mutable state, identity required (UI controllers, delegates, model objects with observers), inheritance or lifecycle (deinit) matters.

Examples

// Struct use-case: JSON DTO
struct UserDTO: Codable {
  var id: Int
  var name: String
  mutating func anonymize() { name = "Anonymous" }
}

// Class use-case: shared session manager
final class Session {
  static let shared = Session()
  var token: String?
  private init() {}
}

Use struct for value semantics and safety; use class when identity, shared state or lifecycle are required.

Approach (brief)
Use a protocol for the service, a concrete APIClient, and inject a mock into the UIViewController so logic can be unit-tested without network calls. Prefer initializer injection when possible; fall back to property injection for storyboard controllers.

Code: protocol + concrete + controller (initializer injection)

protocol APIClient {
  func fetchItems(completion: @escaping (Result<[String], Error>) -> Void)
}

final class RealAPIClient: APIClient {
  func fetchItems(completion: @escaping (Result<[String], Error>) -> Void) {
    // real network request...
    completion(.success(["a","b"]))
  }
}

final class ItemsViewController: UIViewController {
  private let apiClient: APIClient
  init(apiClient: APIClient) {
    self.apiClient = apiClient
    super.init(nibName: nil, bundle: nil)
  }
  required init?(coder: NSCoder) { fatalError("Use init(apiClient:)") }

  override func viewDidLoad() {
    super.viewDidLoad()
    apiClient.fetchItems { result in /* update UI */ }
  }
}

Test: inject mock

final class MockAPIClient: APIClient {
  var result: Result<[String], Error>!
  func fetchItems(completion: @escaping (Result<[String], Error>) -> Void) {
    completion(result)
  }
}

// In test:
let mock = MockAPIClient(); mock.result = .success(["x"])
let vc = ItemsViewController(apiClient: mock)
// exercise vc.viewDidLoad() and assert UI/state

Trade-offs

• Initializer injection: strongest safety/immutability, easy to test, preferred for programmatic VCs. Harder with storyboards because storyboard uses init(coder:).
• Property injection: flexible for storyboard; controller must handle nil client (optional) and be test-safe; risk of runtime misuse if not set before use.
• Storyboard-instantiated controllers: use a factory or coordinator to set dependency after instantiation, or use a custom UIStoryboard extension that injects dependencies. For complex apps, combine patterns (factories + initializer for programmatic; property or factory for storyboards).

Choose initializer injection when you control creation; for storyboard, prefer factory/wrapper to ensure dependencies are set before using the controller.

Overview / Goals
Design an offline-first iOS sync so users can create/edit large datasets locally, sync efficiently, resolve conflicts, run in background, and conserve battery.

Data model

• Primary store: local SQLite/CoreData with per-record metadata: uuid, version (monotonic int or vector clock), lastModified, tombstone flag.
• Operation log (append-only): store user operations (create/update/delete) with opId, targetId, payload, timestamp, clientId. Keep ops compacted periodically into snapshot + tombstones for deleted items.

Sync algorithm

• Delta-based: client sends op-log deltas or per-resource diffs since lastServerSeq. Server responds with server ops/deltas and new serverSeq.
• Batching: batch ops into size/time windows (e.g., 100 ops or 5s) and compress payloads (gzip). Use conditional requests (ETag / If-None-Match) to avoid full payloads.
• Two-phase apply: validate -> dry-apply/conflict-detect -> commit. Use checkpoints to resume.

Conflict strategies

• Prefer CRDTs for sets/mergable fields (e.g., counters, ordered lists) to allow automatic merges.
• For opaque records, use versioned merge with intelligent field-level merge: compare field timestamps; fall back to Last-Writer-Wins for simple fields.
• Expose manual conflict resolution UI when automatic resolution loses meaningful user intent.

Background & battery

• Use BGTaskScheduler (BGAppRefreshTask / BGProcessingTask) to schedule opportunistic syncs, respecting network constraints and battery. Register tasks with appropriate requireNetworkConnectivity and isExpensive flags.
• Use NSURLSession background uploads for large batches; prefer incremental backoff and exponential jitter. Defer full sync to Wi‑Fi/charging if large payloads.

Testing & monitoring

• Unit tests for op-log apply/compaction, property-based tests for CRDT convergence.
• Integration tests: network interruptions, concurrent edits, restore from snapshot.
• Staging with fault injection (latency, dropped packets).
• Monitoring: server-side metrics (conflict rate, op size), client logging (sync durations, failures) sent via analytics; alerts for spike in conflicts or failed syncs.

This design balances correctness (op-log + CRDTs) with efficiency (deltas, batching, BG tasks) and practical UX for resolving complex conflicts.

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.