RxSwift Moved Swiftly from 1.9 to 2.1

RxSwift 2.1.0 is out! Congrats to kzaher and all the members.

Since things moved fast over the winter holidays in RxSwift, you might see some changes that happened between 2.0.0-beta.4 and 2.0.0 that interest you if you haven’t switched yet. When moving from the latest RxSwift beta to 2.0.0, the 2.0.0-rc.0’s Deprecated section of the Change Log may answer some compilation issues you face.

Straightforward changes were needed for my work. For example, I needed to stick Observable in front of create. As covered in the Change Log:

Deprecates free functions in favor of Observable factory methods

An interesting one involves Variable:

Deprecates Variable implementing ObservableType in favor of asObservable()

Looking at GitHubSignup “UsingVanillaObservables > 1″ and “UsingDriver > 2″ in the RxExample code, I see the answer to my questions and so much more. There is an emphasis on using Driver as opposed to Variable objects. Although, a deep dive into Driver is a whole other topic.

In regards to 2.1, the changes from 2.0 to 2.1 are minimal and had no impact on my work.

Enjoy the new stuff!

When and Why Did I Start Meditating?

Why does anyone do what they do? Curiosity is one driving force. Another force comes from beliefs. Beliefs form thoughts which inspire action.

Among other beliefs shared with me while growing up, I believed in actualizing my potential. Among other influences, this was impressed upon me by my parents and a special athletic group known as Sokol.

Formally known as the American Sokol Organization, I belonged to this gymnastics group for almost all of my life as a child. Sokol has the philosophy of a “A Sound Mind in a Sound Body.” Beyond the philosophy, it felt like a good idea. I never regretted attempting to actualize my potential.

While pursuing this continuous quest, I noticed that martial arts had a similar flavor of one being the best they can be. On top of that, the martial artists were doing something new and curious to me. They were meditating!


(Source: pixabay.com)

Based on my Sokol training, I knew that a healthy body wasn’t enough. Yet, how can one strengthen and actualize the mind? Being a kid and seeing meditating also happening in Star Wars, this meditation thing had to be explored! I went to the library and learned what I could.

To make a long story short, I was exposed to the basic techniques and many beliefs that came with my introduction to meditation. I meditated for many years. Over time, I shed myself of the beliefs which did not serve well. For awhile, I even stopped meditating since I wasn’t certain meditation was backed by science.

Just a few years ago, I came across some scientific proof that meditation yields a better brain. In short, increased focus and the ability to respond as opposed to blindly reacting to my emotions was something I gained. Now there was scientific proof from multiple sources too.

The question that remained for me was whether or not I was doing meditation well. I learned from some meditation iPhone apps that this is a common question. The simple answer is that one should just try their best and yet not focus “too hard.” What is especially important is to make meditation into a daily habit.

From what I learned from Nir Eyal and his excellent Hooked book, forming a habit is a well understood thing. For me, I came to understand that no matter what I will meditate daily even if it is for two minutes no matter how silly it felt. The daily repetition helped make it stick even in my most busy times.

So, the journey continues. As a thank you to others who have helped me on this path of self-actualization, I pay it forward. I share what I have learned with others.

Good luck with your own quest for excellence!



Swift structs, closures and Memory Leaks

Using structs and registering closures with a framework? Did you know closures are reference types?

If your closure is registered with a class from a framework and the closure is closing over self then you have a strong reference cycle memory issue. For example, let’s say we have a struct which has an RxSwift class Variable<String> member called someVariable.

When you give the subscribeNext the closure, it will store that closure into the framework. In other words, it has a reference to the closure. If you are referring to self in that closure, you have a strong reference cycle. The struct has a Variable which has a closure that has a reference back to the struct.

Can we just make the self reference a weak reference? No. Not if it’s a struct.

If it’s a class, we can do the following:

Note that we are using class and [weak self] now. We also took away the mutating from before the function.

That solves the memory issue! Thanks goes to some helpful humans which include Darren and Marc Khadpe in this Stackoverflow post.

Update: For an example such as this, Carlos García rightfully pointed out that using [unowned self] would be better. It’s faster and more. Carlos pointed out this article: How Swift Implements Unowned and Weak References and a related Twitter thread.

If you are going to use unowned, you will want to know when your app can crash when using it.  “Weak, Strong, Unowned, Oh My!” – A Guide to References in Swift is a good guide for when to use weak, unowned, and the default strong references.

Swift Protocols With Associated Types – PATs

What first led me into understanding Protocols With Associated Types (PATs)? Answer: RxSwift. It’s an awesome FRP framework for Swift.

What led me to the protocol compilation error “..can only be used as a generic constraint” which looks like this?

1PAT with compiler error

(Source: Alexis Gallagher – Protocols with Associated Types – 1:24)

Answer: Applying BDD (Behavior-Driven Development) to our Protocol Oriented MVVM RxSwift empowered code and using dependency injection.

We were going to use structs and protocols wherever we could. However, we had to back off some. Thanks to Alexis Gallagher, it’s clear now why we ran into the same problem that he presented in his video presentation, Protocols with Associated Types and how they got that way (maybe). Here’s a problem example he shows:

