napkin vs RIBs: the same pattern, two concurrency models

Is RIBs dead? No.

Let's kill that search query first: RIBs is actively maintained. In October 2024 Uber split the project into two repositories — uber/RIBs is now the Android (Kotlin) repo, and iOS lives at uber/RIBs-iOS. The iOS repo published release 1.1.0 on July 12, 2026. If you're evaluating napkin because you think RIBs is abandoned, that premise is wrong — and this page would rather you know that. napkin exists for a different reason.

The actual difference: the reactive backbone

RIBs-iOS 1.1.0 depends on RxSwift 6.9 and RxRelay. Its 1.1.0 release added async/await interop helpers — Single.fromAsync, Observable.fromAsync, onAsyncStep — but the release notes say it plainly: "RxSwift stays the backbone." There is no first-party Combine or Swift-Concurrency-native variant; those exist only as community forks (ModernRIBs, RIBs-SwiftUI).

napkin has no reactive dependency at all. Business logic lives in final actor interactors; routing and presentation are @MainActor; state streams down the tree with AsyncStream and Observations, and every isolation crossing is explicit async/await. The only package dependency is the documentation plugin. If your team already thinks in Swift Concurrency, there is no second concurrency vocabulary to learn — and none to bridge.

Leak detection: runtime vs compile time

Uber's README describes the framework's tooling well: "RIBs come with IDE tooling around code generation, memory leak detection, static analysis and runtime integrations - all which improve developer productivity for large teams or small." That includes a runtime LeakDetector that watches for interactors and view controllers that outlive their scope.

napkin ships Xcode file templates and an install script, but deliberately not the rest of that suite — no static analysis, no runtime integrations, and no leak detector. Its bet is that Swift 6 moved the problem: strict concurrency checking makes ownership and isolation mistakes compile errors, and napkin's structural rule — views hold their presenters weak, presenters own view controllers strongly, one direction only — removes the retain-cycle class the LeakDetector hunts at runtime. That's a trade, not a free lunch: RIBs' runtime detector can catch leaks in code the compiler can't reason about, and its richer tooling earns its keep on large teams. napkin hands you file templates and asks the type system to carry the rest of the weight.

Comparison table

When to choose RIBs

• You have an existing RIBs codebase that works — the framework is maintained; there is no forced migration.
• Your team is fluent in RxSwift and its operators are pulling their weight.
• You want the runtime leak detector and the full IDE tooling suite — static analysis, runtime integrations — on a large team.
• You need to support iOS 15–25 — napkin's iOS 26 floor rules it out for you today.

When to choose napkin

• You're starting a new app on Swift 6 and don't want RxSwift in the dependency graph.
• You want the Router-Interactor-Builder tree expressed in the language's own concurrency vocabulary — actors, @MainActor, @Observable.
• You prefer isolation mistakes to be compile errors rather than runtime detections.
• You can target iOS 26 / macOS 26 and accept a young framework with a small community.

Same sketch, different ink. Both frameworks draw the tree of Routers, Interactors, and Builders; they disagree about what should enforce its rules — a reactive runtime, or the compiler.

Related: napkin vs The Composable Architecture · napkin vs VIPER · When to use napkin · FAQ · Meet napkin (the long version)