> Whenever I see a third party tool I ask myself: how quickly it will be updated to the last SDK version? ... What will I tell to the client? “Oh look, we have to wait one week for technical reasons”. For every project I have taken on I have never had the guts to run such a risk.
Forget the rest of the article, this sums up why it's not for you.
Who is the "you" you're referring to? Me? I hope not, I'm really enjoying RubyMotion.
Would I recommend it to a company that only does iOS development? heck no. How about a RoR company that wants to do some iOS development? Now we're talking. If nothing else, I think it is a great way to learn the Touch/Cocoa/Foundation frameworks without having Obj-C cruft get in the way of having a good time.
I was also sold on that "If you stumble on an issue and you don’t know what’s under the hood it is likely you’ll need much more time (possibly all the time you have saved in advance by using the tool) to find out a way to fix it or a workaround."
This is a problem with current HTML5 -> Native frameworks as well, you have to know what's under the hood so that you can make efficient designs.
I'm curious about this ... how much more is "under the hood" of a RubyMotion app than an ObjC app? In the HTML5 -> Native tools you're dealing with an extra abstraction, Javascript running on top of an interpreter that talks to native APIs, which becomes a problem if you need to use the native APIs in a way the interpreter designers didn't think of. But RubyMotion isn't a layer on top of native code, it is native code -- it's a Ruby->machine code compiler. So is there any more standing between you and the hardware than there is if you use XCode? Maybe I'm totally misunderstanding the architecture ...
Like I have said it is just a "language layer" around Cocoa API, there are no extra, built-on-top classes/things. Instead of writing Obj-c you write Ruby, but the behavior is the same.
Forget the rest of the article, this sums up why it's not for you.