MacRuby on iOS – RubyMotion review

Yesterday, RubyMotion was released and let’s be honest, it is one the best alternatives to Objective-C out there (if not the best).

RubyMotion is a commercial, proprietary fork of MacRuby that targets iOS. This is not a small achievement, MacRuby relies on Objective C’s Garbage Collector (libauto) which is not available on iOS. Static compilation and new memory management solution was required to target the iOS platform . The new runtime had to be small and efficient. Furthermore, being able to run code on iOS isn’t enough, you need tools to interact with the compiler, to debug, to packages applications etc…

I don’t think anyone will contest the fact that RubyMotion is a well done product. The question however is, “is it worth for you to invest some money, time and energy in this product instead of using Apple’s language and tools“. In this article, I’ll try to balance the pros and cons of RubyMotion so you can have a better understanding of what RubyMotion could mean for you. As a disclaimer I should say that I was beta testing RubyMotion, that they are strong ties between RubyMotion and the MacRuby project I’m part of and finally that having MacRuby on iOS has been something I’ve been looking forward for a very long time.

Over the last few months I’ve seen RubyMotion take shape and finally hit the big 1.0. As you can see from Twitter and HackerNews, the Ruby community is excited about being able to use their language to write statically compiled, native iOS apps. Spoiler alert, they are right, it’s a lot of fun.



What I like about RubyMotion:

Ruby Language

I don’t mind Objective-C, I think it’s a fine superset of C, with the arrival of blocks, new literals and automatic memory management via ARC, Objective-C is actually getting better over time. But frankly, it’s not Ruby. You still have to deal with headers, you always have to compile your code via some weird Xcode voodoo settings, testing is a pain, the language, even with the new literals is quite verbose. On the other hand, using Ruby syntax I can get much more flexibility, reuse my code via mixins, easily reopen existing classes etc… At the end of the day, I end up with some code that seems cleaner, easier to understand and maintain even though I’m calling the same underlying APIs. Ruby’s flexibility also allows developers to make their own higher level APIs, take a look at some of the wrappers/helpers I wrote while playing with RubyMotion.

Matt Aimonetti - Ruby Logo


RubyMotion is based on MacRuby, meaning that all the time and energy invested in the project will benefit RubyMotion’s users. All the concepts I explain in my MacRuby book apply to RubyMotion. You don’t have to find workarounds to work with native APIs, Ruby objects are Objective-C objects and performance is great. I do regret Apple didn’t decide to embrace MacRuby for iOS but at the same time, even though we lost the Open Source aspect of the project and Apple’s backing, we gained much more flexibility and freedom on Laurent’s part.

REPL/Interactive shell

RubyMotion doesn’t currently have a debugger, but it does have something Objective-C developers don’t have, a REPL working with the simulator. This feature is quite handy when debugging your application or learning the Cocoa APIs. You can click on a visual element in the simulator and start modifying the objects in real time in a terminal window and see the modifications in the simulator. It reminds me of the first time I used firebug to edit the html/css of a web page and saw the changes in real time.

Matt Aimonetti - RubyMotion REPL

Not dependent on Xcode

Xcode is fine when you write Objective-C code, but it crashes often, it has a complicated UI and never really worked well for MacRuby due to the fact that Objective-C and Ruby have different requirements and the that Xcode is not open source. It’s also fully controlled by Apple and doesn’t provide APIs for 3rd party developers. (That said, the Xcode team has often helped out when a new released of Xcode broke MacRuby, so thank you guys).

Being able to use simple rake tasks to compile, simulate and deploy applications is just really really nice. I’m sure we’ll end up with better IDE integration, nice GUIs for some who like that, but in the meantime, as a “hacker”, I really enjoy the simplicity of the Rake tasks and not being forced in using a specific IDE.


Memory management

Even though ARC made memory management much easier for Objective-C developers, when using RubyMotion you don’t have to worry about memory (well at least not explicitly, don’t be dumb and create a bazillion objects and hold references to them either). This includes the CoreFoundation objects that you still have to manually manage in Objective-C. Memory management is transparent and in most cases it’s really nice.



What I like less about RubyMotion

Here is a list of things that are cons to using RubyMotion, note that while the list is longer than my list of “pros”, I listed a lot of small things. I also think that most of these issues will get solved in the next few months.


Ruby language

There are some cases where Ruby just isn’t that great or is not an option. Examples include dealing with API relying heavily on pointers, when using some of the lower level APIs or when you have to interact with C++ (video game engines for instance). The good news is that within the same project, you can write part of your code in Objective-C and the rest in RubyMotion. The other thing that bothers me a little bit with writing Ruby code for iOS is that you can’t easily enforce argument types and therefore you are losing a lot of the features provided by Clang to the Objective-C developers. I dream of an optionally typed Ruby — but that’s a different topic.

