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.

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…

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.

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…