RubyMotion is a new (commercial) way to develop apps for iOS, this time with Ruby. So why do I think this is better than the traditional way using ObjectveC or other alternatives?
Advantages to other alternatives
Other alternatives often use a wrapper or a different runtime. The problem is that you have to wait for the library/wrapper vendor to include new APIs when iOS gets a new update. RubyMotion instead has a static compiler which compiles to the same code as ObjectiveC. So you can use the myriads of ObjectiveC libraries or even the interface builder. You can even mix your RubyMotion code with existing ObjectiveC programs. Also the static compilation gives you the performance advantages of real native code so that you don’t suffer from the penalties of using another layer. So you could write your programs like you would in ObjectiveC with the same performance and using the same libraries, then why choose RubyMotion?
Advantages to the traditional way
First: Ruby. The Ruby language has a very nice foundation: everything is an expression. And everything can be evaluated with logic operators (only nil and false is false).
In ObjectiveC you would write:
cell = tableView.dequeueReusableCellWithIdentifier(reuseId);
if (!cell) {
cell = [[TableViewCell alloc] initWithStyle: cellStyle, reuseIdentifier: reuseId]];
}
whereas in Ruby you can write
cell = tableView.dequeueReusableCellWithIdentifier(@reuse_id) || TableViewCell.alloc.initWithStyle(@cell_style, reuseIdentifier:@reuse_id)
As you can see you can use the Cocoa APIs right away. But what excites me even more is the community which builds around RubyMotion. RubyMotion is only some months old but many libraries and even award winning apps have been written. Some libraries wrap so called boiler plate code and make it more pleasant you to use. Other introduce new metaphors which change the way apps are written entirely.
I see a bright future for RubyMotion. It won’t replace ObjectiveC for everyone but it is a great alternative.
Schneide Blog 
I agree that it is a great alternative but you always have to remember:
Learning Objective-C is easy. Learning the frameworks is hard. RubyMotion does not free you from learning the frameworks.
And to put things into perspective you should mention that you are obviously a beginner when it comes to Objective-C – right?
1. Your nil-check and the creation of your cell-instance should not be needed when using modern UIKit techniques.
2. You could do more or less the same by using the ternary conditional operator (?).
3. If you are not writing your code in Objective-C you can’t use Xcode’s static code analyzer directly. You would have to apply the analyzer on the output of RubyMotions static compiler.
4. You can’t use Xcode’s refactoring tools.
5. You cannot use LLDB – only GDB for debugging.
6. RubyMotion is not available for OS X. You are writing tons of code that has nothing to do with iOS but you can’t easily use this code in an OS X app…
You are right. Learning a language like Objective-C is easy. Cocoa and all the other frameworks and the runtime are the hard part. And yes I am a beginner in Objective-C land.
1. Maybe this wasn’t a good example, but for modern UIKit techniques you would need the help of Xcode and bindings or am I mistaken?
2. Yes, you could. But IMHO the fast circuit or operator is more true for what happens here. (but that’s just personal taste)
3./4./5. Yes, you lack in tool/IDE support right now, given that RubyMotion is less than a year old this does not suprise but it looks like e.g. JetBrains are building RubyMotion plugins for their IntelliJ Idea.
6. I don’t know how much of the code can be used with MacRuby, from which RubyMotion is derived. In your experience how often do you need this? And when you need this, you could even write your code you want to reuse in Objective-C.
On the other hand what I find most interesting and exciting is the fresh wind which is coming from the community where many abstractions and new ways of building iOS apps are tested out. All in all I think it’s a different way and mentality.
Objective-C is a proven way and Xcode is a huge help. But for me and maybe many others it seems so heavyweight.
I think languages and developing metaphors are a way of thinking. When you found one environment which fits like a glove and in which you are sound as a bell you are much more productive. RubyMotion is this environment for me.
1. No. On OS X (using Cocoa Bindings) you would do it with bindings and the help of Xcode (although you could do everything also by hand). UIKit (and AppKit, since 10.7) has a way to let you register classes/nibs/xibs on a per reuse identifier basis by using registerNib:forCellReuseIdentifier: (UITableView) or registerClass:forCellReuseIdentifier: (UITableView). When using one of those methods the dequeue method of UITableView is guaranteed to return a non-nil value. The former method is available since iOS 5 and the latter since iOS 6. Storyboarding could also help in this situation if you have static tables but then you would need the help of Xcode (which is not bad at all).
2. Agreed.
3./4./5. Sure. Its nice to see companies improving these things. I am wondering: Are you using RubyMotion for commercial stuff? If so how do you profile your app right now? Isn’t it a bit risky to use such a new technology for commercial projects if (IMHO better) alternatives are available at no cost? At one day RubyMotion will have a decent profiler but Instruments can do so much more than just profiling… I wonder if they ever manage to develop something nearly as powerful as Instruments.
6. Everything UI related is not really reusable but the remaining things are: The model layer, the whole business logic, the network layer etc. Its very easy to see if the code you write right now is or should be platform independent: If you are only using frameworks which are available on both platforms then the code you are writing should be platform independent as well. Example: Your method is modifying an image (CIImage, using Core Image) and is storing it using Core Data. Your method is using Core Image and Core Data; both frameworks are available on both platforms. My implementation of this method would be platform independent and yours not (assuming you don’t want to use the code generated by RubyMotion as is). I am sure that sooner or later we will see RubyMotion for OS X (it is a no-brainer) but then again: Why this dependency in commercial projects?
By the way: It seems that Ruby is incompatible with the whole error (NSError) management of Foundation. You usually pass a reference to an NSError * (a NSError * *) to a method, check some return value and then access the pointer value. In RubyMotion you always have to manually create a new Pointer instance by calling Pointer.new… This is a tradeoff you have to make everywhere, every time.
Sure. Fresh minds are always welcome. 🙂 Let’s see how RubyMotion looks like in 2-5 years from now…
First: thank you for taking so much time to comment I appreciate it.
About the tools: maybe there is another way, can’t Xcode and other tools be used with plugins? This could be a way to get RubyMotion support.
Instruments uses DTrace under the hood which can be used with any process (some seem to got it working). So maybe this works out of the box. I have to try it out.
We do not use RubyMotion in commercial projects right now and yes it is an additional dependency which could be a blocker (depends on the client and the project).
The NSError problems: you could write a helper which wraps this.
Xcode never had an official plugin API. Since Xcode is distributed via the Mac App Store Xcode should not be able to load code (loading a (native) plugin means loading code). Maybe Apple made an exception for Xcode – I don’t know. But I don’t think Apple will ever introduce a plugin API for Xcode. Yes – Instruments is using DTrace and you can feed it your own probes. I am not sure how practical this is since you don’t have a direct mapping between your Ruby code and the generated Objective-C code or am I wrong? In theory it should not be possible to have a direct mapping between MotionRuby code and the Objective-C code which is needed for debugging/profiling… Of course I could be totally wrong about this.