Anyone who has done any serious MacRuby development would already tell you that normal Ruby gems aren't usually the best way to go (slow, don't use Objective-C frameworks).
I can see where this could be a problem if you typically just glue gems together to make products, but if you're used to rolling your own solutions it isn't a big deal.
Sucks, but not a show stopper.
On the upside, CocoaPods support is integrated with RubyMotion. Sure, there is a whole world of useful Ruby gems, but, generally speaking, the libraries you'll find in CocoaPods have been developed specifically for iOS.
Re:RubyMotion - Ruby for iOS
by thibaut_barrere on Thursday May 03, 2012 @02:21PM
(#3925039)
I personally don't care, as I will mostly use a mixture of well-tested, iOS specific ruby libraries I will write and share, together with ObjC libraries.
Re:RubyMotion - Ruby for iOS
by jamesgeck0 on Thursday May 03, 2012 @02:26PM
(#3925064)
I didn't see any documentation describing the ins and outs of statically compiled Ruby. Anyone know how it differs from normal Ruby?
> Because RubyMotion implements a dialect of Ruby that is statically compiled, regular Ruby gems will not work in RubyMotion. We provide documentation which describes how to architect gems to work with RubyMotion.