Concern about RxSwift dependency and feasibility of migrating to Combine (or other reactive frameworks)

Hi maintainers,
First of all, thank you for the great work on ribs-ios—it's been a solid foundation for many of us.
Recently our team has started to evaluate the long-term cost of keeping RxSwift as the only built-in reactive dependency. RxSwift is a fantastic library, but it adds ~2 MB to the binary, drags in a third-party scheduler model, and—most importantly—requires engineers to master an additional DSL that no longer ships with the OS. With Apple investing heavily in Combine and async/await, we worry that:

1. On-going binary-size / security-surface overhead (RxSwift is not distributed with the OS).
2. Harder hiring / onboarding (new iOS engineers already know Combine, but rarely RxSwift).
3. Potential mismatch with Apple's future APIs (e.g. async sequences, Swift Concurrency back-pressure).
4. One more layer to maintain when RxSwift eventually winds down.

Therefore we'd like to understand:
A. How tightly is ribs-ios coupled to RxSwift today?

1. Are we using any Rx-specific scheduler contracts that have no Combine equivalent?
2. Is there any public API surface that exposes Rx types (Observable, Single, Completable, etc.)?

B. Has there been any prior discussion / spike about providing a "reactive-provider" protocol so that consumers could plug in Combine, ReactiveSwift, or even their own lightweight wrapper?

C. If such a layer does not exist, would the maintainers be open to a PR that introduces one?

1. We imagine a tiny ReactiveProvider protocol (with operators like map/flatMap/zip/just/fail) plus two concrete modules: RIBsRxSwift and RIBsCombine.
2. By default the repo could still ship RIBsRxSwift so the change is 100 % source-compatible for current users.
3. Consumers who want Combine would depend on RIBsCombine instead and get zero RxSwift binary cost.

D. Are there any architectural blockers we should be aware of (e.g. intricate uses of RxSwift's recursive scheduler or custom disposables that Combine cannot replicate)?

We are happy to invest engineering time to prototype the approach, but we wanted to check direction with you first to avoid duplicate effort or design conflicts.
Looking forward to your thoughts!

The issue names no files or tests. Start by reviewing the repository's RxSwift dependencies, public APIs, scheduler usage, and disposal patterns; compare those constraints with the proposed Combine or provider-based design. Done would require an agreed migration direction or prototype scope from maintainers.