Another downside of using Ruby is that Ruby developers will assume all standard libraries and gems will be compatible with RubyMotion. This isn’t the case. You need to think of RubyMotion as only offering the Ruby syntax (modulo a few differences). To be honest, most of the std libs and gems aren’t that useful when writing iOS apps. Even when I write MacRuby apps, I rarely rely on them and pick libraries designed to work in a non-blocking, multi-threaded environment (usually ObjC libs that I wrap).


Cocoa Touch

If you’re already an iOS/OS X developer, you know that most of the hurdles aren’t the language syntax but the Cocoa APIs. These APIs are what you need to interact with to create your application. Cocoa APIs are usually much lower-level compared to what you usually see in Python, Ruby or even Java. While they are quite consistent, the APIs still have a stiff learning curve and currently,  if you want to write iOS applications, even if you know Ruby, you still have to learn Cocoa.

However, I do think that with RubyMotion now building a userbase, we will start seeing more and more wrappers around these sometimes hideous APIs.


No Xcode/IDE

There are cases where an IDE is really practical, especially when learning new APIs. Being able to have code completion, quick access to the documentation, instrumentation, debugging, interface builder, refactoring tools are things that Objective-C developers might have a hard time with when switching to RubyMotion. If you don’t know either Ruby or Cocoa, getting started with RubyMotion might be quite hard and you are probably not currently in the target audience.


Writing UI code by hand

In some cases, it makes sense, in other, it should be much easier. I know that Laurent is working on a DSL to make that easier and I’m looking forward to it. But in the mean time, this is quite a painful exercise, especially due to the complexity of the Cocoa UI APIs. Using Xcode’s interface builder and Storyboards is something I know a lot of us wish we could do with RubyMotion when developing specific types of applications.

Matt Aimonetti - Xcode iOS storyboard

No debugger

Again, this is eventually coming but the current lack of debugger can be problematic at times, especially when the problem isn’t obvious.


Lack of clear target audience

It’s hard to blame a brand new product for not having clearly defined a target audience. But as a developer I find myself wondering “when should I use RubyMotion and for what kinds of problems?” Is RubyMotion great for quick prototypes I can then turn into production code? Or is good for throw away prototypes? Is it reserved for “fart and flash light” applications? Is it ready for prime time and should I invest and write my new awesome apps using it? Should I convert over my existing code base over from Titanium (or whatever other alternatives you used)? Should I use RubyMotion every time I would use Objective-C?

I guess we will see when the first applications start hitting the app store and people start reporting on their experience.


I’m partially to blame here since I could have moved my butt and start writing a book but the point is nonetheless valid. All the iOS documentation out there is for Objective-C, all the APIs and samples provided by Apple are obviously only for Objective-C. Thankfully, you can use the 2 MacRuby books available out there to understand how to convert this existing documentation into something useful, but RubyMotion will need to provide better and more adapted documentation for beginners. I have no doubt that this is coming sooner than later.


Proprietary solution

RubyMotion isn’t open source and currently fully relies on the shoulders of a single man. If unfortunately, Laurent goes out of business or decides to do something else then we will have to rewrite our apps in Objective-C.  Using RubyMotion for a professional product represents a significant business risk, which is exactly the same as using proprietary technology from any vendor. Apple could also decide to switch to JavaScript or rewrite iOS in Java and deprecate Objective-C. Let’s just say that it is unlikely.

I usually favor open source solutions, from the programming language I use to the OS I deploy on. This isn’t always possible and if you want to write iOS applications, you don’t currently have a choice. I do wish Laurent had found a way to make money while keeping the source code open. But who knows — after he makes his first million(s), he might change his mind.

Matt Aimonetti - RMS


I would strongly suggest you consider giving RubyMotion a try. I can assure you that it will provide at least a few hours of ‘hacking fun’ (and you will be able to brag about havng written your own iPhone app).  It will also help support financially someone who’s taking a risk in trying to push mobile development to the next level.

RubyMotion is, by far, my favorite alternative to Objective-C. But it is hard to tell, just 48 hours after its release, what people will do with it. Can it transcend the programming language barriers and attract Python, PHP, Java, ObjC and JavaScript developers? What is the sweet spot for RubyMotion applications? Will it affect the native vs web app battle? Can it make iOS development more accessible to the masses? Only time will tell.

What do you think?


Similar Posts

