Mruby and MobiRuby

If you want to learn how to develop iOS apps, then you should learn Objective C. I'm a Ruby developer and as much as I love the language, when I decided I also wanted to write iOS apps I bit the bullet and started learning Objective C. In the process I've found that learning Objective C is actually pretty easy - as the author of this post points out, it's CocoaTouch and the overall Xcode and iOS ecosystem and environment that takes time to learn.

This is fairly analogous to learning Ruby on Rails if you know neither Ruby nor Rails, although because I had experience with curly-brace/semicolon languages and pointers (a bit of C, plus PHP and Javascript) I found that learning Objective C was easier for me than learning Ruby. But just like Rails is a steep mountain to climb, so is CocoaTouch.

However, learning Objective C and CocoaTouch has been fun, enjoyable, enlightening, and well worth it. As the old saying goes, if something is worth doing, it is worth doing right. If you believe developing iOS apps is worth doing, then do it right with Objective C. You won't regret it, and by adding another language, framework, and way of doing things to your toolbelt, you'll become a better Ruby programmer too.

A quick look at the MobiRuby example code worries me. It looks like Objective-C, but awkwardly written using Ruby syntax. In other words, it looks more like an Objective-C wrapper, than a Ruby DSL for writing iPhone apps.

However, with plans to port the system to Android, perhaps a unified DSL could be built to target both platforms.

There's a larger point in this post about using frameworks with the language they were designed for. Using another language to wrap a language you don't like to use a framework is often extremely limiting and awkward.

As a developer trying to get things done, I'm far more productive if I bite the bullet and learn the language the framework was designed for rather than bend the framework to fit my favorite language. I've found this to be true across mobile, web and pure backend server technologies.

As long as you can still reach the APIs you need 100% of the time, there's nothing wrong with the abstraction. Ruby is a huge timesaver over Objective-C... this is obvious in the syntax. The ability to create apps that run on anything but are 100% written in Ruby will be a huge step forward for the language. So that's why I think it is Matz working on this.

I see a great future for this - hopefully will get more users hacking on embedded devices with Ruby codes (ruby + Arduinio or even Routers - e.g. OpenWRT).

Quick glance in the Make file, sees runtime libraries for Win/gcc/iOS - should be able to build an arm exe easily.

Very interesting post. It hints are some serious architectural differences between MacRuby and MobiRuby. It'll be interesting to see if these differences limit the ability of MobiRuby to create a usable way to work with Cocoa in ruby.

All fair points that I agree with. Mruby is promising but it's still in its infancy. Whereas MobiRuby is interesting on its own, but lacking advantages over Obj-C for real development.

I'd be very interested to see what this "incremental garbage collection" Matz talks about does to battery life.

Also, what's up with all the underscore methods in MobiRuby?

I want to see redis with mruby scripting instead of or also with Lua scripting, one day.