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 k

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.