RxSwift vs ReactiveCocoa

rxswiftWhen I started looking into FRP (Functional Reactive Programming) on iOS, ReactiveCocoa was pretty much the only way to go. Today there are quite a few FRP frameworks available, with ReactiveCocoa and RxSwift as the two most popular. ReactiveCocoa has been out there for a while and at the moment it is obviously more popular, but RxSwift is catching up fast. Both frameworks are extremely powerful and you can’t go wrong with either, but my vote goes to RxSwift for a few reasons.

First of all, RxSwift has a much simpler interface. ReactiveCocoa uses Signal/SignalProducer/Action, and in Rx everything is an Observable. This simplification is often considered as a cause for concern in online discussions regarding RxSwift and ReactiveCocoa. Two main causes for concern are mentioned, the first is the ability to differentiate between hot and cold observables, and the second is error handling.

The first issue is that the consumer of some API does not know if an Observable is hot or cold. The examples given in online discussions for that case are usually network requests. In case of a cold observable, each time you subscribe you’re making a new network request for the same resource. However, there is a shareReplay operator that is used when multiple observers share events from only one subscription. In addition, you can also have a central place to get an Observable for that particular network resuorce. That way you can return an existing Observable instance if that network operation is ongoing. If not, you can create a new one and have it available to be shared while the network operation is in progress.

The second concern regarding RxSwift is error handling. Working with ReactiveCocoa I did run into composition issues when two Signals/SignalProducers were using the same value type but different error types and that poses an issue when you try to compose them. At the link below you can find the reasons behind RxSwift error handling.

https://github.com/ReactiveX/RxSwift/blob/master/Documentation/DesignRationale.md

There are a few more reasons why I chose RxSwift. Even though I had previous knowledge of FRP with ReactiveCocoa, I found RxSwift API easier to read and more intuitive. The documentation and code examples are much better.

RxSwift introduced some simple but very useful operators and variables – debug operator automatically logs all events to console (ReactiveCocoa has it now), and to debug memory leaks there is a convenient variable RxSwift.resourceCount so you can easily check for leaks.

Binding to UI with RxDataSources is something that I found very interesting. Very convenient TableView and CollectionView bindings that support animation.

Last but not least, RxCoreData. An RxSwift extension fo CoreData with many conveniences to observe changes to the data store.

If you liked this blog post I’d appreciate if you followed me on Twitter

Related Post

Remember to share...Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

Leave a Reply

Your email address will not be published. Required fields are marked *