, ,

  1. #1 by Gavin Miller - May 4th, 2012 at 07:49

    Thanks for the summary Matt, really appreciate someone going over the Pros and Cons! RubyMotion certainly looks useful and would be fun to try out on a side-project – your point about proprietary lock in certainly addressed the “side-project” part of that issue.

  2. #2 by Dennis Major - May 4th, 2012 at 08:17

    What I liked about the article – as usual thorough and informative.

    What I Didn’t like – at some point “not being Open Source” as criticism slips over into dogma – is this the case here – perhaps.

    OS has benefited me and others greatly but if someone takes a risk on an idea and feels he/she can offer something good enough that customers will buy it – good on them for taking that high profile risk and being willing to let their implementation of their idea be judged by the market.

    • #3 by Matt Aimonetti - May 4th, 2012 at 08:49

      Fair criticism and I’m not blaming Laurent, I’m just saying that there is a certain risk if you were to build a big project you plan on developing for years. That said, I have a license, wrote apps and will keep on hacking away with RubyMotion.

  3. #4 by Javier Cicchelli - May 4th, 2012 at 08:43

    Matt, you properly addressed the main technical/business points and issues I have with RubyMotion. Moreover, I’m curious to see how RubyMotion will coexist with MobiRuby in the near future. How do you see it?

    • #5 by Matt Aimonetti - May 4th, 2012 at 09:04

      It’s hard to compare a released product I’ve tested for months with one that was only announced and isn’t out yet.

      But, I think that MobiRuby will attract hackers wanting to work on the implementation itself, some maybe creating meta languages/DSLs on top of mruby. It will also attract developers who are not willing to spend some money to try Ruby on iOS.
      However, RubyMotion benefits from MacRuby’s work and the fact that your Ruby code doesn’t need to go through a bridge is a huge advantage. Furthermore, RubyMotion is much further along, and because the development is funded by the cost of the license, some support will be provided.

      However, at the end of the day it will be up to the community to decide. I will certainly play with both and I hope we, as a community will come with a better way to write mobile apps and show that Ruby can provide developers with more than just a nice syntax.

  4. #6 by Daniel Lucraft - May 4th, 2012 at 08:51

    Very good analysis. One of the things you identify as a downside, that we spend most of our time figuring out and working with iOS APIs anyway, I think somewhat counteracts the worry that we are investing in a new platform that might disappear.

  5. #7 by Fernand - May 4th, 2012 at 09:32

    Hi Matt – Thanks for sharing your thoughts on this! Very good read. I am really amazed by how much Laurent has done to make this happen. I have been dabbling with xcode for a while and no matter how much I try it is just not fun to work with. Could be the ide or the language or both. Once of the thing that appeals to me with RM is that I can easily print stuff out or examine my app in the console. So in that sense RM is kind of a getaway drug for me to learn the various api’s and just for that think it’s worth the price. One of the thing that would make this experience even more awesome would be if I could just cmd-r in the simulator to see my updates. That said I totally share your point that for rubyist the rake and console experience is a very appealing alternative. Another thought came to me while playing with RM is the ruby naming convention is totally shot in that space ie my_fred vs myFred and the objc named args. I understand that it’s part of the deal, but feels a bit jurassic in ruby land.

    • #8 by Andrew Pouliot - May 4th, 2012 at 10:58

      Xcode has a very powerful tool in this regard: gdb / lldb.
      You can inspect and alter objects, properties, core animation layers, etc. from a command line. Admittedly, it would be much better if it supported full ObjC syntax and were less buggy, but I don’t see how the REPL is far superior given that it sounds like there isn’t a real debugger in RubyMotion.
      My 2¢.

      • #9 by Matt Aimonetti - May 4th, 2012 at 11:09

        A REPL and a debugger are two different things, as mentioned in the article, I wish RubyMotion had a debugger but Xcode won’t have a REPL anytime soon.

        • #10 by Billy Mabray - May 4th, 2012 at 13:43

          Can you expand on the difference a bit? If lldb can read, evaluate, and print, how is it different from a REPL?

  6. #11 by Nick - May 4th, 2012 at 09:46

    As an iOS dev coming from the ruby world, this project is fantastic in almost every way. I’ve already purchased a license and I’d pay 10x the amount if it does what it says on the box.

    However, I get extremely nervous about building apps for clients using 3rd-party frameworks (Titanium, Rhodes, etc). I can’t promise long-term support to my client if I have to rely on someone else other than Apple and me. I can’t blame Laurent for that, and it’s really not solved by open source either (saying “pull requests welcome” is a cop out). It’s just too much of a risk for many people.

    So, I may not be able to use this as my primary tool, but I do see this being perfect for prototyping and side projects where clients don’t come into the mix.

    • #12 by Beelsebob - May 4th, 2012 at 22:26

      I find it odd that you see this as good for prototyping, when it involves a lot more typing to set up simple UIs due to the lack of IB. Can you explain what makes it better for quick prototypes?

  7. #13 by Clint Bishop - May 4th, 2012 at 10:18

    You mention giving RubyMotion a try, that it will provide a few hours of hacking fun — the $150 (early bird, even) price tag seems a little steep for hacking. Is there a trial or demo that I’m missing on the website, or do we have to drop coin to play around with this thing?

    • #14 by Matt Aimonetti - May 4th, 2012 at 10:36

      Unfortunately, there isn’t a trial/demo version :(

      For most of us, the price of a license represents about an hour of consulting work (or less for the lucky ones charging 10k/day :p) If you are student, you can contact and ask for an educational discount.
      Thinking about it, If a 2 hour move costs you $12, you’ll get the same value off of RubyMotion if you hack on an app for 25 hours

  8. #15 by Charles Oliver Nutter - May 4th, 2012 at 11:44

    I’m not clear how much of “Ruby” has been stripped out of RubyMotion. In order to get executables that small, it seems like it has to have removed most of the core class implementations users expect to have. MacRuby’s library (libmacruby) is a *13MB* binary. Obviously this includes things like the compiler, for loading code that has not been precompiled, but it is still an extreme difference compared to the size of a bare-bones RubyMotion app.

    Have you been able to determine how much of “Ruby” — in terms of core classes, standard extensions, and the like — is actually available in RubyMotion?

    • #16 by Matt Aimonetti - May 4th, 2012 at 11:55

      Things like ‘rubygems’, ‘require’, ‘eval’ don’t work and probably will never work due to the platform restrictions. The std library isn’t available either but everything else (core classes) at the core of the language seems to work fine. That said I haven’t tried to run any language specs but I haven’t encountered any issues.

  9. #17 by Charles Oliver Nutter - May 4th, 2012 at 11:45

    I should also point out my primary concern: how far away can you get from Ruby and still call it Ruby? RubyMotion already has incompatible syntax (inherited from MacRuby), but beyond that it probably can’t even run existing libraries or code without significant modification.

    Perhaps it should be made more clear that RubyMotion is a very distinct subset of Ruby.

    • #18 by Matt Aimonetti - May 4th, 2012 at 12:05

      That’s not for me to decide, it sounds however like a semantic discussion that might only matter to Ruby implementers. I thought that’s what the ISO standard was for?
      Ruby is definitely a restricted version of the Ruby language, is it still Ruby, I let others argue about that.

      Regarding MacRuby, the only language extension I’m aware of are the keyed arguments which is usually used in a compatible way. But you are right that the syntax isn’t fully compatible since you can defined methods taking keyed arguments, something I haven’t seen many people do, but that is obviously doable.

  10. #19 by JackB - May 4th, 2012 at 19:40

    How to call native C/C++ or ObjectiveC library directly, seems there is no example code, right?

  11. #21 by Matt Aimonetti - May 5th, 2012 at 02:16

    Billy Mabray :

    Can you expand on the difference a bit? If lldb can read, evaluate, and print, how is it different from a REPL?

    correct me if I’m wrong, but LLDB is primarily a debugger, meaning that you are setting breakpoints or watch some variables. You can certainly also inspect the state of your application while you hit the breakpoint. On the other hand a REPL will run in parallel of you application, will allow you to evaluate code in your application language such as modifying and creating new objects on the fly while the run loop is still going. While you can call methods from lldb or set variables, if you try to dispatch a block you will see that it isn’t trivial. Creating a new button, and setting it up and moving it can be quite hard with a debugger. You can certainly do it but it’s not what the tool is designed to do. Finally, in the case of RubyMotion you can click on any UI element and start editing it right away which would require much more work in a debugger.

  12. #22 by Jonathan jjeffus - May 5th, 2012 at 18:36

    Im not sure why there’s a huge buzz for this, RhoMobile has been around for at least a year.

  13. #23 by Steven Ringo - May 6th, 2012 at 05:18

    Rhomobile does not compile to native iOS code and does not interact directly with the Cocoa Touch APIs.

  14. #24 by Ian Phillips - May 7th, 2012 at 10:44

    Nice write-up!

    One point though: there’s nothing to stop you using IB with RubyMotion, it’s maybe a little clunky as you can’t visually wire up IBOutlets and IBActions, but it can be done. I’ve got an example of this on GitHub and a write up of the steps needed here

    I haven’t tried using storyboard yet but it works fine for standard views.

Comments are closed.