At face value, I like the idea of RubyMotion, but I can't help but feel like it's a crutch to avoid picking up a few subtleties in Objective-C. The article even points out that RubyMotion doesn't hide much of the API from you, so in some ways it feels like 6 in one hand, half a dozen in the other. I'm not trying to be a naysayer, but I don't think the barrier to entry is as high as some make out to be.
Call it my crutch, but I got an app shipped without having to worry about a lot of the baggage that comes with Objective-C as a language. Here's two of my favorite examples of things I didn't have to worry about:
You're definitely right — nil / NSNull is confusing to newbies, but Ruby is just as bad. The way it handles UTF8 is somewhat backwards, and the fact that symbols and strings are different (but sometimes used interchangeably) can cause 'gotchas' for newbies too. I'd argue that your language of choice is really dependent on which set of baggage you've internalized :-)
RubyMotion is a huge win for me because of the super low friction toolchain. I don't ever have to load XCode and I can automate the build process however I like because it's all command-line based.
I was convinced the moment I checked out https://github.com/HipByte/RubyMotionSamples and just started typing 'rake' in each directory not ever having to setup directory paths for xcode project settings.
The bigger reason to use RubyMotion is not a different syntax - you do end up using very similar code anyway, although lack of header files is a nice thing - but different tools. Objective-C is not the barrier. Xcode is.
After many attempts at getting started with Xcode and Objective-C had fizzled...it was an absolute joy trying RubyMotion and getting setup as an iOS Developer last night.
I can't wait to learn more, and it's wonderful being able to develop in Sublime, use RubyGems, Git, etc.
