I'm doing a serious project in RubyMotion at the moment. It doesn't save you having to know Objective-C, since all example code for doing anything in Cocoa are still in Objective-C, but it does save you from having to write in Objective-C itself. That means, no writing everything twice (header files, type declarations), and no brackets. I find Ruby a lot more readable, even when writing the incredibly long method names from Cocoa.
But the real payoff is threefold:
1) You can use and write very ruby-ish wrappers for things. A great example is teacup, which lets you essentially write stylesheets for your UIViews (and I guess now NSViews).
2) Working with collections like arrays and hashes is MUCH more convenient. You can spend a good part of your time doing just that.
3) Command-line toolchain. It's not for everyone, of course, but for those who work better like that, it's a revolution.
Right now it's pretty wild west. There's no obvious winner in terms of libraries for the data layer, for example. So taking on an RM project right now either means rolling up your sleeves and hacking on the infrastructure, or just living with raw Cocoa, without benefit of autocomplete. Give it another 6-12 months and I think you'll see a very strong contender.
> That means, no writing everything twice (header files,
> type declarations)
Your header files can be practically empty if you don't need to show something to outside. Just put your @property'ies into class extension. Even @synthesize no longer needed (most of the time, there are exceptions).
> Working with collections like arrays and hashes is MUCH
> more convenient. You can spend a good part of your time
> doing just that.
With latest versions of XCode it is possible to use foo[5] instead of [foo objectAtIndex:5] and foo[@"bar"] instead of [foo objectForKey:@"bar"];
There are also array and dictionary literals @[…], @{…} and you can also just type @1 to get NSNumber from primitive.
I'm aware of all that, but of course you DO want to show things to the outside, all the time. I also know about the newer syntax, which is awesome the few times I still dip into ObjC, but I'm more thinking of map/each/select/detect/etc. There are builtin methods for doing those, but their sheer verbosity tends to discourage the sort of free and easy chaining that Ruby encourages. (Some might argue that's a benefit. Not me.)
Cocoa is a fantastic system to build on top of. NSDate is MILES better than the Ruby time stuff, for example. NS/UI solid core plus Ruby's flexible syntax and culture of sensible defaults is a marriage made in heaven.
>> I'm aware of all that, but of course you DO want to show things to the outside, all the time.
Well, there's a solid argument to be made in favor of limiting how much internals are exposed to other objects. I personally like keeping my headers as minimal as possible.
I found BlockKit [1] to be very useful for any Ruby-like collection methods. BlockKit, as the name says, uses blocks extensively to provide all the most common collection methods one would find in Ruby. Some examples of these methods, taken from the NSArray(BlocksKit) [2] documentation are "each", "apply", "map" & "reduce". There are much more.
But the real payoff is threefold:
1) You can use and write very ruby-ish wrappers for things. A great example is teacup, which lets you essentially write stylesheets for your UIViews (and I guess now NSViews).
2) Working with collections like arrays and hashes is MUCH more convenient. You can spend a good part of your time doing just that.
3) Command-line toolchain. It's not for everyone, of course, but for those who work better like that, it's a revolution.
Right now it's pretty wild west. There's no obvious winner in terms of libraries for the data layer, for example. So taking on an RM project right now either means rolling up your sleeves and hacking on the infrastructure, or just living with raw Cocoa, without benefit of autocomplete. Give it another 6-12 months and I think you'll see a very strong contender.