Transposing An Existing XCode Project to Rubymotion For the last two weeks I've been working flat out with Rubymotion, a new toolchain that allows developers to build native iOS applications using the beautiful, elegant Ruby programming language instead of the verbose and somewhat fussy Objective-C programming language. The app I've been working on is an existing client app we've been developing for several months. The app was about 80% ready for a pilot launch but still had quite a bit of development to go before being shipped. After discussing Rubymotion with the client, we agreed that it would save us both time and money in future development if we move over to Rubymotion. I was tasked with doing the migration; transposing the entire application to Rubymotion. Timescale For those of you looking to do the same, here are some stats that might help you estimate the time required and the costs involved. The migration took me twelve full working days; around 96 -> 120 hours which is a little longer than I had expected. Part of this time was learning the nuances of Rubymotion though, and a lot of it was debugging (I had some issues with TestFlight which caused the app to fail silently instead of raising exceptions. I lost about a day debugging that)! If was to do it again now I reckon it would take me 2/3 of the time. App Size and Lines of Code The app consists of 23 ViewControllers, 12 Models, 17 custom View Classes (mostly table cells), 3 class extensions and about 11 other custom classes. So here are the stats for the app before and after: Language/Tool Lines of Code Number of files Ruby/Rubymotion 5604 68 Objective-C/XCode 5292 138 Just to be clear, the lines of code here do not include 3rd party libraries or config and settings files automatically created by either tool suite. The lines of code counted here are all lines written by me, not including white space or blank lines. The same applies to the number of files. Each file counted here is a file I've created with the exception of the app delegate files. So at first I was a little shocked at the lines of code. Ruby's a far more succinct language than Objective-C but yet the number of lines of code was higher in the Rubymotion project than the XCode project. The explanation is that in Rubymotion I haven't used Interface Builder. Instead, all of the views are built programatically within the view controller files. While it is possible to use Interface Builder, I prefer not to. Losing Interface Builder was actually my biggest reservation when I first saw Rubymotion but since I've started building my own views programatically I prefer it. I feel it gives me more control over the view elements and more awareness about how they are nested, aligned and configured. Granted, this is not everyone's preference though. ❤❤❤ Things I love about Rubymotion ❤❤❤ Here's what I love about Rubymotion so far (to name just a few things): Faster development time The most important benefit of Rubymotion is that it's faster to write code and to change existing code. When working with new apps that are prone to change a lot as more and more stake-holders throw in their 10c this is a huge advantage. Getting a prototype up and running, or a MVP to market is now faster and this should encourage development and innovation of some exciting new products in the App Store. I Can Haz Modules! My single biggest bug-bear with Objective-C is that there are no modules or mixins. This usually means that the same code is written a bunch of times in different places, meaning that changes to the code become more and more costly as the app grows. Ruby's modules offer a great way to mix in code shared across various classes and they're supported in Rubymotion (although it's still not 100% perfect yet). Ruby-Style Selector Short-cuts Rubymotion offers shortcuts for various Objective-C selectors, the most helpful of which being the objectForKey and setObject:forKey: # objective-C NSMutableDictionary *myOptions = [[NSMutableDictionary alloc] init]; [myOptions setObject: @"value" forKey: @"key"]; [myOptions objectForKey: @"key"]; # => @"value" # Ruby myOptions = {} myOptions[:key] = "value" myOptions[:key] # => "value" These are a godsend and a huge help both when writing and reading code. Protocols are handled automatically In Objective-C, to make a class conform to a specific protocol you have to define this in the class's interface. This can get quite tedious to keep track of, especially when you have a class that conforms to several protocols. Since protocols are not a feature of Ruby, all of this is done away with. Description is no longer a reserved word! In Objective-C (well, Cocoa), description is a reserved word. If I give a class a property named description it will crash when I run the code. Given that this is such a common word for a model attribute, I always thought that was a pretty dumb word to reserve. Thankfully this is not an issue in Rubymotion. I can use TextMate XCode is clunky, and temperamental and crashes constantly. With Rubymotion I get to use any text eitor I like. My preference is TextMate! There's also a Ruby Motion Bundle for TextMate! Things I'd Like To See In Future Versions Rubymotion is still in it's infancy and is likely to change a lot over the coming months/years... More Opinionated File-Structure Apps can get pretty huge! The app I've mentioned in this post is currently at 68 files and that's likely to grow! Most developers will split these files into sub-directories based on the file's role. As a seasoned Rails developer, I instinctively opted for the following rails(ish) structure: app/ controllers/ models/ views/ lib/ While it doesn't have to be my preferred directory structure, I'd like to see Rubymotion start to be more opinionated about how to approach things like this. This would have two advantages: It's easier for new developers to learn the ropes when there are standard practises in place. It's easier to work with another developer's code when things are laid out as you expect them to be. Generators for common file types I'd also like to see Rails-like generator scripts for common class types in Rubymotion. For example: $ motion generate table_view_controller my Which would generate app/controllers/my_view_controller.rb with the following template: class MyViewController < UITableViewController def viewDidLoad # do something ... end # == UITableViewDelegate == def tableView(tableView, heightForRowAtIndexPath: indexPath) tableView.rowHeight end def tableView(tableView, didSelectRowAtIndexPath: indexPath) # do something here... end def tableView(tableView, viewForHeaderInSection: section) end # == UITableViewDatasource == def tableView(tableView, cellForRowAtIndexPath: indexPath) # return a table cell end def numberOfSectionsInTableView(tableView) 1 end def tableView(tableView, numberOfRowsInSection: section) 10 end def tableView(tableView, titleForHeaderInSection: section) "My Section" end end This would be a huge help! Decoupling Views from Controllers While I do prefer writing views programatically, I don't like defining so many view items in my controller - I think this violates the principle of MVC. I've seen one proposed DSL for creating view classes in Rubymotion which would be an interesting one to watch. Better Error Backtrace While the error backtrace in Rubymotion is OK, it's not awesome. For example, sometimes the error messages are cut short of the line number. Other times they're just not that descriptive at all. It would be really great if we could get a little more feedback in the console as to what's happening when the code raises an exception. Console log when running on a device At the moment you can build your app to a device but you can't yet see the console log output while the app is running on your device (as is possible with Xcode). If it is possible to do, this would be really useful too as I much prefer using a real device over the iOS Simulator. My Verdict I love Rubymotion and plan on using it on all of our upcoming iOS projects! Moving our client's app from Objective-C was a bit of a mission and took a lot longer than I though but, given that it should save us a lot more than two weeks of work in future, I think it was the right decision in this case. It means I can now respond to the client's feedback quicker and more comfortably!