2PAT single variable declaration

(Same source: 2:47)

This great presentation was part of the 2015 Functional Swift Conference. The Protocols with Associated Types, and How They Got That Way slides are available. However, I highly recommend listening to the whole presentation. Since it’s 56 minutes long, this blog post links to certain key parts of it with associated snapshot images just to give you a taste of what is in there.

From this presentation, there are some crucial key takeaways:

  • Can’t use dynamic dispatch with PATs
  • typealias can do two very different things
  • There are workarounds if you need to do dynamic dispatch

Can’t Use Dynamic Dispatch With PATs

The compilation error “..can only be used as a generic constraint” described above shows how PATs are unique and different from plain old Protocols. The following dives into the ramifications of this situation:

3No Dynamic dispatch

(Same source: 6:54)

PATs are their own thing. As Alexis G. says, call them PATs and recognize how they are different.

typealias Can Do Two Very Different Things

4typealias two different uses

(Same source: 11:39)

As specified in the Swift Language Reference on Declarations, you can use typealias to:

  • Create a name for a type. See the “Type Alias Declaration” section.
  • Require something that conforms to a PAT, to specify a type. See the “Protocol Associated Type Declaration” section

Slide 18 of his presentation has a good example of showing typealias being used in a PAT.

There Are Workarounds If You need to do Dynamic Dispatch


(Same source: 39:08)

Workarounds are:

  • Enums
  • Type Erasure

The future looks bright if they add Existentials to the language. There is a Stackoverflow post about the generic concept an Existential Type.


Until they add Existential Types to the Swift language, we should fully understand PATs and how to use other parts of the Swift language to accomplish what we want.

As an aside: If you got this far, you really may want to watch the whole presentation on youtube. This blog post was made to just catch some of the interesting bits for later referral. Enjoy!

RxSwift Driver – What is it?

Curiosity is a powerful thing. When I saw this RxSwift Driver being discussed on RxSwift Slack and read the helpful RxSwift GitHub issue “Need better explanation / examples for Driver” submitted by Florent Pillet, it seemed helpful to capture what I saw.

As Carlos García shared on the GitHub issue:

One should think of the following:

as the same as:

Krunoslav Zaher aka kzaher on the RxSwift slack community said that it is a combination of: “main thread + shared subscriptions + no errors.” He goes on to say that shareReplay(1) is a shared subscriptions example. Carlos adds there are several examples in RxExample.

kzaher sums it all up nicely by sharing:

Yeah, it’s just a tiny builder/dsl for Observables. I think this should help me and others a lot with ensuring you can safely bind values to UI.

Using Driver is optional, but it helps the compiler catch things and will help emphasize things that might have been missed. As kzaher put it:

..and warn me when I’ve forgot to handle unexpected errors, or binding from background thread or doing something I should have when dealing with UI applications.

You may want to keep an eye on the RxSwift documentation as it grows and develops over time. Specifically, this Units document. Driver sounds exciting and I look forward to trying it in-depth in the near future!

Jan 2, 2016 Update: The Units document has been updated and much more has been added to it. Good stuff!

RxSwift Glossary and Concepts

Do you speak RxSwift? Do you know the concepts, words and operators? Here is a snapshot summary of many of them.

Some of the RxSwift Concepts from Getting Started

An Observable is a definition of: 

  • “..how the sequence is generated..”
  • “..what parameters are used for element generation..”


“..release all of the resources that were allocated to compute upcoming elements..”

Observable aka Sequence

  • One after another, the Observable sends a Next (element), Error, or a Completed
  • What stops them from coming? An Error, Completed or dispose the subscriptions.


Subscribes to Observables


(Source: Rx.playground)

Terse mode: “acts both as an Observer and as an Observable”

Full mode: “A Subject is a sort of bridge or proxy that is available in some implementations of ReactiveX that acts both as an observer and as an Observable. Because it is an observer, it can subscribe to one or more Observables, and because it is an Observable, it can pass through the items it observes by reemitting them, and it can also emit new items.”


There is a list sorted by functionality at https://github.com/ReactiveX/RxSwift/blob/master/Documentation/API.md#rxswift-supported-operators

Operator Types:

(Sources: Rx.playground and github docs)

  • Combination operators – startWithcombineLatestmergeswitchLatestzip; “Operators that work with multiple source Observables to create a single Observable”
  • Conditional and Boolean Operators – takeUntiltakeWhile – “Operators that evaluate one or more Observables or items emitted by Observables.”
  • Connectable Observable Operators – multicastreplay, replayAll, publish – “like an ordinary Observable yet only when its connect() is called does it emit”
  • Error Handling Operators- catchErrorretry – “Operators that help to recover from error notifications from an Observable.”
  • Filtering Observables – distinctUntilChanged, filtertake; “Operators that selectively emit items from a source Observable.”
  • Mathematical and Aggregate Operators – concat, reduce – “Operators that operate on the entire sequence of items emitted by an Observable”
  • Observable Utility Operators – doOn, subscribesubscribeNextsubscribeCompletedsubscribeError; “toolbox of useful Operators for working with Observables”
  • Transforming Observables – map / selectflatMapscan; “Operators that transform items that are emitted by an Observable”
  • Units – “purpose of Driver unit is to ensure the underlying observable sequence has the following properties”: It “can’t fail”, “main thread”, and more.


