

Ask HN: What Are Your RubyMotion Gotchas? - thetrumanshow

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?
======
evilduck
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.

------
scorpion032
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.

~~~
danneu
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.

~~~
cnp
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!

