A few days ago, former Apple engineer Laurent Sansonetti released RubyMotion to the world. RubyMotion is a MacRuby implementation and toolchain for iOS, with a few key differences that allow for apps developed with it, first, to work; and second, to be allowed on the App Store.
The technical differences between RubyMotion for iOS and MacRuby for the desktop lie principally in the memory management (while MacRuby uses Garbage Collection, RubyMotion uses something similar to ARC) and the compilation model (MacRuby is interpreted, though it can be compiled, while RubyMotion is all statically compiled, that is, it generates a monolithic binary that can run on iOS). Apart from that, the syntactical rules are mostly the same, so any knowledge you have about MacRuby will certainly be useful when is time to work with RubyMotion.
I purchased RubyMotion a couple of days after its release, when I had had opportunity to read about it and considered that it might be useful to me. I haven’t had the opportunity to play too much with it yet, but I already have formed a preliminary opinion and I’d thought I’d share my thoughts here, and perhaps see how they change after I play with it a bit more. Specially since RubyMotion is evolving very rapidly, so some considerations need to take into account the moment they occurred: for example, when initially released, the interfaces for iOS apps were expected to be coded purely programmatically, there was no support (other than using ibtool for compiling them manually) at all for using Interface Builder to design them. Nowadays, the Rakefile already takes care of compiling them for you.
I have a background in Ruby, even though I haven’t used it professionally as much as Objective-C. I was also eager to learn how to use Cocoa from Ruby, first with RubyCocoa, and later with MacRuby. Part of my motivation for doing so was partly to avoid the steep learning curve of Objective-C and Cocoa, and partly to be able to use Ruby’s natural expressiveness and terseness.
Nowadays I know better. No matter whether you develop in Ruby or in Objective-C, the hardest part is getting intimate with the Cocoa frameworks. There’s no way around it. The way the Cocoa framework is architected, you have two ways to work with it: swim upstream, or go with the current. If you go with the current, easy things are easy and hard things are still hard, but doable. If you pretend to go against the current, you’ll have a hard time just to make the simplest of things.
And so, working effectively with either MacRuby or RubyMotion requires knowing the Cocoa frameworks. Now, this means you either leverage your existing knowledge of them with Objective-C, or you learn on the fly how to use them with Ruby. And my opinion is that the later will be harder, since most of the documentation and examples are created for Objective-C, and the syntax changes Ruby has made to accommodate Objective-C’s method signatures makes it difficult even for (or specially for) experienced rubyists.
So, my guess is that RubyMotion will be more useful to accomplished Cocoa practitioners, which may find Ruby syntax and terseness very accommodating, than to expert rubyists which will find themselves a little disoriented, moreover when the gems they are familiar with are not available in RubyMotion, and they have to learn the new Cocoa ways of getting things done.
I am sure a lot of rails developers will flock to this new platform, since no doubt their customers are demanding mobile clients for their existing apps, and they find themselves at ease within the confines of the higher design standards of Apple. But I’m afraid that, finding themselves in unfamiliar territory, they’ll have to fall back to snippets, recipes and library wrappers (training wheels, if you like) created by the minority among them that already do develop for Objective-C, just as it happened when Ruby on Rails exploded in popularity. And some of them won’t find the effort worth doing in learning the Cocoa frameworks, and thus deeming RubyMotion inadequate for their development needs, when it is more than adequate for most kinds of applications.
My advice? If you have a Mac and are already familiar with both Ruby and the Cocoa Touch framework, and are willing to pony up $150, give it a try. If not, try first with MacRuby before paying for a tool that you won’t use.
Personally, I already have an app in mind which could leverage the expresiveness of Ruby code and simplify what could potentially be lengthy and cumbersome (and error-prone) Objetive-C code. But that is the matter of another post.