Schedulers are an abstraction away from what does work (queues / threads).


By the way, the RxSwiftCommunity bears checking in on from time to time. Action is listed there and it comes up often in the RxSwift Slack community and at least once in Stack Overflow. Just like the adoption of RxSwift, I sense the community will grow over time.

Update: If one looks at the code commits done for the RxSwiftCommunity website, one can easily see lots of activity going on.

RxSwift and Memory

Tom Burns asked a good question about TableView bindings outliving the view controller. As he said:

I’m asking because I noticed that some of my tableview bindings were outliving the view controller being popped back off the stack and it seemed like unnecessary work was being done…

kzaher of the RxSwift Slack community pointed out the following code as being the culprit:

Tom fixed the code to use an “[unowned self]” before the newObjects. Such as:

Although such memory situations aren’t limited to RxSwift, using RxSwift might encourage such situations to come up more often. It something to watch out for.

Regardless, this is something we all can run into from time to time. I feel fortunate enough to have caught the conversation in the RxSwift Slack community and am grateful to Tom for asking.

Simpler RxSwift Test Code

Looking at some RxSwift test code, I knew it could be better. As I shared with Krunoslav Zaher aka kzaher in the RxSwift Slack community:

I feel the opportunity for improvement down to my soul.

Test Code
He kindly helped me simplify some RxSwift test code. He suggested that instead of:

Do something like this:

To make that work, I had to change the oldBakeryServiceSpy from something like this:

To this:

This also allowed us to use failWith. As in:


More kzaher Words of Wisdom

if you are mocking, just use just, sequenceOf, [].toObservable()

It was also shared that TestScheduler will be released soon and one can look at the unit tests.

What about Simplifying Our Use of the DisposeBag?

As a result of what we read in the README, we use DisposeBag objects often. As kzaher shared:

If you use operators, that will reduce the amount of dispose bags significantly. We handle all of disposing for you. You only dispose terminal endpoints where you do “subscribe”

All Part of the Game of Learning

Slowly things are improving. Although it’s all part of the game of learning something new, I think it would serve all well if someone created a game called “Simplify This RxSwift code.” I know I would happily play it.

Path to Learning FRP and RxSwift In a Nutshell

This is some of what I did to learn FRP / RxSwift:

The RxSwift Slack Community is awesome: http://slack.rxswift.org They guided me to these resources.

Besides playing around with lots of code, that’s the meat of what I did. I know every individual has his or her own path of learning. However, I figured I would share a terse version of mine in case it helps.

Update December 31, 2015: I would watch Functional Reactive Programming with RxSwift by Max Alexander first.


Learning RxSwift

Although ReactiveCocoa looked promising, it had a few things that are not yet there. These are outlined in an earlier article, ReactiveCocoa and MVVM Initial Experience. So, it was time to explore RxSwift.

I started with reading the concepts in the README. It was pretty straight forward. My next move was to find an example which is like the ReactiveCocoa oriented ReactiveTwitterSearch example that I loved so much. Where to begin? Good thing I discovered the RxSwift slack community.

Having an active slack community is a huge win! With the help of Carlos García in slack, I found GitHubSignup in the RxExample examples. This was definitely what I was looking for.

For fun, I created a small demo app which explored the bindings. I decided to see what was there for a UIPickerView and UITextView.

Compared to ReactiveCocoa, the RxSwift repo comes with extensions to some of the UIKit components. These are known as RxCocoa extensions. RxCocoa is located alongside the RxSwift code in the GitHub repository. However, if you are using CocoaPods like I am, RxSwift and RxCocoa are two separate pods.

After much searching, I discovered there is no extension made for the UIPickerView. So, I just made a PickerViewAdapter which contains a selectedPerson RxSwift Variable and PickingPersonViewModel. The adapter handles the UIPickerViewDelegate and UIPickerViewDataSource while calling through to the PickingPersonViewModel. The adapter is used by the View Controller.

With the UITextView, I had much better luck. With a simple binding, I was able to hook up a notes UITextView up with a specific note in the NotesViewModel. Changes to the UITextView would be reflected in the note. Pretty neat! Code is here:

_ = notesTextView.rx_text.subscribeNext { someText in

// Changes to notesTextView’s text triggers this block.

self.notesViewModel.currentNote().value.text = someText


How do extensions like rx_text work? I looked at the simplest example, the RxSwift UILabel extension. AnyObserver has an observer which is an event handler. As can be seen in the code, the UILabel extension with rx_text is an adapter that handles String events.

Although it’s currently Beta, there’s a sense that RxSwift will be out of beta soon. This is based on a Github request for it to be released as 2.0.0.

Based upon my observations and discussing it with some smart people at CARFAX I know, it looks like RxSwift is pretty solid. If you are interested in supporting MVVM in a Functional Reactive programming style, I recommend you check it out!