The Rubymotion Failure

A while ago I wrote a post about my foray into using Rubymotion (RM) for iPhone development. RM is a development tool for programming in the Ruby language for the iPhone. The basic reason for this approach was that I had an Android App with a lot of non-ui code and Hipbyte's promise that Rubymotion will support Android. Therefore, I would have a single code base to maintain between the two platforms. The other reason was merely cosmetic in nature. I think Obj-C is one of the more horrendous languages around. This effort was a resounding failure.

From that post, fast forward a few months, and as of Jan 1st, the start of the new year, I have scrapped the entire Rubymotion project. A total of 5-6 months of development has come to a screeching halt. Rubymotion has been a disaster.

First off, from a old cogger developer that actually likes statically typed languages, Ruby is an atrocity. But with some discipline it could be worked. However, the mere fact that it is Ruby, makes it problematic for smallish platforms because of its memory usage. I found that Rubymotion had bizarre memory problems. Weak Reference exceptions would popup when trying to do NSCoder serializations, where I wasn't using any weak references in the object graph. That lead me to write my own text based externalization library, because the Sugarcube NSCoder strategy kept failing. Sugarcube is a Ruby Gem that makes using Rubymotion a bit more like Ruby and less than Obj-C.

Other memory problems kept creeping up occasionally. One notable one is where somehow a reference to a list of one type of object became a list of another object. Now, Ruby doesn't have any type safety, but if you are disciplined enough, you can be 100% sure that if a variable to be of a certain type, it should be just that.

I had something of the sort:

class A  
  attr_accessor :bList
  def initialize
     self.bList = []
  end
  def add(args)
     self.bList << B.new(args)
  end
  def process
     bList.each do |b|
        b.doit
     end
  end
end 
class B
   def initialize(args)
     ...   
   end
   def doit
     ....
   end
end

 In A#process, the app would crash because bList didn't contain a list of B. That was evident because the error message said that the target object didn't have a method named "doit".  A few puts statements, revealed that it was an object of a different type. WTF? The list of the other object did exist, but should have been in some other object.

To top all that, it wasn't consistent, which probably was a result of the particular memory recovery strategy they were using. Apparently, I got from the community support list that they don't use iPhone Automated Reference Counting and use something else. That is probably due to the dynamic nature of Ruby and what they have to plan on with the crazy bullshit you can do in Ruby.  This error was the most egregious one and with the group not being quite forthcoming with the problems leads to undermine my faith in the product. If you can't trust the fundamentals then what the hell are we doing. Gödel, I digress.

Other memory problems seem to be with the memory collection. I won't call it garbage collection, because the Rubymotion people seemed to vehemently avoid that term. It would seem that at the end of segment of a thread, the app would freeze up, maybe for as much as 10 seconds. One community member confirmed this problem, and could replicated using autorelease_pool.  That seem to fall on deaf ears, and the RM community guy couldn't understand why I was having all these memory problems and doubted my use of mutexes , locks, and semaphores. I'm quite well versed at concurrent programming, thank you, and instead of doing any real investigation, passed it off as a problem that I'm doing something too complicated. Really?

I actually found a problem, and did my best to reduce the problem to a minimal app to demonstrate the problem, put it on Github. The AppDelegate class would illustrate the problem. Even that was too much. Here is a response from the HipByte support site:

Hello Dr. Polar Humenn,     

A good test project usually consist of one file with the minimum amount of code that exposes the error or wrong behaviour. It would really help us if you could create a further reduced test project.     We can take a look at the unreduced test project. But please be advised that won't happen until we have gone through our backlog of support tickets.     

Thank you, 

Mark. 

At this point, I was sorry to  tell them that wasn't going to happen, and I was giving up on Rubymotion. That was Jan 1st. Time to start a new year.

So, now what? I'm using Xcode and Swift, and unfortunately, I will have to maintain two completely different code bases.  And I'm on a fast and furious programming to get it up and running using Swift. Swift is not without its own problems, but the type safety definitely helps, and it's not Obj-C. The problem is that Xcode is not Eclipse, and the syntax evaluator keeps crashing. At least it is resilient that it restarts itself, but the crashing all the time is quite annoying. The code completion, when the syntax evaluator isn't crashing, it works, albeit a bit slow. Documentation is crap. And apparently, as I wrote here, Xcode cannot refactor Swift code, only Obj-C.

I'm a registered  Beta user for RoboVM which is a Java product for the iPhone out of Sweden, but I haven't had the courage to fire it up. Right now due to this failure, time has become critical.

Cheers,
Dr. Polar Humenn