Cesare Rocchi has an article called On why I am not buying RubyMotion, with his reasons why he's not going to use RubyMotion (found via the ever useful iOS Dev Weekly). I agree with some of it, but overall, I think it's a bit of a strawman. Of course, the arguments are almost identical to the arguments for - and against - MonoTouch, which I'm rather fond of.
On the I agree side:
RubyMotion is not a way to avoid Objective-c. Maybe you will not write it, but you have to be able to read it, because RubyMotion is hooked to the same runtime and Cocoa API. Guess which code you’ll see when you open the documentation? Unless RubyMotion is going to “port” all the huge Cocoa documentation (which is copyrighted) in Ruby format you definitely have to be able to read (thus learn) Objective-c.
I absolutly agree with this. If you are going to do iOS development - in any language - you will need to be able to read Objective-C, and learn CocoaTouch. This is unavoidable, and for most developers, this is a weekend exercise (rather more for CocoaTouch).
You don't need to be able to write it - just read enough to work out what parameters and methods look like, how the .h/.m structure looks like, and that kind of thing. If you know a C-style language (C, C++, Java, C# etc) this is trivial. He has a point, but it's not a good one.
On most of the rest, I disagree.
Say Apple releases a iOS6 today. Will an aligned version of the tool be ready today? If not, when? One day would be fine, one week would not.
Apple never releases an OS "today". So far, they have released everything (to the public, and hence, to the appstore) with atleat 3 months notice. Late June until mid-October last time. RubyMotion have no benchmark for getting API's released, but Xamarin have a reputation for having betas out within 24 hours (including weekends) for new iOS betas. The first one might take a little longer (2 days) due to the number of new API's, but releases like iOS5b3 was within 24 hours. I doubt it'll be any different for RubyMotion.
“Oh look, we have to wait one week for technical reasons”
See above. If you are releasing an app for the release date of a specific iOS version, you might have a problem (eg releasing for the RTM of iOS6), but unless you are very lucky, Apple is not likely to approve it on the day. Apple will not accept submissions using a beta SDK, so you can't use it for production until it's released anyway. And until then, you still have all the non-beta stuff, which runs fine (usually) on the beta OS.
If you wanna invest on a platform it is worth to learn its “official” tools.
Very true, but sometimes, cross-platform portability is more important, or reusing your existing skills rather than throwing them out and starting again. This can be fun, but sometimes, fun is running something you wrote, in an afternoon, on the device. I already know how to talk to a webservice, or parse XML and JSON, or talk to a database. I can concentrate on the differences, not relearn stuff I already know.
Real cross platform examples include writing a single codebase to work on 3 major mobile OS's (with native UI in all cases), or using your backend code in your new mobile app (which would be workable for RubyMotion if you had a well structured Ruby web app).
Control: If RubyMotion wants to “steal” users to Xcode it won’t probably succeed but if it wants to bring Ruby developers to iOS then it is probably going to.
I suspect their aim is Rubyists, not Obj-C-ists. But some are both, so there will be some movement I suspect. In the same direction, Adobe's aim was never to get iOS developers to write apps in Flash - it was to get Flash dev's to be able to target iOS. Anything else is a bonus.
ps: A few curiosities. If you skip XCode how are you supposed to set up configurations of iCloud, push notifications, iAds, game center?
These are all done via itunes connect (mostly), or plists. I'm not sure how RubyMotion does it (I'd assume the same way), but MonoTouch does it using.... xcode! Make a new plist. Edit it in xcode. Job done. Same goes for Interface Builder, CoreData and other essential(?) parts of iOS development.
I'm yet to hit something which I can't do in MonoTouch, but can be done in xcode. Actually, not true: the (lack of) processing of images can't be turned off in MonoTouch, but it can be in xcode, allowing things like ImageOptim to be used - but I think Xamarin are working on that. Not exactly a big issue, but it is something.
My reason not to use RubyMotion in production - aside from the fact I'm more than happy with MonoTouch - is that its very early technology. I know what other tools, including MonoTouch and xcode, were like in the early versions, and until RubyMotion matures a lot more, it's going to be down to the hardcore enthusiasts. MonoTouch is mostly past that phase, as it's stable and predictable now, but given 12 months or so, RubyMotion may be in the same place.
If you want to learn Objective-C, do it. If you already know Objective-C, use it. Nothing stopping you, and I suspect you'll have loads of fun doing it (I did). If you want to make iOS apps, pick the tool you feel you want to use now, and use that. You can always change your mind later. Personally, I'm tempted to (re)learn Ruby just to use RubyMotion. If they had a free simulator-only version, I'd definitely be trying it.
