RxSwift at first sight

I spent my last year figuring out how reactive programming works and whether it's good for me and my apps if I'm experimenting with it. I got familiar with various solutions, starting with ReactiveCocoa & Objective-C, ReactiveCocoa with Swift, VinceRP my friend's lightweight implementation. All of these are amazing projects, one with its maturity and complexity, one with its easy to understand concept.

Along the way I wrote some articles about my experiences with reactive and I got asked a lot recently about RxSwift. Shamelessly I never had the chance to start a project with it. Okay, let me be a little more honest here. I never tried Rx in any language before, so I always thought about RxSwift as it's something easy to use for people who used Rx previously in a different environment. Now is the time for me to try it out.


It's the most commonly used implementation of the reactive paradigms. A difference compared to other RP libraries is that given it's cross-platform, it has the biggest community, tons of documentation and discussions available and a lot of people contributing.


The language grew a lot in the last year, it's also open source now. Projects like RxSwift grew with it together, there is not much to stop you from using it anymore. Breaking changes are still on the radar, but they might not go away soon. It probably means continuous improvements, which is good, right?

An app with RxSwift

If you've ever read a post on my blog at this point your guess is probably that I wrote an app using RxSwift and you are right. That's a time-expensive habit, but I don't like to rely on ideal environment examples so I usually write an app that makes at least a little sense. This way I can understand how to get the framework to work for me, not the other way around. The framework you use is one major mutating factor to the infinite ways of solving a problem. This diversity is probably one of the reasons why I'm so in love with programming though.

So this one is called iCopyPasta, little sister and iOS version of CopyPasta, the Mac pasteboard feed demo app for last year's Functional Swift Conf. Of course these are not production ready apps so they are not ready for distribution. I'm using the Mac version every day, but I might be biased. The plan is to deliver both in the future, maybe connected to each other.

Isn't it always the plan?


I started out with observing the UIPasteboard for updates about string and image types arriving to the pasteboard when you copy something.

Previously I observed string and image on the general UIPasteboard directly, but it turned out to be a fragile solution, because UIPasteboard might not be KVO-safe (see the comments below). Based on the advice I used another great feature of RxSwift to observe the UIPasteboardChangedNotification with rx_notification.

The pasteboard here will be an Observable<NSNotification> that's why it was easy to subscribe to its .Next events and update the table view accordingly. The map is necessary to get the string or image from the object received through the notification and turn it into a PasteboardItem.

Dispose bags

Subscriptions produce Disposables which are going to be allocated permanently if the given subscription doesn't terminate. This way you either have to call dispose on them, or use dispose bags for automatic disposal like I did.

UIKit/Appkit bindings

You can bind an Observable sequence to a table view easily with the power of rx_itemsWithCellIdentifier. The element is coming from my PasteboardItem enum here, that's why I'm switching over it, to make a difference in the representation.

Another great addition is rx_modelSelected, where you can get your element back when selection is triggered. It's basically a wrapper for tableView:didSelectRowAtIndexPath:. Neat!

Check out all the UIKit/AppKit (RxCocoa) extensions on RxSwift's GitHub.

Overall feelings

I've seen a very little of what RxSwift is capable of, but I've seen enough to know Rx is a great implementation. It's nice to understand a bit more about how it works and how to think in it.

I loved having this amount of learning content around, like the Rx.playground in the repository, RxMarbles and a great community. It inspired me a lot, I'd love to share similar developer experience with our users at bitrise.io. A lot of important features, like schedulers I hadn't cover, but worth checking.

It's clear for me, that I need more time to understand Rx better. It wasn't hours with ReactiveCocoa, I was lucky enough to work with it day by day for more than a year, thanks to the guys back at Prezi.

As someone who started with ReactiveCocoa though, I'd still prefer to coding in it, probably because I'm already confident and fast with it. I will probably use both in the future, but I think practice in one of them might not mean significant advantage when learning the other. They have differences on several levels and both of them (and reactive programming in general) has a steep learning curve. I'm already on the bright side with ReactiveCocoa, but if you are just starting up I suggest to try out both, or even more.

To read

If you're still trying to figure out which RP library to use, I recommend to read Ash Furrow's writing about how to choose.

Go ahead and check out some videos/articles about F(R)P in iOS for great videos & articles in the topic.

Show Comments