RubyMotion Goes 2.0 And Gets OS X Support, Templates and Plugins
It has been exactly a year since we launched RubyMotion. Yep, this is right, RubyMotion is one year old!
We released over the year a total of 35 software updates fixing countless bugs reported by our beloved users. That’s almost 3 updates per month on average!
We shipped significant features such as creating static libraries, debugging support (on both simulator and device), API reference documentation browser, automatic file dependencies, and more. We also shipped support for iOS 6.0 and the new iPhone 5 architecture right after their announcements.
We did not expect the RubyMotion community to grow that fast. In just one year, we got exhaustive wrappers, professional screencasts, a couple books, and we even organized our very own conference!
We now believe it is time to focus on the second phase of our roadmap, which will essentially consist of introducing new innovative features on top of our toolchain as well as targeting other platforms.
Today, we are shipping our first 2.x release. We still have quite a bit of road to clear up our roadmap but we believe we are on the right path.
OS X Support
RubyMotion is now supporting Mac application development. You can create OS X apps using the same toolchain you already know. We ported our static compiler, command-line interface and interactive shell (REPL) for OS X application development!
RubyMotion OS X apps are statically compiled to Intel 32-bit and 64-bit architectures, include our custom ARC-inspired memory management system, weight less than two megabytes and do not require any 3rd-party dependency to run.
The build system also supports OS X v10.7 and v10.8 as deployment targets and includes an archive Rake task for distribution. 3rd-party projects can be vendored using the updated motion-cocoapods gem.
The documentation in our developer center has been updated for OS X. We have also been adding a few OS X samples to our sample code repository, check them out! We will be adding more samples soon, feel free to contribute some too.
Finally, we are also happy to report that popular RubyMotion libraries such as Bubblewrap, Teacup and Joybox have been ported to OS X. We hope that other libraries will also be gradually ported to this new platform.
As you may know, RubyMotion is an improved version of MacRuby, an implementation of Ruby for the Mac that we started in 2006 at Apple.
A lot of MacRuby enthusiasts supported us when we launched RubyMotion a year ago, and RubyMotion OS X support has been a consistent feature request over the year, since day 1.
Today, OS X support ships to all RubyMotion customers, for free. This is our birthday gift to you guys, thanks for your support!
RubyMotion now exposes functionality to let users chose a template when creating a new project, by passing a value to the —template argument of the motion create command.
RubyMotion comes with 3 builtin templates: ios (the default one), osx and gem, which will respectively create a RubyMotion iOS, OS X or RubyGem project.
For example, to create a new OS X project named Hello:
$ motion create --template=osx Hello
Create Hello Create Hello/app/app_delegate.rb Create Hello/app/menu.rb Create Hello/Rakefile Create Hello/resources/Credits.rtf Create Hello/spec/main_spec.rb
3rd-party templates can also be installed into the ~/Library/RubyMotion/template directory.
We expect certain RubyMotion gems to make use of the system to provide richer project templates that include specific integration code. As an example, the Joybox team is looking into making a template that includes a game skeletton.
Similarly to the template system, RubyMotion now exposes a way to add new commands to the motion command-line tool, using plugins.
Builtin commands, such as create, update, support and ri, have been extracted as plugins. 3rd-party commands can also be installed into the ~/Library/RubyMotion/command directory.
RubyMotion gems can now extend the motion command with their own actions, for example custom code generators.
Common Build Directory
The build system has been improved to use a common build directory when compiling external project files (ex. gems).
This makes build times faster as gems will not be recompiled every time the project configuration changes, or when multiple RubyMotion projects are using the same gem.
RubyMotion now exposes a way to let users create weak references. For convenience reasons, we implemented the WeakRef class which is also present in the standard Ruby library.
Weak references can be used in order to prevent cyclic references. A good example is implementing the delegate pattern.
class MyController def initialize(delegate) @delegate = WeakRef.new(delegate) end def do_something # ... @delegate.did_something end end
Objects passed to WeakRef.new will not be retained, and any message sent to a WeakRef object will be forwarded to the passed object.
For performance reasons, WeakRef objects are recognized early by the method dispatcher. The WeakRef class in RubyMotion cannot be subclassed.
We expect the RubyMotion memory management system to be able to deal with cyclic references in the future. In this case, the WeakRef class will be replaced by a no-op.