Having written two RubyMotion iOS apps, it became clear that it was time to put down some thoughts on using RubyMotion in anger. RubyMotion changes the iOS development toolchain to a Ruby like language and a bunch of tools that all run from the command line. It moves the focus of iOS development from XCode to Vim/Emacs/editor of your choice. And significantly improves the readability of the git log and makes it easier to reason about iOS code in general.
When you use Vim every day for roughly 12 - 16 hours per day it becomes second nature. When asked to switch to another environment, it is like going back to learning to walk as a toddler, even when you know how to run as an adult. Trying to build something in XCode feels like this and even though the outcome is an amazing app the process is like wading through molasses. Languages aren’t very scary compared to having to switch environments. RubyMotion allows a Ruby programmer to stick to the toolchain that they have spent the last few years with. And in most cases provides a joyful environment to do so.
Being a stickler for the story that a git log presents means that project files and nib files ruin a development environment. Particularly when they can change just by opening them. Rails has a similar problem with schema.rb where running a migration will re-order or adjust the spacing for schema.rb even though you weren’t the user who created it. The only reason I commit these files that are autogenerated is because of convention in the community. If these files go away then it is a massive improvement for the readability of the git log because doing
--stat doesn’t end up listing files that aren’t integral to the commit.
Promotion, Motion-kit, Sugarcube and Bubblewrap are great libraries. They make building iOS apps much more convenient. More libraries in this vein for
Objective C/Swift would greatly improve the composability of apps. There are some choices around Ruby constructs that aren’t great in these libraries so they are far from perfect. But the spirit is great.
The community of RubyMotion developers is intimate and hungry for people. This has the benefit of people who are eager to help and make things better but suffers having less content to other communities.
Giving RubyMotion a try has been a surprising experience that has torn down the barrier to shipping iOS apps that are functional, fast and have code that is pretty easy to reason about. If you are someone that uses Vim/Emacs and spends a lot of time in the console, you will find RubyMotion matches your way of working more than the traditional ways of developing iOS apps.
As an aside, trying to adapt RubyMotion’s project/build management to Swift so that you can write Swift without XCode/AppCode is a very interesting approach that could change the way a lot of developers write iOS apps.