The New Carbon

After scratching an itch and developing my new cocoapod TotalObserver, I started to read more about ReactiveCocoa (again) and notice the similarities between what I was doing and RACSignal. This got me thinking about Reactive Programming and how that might fit into Cocoa going forward, when I realized an alignment that can’t be a coincidence. The more I consider it, the more it makes sense. Interest in hearing everyone’s thoughts.

Will today’s Cocoa today be the new Carbon after WWDC 2016? I think Carbon is a good analogy for a new transition Apple has in store for developers on their platforms.

Carbon was originally a partial rewrite of the classic Mac OS toolbox to turn it into an API layer that was portable to the new OS X platform. On OS X Carbon came to be a set of APIs, parallel to Cocoa, that was kept pace for a while but everyone knew wasn’t going to last forever. Over time, all developers eventually migrated to the other OS X API and its language, Cocoa & Objective-C.

Perhaps is Apple planning a similar transition now. However, instead of transitioning between platforms its between languages, Objective-C to Swift. Like Carbon was the API that spanned both OSes, Cocoa will stay for a time as the API that supports both languages, with some small amount of necessary cruft, but there will be a new API paradigm that’s exclusive to Swift.

The analogy is not perfect. In early days of OS X, Cocoa wasn’t new but rather was an evolution of NeXTStep. And anyone adapting an old Mac OS app to Carbon didn’t have a free ride, as it was certainly an API in flux with bugs and quirks on both the old and new platform. To stay relevant Mac OS developers were forced to undergo the transition to keep their customers moving to OS X. Instead the upcoming transition will begin with Cocoa as a solid, fully functional API and language, and after the new platform is unveiled, unmodified Cocoa apps should stay as relevant as before. This new transition will be more of a choice.

The transition form of Cocoa has been underway since Swift 1.0 with piecemeal adoption of the new language allowed, native Swift objects bridged to their Foundation counterparts, and significant amount syntax meant to adapt to Cocoa APIs. For those of us sticking with the old language, added “nullable” qualifiers and collection generics. And this is all before the new platform is unveiled. But all those features I note above have a certain familiar the whiff of compatibility

Its as if we’re in mid-90s and OS X isn’t on anyone’s radar yet but Apple is introducing developers to Carbon as new Mac OS toolbox paradigm for System 7.5. Imagine Apple quietly, confidently working towards NeXTStep as their new OS back then instead of fumbling with Copeland and Taligent.

What will the new platform be? I suspect its a top-to-bottom revamp of the Cocoa APIs on all their platforms, Swift-only, and inspired by Functional Reactive Programming and perhaps MVVM. The few clues to this are in what’s fallen by the wayside in Cocoa, or at least unchanged for years:

KVO and Cocoa Bindings on OS X

When bindings was left out of iOS, not too many OS X developers were complaining. Its hadn’t ever been a great success and I bet Apple was planning its replacement even back then. Apple probably barely entertained bringing it over, or I suspect not at all, even when everything else cool in OS X was seeing a rewrite into iOS if not a straight port. With the exception Objective-C properties getting automatic KVO support and some frameworks like AVFoundation exposing small amounts of functionality exclusively through observed properties, KVO has seen no fresh coats of paint, and no fanfare. WWDC has had no sessions “What’s new in KVO and Bindings”. Since this is withered so long in Cocoa, it likely to be central to the new paradigm. Its further evidence that something like KVO has been left out of Swift to date.

Target-Action & the Responder Chain

This mechanism for connecting control views to their controllers objects goes back to the beginning of NeXTStep, including dragging lines to make connections in Interface Builder. In iOS, controls can have multiple targets instead of just one, but otherwise nothing new. One might suggest that there’s no reason to change what works, and so there’s no evidence of upheaval. However, since blocks were introduced to Objective-C, several parts of the frameworks have adopted them and modernized their interfaces, but not controls and the responser chain. One can easily have imagined a new method like `addTargetBlock:forControlEvent:`, but between 2009 and now there’s been nothing like that. I suspect there’s old sections of the frameworks like this, as well as KVO, for which was thought: don’t bother adding blocks here, we’ll be replacing it completely soon enough.


This is the encompassing paradigm under the application-level frameworks, again, going back to the beginning of NeXTStep. Since the beginning, window controllers and now view controllers have been a easy place for a large portion of an app’s code to accumulate. Cocoa Bindings and scriptability on OS X were good incentives to architect an application differently and put more logic to the modal layer, but it’s been a struggle for developers to do so. So many iOS apps I see consist mainly of the App Delegate, a slew of UIViewControllers, plus the thinnest of “model objects” to make use of Core Data. The Massive View Controller problem is a constant topic. I don’t see Apple sitting by and letting developers constantly fall into this trap; their developers are too idealistic, in my experience, to continue with the current problematic paradigm this long without a plan in place to address it.

It looks to me like there’s little debate that Reactive Programming, specifically Functional Reactive which ReactiveCocoa is modelled after, leads to simpler and more robust code. It’s a new system of adding observers to objects and events, binding views to models and goes hand-in-hand with MVVM as a new spin on MVC. It hits all the bases, aligning perfectly with the cruftiest pieces of Cocoa that Apple has most neglected. Reactive and FRP specifically was hitting the radar of the early adopters several years ago, perhaps the right time period for Apple to have been starting down the path of replacing Cocoa. And no coincidence, Swift is a big step in the Functional direction from Objective-C. Map and flatmap are standard, and some of us are even learning what the work “monad” means!

I think the writing is on the wall. Apple has had what seems like a moratorium on enhancing some fundamental parts of Cocoa with conveniences for blocks and updated support for Swift, and it seems likely they’ve all been on the chopping block. Old and busted to be replaced by new hotness. And the timing is right, Swift has done a major revision and filled in most of its missing pieces needed for current Cocoa development, everything is set for its next version to leave Cocoa behind. Cocoa as it is today will probably linger for a long time, like Carbon did, but when it goes, Objective-C will surely go with it.

Who’s to say the new paradigm will be named, perhaps Cocoa 2? I think personally that the “Cocoa” name, which was picked for its affinity with “Java”, needs replacing and that what’s to come will probably be given a name that has affinity with “Swift” instead.

P.S. I’d like to see a band named “Target-Action & the Responder Chain”