I write Mac software, but over the last year I’ve increasingly been building Ruby on Rails web apps as well. Today I finally took a look at “RubyCocoa”:www.rubycocoa.com/. I wanted to whip up a quick Cocoa app that would involve some text parsing, and a dynamic scripting language like Ruby is a much better fit for text processing than C, C++, or Objective-C.
It turns out RubyCocoa works amazingly well. I have only scratched the surface with a small test app, but I was blown away by its ease-of-use, Xcode integration, example projects, and apparent maturity. You have full access to AppKit from Ruby-based controllers and views, and a single NIB file can even reference both Objective-C and Ruby classes. Fantastic stuff.
I don’t know if it’s ready for commercial software use yet. For distribution, I tested including the RubyCocoa.framework inside the application package and the app launches and runs correctly on a system without the full RubyCocoa install. There may be issues with requiring a recent version of Ruby, but otherwise it’s a fully native app.
My only disappointment was in the Objective-C calling conventions. There are two versions to choose from: a style using underscores to separate named values, and a slightly easier Ruby syntax using symbols and extra parameters. Here they are:
Objective-C:
[my_window setFrame:r display:YES animate:YES]
Ruby Underscores:
my_window.setFrame_display_animate(r, true, true)
Ruby Symbols:
my_window.setFrame(r, :display, true, :animate, true)
In my opinion, a better approach would be to take advantage of Ruby’s trick of allowing the last parameter to be a hash supplied without the curly braces. This feels more readable to me and more closely matches the Objective-C equivalent.
Better:
my_window.setFrame(r, :display => true, :animate => true)
In any case, that’s a minor complaint and doesn’t take much away from the beauty of writing native Mac apps in Ruby.
