Over a million developers have joined DZone.

RxSwift vs. ReactiveSwift

DZone's Guide to

RxSwift vs. ReactiveSwift

Some of the most common use cases for reactive programming are asynchronous networking and binding values to UI controls. Is RxSwift or ReactiveSwift better at handling them?

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

In June 2016, Chris Eidhof and Florian Kugler (of objc.io fame) started a new Swift screencast series called Swift Talk. The format is simple: for 15 to 20 minutes each week, two experienced programmers pair-program, problem-solve and refactor together. The result is some excellent insight into the process of programming and design.

Last week in episode #34, Chris and Florian did their first episode on one of my favorite topics: Reactive Programming. They work through a reactive programming problem using RxSwift, exploring some of the most common use cases for a reactive programming library: asynchronous networking, combining event streams from multiple sources, and binding values to UI controls. The source code for the episode is available for free on GitHub. Whether or not you’ve watched the episode, I recommend cloning the repo and playing around with the app in the simulator.

I haven’t yet had the opportunity to work with RxSwift, but I have a lot of experience with ReactiveCocoa and have made a few contributions. Since the recent release of ReactiveCocoa 5, which overhauled its UI binding APIs for Swift 3, and ReactiveSwift (the cross-platform core of ReactiveCocoa), I thought it would be interesting to use this example app from Swift Talk to compare the two libraries.

A quick note on terminology: throughout this article, I’ll be using RxSwift to also refer to RxCocoa, which is bundled alongside it and provides the UI binding layer. In the same way, I’ll be using ReactiveSwift and ReactiveCocoa interchangeably.

Porting From RxSwift to ReactiveSwift

Let’s take a first pass and port examples in the source directly to the equivalent ReactiveSwift APIs. Even though the changes are fairly minimal, we can learn a lot about the philosophical differences between the two libraries.

Observing Changes to a Simple UI Control

-let priceSignal = priceSlider.rx.value
+let priceSignal = priceSlider.reactive.values
     .map { floor(Double($0)) }

+priceLabel.reactive.text <~ priceSignal
     .map { "\($0) USD" }
-    .bindTo(priceLabel.rx.text)
-    .addDisposableTo(disposeBag)

Here's the original source.

RxSwift’s bindTo(_:) and addDisposableTo(_:) functions are both unified in ReactiveSwift under the binding operator, <~. On the left side of the operator is the “binding target”, defined by BindingTargetProtocol. Binding targets do two things: consume values from a stream, and define a Lifetime, i.e., when the binding should end (usually when the target is deinitialized).

-func load<A>(_ resource: Resource<A>) -> Observable<A> {
-    return Observable.create { observer in
+func load<A>(_ resource: Resource<A>) -> SignalProducer<A, AnyError> {
+    return SignalProducer { observer, disposable in
         print("start loading")
         self.load(resource) { result in
             switch result {
             case .error(let error):
-                observer.onError(error)
+                observer.send(error: AnyError(error))
             case .success(let value):
-                observer.onNext(value)
-                observer.onCompleted()
+                observer.send(value: value)
+                observer.sendCompleted()
-        return Disposables.create()

Here's the original source.

The biggest difference here is the SignalProducer type. Here’s where ReactiveSwift begins to diverge from RxSwift: the notion of “hot” and “cold” signals are separated out into two different types. You can compare RxSwift’s explanation of the difference with ReactiveSwift’s TV streaming analogy.

The second major difference between the two libraries is ReactiveSwift’s Signal and SignalProducer add a second generic type parameter: the Error type. If you’re familiar with Swift’s error handling model, it might seem like an unconventional choice to have strongly-typed errors. One benefit is that errors can become self-documenting: you have a type whose documentation or source code can be looked up to discover what errors might occur. But the real benefit is the existence of the NoError type, which allows you to prove at compile time that no ever will ever occur, by being impossible to construct. Many of ReactiveSwift’s error handling features are made possible by NoError.

In this case, because we’re bridging untyped Swift errors into the strongly-typed model of ReactiveSwift, we use the AnyError wrapper type.

Combining the Results

-let vatSignal = countriesDataSource.selectedIndex.asObservable()
-    .distinctUntilChanged()
+let vatSignal = countriesDataSource.selectedIndex.producer
+    .skipRepeats()
     .map { [unowned self] index in
-    }.flatMap { [unowned self] country in
-        self.webservice.load(vat(country: country)).map { Optional.some($0) }.startWith(nil)
-    }.shareReplay(1)
+    }.flatMap(.latest) { [unowned self] country in
+        self.webservice.load(vat(country: country)).map { Optional.some($0) }.prefix(value: nil)
+    }.replayLazily(upTo: 1)

Here's the original source.

There’s a little more going on here:

  • countriesDataSource.selectedIndex has changed from a Variable<Int> to a MutableProperty<Int>. To observe the current value, followed by all future changes, we use the producer property, which returns a SignalProducer<Int, NoError>.
  • There’s a new .latest parameter to flatMap(). You can learn about the differences between flattening strategies in ReactiveSwift’s documentation. These strategies are all possible in RxSwift, but the flatMap operator chooses a default strategy. In ReactiveSwift, no strategy is considered to be a sensible default for all cases, and so you instead choose the strategy that is most appropriate for your use case.
  • The shareReply() operator is basically the same, but under the name replayLazily(upTo:).

RxSwift provides the Variable type, a mutable box that holds a current value and lets you observe changes to its value over time. In order to combine Variables with other streams, you have to convert it to an Observable, losing its “Variable-ness” in the process. ReactiveSwift’s MutableProperty is equivalent, but along with PropertyProtocol, there are a number of interesting ways you can combine properties, while preserving the fact that a) they are guaranteed to have a current value, and b) they are guaranteed to never fail. You can read more about Property in ReactiveSwift’s documentation.

RxSwift and ReactiveSwift are two different approaches — perhaps surprisingly so — to the same underlying problem. Both make heavy use of Swift’s type system to help you describe your application’s asynchronous logic in a high-level way, and with very different results.

This episode of Swift Talk was an introduction to reactive programming, and not intended to prescribe the “right way” of solving the problem. There’s certainly a more idiomatic way to write this code with either library. By comparing these two libraries, we’ve been able to see how even apparently subtle differences in API design can influence the code we write.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

mobile ,rxswift ,reactive programming ,app development ,reactiveswift

Published at DZone with permission of Adam Sharp, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}