Steve Madsen
RubyMotion

Yesterday, Laurent Sansonetti announced RubyMotion, the first product from his new company, HipByte. Laurent is the creator of MacRuby and worked on it part-time while an employee at Apple.

RubyMotion is interesting, but I don’t have any plans to use it myself, especially for client work. There are two reasons.

The first is from a business standpoint. I learned long ago to put aside my own opinions of how things should be done whenever possible and to swim with the current. This applies to managing servers (use the package manager and avoid installing your own software) and developing software (understand the intention of the API’s author and use it accordingly).

Apple ships a lot of open-source software with OS X, but they aren’t great about keeping up with releases. Nor are they good at supporting alternative ways to write software on their platforms. Remember Java, RubyCocoa, and PyObjC? This is even true, to some extent, of MacRuby. Apple paid Laurent to work on MacRuby, yet MacRuby never shipped with an OS X release. If you want to use MacRuby in a shipping application, you either require your users to install it (terrible UX) or embed it yourself (at a cost of 10+ MB to your app bundle).

Lion shipped on July 20, 2011. It includes Ruby 1.8.7-p249. 1.8.7 has been in maintenance mode for a long time and Apple has ignored numerous patches.

  • p299, released on June 23, 2010, over a year before Lion
  • p302, released on August 16, 2010
  • p330, released on December 25, 2010
  • p352, released on July 2, 2011

The Ruby core team has encouraged people to move to 1.9 since the official release of 1.9.2-p0 on August 18, 2010. There are no signs that Apple will move the system Ruby to the 1.9 series in the upcoming Mountain Lion release, either, nearly two years later.

I’m offering all this as a long-winded way to say that I do not put much faith in Apple’s desire to avoid breaking a third-party toolchain such as RubyMotion when they can’t be bothered to do a good job supporting the Ruby they ship on OS X. It’s less troublesome, but still an issue, that they never shipped the MacRuby framework, which they paid an employee to work on.

If Apple were to break RubyMotion, intentionally or otherwise, in a future iOS release, I would be unable to fix those apps until RubyMotion adapted to the change, however long that took. In the meantime, the apps would be broken, making users unhappy. If the apps were for clients, my choice of a third-party toolchain will reflect very badly on me, as well.

Objective-C is how Apple wants developers to build apps for iOS. Choosing something else means swimming against the current and invites trouble later. At the very least, the pool of available talent is massively reduced. This puts my clients in a bad place if they can’t or won’t come back to me for updates.

My second concern is about programmer productivity. Xcode takes a lot of abuse, and Xcode 4 has been somewhat of a step back, but it’s still a pretty good IDE. I may in the minority, but I really like the wordiness of the Cocoa APIs and the way that Objective-C’s mixes arguments into the middle of method names. For any method that takes more than two arguments, this naming style saves me from needing to remember things. Xcode’s code completion is crucial to this, though. When it stops working, writing to the Cocoa APIs is painful.

One of RubyMotion’s selling points is that I get to use my preferred editor. Does any text editor offer intelligent code completion for classes from both frameworks and my own source files, without a manual indexing step? If not (and I doubt it, since it’s a big job), then I’m back to having to remember things, and a lot more than just the order of method arguments.

RubyMotion also throws Interface Builder out. The promise is that you’ll build interfaces in code, using an ASCII art style similar to Cocoa Autolayout. I don’t see this as anything other than an admission that RubyMotion can’t work with IB. It is a huge weakness, perhaps worse than the code completion problem.

RubyMotion is an interesting idea, but I won’t consider it for anything more than prototyping in the near term.

Update: Ian Phillips demonstrates that it is possible to use Interface Builder, but very minimally. You can lay out the interface, but that’s it. No outlets, no actions and no storyboards (which are great, if you haven’t tried them yet). A big part of what makes the Cocoa + IB combination so wonderful is that we can freeze dry a set of objects that make up an interface and later recreate them, with all their connections intact. This work must still be done in code with RubyMotion, which is ugly. Until RubyMotion can support NIBs 100%, it might be better not to use them at all.