On Why I Am Not Buying RubyMotion
RubyMotion is a recently released tool which allows to create native iOS applications using Ruby. It was made by Laurent Sansonetti, an ex-Apple employee, also leader of MacRuby. RubyMotion enables to develop native applications by skipping Xcode and using commands from the terminal to compile, run and even submit the application to the store.
I like Ruby and the way it is easy to work with. I personally use ruby in many projects, mostly on the server side. I am not a lover of Xcode. Yet, RubyMotion is not for me.
Whenever I see a third party tool I ask myself: how quickly it will be updated to the last SDK version? Say Apple releases a iOS6 today. Will an aligned version of the tool be ready today? If not, when? One day would be fine, one week would not. And then I keep going: am I ready to run such a risk? What will I tell to the client? “Oh look, we have to wait one week for technical reasons”. For every project I have taken on I have never had the guts to run such a risk. Even if somebody promises that I’ll save 50% of code and money, I don’t like to have unneeded dependencies. Xcode is not like heaven but it is decent enough to build what I want. Using a third party tool is like gambling: you might win or loose but you don’t know in advance. In this respect RubyMotion has a bit different approach in that it “links” to the SDK. This means that if the iOS6 includes news classes, those should be available in RubyMotion, provided that you download the new SDK and “link” it correctly to RubyMotion. To some extent, RubyMotion is a “language layer” around the SDK, so it should not suffer from this issue. Still I am not convinced. What would change my mind is the possibility to generate a full Xcode project with Objective-c code. And I see this is not the case. In that case I’d feel more secure, provided that the generated code is humanly manageable.
If you wanna invest on a platform it is worth to learn its “official” tools. If you stumble on an issue and you don’t know what’s under the hood it is likely you’ll need much more time (possibly all the time you have saved in advance by using the tool) to find out a way to fix it or a workaround. If you are working on a product of yours maybe you can postpone the deadline or find the right justification for your users. If you are doing client work on the clock, either you are creative and convincing with your excuses or you are in trouble.
I like to have control on the things I build. Xcode and its ecosystem give me access to every aspect I am allowed to work on. A third party tool like RubyMotion doesn’t give me that feel of control. I have spent much time with Xcode and the official way of doing things. I feel at home, not the best home, but home. If RubyMotion wants to “steal” users to Xcode it won’t probably succeed but if it wants to bring Ruby developers to iOS then it is probably going to.
RubyMotion is not a way to avoid Objective-c. Maybe you will not write it, but you have to be able to read it, because RubyMotion is hooked to the same runtime and Cocoa API. Guess which code you’ll see when you open the documentation? Unless RubyMotion is going to “port” all the huge Cocoa documentation (which is copyrighted) in Ruby format you definitely have to be able to read (thus learn) Objective-c. In this perspective RubyMotion just saves you some typing but does not allow you to skip learning Objective-c and Cocoa API. And no, there is no tab completion at the moment.
The last is a philosophical disquisition. There is a thing I have learned working on Apple tools and developing applications for such a platform: it is better to stay with them all the way. I don’t wanna sound ‘conservative’ but by following the official way I never had to rewrite code, restart a project from scratch, been off from the store, found version incompatibilities, etc. Plus, the iOS/Mac community is very supportive, a feature which I have not always found in some Ruby circles.
I am open to change my mind, but all the posts pro-RubyMotion I have read so far provide superficial examples on how things seem to look simpler. More than happy to check a real project developed in RubyMotion and its Objective-c counterpart to analyze readability, code length, etc. and draw more informed conclusions.
Happy to discuss it on twitter
ps: A few curiosities. If you skip XCode how are you supposed to set up configurations of iCloud, push notifications, iAds, game center?
ps2: How cool would it be to have a REPL console like the one in RubyMotion on the Xcode console?
Ongoing discussion on Hacker News.