Apple Systems & Concurrency Primer

0 · Overview

The organizing question: where does lifetime/safety get decided? C++ at scope exit (RAII, deterministic). ObjC at runtime (refcount, you avoid cycles by hand). Swift increasingly at compile time (ownership + actor isolation checked by the compiler). Moving C++→Swift you trade manual control for compiler-enforced guarantees; moving Swift→C++ you regain control and lose the guardrails.

1 · Memory management — who frees, and when

2 · Ownership & smart pointers / references — the direct mapping

auto p = std::make_unique<Node>();  // sole owner
auto s = std::make_shared<Node>();  // shared, atomic rc
std::weak_ptr<Node> w = s;          // no rc bump
if (auto sp = w.lock()) { ... }      // promote to use

@property (strong) Node *next;   // owns
@property (weak)   Node *prev;   // auto-nils
// __weak / __strong in blocks:
__weak typeof(self) ws = self;
[obj run:^{ __strong typeof(ws) ss = ws; ... }];

var next: Node?            // strong (default)
weak var prev: Node?       // auto-nils, optional
unowned let parent: Node   // non-nil, traps if dead
obj.run { [weak self] in     // capture list
  guard let self else { return }; ... }

3 · Value vs reference semantics — the biggest Swift divergence

4 · Retain cycles & how each breaks them — the #1 refcount bug

Refcounting (ARC, shared_ptr) can't free a cycle: A→B→A keeps both counts ≥1 forever. The fix is the same in all three: make one edge non-owning.

struct Node {
  std::shared_ptr<Node> next;
  std::weak_ptr<Node>   prev; // break cycle
};

@property (weak) id delegate; // classic
__weak typeof(self) ws = self;
self.block = ^{ [ws doThing]; };

weak var delegate: Delegate?
task = Task { [weak self] in
  guard let self else { return }
}

5 · Threads & the primitives — the building blocks

std::mutex m;
void inc() {
  std::lock_guard lk(m); // RAII: unlocks on scope exit
  ++count;               // even on exception
}
std::atomic<int> n{0}; n.fetch_add(1);

dispatch_queue_t q =
  dispatch_queue_create("work", DISPATCH_QUEUE_SERIAL);
dispatch_async(q, ^{ [self doWork]; });
// serial queue = mutual exclusion w/o a lock

actor Counter {
  private var n = 0
  func inc() { n += 1 }  // isolated, race-free
}
let c = Counter()
await c.inc()             // suspension point

6 · Async — callbacks → structured concurrency

Structured concurrency & Tasks — the model that makes the lifetime guarantee

func load() async throws -> Page {
  async let user   = fetchUser()      // both run
  async let feed   = fetchFeed()      // concurrently
  return Page(try await user,         // joined here
              try await feed)
}  // if this throws, the other is auto-cancelled

try await withThrowingTaskGroup(of: Img.self) { g in
  for url in urls { g.addTask { try await fetch(url) } }
  var out: [Img] = []
  for try await img in g { out.append(img) }
  return out                          // won't return till all done
}  // throw/cancel cancels every child

@IBAction func tap() {
  task = Task { [weak self] in      // escapes scope
    guard let self else { return }
    await self.refresh()
  }                                   // must cancel in deinit:
}                                     // task?.cancel()

6.5 · The Apple concurrency evolution — pthread → GCD → Combine → async/await + actors

GCD's other standing problems (carried until actors/async-await buried them)

• Thread explosion (the precise version) — it's not "every queue." Blocking calls (dispatch_sync, semaphore/condition waits, blocking I/O) on the global concurrent queues tie up pool threads; GCD keeps spawning worker threads to replace blocked ones, up to a global ceiling (historically ~512 threads). You don't get "thousands of threads" — long before the ceiling you get a saturated, thrashing pool where new work stalls (and on a deadlocked dependency, never runs). The fix: never block a pool thread — await suspends instead. Rule: don't dispatch_sync / wait on semaphores from a concurrent queue. (The oft-cited "64" is the in-flight-blocked-work-item count, not a thread cap.)
• No cancellation — a dispatched block runs to completion; DispatchWorkItem.cancel() only skips work that hasn't started, it can't interrupt a running block. You end up threading manual isCancelled flags. (Tasks are cooperatively cancellable end-to-end.)
• No ownership / lifetime — fire-and-forget work isn't joined by anyone; nothing guarantees child work finishes (or is cancelled) before the parent moves on. Not a memory leak — a lifetime gap. (Structured concurrency makes children part of the parent's scope.)
• Priority handling is easy to get wrong — GCD does some priority donation (a sync from a high-QoS context raises the target), but cross-QoS queue hops still cause inversions you have to reason about by hand. (async/await escalates priority automatically.)
• No race enforcement — serial queues are a tool, not enforcement; nothing stops sharing mutable state across queues, and the compiler won't warn you. (actors + Sendable enforce isolation at compile time.)

fetchUser(id) { user in
  loadProfile(user) { profile in
    loadAvatar(profile) { img in      // 3 deep…
      DispatchQueue.main.async { update(img) }
    }
  }
}
// and the classic foot-gun:
queue.sync { queue.sync { } }   // ⛔ self-deadlock

cancellable = fetchUser(id)
  .flatMap { loadProfile($0) }
  .flatMap { loadAvatar($0) }
  .receive(on: DispatchQueue.main)
  .sink(receiveCompletion: { ... },   // error here
        receiveValue: { update($0) })
// powerful for streams, heavy for one-shot

func load() async throws {
  let user    = try await fetchUser(id)
  let profile = try await loadProfile(user)
  let img     = try await loadAvatar(profile)
  await MainActor.run { update(img) }
}  // errors via throws; cancellation cooperative

The forward-progress contract — the cooperative-pool trap you WILL hit

MainActor-by-default — Swift 6.2 (Sept 2025)

7 · Data races & how each prevents them — the safety gradient

8 · Atomics & the memory model — the low level (mostly C++)

C++ exposes the hardware memory model directly; ObjC/Swift mostly hide it (you use atomics/locks/actors and don't pick orderings).

std::atomic<int> flag{0};
flag.store(1, std::memory_order_release);
int v = flag.load(std::memory_order_acquire);
// relaxed | acquire | release | seq_cst

@property (atomic) int count; // seq-cst-ish
// OSAtomic* (deprecated) / stdatomic.h
// you rarely pick an ordering

// Atomics package (swift-atomics)
let a = ManagedAtomic<Int>(0)
a.wrappingIncrement(ordering: .relaxed)
// but usually: use an actor instead

9 · Gotchas worth naming

10 · Summary

For anyone moving mobile→systems: the hard concepts (refcounting, retain cycles, queues) you already own from ObjC/Swift. C++ adds sole ownership (unique_ptr), deterministic scope-bound cleanup (RAII), and the exposed memory model (orderings) — more control, fewer guardrails. Swift adds compile-time race safety (actors/Sendable) that C++ leaves to your discipline. Choose the language's grain: lean on the compiler in Swift, lean on RAII + sanitizers in C++.