What Excites Me About RubyMotion

RubyMotion made a splash when it came out four months ago. But summer wanes and winter is coming, so where are we now? By far, the most exciting change has been the growth of the community and what it's cooking.

From my perspective, RubyMotion libraries have gone through three waves. The first are very thin shortcuts for the original Objective-C functions; mostly, these are to reduce keystrokes and add a bit of Ruby flair. They're low-hanging fruit, and BubbleWrap has them in spades:

# NSSearchPathForDirectoriesInDomains...
App.documents_path

# NSBundle.mainBundle.resourcePath
App.resources_path

# NSNotificationCenter.defaultCenter
App.notification_center

These are nifty, but not a huge win over Objective-C; we get a little more unique with the second wave of new libraries. These abstract entire classes and frameworks into idiomatic Ruby wrappers. A lot of the vestigial Objective-C paradigms (delegation, protocols, selectors) don't make sense in Ruby and having a layer of abstraction hiding these details is a step in the right direction. For example, check out how BubbleWrap handles using the front-facing camera:

BW::Device.camera.front.picture do |result|
  p result[:original_image]
end

Clean, right? No dealing with UIImagePickerController or its protocol. Twittermotion uses a similar structure for composing a tweet with the iOS native interface:

Twitter::Composer.compose(tweet: 'Hello RubyMotion!', urls: ["http://clayallsopp.com"]) do |composer|
  if composer.cancelled?
    # user didnt sent the tweet
  elsif composer.done?
    # user sent the tweet
  end
end

Most of these wrappers are probably implementable in Objective-C, but they are tremendously easier to grok at-a-glance for Rubyists and any others just beginning iOS development.

At this point, it would be understandable if you still didn't think RubyMotion merited its $200 price tag. But before you close the tab and move on, there's one more wave of RubyMotion libraries: those that invent completely new metaphors for development.

What do I mean by new metaphors? These libraries do more than just wrap the standard iOS SDK: they turn it on its head and allow us to express ourselves in novel ways. Take Teacup, which lets us separate our layout and style logic into Stylesheet objects:

Teacup::Stylesheet.new(:menu) do
  style :root,
    landscape: true

  style :menu_item,
    left:   0,
    top:    0,
    width:  160,
    height: 160,
    landscape: {
      width: 240  # make it wide in landscape view
    },
    title: 'Menu'
end
class MenuController < UIViewController
  stylesheet :menu

  layout :root do
    @menu_item = subview(UILabel, :menu_item)
  end
end

Instead of spending dozens of lines doing frame calculations and positions in our controllers, we can separate these parameters into a smarter object. Given how thick iOS controllers can become if unmanaged, it's a major boon for when you need programmatic control of your views. Plus, since Stylesheets are normal Ruby objects, perhaps we could dynamically create them from a server configuration or let the user tweak them to as preferred.

Formotion is another "new metaphor" library; it allows you to declaratively construct complex and interactive views. Although you can create standalone form-based layouts like the Settings and Contacts apps, views can also be constructed using just a model's definition. This lets us prototype screens in an application's flow incredibly quickly, like this little example:

class User
  include Formotion::Formable

  form_property :name, :string
  form_property :score, :number, transform: lambda { |value| value.to_i }

  form_property :team, :picker, items: ["Red", "Blue", "Green"]

  form_title "Edit User"
end
user = User.new("Harry", 100, "Green")
controller = Formotion::FormableController.alloc.initWithModel(user)
self.navigationController << controller

Formotion

Pretty incredible that I can construct a non-trivial UI with only what, a dozen lines of code?

And these libraries are just the start of a wholly new way of looking at how we structure and develop mobile apps. This is why I keep pushing myself to create with RubyMotion, as to re-think the status quo of the past five years. iOS development has come a long way since 2008 and there's absolutely nothing wrong about the current APIs, but Ruby seems to help developers frame tasks in new a new and often revealing light.

So is it worth the price tag? For some, still maybe not quite yet. But what just the past few months have shown is a window into something fresh. And to me, that's just plain exciting.

This was adapted from a talk I gave at an SF Bay RubyMotion Meetup