Last week, RubyMotion was pretty big news. Big enough, it seems, that two of my favorite podcasts—Hypercritical and Build&Analyze, both on the 5by5 network—covered the announcement in their most recent episodes.

Both shows are hosted by seasoned programmers who are Mac users, though, I would say, neither fanatically so.

Both hosts advised against using RubyMotion.

It’s not that they didn’t have reasonable, even strong arguments, but they both made two assumptions that don’t hold up for me:

1. The main reason you would want to use something like RubyMotion is to avoid learning Objective C.
2. Objective C isn’t that hard, so you should just learn it.

The first assumption may be true for lots of people, but it’s not the only reason one might want to use RubyMotion. Here are a few more:

1. The most obvious: you are a Ruby developer. Both hosts are quick to point out that you are not simply off the hook because you can write in Ruby. You still have to learn iOS’s APIs, which, they both point out, is harder than learning Objective C. If that’s the case (and I do think it is), then what does it matter if you’re writing in Ruby or Objective C? Their argument basically says you benefit in neither scenario, so I don’t see it as an anti-RubyMotion argument.
2. Readability. I’m not trying to start an Objective C versus Ruby flamewar, here. Also, yes, since you’re still writing to the iOS APIs, your Ruby is going to look a lot like Objective C in some places, like your API calls. What I mean is that if you are a Ruby developer primarily, and you learn Objective C for an iOS project, and then you don’t touch Objective C again for a year or two, are you going to be able to maintain or reuse your own code when you come back to it?
3. Uh, did you watch that video? Can Xcode come close to this? Does Xcode even have a REPL(I agree, John, that it was bold of Ars not to link that term) feature like this? I’m not aware of any.
4. Code re-use. I know these can be dirty words in some arenas, but there’s a time and place. If you have some complex business logic that’s well-tested and already written in Ruby, why fork it and port it to Objective C if you don’t have to?

The application of the second assumption, that Objective C is easy enough that you might as well just learn it, was a bit murkier. The hosts seemed to say, if I understood correctly, that you don’t want to end up cornered when RubyMotion is somehow locked out of the App Store, or when RubyMotion fails to support some new API in a future version of iOS or similar. You don’t want to have a dependency on some third party library at that point. But if Objective C is so easy to learn, wouldn’t it be just as easy to learn at that point? They claimed a good programmer would be able to learn Objective C in a weekend—though it would take a good bit longer to learn UIKit and its APIs. How can you ever be cornered if it only takes a weekend to learn the other language? It’s likely they meant that porting your application in a weekend is a much taller order, but I don’t recall either of them saying as much.

Again, I’m not disagreeing with the basic premise of their arguments, which is, using the tools intended by the platform owners is most often the safest and most robust path to software production. I do, however, see the appeal in using something like RubyMotion.

I’m also very interested to hear what Dan Benjamin, co-host of both shows and owner of the 5by5 network. Unless I missed it, he has not really weighed in except with passing statements that he is interested in RubyMotion, though observing the wisdom of using Apple’s toys when in Apple’s sandbox.

UPDATE: After a brief conversation with Siracusa on this post, I’d like to correct myself. He for sure did not espouse the first point above. Also, I pretty much just conflated his totally open-minded exploration of the potential pitfalls of using a bridge with Marco’s more skeptical viewpoint.