Combine, and migrating away from it

The model: publishers, operators, subscribers

A Combine pipeline is a value assembly line:

import Combine

final class SearchModel: ObservableObject {
    @Published var query = ""                       // publisher of query changes
    @Published private(set) var results: [City] = []

    private var cancellables = Set<AnyCancellable>()

    init(searcher: CitySearching) {
        $query                                      // Publisher<String, Never>
            .debounce(for: .milliseconds(300), scheduler: RunLoop.main)
            .removeDuplicates()
            .sink { [weak self] text in             // subscriber
                self?.performSearch(text)
            }
            .store(in: &cancellables)               // keep the subscription alive
    }
}

Reading order for any pipeline you meet:

1. The publisher — where values come from. $query is @Published's projected value (property-wrapper machinery you already know: $ = projection, here a publisher instead of a binding).
2. The operators — transformations: map, filter, debounce, removeDuplicates, combineLatest.
3. The subscriber — where values land: sink { } runs a closure; assign(to:) writes a property.
4. The cancellable — the subscription's lifetime. This is where Combine's two classic bugs live.

The two bugs you will actually fix

The dropped cancellable. sink returns an AnyCancellable; when it deallocates, the subscription cancels. Forget .store(in: &cancellables) and the pipeline silently dies at the end of init — the search field that "just doesn't search" with no error anywhere. When you meet mysteriously-dead reactive code, check the cancellable's lifetime first.

The retain cycle. sink's closure is stored (via the cancellable, on self) and captures — this is exactly the stored-closure cycle from the ARC lesson: self → cancellables → closure → self. Hence the reflexive [weak self] in sinks. A Combine-era codebase's leaks live disproportionately in its sinks.

Why debounce earns its keep

The search pipeline above encodes a real product behaviour worth having in any framework: don't hit the API on every keystroke; wait for the user to pause, and skip repeats. That semantics transfers — implement it once and you understand it in Combine, async, or any UI framework:

Nine keystrokes became three API calls — and note the third: "swift" fired again even though "swift" had fired before, because removeDuplicates only suppresses consecutive duplicates ("swi" fired in between). That subtlety is the operator's actual contract, and misremembering it as "dedupe all history" is a real interview stumble.

The migration map

Combine → async is mechanical once you see the pairs:

Two of these deserve the concrete shape. The bridge — when old code must feed new:

for await value in model.$query.values {    // .values: Publisher → AsyncSequence
    await handle(value)
}

Debounced search without Combine — the modern idiom is disarmingly small:

.task(id: query) {                          // restarts (cancelling the old task) on every change
    try? await Task.sleep(for: .milliseconds(300))   // cancelled sleep = keystroke arrived
    guard !Task.isCancelled else { return }
    await search(query)
}

Each keystroke changes id:, cancelling the previous task mid-sleep; only a task whose sleep survives 300ms searches. Debounce falls out of structured cancellation — no operator library required. That comparison is the honest summary of the whole migration: Combine solved values-over-time with an operator algebra; modern Swift solves most of the same cases with language-level tasks and cancellation.