I’ve been seeing a lot this topic lately and I thought I’d share my opinion on it. The first thing I’d like to say is that binding is easily the #1 feature request that I want brought over to iOS from Cocoa on OS X. As a long time Flex developer I’ve had the enjoyment of binding data to UI controls. For front-end development, it saves so much time and you start wondering how you’ve ever developed front-ends without it.

Even though it’s been a complete dream of mine to have reactive programming on iOS, here are the key reasons for me on why I’m waiting:

Memory and Performance

Binding is expensive. On iOS, we don’t have the luxury of speed of a desktop or laptop computer. Over time this will change but there is still a large number of devices that are iPhone 4, 4S and older generation iPads. To me this makes sense as the #1 reason that Apple hasn’t included binding in iOS. Reactive Cocoa, the popular framework for iOS is seeing a little bit of the performance issues that binding presents. I strongly believe in Larry Pages quote about speed:

I’m not talking about premature optimization here but if your software performs faster your users will have a better user experience, and that is what matters the most.  A lot of the early versions of libraries will have performance issues.

Maintainability

Reactive Cocoa is a great library for achieving binding on iOS, but what are you going to do when Apple finally includes binding natively on iOS?  Will you update all of your apps? One example I have is NSJSONSerialization. There were a few libraries out there that touted ease of use and performance benefits and you had to do your own analysis on each library and decide.  When it released, it was the fastest JSON serializer available on iOS and it shipped with Cocoa so you don’t have to worry about updating the library. It’s very easy for developers to ignore changes that should be made internally to an app that will be better long term.

Know when to use a hammer and when to use an axe

It’s very easy to complicate application architecture with such a powerful tool. In my Flex days, there were developers using binding at an entire class level versus property level and they kept all of the models in the entire application in one class to seem “tidy” but was suffering huge performance issues over time because the binding had to react to every single property in that class whenever binding fired.  This would be an absolute nightmare on a mobile device with smaller resources.

There are some benefits to using reactive cocoa or other binding frameworks on iOS, just use it wisely and program on purpose.

It takes a lot of discipline to go against the popular trend right now but with these trade-offs, I think I’ll wait a little longer. I’m confident that reactive programming on iOS will be as common as IBOutlet.