Ask HN: What Are Your RubyMotion Gotchas? | Hacker News Reader

Ask HN: What Are Your RubyMotion Gotchas?

Its been almost a year since RubyMotion launched. Some of you have gotten a chance to play with it. Others have probably gone full-speed with it. Some are working in teams, others have surely gone solo. My question is... what's the catch so far?

View on HN

In RubyMotion, a string is a NSString, a floating point number is a Numeric, which is a NSNumber, so it's not a leaky abstraction like Phonegap is. Your Obj-C knowledge will carry forward if you already know it. RubyMotion puts Ruby's sugar on top of it too, but there's almost nothing the from the iOS SDK that's off limits, if you need to use a method from NSDate instead of Ruby's Time, you can. In PhoneGap, if you wanted to use CoreImage heavily you'd likely have to write a custom PhoneGap plugin, in Objective-C, to make it available to your JS. In RubyMotion, you just use CoreImage.

A couple of maybe-unexpected (but documented) differences for iOS devs: you don't use ARC, RubyMotion does its own memory management, and there's a wrapper around Grand Central Dispatch and you can't access it directly (I don't know the full reasoning for that).

For a Rubyist: You sometimes have to deal with pointers which looks strange. There are named parameters, which Ruby 2.0 just introduced but it will look a little strange at first.

Overall, there's conflicting idiomatic styles between Objective-C and the iOS SDK and Ruby's typical implementation (camel-case vs snake-case, short method names vs long method names, implicit returns, etc). You'll have to make a decision for yourself how to resolve that. Debugging is still a little rough around the edges, it's doable but not as nice as regular Ruby or Objective-C, though the RubyMotion REPL helps immensely with that.

Additional benefit, unit testing is easier than Obj-C and built into RM by default with MacBacon (RSpec-like), and Ruby has a strong culture of testing code, so that's a positive influnce in the iOS dev community.

Even with RubyMotion, you have to still learn the full iOS API. There is no way around that. You save a little bit of syntax, but Xcode is a pretty good IDE so that isn't the big deal.

The big deal is the community and culture of the open source that comes with Ruby folks. The number of open source RubyMotion applications is already perhaps higher than the objective C ones.

If I were to choose to build ONE iOS product today, I'd prefer to do it in the native objective C. But if I am a shop that plans to build quite a few of them, RubyMotion would be my choice.

While I started with iOS development through the traditional route of those Stanford courses, I learned the bulk of my more in-depth knowledge after focusing on RubyMotion.

"You'll still have to learn the iOS API" is true, but I think it's a red herring. Because RubyMotion isn't just swapping ObjC with Ruby, and there are more compelling reasons for trying out RubyMotion than "you get to use Ruby".

RubyMotion is a vast simplification of the development environment (rake + vim), a set of wrappers that vastly simplify Cocoa Touch objects/libs, and a small helpful community that makes it easy to filter out signal from the noise when you hit an obstacle.

And those are the reasons why RubyMotion helped me become a better iOS developer as a newbie.

By wrapping Cocoa Touch in some painful areas, it helped me focus on learning the iOS framework at a higher level instead of wrestling with ceremony.

I totally agree with this. I learned so much about iOS and Objective-C from starting development with RubyMotion.

I guess that's my gotcha: you'll end up in Objective-C even if you're trying to avoid it, and that will be... just fine!

Reply on news.ycombinator.com