The MacRuby framework is a fresh and exciting way for us Ruby developers to build native Mac OS X applications. MacRuby marries one of today’s most flexible and streamlined programming languages with the power of Apple’s OS X core technologies; with it we Rubyists can for the first time construct fully compiled, Apple App Store-eligible OS X applications.
This is especially thrilling because it elevates Ruby from a specialized niche language (web applications) to a new level. Our language — not Python, not Perl, not Java — has been chosen to stand alongside and, some say, eventually replace Apple’s Objective-C.
But it must be granted that to develop in MacRuby is to develop at the bleeding edge. Its most current release is version .10, and the MacRuby community, while growing, is still very small. Books on the framework are still being written or in press, and there just aren’t very many online resources available yet. You won’t find zillions of code samples in StackOverflow. In other words, when you strike out on the MacRuby trail, it’s not as well-worn as the Rails path or even the Objective-C path. It feels a lot like you’ve been handed one of those old parchment maps with vast unexplored areas marked, “here be dragons.”
As you work your way through these undocumented areas you’ll need to wield a lot of patience and creativity. That’s the price you pay for being on the vanguard of the MacRuby movement.
My traits are representative of many present and future MacRuby developers: Mac user, TextMate fan, Ruby on Rails developer, and former Java & C programmer. I’ve dipped my toe into the MacRuby waters and I’ve learned a few things. So with our commonalities in mind, let me share with you some observations and words of encouragement…
First, you’re going to miss ActiveRecord and be frustrated by its absence. The lack of an ActiveRecord-style ORM has been the bitterest pill to swallow. After all, when you embrace the MVC style of Rails, you quickly become accustomed to — even spoiled by — AR’s database-centric style and ease of use. All you had to do was define your models in the database, add a few validations and relationships to link things together, and it just worked! Well, not so in MacRuby (or Cocoa, for that matter). There is a database layer called Core Data, but it’s nothing like ActiveRecord and it isn’t even an ORM at all. You’re going to have to get used to dealing with data in a much more raw way, and wave goodbye to AR’s seamless data integration.
Related to the first point, MacRuby is MVC but it’s different in some subtle ways. Core Data and Cocoa just aren’t data-centric in the same way Rails is, and Rails developers are trained to think from a data point-of-view. (What’s the first thing you do when you write an application? Generate a scaffold and write your migrations.) Everything to a Rails developer is UI layered on top of model manipulations, and the prevailing philosophy is “fat models, skinny controllers.” But MacRuby turns this on its ear. It is view-centric and the data exists subservient to it. Controllers are fat, and data is retrieved as necessary to populate or persist the UI.
Third, you’re probably excited that MacRuby lets you get into OS X application development without climbing Objective-C’s rather steep learning curve. You’re partially correct. You don’t need to learn OC per se, but you still need to learn Cocoa and grok the Objective-C style of message passing, which MacRuby embraces. Cocoa is well-documented, but it’s massive. You’re going to have to learn strange things like managed object contexts, NSPredicates, IBActions and IBOutlets. The sad fact is, it’s probably easier to transition to MacRuby as an Objective-C coder learning Ruby, than a Ruby coder learning Cocoa. Brace yourself for some head-scratchers and try to remain optimistic and patient.
Fourth, XCode 4 is a fine IDE, so give it a fair shake. Its Ruby color syntax highlighting is weak at the moment, but there are some very nice features bundled into Apple’s latest IDE. It’s fast, smooth, has a really nice user interface builder, and offers a great documentation system. You’ll lean heavily on the latter as you scale the Cocoa cliff.
Last, you’ll sorely miss your Rails console. Oh, there’s macirb, of course, but there’s nothing handier in the world than our faithful console where you can load models, experiment with finder syntax, and hand-debug odd behavior.
These differences, while stark, aren’t keeping me from embracing this very exciting new tool. Let me conclude with this advice: there will be times that you’ll need to get out of your own way when working with MacRuby, because more than once you’ll exclaim in frustration, “I could do that in one line in Rails!” Just take a breath and remember that this is new ground, and with unexplored territory there are often greater rewards.
In later articles of this series I’ll post some code snippets and other items to help those who come behind me.