✦ Life After Objective-C

While catching up on my podcast queue, I listened to the Hypercritical episode where Dan Benjamin and John Siracusa talk about the future of Objective-C and Cocoa. John recalled the Copland fiasco when Apple was way behind Windows95 in terms of system architecture and needed to innovate or die.

He wrote an article in 2005 where he points out that Objective-C and the Cocoa APIs are quickly becoming Apple’s achilles heel. As other platforms move toward higher level languages and away from the low levels like C, Apple will have a harder time convincing new developers to join their platform and innovate with this verbose and antiquated environment.

Apple is approaching another “Copland” moment. What will be the next step? I have a theory.

MacRuby

I say it will be MacRuby. I’ve been watching the development for a while and I’m very impressed. As a Ruby dev I have selfish reasons to hope for this, but I think there are very good hints that Apple is considering MacRuby as the successor.

Back in 2010, I stumbled on this tweet response from Laurent Sansonetti:

That got me thinking.

We Don’t Need No Stinking Bridges!

There have been several bridges for scripting languages like PyObjC and RubyCocoa. Apple officially encouraged their use, but they were cumbersome. They have to translate from the scripting runtime into the Objective-C runtime and do fancy pretending to dispatch messages on Objective-C objects. The bridges were a mapping layer that needed to be updated to support newer Cocoa APIs. And good luck if there was a bug in the bridging framework. More layers == more complexity.

Laurent developed MacRuby while at Apple to replace the old RubyCocoa bridge. It is built on top of the Objective-C runtime and dispatcher for message passing. All Ruby objects are descended from NSObject. The Ruby 1.9 hash syntax makes specifying Objective-C selectors as easy as this:

# Assume this is a UINavigationController
navigationController.pushViewController newViewController, animated: true

There is automatic boxing and unboxing for C scalar values. Ruby blocks run as Objective-C blocks; just hand them in to the Cocoa APIs and you’ll get called back. Any Ruby object can be messaged from Objective-C without any setup. They inherit from NSObject after all!

And MacRuby uses the Objective-C garbage collector. It’s a marvelous integration that works right now. There are apps in the Mac App store built with this. Apple dropped the bridging solutions and included a MacRuby template in Xcode 4. They invest enough in this to convince me that it will play an important role.

In the followup podcast, Siracusa discusses MacRuby as a possibility but dismisses it as a bridge that doesn’t solve the whole problem. I don’t think MacRuby is merely a bridge any more than you can consider Objective-C a “bridge” from C to “real” object oriented environments. Objective-C stood by itself for years. If Apple wants to move all devs to MacRuby and then someday swap out the ObjC runtime for something else, that’s fine. But I wouldn’t say that this makes MacRuby merely a bridge. It can stand by itself.

iOS?

MacRuby compiles down to LLVM byte code which can then be compiled for ARM. It yields the same code as if built with Objective-C objects—it’s just a prettier language on top of the runtime. This solves the efficiency problem for running on iOS devices. The only reason MacRuby isn’t yet supported is garbage collection. We may need to wait for hardware refreshes if the GC can’t be sped up, but I think the trajectory looks clear.

MacRuby solves two big problems; getting new developers and helping the existing ones keep moving forward. Apple doesn’t have to ditch Objective-C. In fact, I wouldn’t be surprised if they kept it around. The integration between the two is so seamless that Objective-C plays the “low level SDK” equivalent for MacRuby. Need higher performance? Write an ObjC method wrapping your fancy pointer arithmetic in raw C. Flex those hard core muscles!

Ruby is a hot, hot language right now. There’s a wonderful community of bright, insanely collaborative developers pushing the envelope forward with Rails, Bundler, Rubygems, Cucumber, Rspec, etc. If I were Apple, I’d tap that. Yesterday¹.

And what of Cocoa? It’s an old API that was built around Objective-C’s eccentricities. Keep it for now because I don’t think it matters. Once MacRuby gets “the blessing from on high” things like the Hotcocoa project will emerge to help us bring these new idioms forward.

What If Jobs Were One Of Us… ♪

It makes a lot of sense to me. MacRuby uses the same runtime with no bridge support needed; Ruby classes are Objective-C classes. Ruby can satisfy new developers and is marvelously backward compatible for the old timers. Apple is showing signs of this transition. It’s too good to pass up.