Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#44 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
swift
Ambito
mobile

Direzione di ricerca

L’issue non indica alcun file o test. Inizia esaminando le dipendenze RxSwift del repository, le API pubbliche, l’utilizzo degli scheduler e i pattern di disposal; confronta questi vincoli con il design proposto basato su Combine o su provider. Il lavoro sarebbe completato quando i maintainer avranno concordato una direzione di migrazione o l’ambito di un prototipo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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!

Lingua principale
Swift
Stelle
193
Fork
25
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di uber/RIBs-iOS

Tutte le issue di uber/RIBs-iOS

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.