Plans for RubyMotion

by: Aaron Lasseigne

Amir and I have talked a lot about what we want to do with RubyMotion. Outside of the upcoming branding switch to DragonRuby, we haven't said too much about our other plans. I wanted to take a minute and run through what's at the top of the list. I can't give a true timeline yet because Ryan and I are still getting our feet under us and honestly, we're just not sure how fast we can move yet.

The Great Detangling

RubyMotion was originally designed to be a closed source solution for using Ruby to build applications for Apple platforms. The RubyMotion product included a Ruby compiler, support for using Ruby to write Objective-C, and tooling for writing applications. All of this was written with the idea that it would only run on a MacBook. Android support was added into the mix increasing the complexity of each of those pieces. If the plan was to continue the status quo, what we have would be fine. We don't want to stick with the status quo.

We want to open source some pieces of the RubyMotion product. Which pieces is still a discussion we're having. What we know though, is that we can't open source any of it if everything is tied together. We need to start detangling all these parts.

By splitting the product into parts, we create components that can be reused and composed in different ways. We also give ourselves the opportunity to open source pieces of the system. All three of us are open source advocates but we're also realists. We need to make sure that we're responsible in how we approach open source. This is not a small or simple codebase. It'll require paid individuals to help it succeed.

Better Support for Android

Our Android support is not where it should be and we need to improve it. That's the hard truth. We've not kept on top of the tooling surrounding Android like we should have. We need to make sure newer NDKs, SDKs, and platform tools are supported. It may be best practice to stay a little behind in order to support the widest variety of devices but that doesn't mean you shouldn't be able to use the latest if you want.

Newer Ruby

The RubyMotion compiler supports Ruby 1.9. Given that Ruby is on 2.6, we're a bit behind. This creates two major problems. First, you can't use new syntax and features that we all want. Second, it limits the ecosystem of gems available in a pretty significant way.

Part of the hurdle here has been that RubyMotion has a special syntax for Objective-C arguments that conflicts with the implementation of keyword arguments in Ruby 2.0. To resolve this, we're going to have to change how we handle these arguments. Ruby 2.0 was also a big release for Ruby with lots of changes. It's not trivial to implement everything that's been added.

The good news is that after 2.0, the changes are more managable and should be easier to add (with the possible exception of refinements). We need to do the hard work of getting unstuck so that we can start to keep up again.

What About...

We've gotten a lot of requests for various features. What you see here is our top priorities. It's not everything we want to do but we don't have infinite time so we have to make choices. If there's something you don't see here don't think we're ignoring it. It might just be further down the timeline.

DragonRuby

Our goal is to reignite the fire under RubyMotion and expand outside of the mobile world. We decided that RubyMotion needed a rebranding. A new life. It needed room to grow and a new name to go with it.

With Amir's announcement at Ruby Kaigi, we've shown an example of where we can take Ruby. The DragonRuby Game Toolkit allows you to build cross platform games. It brings the joy of Ruby to a whole new group of developers.

Right now the DragonRuby Game Toolkit uses mruby under the hood but once we fully extract our compiler, we'll replace mruby. It shows that we can begin extending Ruby into other areas of development and onto new hardware. It's a step toward making our compiler more generic.

We still have some work to do but RubyMotion as you know it will be rebranded as the DragonRuby Mobile Toolkit. Ultimately our Game Toolkit and Mobile Toolkit will both run on the DragonRuby compiler and will share a lot of other code under the hood. Updates to one will benefit the other.

We're working on a new website that will showcase both toolkits. It'll be hosted on dragonruby.org and will also include a better experience for our current users who want to manage their account. We're really excited about all of these changes and we hope you are too.

If you have questions feel free to reach out to me on the Motioneers Slack channel.