RubyMotion Blog

Avatar

This is the official blog of RubyMotion, a toolchain for iOS, OS X and Android development that lets you do iPhone, iPad, Mac and Android apps in Ruby.

Follow us on Twitter to stay tuned with everything that's happening in the community!

Not a RubyMotion user yet? Give it a spin today!

Announcing the public Beta of RubyMotion for Android

We are super excited to announce that RubyMotion for Android is now available in public beta.

Since its introduction in May, during our annual developer conference in San Francisco, we have been working extremely hard on RubyMotion for Android, with the goal that it should be usable by early adopters.

While functional and relatively stable, RubyMotion for Android is still not ready for prime time yet. However, we do believe that it can be used by seasoned developers and we hope that we will receive enough feedback to polish the product enough that it can be used by everyone.

Availability

The RubyMotion for Android public beta is free for all customers.

Getting started

After applying the latest software update, you can install the beta by using the following command:

$ sudo motion update          # make sure you have the latest update
$ sudo motion update --pre    # install the pre-release beta

Please follow the Getting Started guide for more information on how to set up a proper Android development environment.

Features

RubyMotion supports the following versions of Android: 1.5, 1.6, 2.1, 2.2, 2.3, 3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 4.3, 4.4 and L (latest).

RubyMotion for Android apps are statically compiled into ARM machine code using our ahead-of-time (AOT) compiler. Both armv5te and armv7 architectures are supported by the compiler.

The RubyMotion for Android runtime features a brand-new implementation of Ruby, based on Java. You get to call into the entire set of Java APIs. Check out the Runtime guide for more information. Both Dalvik and ART runtimes are supported.

The command-line interface features a REPL (interactive console) that works on both the Android emulator and a USB-connected device. This works by doing remote JIT compilations from the Mac to ARM.

RubyMotion for Android apps can also vendor third-party Java libraries (jar files) and can be submitted to the Google Play store.

Make sure to check out the Android samples from our repository.

Our friends at MotionInMotion are working on RubyMotion for Android screencasts. Stay tuned!

Future work

Here are the things we will be doing in the soon future:

  • Performance work; at this stage all optimizations are disabled and a lot of logging is going on (for debugging purposes). Don’t try to benchmark it.
  • The runtime is still missing a lot of builtin Ruby classes and methods.
  • A Mac computer is required. Some of you guys have been asking for Linux support, if there is enough demand we might consider it.
  • We will provide builtin support for the other Android APIs (such as Android Wear, Android Car, etc.).

We need your help

RubyMotion for Android is still a beta at this stage. Please give it a try and report bugs to us. Your help will be essential to help us make RubyMotion for Android ready for everyone. Also, please keep in mind that this is a beta, bugs are expected!

Enjoy!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion #inspect 2014 Wrap-Up

This year’s RubyMotion conference was immediately followed up with WWDC and then Google I/O, so we’ve hardly had a chance to sit back and reflect on all the exciting news that emerged from #inspect!


The Fort Mason Center

As much as we enjoyed cramming 150+ people into a tiny room last year, we decided that maybe a little more leg room wouldn’t go unappreciated:

This year’s conference was at the historic Fort Mason Center, near Fisherman’s Wharf. If you need to plan an event in San Francisco, put this one on your radar. The view of the marina and Golden Gate Bridge was a very pleasant back drop.

Food and Libations

This year’s catering was amazing, in keeping with the traditions set at #inspect 2013. We should all take a moment to thank Todd Werth and Ken Miller from InfiniteRed for organizing the catering, which was provided by Local Mission Market.

For the after party we invited Rogue Brewery to share five of their popular and most delicious beers, and no one (yes, even Laurent) left disappointed. Turns out that tasty food and tasty beer go a long way towards a successful conference!

Knowledge was Dropped

It’s fun to play with new gems, but you won’t get far if you don’t know what the operating system is capable of. This years’ speakers had a ton of information to share with us.

Mark Rickert has been sharing great marketing tips in the RubyMotion Dispatch. He had even more advice for us, including some of his own successes for context. Wearing the marketing hat doesn’t need to be painful, and it’s essential for the success of your apps. (slides, video)

We heard about the trials and tribulations of CoreData from Lori Olson. She needed to import tens of thousands of records into her app, which it turns out is no small task! Core Data can handle it, but handling Core Data is another matter. (slides, video)

To help wrangle that behemoth of a library, Ken Miller created CoreDataQuery and ruby-xcdm. It’s not just a DSL around CoreData, it produces the same XML files that are created from Xcode’s GUI. This means that it has feature parity with the traditional Xcode tools, in particular migrations are supported. (slides, video)

Jack Watson-Hamblin creates the MotionInMotion screencasts, and he has some great advice for anyone who wants to learn and help: teach! It’s never too early or late to share what you have learned. (slides, video)

For anyone interested in game development, Will Raxworthy showed us how incredibly easy it is to build a game with SpriteKit and RubyMotion. He built the entire app before our eyes, with gravity and collision detection, all in a simple to understand object-oriented framework. (slides, video)

Dave Lee is a core contributor to the ReactiveCocoa project, which is at the same time powerful and daunting. Dave showed us what a RAC refactor looks like, and how you can benefit from the reactive code style. (video)

On the more practical side of things, we watched Dennis Ushakov demo the RubyMotion features that are baked into RubyMine. It’s not just for Rails! Debugging, refactoring, and code-aware autocomplete are all available. (video)

There’s a ton of money to be made in the under-served enterprise arena, and Kevin Poorman showed us just how easy it is to make apps that cater to that community, using SalesForce as an example. (video)

When Alex Rothenberg started developing in iOS he quickly realized that “Cocoa is no Rails”. It’s verbose, obtuse, and also verbose and verbose. Something had to be done, and Alex shared ideas about how Ruby paradigms can fit nicely in Cocoa. (video)

We heard from Ivan Acosta-Rubio about his successes (and frustrations!) working with (and wrestling with) the AVFoundation framework to produce images and video. Turns out it’s easy, once you understand the players. (video)

We had a TON of fun watching Mark Villacampa control a tiny robot from his phone! Mark discussed the various iOS-to-hardware communication options that are available. (video)

Testing junkies were happily sated with Isaac Murchie's demo of Appium. It takes iOS testing into the cloud, making it much faster and thorough than what you can accomplish with good ol’ rake spec. (slides, video)

We also heard from three developers who are working on projects that are experiencing the kind of problem we all hope for: Success! We heard from Ryan Romanchuk from Frontback, Daniel Dickison from BandCamp, and our own Colin Gray from Jukely. With Gant Laborde asking questions (and fielding questions from the audience), we discussed how we chose RubyMotion, how we test our apps, and what we do to make sure we’re shipping solid applications. (video)

Gems were shared

What a productive year it’s been for the RubyMotion community! I don’t have the space here to gush over all the gems and features that were featured or released at #inspect, but here are some that stand out:

Clay Allsopp demoed some of the build tools have been created at Propeller. Everything from automated screenshot testing (with diffs!) to command-line based deployment tools. From start to deploy, you never have to leave the terminal! Learn about them all at Propeller’s github organization: https://github.com/usepropeller (slides, video)

From Todd Werth at InfiniteRed, the RMQ library has been expanded to include a wealth of REPL tools, a grid-based layout engine, and a documentation website that puts the rest of the WORLD’S to shame: http://rubymotionquery.com (slides, video)

Jamon Holmgren has big plans for the 2.0 release of ProMotion: more screens, a modular design, and he hinted at possible Android support! (slides, video)

Colin Gray and Jamon Holmgren have been working on a new layout tool to replace Teacup called MotionKit. Its goal is to encourage lighter controllers by moving layout, styling, and animation code into a new class: the Layout. The end result? (slides, video)

At last year’s #inspect someone asked Austin Seraphin if “automated accessibility testing” would be possible… this year it was announced! The motion-accessibility gem has seen huge updates over the course of a year. A REPL-based browser, automated testing for your specs, and of course a light, terse DSL that makes it easy to update your app with accessibility in mind. (video, article)

And joining us from Australia via Skype, Nikolay Nimshelov gave a demo of his awe-inspiring gem UnderOS, which brings HTML, CSS, and web paradigms to iOS. It’s really remarkable! (video)

RubyMotion is FAST

When we need to defend our claim that “RubyMotion is Fast”, we should thank the long-time MacRuby and RubyMotion developer Shizuo Fujita (aka Watson). Watson optimizes every aspect of the RubyMotion compiler and runtime so that our apps run just as fast as their Objective-C brethren. RubyMotion 3.0 has a ton of performance increases thanks to his work. He shared the improvements he’s been working on, including some benchmarking tools that we can all use to improve our own code: motion-benchmark and motion-benchmark-ips.

The runner up to the big announcement

We’re all really excited for the “big announcement” this year, but standing tall and proud in the shadow of that announcement is Eloy Duran’s new code-reloading tool that had everyone’s jaw resting firmly on the floor. A save, a quick code compile, and your updated code is injected into your app while it is still running in the simulator. Eloy showed us how this feature decreases the time it takes to style views and try new features. This is going to drastically change the face of RubyMotion development in iOS.

The big one

The internet was all a-buzz about this year’s big announcement: Android support is coming to RubyMotion. It has everything we already enjoy in iOS and OS X:

  • Compiles to native code, no bridging involved
  • Native Ruby classes extend existing Java classes
  • Terminal-based workflow
  • Rakefile-based project configuration
  • And best of all: the RubyMotion community ;-)

Laurent demoed some apps that he’s written that are already running. They launched immediately and ran smoothly. As promised, they have the same performance characteristics as an app written in Java. Those sample apps are available in the HipByte’s github organization.

The entire State of the Union talk, with Watson, Eloy, and Laurent is available to watch online.

Summary

Last year was all about affirming that RubyMotion isn’t just some toy that Rubyists like to play with, it’s a development tool that is powering complex consumer apps. This year showed that not only has that trend continued, but it’s grown at an accelerated rate! We’re more productive and having more fun than ever.

We’re entering the Android arena at a ripe time for the platform: Android L is a huge step forward in design, and all the new Android platforms (TV, auto, wearables) are all supported in RubyMotion.

This year is going to be a great year for Android and cross-platform gems! We’re very excited to see what you come up with! See you all at #inspect 2015!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion 3.0 Sneak Peek: Android Support

It’s very sunny here in San Francisco, California, and we are super excited to give you a first sneak peek at the next major version of RubyMotion, numbered 3.0, which will be released later this year!

Android Support

RubyMotion 3.0 features support for a new mobile platform: Android. You can now write full-fledged Android apps in Ruby instead of Java. If you have a RubyMotion app for iOS or OS X and want to port it to Android, you can even share some of the code! One language, three platforms.

RubyMotion Android projects are created and managed exactly the same way as RubyMotion iOS and OS X projects. The —template=android argument can be passed to motion create to create a new Android project.

$ motion create --template=android Hello
    Create Hello
    Create Hello/.gitignore
    Create Hello/app/main_activity.rb
    Create Hello/Rakefile
    Create Hello/resources
    Create Hello/assets
$ cd Hello
$ rake

The entire project configuration lives in the Rakefile. RubyMotion for Android features a build system driven by Rake tasks, similar to what we already do for the other platforms. You can build and run apps in the Android emulator (rake emulator), on your USB-connected Android device (rake device), and prepare and sign builds suitable for a Google Play submission (rake release).

The AndroidManifest.xml file (similar to iOS’ Info.plist file) is also generated based on the values in the Rakefile.

You can keep using your favorite editor when working on an Android project in RubyMotion: Eclipse is not required nor used in any part of the process. In addition, ctags-based editors will have auto-completion for Java APIs.

Android projects can also vendor 3rd-party Java libraries, similar to how iOS and OS X projects can vendor 3rd-party Objective-C libraries. If you need a MapView in your app, integrating the Google Play Services library is just one app.vendor_project call away.

In a RubyMotion Android projects, raw resource files can be added to the assets directory, while special application-level resources can exist in the resources directory. The build system will make sure these are properly packaged and identifiable via the R class.

Runtime

RubyMotion for Android features a completely new Ruby runtime specifically designed and implemented for Android development. This is a new implementation of the Ruby language, it does not share code with RubyMotion for the Objective-C runtime. We are using the RubySpec project to make sure the runtime behaves as expected.

class MainActivity < Android::App::Activity
  def onCreate(savedInstanceState)
    super

    text = Android::Widget::TextView.new(self)
    text.text = 'Hello World!'
    self.contentView = text
  end
end

The object model of RubyMotion for Android is based on Java. Ruby classes, objects, methods and exceptions are Java classes, objects, methods and exceptions, and vice-versa. No bridge is involved.

The Ruby builtin classes are also based on core Java classes:

This unified runtime approach provides an excellent integration with Java APIs as well as good performance, since objects do not have to be bridged. The runtime uses the Java Native Interface (JNI) in order to integrate with Java, and the entire set of Android APIs is available in Ruby, out of the box.

The memory management is delegated to Dalvik’s generational and concurrent garbage collector. The runtime creates and destroys global references when needed (such as when an instance variable is set), and the destruction of local references is determined at compile time.

The garbage collector is very efficient; it features a per-thread allocation pool for fast allocations, finalizations can happen on dedicated threads, and cycles are properly handled.

Compiler

RubyMotion Android apps are fully compiled into optimized machine code, exactly like their iOS and OS X counterparts.

We feature an LLVM-based static compiler that will transform Ruby source files into ARM machine code. The generated machine code contains functions that conform to JNI so that they can be inserted into the Java runtime as is.

Since Android does not allow classes to be created at runtime, the compiler will emit DEX byte-code for class interfaces, but mark all methods as defined in native code.

The compiler also emits DWARF metadata, which lets us properly symbolicate exceptions, and also allows us to set source-level breakpoints when attaching a debugger.

The build system links all object files with the RubyMotion runtime in order to create an NDK shared library.

RubyMotion Android apps are packaged as .apk archives, exactly like Java-written apps. They weight about 500KB by default and start as fast as Java-written apps. All Android API levels are supported.

Samples

We are extremely excited about RubyMotion for Android. We can finally use the same language to develop an application for multiple platforms, and even if platform-specific code (ex. user interface) will have to be written, we do believe that a significant part of the app, such as the backend, can be shared.

We spent the last days working on sample code apps.

We also created an application for our conference, which has been submitted and is available in the Google Play store. If you have an Android device, check it out! The source code will be published on GitHub right after the conference.

We Need Your Help

RubyMotion 3.0 is not ready for prime-time yet. We are working hard on improving and polishing it so that it can be delivered to everyone.

The reason we are giving you a sneak peek today is because we can’t achieve that without you. RubyMotion for Android features a brand-new implementation of Ruby that will require significant testing before it can be as mature as the existing RubyMotion platforms support.

We are looking for volunteers interested in accessing early builds of RubyMotion 3.0, testing the new features and giving us continuous feedback so that we can quickly iterate.

Are you the author of a RubyMotion gem that you think would make sense to exist for Android? Do you have an app in the App Store that you would like to port and submit to the Google Play Store? Are you willing to test early builds of RubyMotion for Android, report bugs and work with us? We need your help.

If you are interested, please fill out this form. We will only approve a small amount of developers for the beta, and we will start seeding the first builds in early July. Thanks a lot!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

New in RubyMotion: BigDecimal, Better Localization

The last RubyMotion releases introduced a couple high-level changes that we would like to cover, before we get to start our second developer conference, next week!

BigDecimal

As of RubyMotion 2.28, the BigDecimal class is introduced, based on top of Cocoa’s NSDecimalNumber class.

It implements all of CRuby’s BigDecimal operator methods, and can be passed to Objective-C APIs that expect arguments as NSDecimalNumber objects, NSDecimal structures, or pointers to NSDecimal structures.

NSDecimalNumber objects are therefore not converted to Float objects anymore, and remain intact when passed to and retrieved from Objective-C APIs.

In case your application requires high-precision representations for floating point objects, we recommend using BigDecimal instead of Float.

(main)> x = BigDecimal.new('0.123456789')
=> 0.123456789
(main)> x + 1
=> 1.123456789

Better Localization

The build system has been improved to detect and properly compile strings resource files into the application bundle. This patch was contributed by Hwee-Boon Yar.

Additionally, the NSLocalizedString() API and its variants, NSLocalizedStringFromTable(), NSLocalizedStringFromTableInBundle() and NSLocalizedStringWithDefaultValue(), have been added as methods of the Kernel module. Previously they were not available as they are C-level preprocessor macros, and one had to call the NSBundle Objective-C API directly.

String resource files are usually used to localize an application, by providing the translations of user interface strings. A resource file per localization is the norm.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion #inspect 2014: Last Speakers, Panel, Schedule

In about a month we will be launching our second annual developer conference, #inspect, the 28th and 29th May in sunny San Francisco, California.



RubyMotion #inspect 2014 will be a 2-day single track conference, 100% about RubyMotion. We picked an awesome venue, Fort Mason, a former US military post office which offers a scenic view of the famous Golden Gate Bridge.

We are obviously super excited about the conference. Make sure to grab a ticket when you can, we are selling those fast.

Last Speakers

We are now revealing the last 6 speakers, in addition to 16 already-announced speakers:

  • Kevin Poorman is a software architect at West Monroe Partners and a certified Force.com developer. He authored several RubyMotion apps, all tied to the Salesforce enterprise resource, and will talk about connecting RubyMotion to enterprise systems.

  • Andy Pliszka works at Pivotal Labs on large iOS projects. He will talk about setting up RubyMotion for Test-Driven Development (TDD) and how to leverage test-first methodology when building RubyMotion projects.

  • Ivan Acosta-Rubio writes iOS apps using RubyMotion at Software Criollo. In his talk, Ivan will introduce the AV-Foundation framework and how to capture media on iOS and OS X. Let’s write some spying tools!

  • Isaac Murchie works at Sauce Labs and will talk about using tried-and-true Ruby tools, such as RSpec, Cucumber and Capybara, to automate the testing of RubyMotion projects with Appium, in order to deliver robust mobile apps.

  • Paul Colton is the co-Founder and CEO of Pixate. Paul will review the Freestyle framework and how it can be used to style RubyMotion apps using just plain CSS.

  • Mark Villacampa works for Cabify on their RubyMotion app and is also a hardware enthusiast, hacking 3D printers. Mark will talk about connecting RubyMotion to hardware, walk through all the available options, and giving recommendations for the folks interested to try at home.

This ends our speakers selection for this year! If you submitted a proposal and didn’t get in we are truly sorry. We got a lot of proposals this year and it was tough to make the pick!

Panel

We will be organizing a panel dedicated to RubyMotion apps in production.

The panel will be composed of folks working on high-profile RubyMotion apps, such as Bandcamp, Jukely, A Dark Room (which is at the time of this writing, number one in the top-paid category of the US App Store!), and possibly Frontback and Jimdo.

We will discuss their experience, common pitfalls when working on a high-profile RubyMotion app, then take questions from the audience.

Schedule

We published the schedule of the conference. One keynote, 20 presentations, one panel. As you can see, it’s fully packed with awesomeness!

We still have tickets available, so if you want to join us, now is the time, register today!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion #inspect 2014: Announcing More Speakers, Student Tickets

In a bit more than a month, the 28th and 29th May, we will be launching our second annual developer conference, #inspect, this time in sunny San Francisco, California.



RubyMotion #inspect 2014 will be a 2-day single track conference, 100% about RubyMotion. We picked an awesome venue, Fort Mason, a former US military post office which offers a scenic view of the famous Golden Gate Bridge.

We are obviously super excited about the conference. Make sure to grab a ticket when you can, we are selling those fast.

More Speakers

We are happy to reveal four more awesome speakers, in addition to 12 already-announced speakers:

  • Alex Rothenberg is a software engineer at McKinsey and the author of the motion-addressbook library. He will talk about simplifying the Cocoa APIs and making sure they do not crush your Ruby code.

  • Dennis Ushakov, a software engineer at JetBrains, will show off RubyMine and its excellent integration with the RubyMotion toolchain.

  • Nikolay Nemshilov is a senior software developer at Ninefold and also the author of UnderOS (or shortly, uOS), a project that aims to help web-developers to get into native iOS development by reusing knowledge and technologies they already know, which he will present.

  • Austin Seraphin is a blind developer and an accessibility expert. Austin was a speaker at #inspect 2013 last year and delivered one of the most acclaimed presentations. Since then, he authored the motion-accessibility gem and will talk about how making RubyMotion apps accessible to the blind.

We will be announcing the last batch of speakers soon. If you submitted a talk proposal, we will get back to you as soon as we can. Thanks for your patience!

Student Tickets

Due to the demand we will be offering a limited batch of tickets for students to the conference at a highly discounted price.

Students tickets are priced at $149 and require proof of enrollment. Please email us in order to get one. We will update this post once the batch will be gone.

Call for Sponsors

We are still looking for a small number of sponsors to share in the support of #inspect 2014. This is a great opportunity to show your commitment to the RubyMotion community and also promote your products or services. If you or your company are interested get in touch.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion Success Story: A Dark Room

A Dark Room is a very popular text-based role playing game (RPG). Originally web-based, Amir Rajan ported it to iOS using RubyMotion, and very quickly the app went from being the top game in the RPG category to be in the top 5 paid apps in the UK App Store. At the time of this writing it’s on its way to the top paid category of the US App Store.

The game now enjoys a 5-star rating and has been positively covered numerous times in the press.

We sat down with Amir to discuss his experience building this awesome game in RubyMotion.


What is your background, and what brought you to become involved in RubyMotion?

Before I took my sabbatical (I guess you can say I’ve gone independent now), my entire 8 year development career was all .Net development. I used ruby primarily for build automation during my day time job. Outside of my 9-5, side work I did was primarily Rails and NodeJS. I’ve contributed quite a bit to the open source .Net community. I’m a contributor to NSpec (an RSpec clone), SpecWatchr (an auto test tool for NSpec), Oak (a dynamic “poly fill” for C# andASP.NET MVC), and Canopy F# (a Web UI automation DSL for Selenium and PhantomJS).

One of my friends told me about RubyMotion. I was immediately interested given that I had an appetite for “different ways” (better ways) to approach problems.

Why did you choose to use RubyMotion instead of Xcode and Objective-C?

My first few apps that I built (none of which made it into the App Store) were actually built using Xcode and Objective C. Notably, I built a little budgeting app for myself with a Rails back end. At that time I actually had RubyMotion but wanted to have a solid basis of “vanilla” iOS development before making an assessment on RubyMotion.

One thing I saw immediately was the contrast between the work I did on the server side Rails app vs when I went back to Xcode. The hardest things to explain is the “Ruby mindset”: light weight environments, concise workflows, editor agnostic, fast feedback loops, simple API’s… essentially developer happiness.

As painful as it was to work outside of my souped up VIM environment, I completed my budgeting app using Xcode and Objective C for the client side. I did not enjoy the experience. Objective C is verbose, the Cocoa API’s are unintuitive, a lot of ceremony with regards to class definitions. Xcode makes it difficult to work with vendor libraries (try referencing AFNetworking for HTTP communication and Cedar for testing if you don’t believe me). Interface Builder was frustrating to work with too.

Now that I had my perspective, I worked with RubyMotion instead. The wrappers are wonderful (I primarily used BubbleWrap and Promotion). The rake tasks that come out of the box are great. Testing is first class, MacBacon has an RSpec style DSL that I know well and enjoy working with. Package management is solid, and I was able to use Objective-C libraries via CocoaPods. It just felt like everything was thought through, distilled down, and presented in a form that was immediately familiar to me given my Ruby background (and the “Ruby mindset”).

What inspired you to create “A Dark Room”?

A Dark Room is actually a joint venture between myself an Michael Townsend. He created the web version of the game. It went viral on Hacker News and I stumbled across it. At this time I was on a sabbatical, and decided that this would be a wonderful project to take on. I absolutely loved the web version of the game, but it wasn’t touch device compatible. I sent an email to Michael, asking if I could port it to iOS. He said yes! 4 months and 12,000 lines of RubyMotion later, I had a game in the App Store.

How did you begin writing the app, what were your early development stages?

I had some real world experience with Xcode and Objective C. In fact, the first few hours of A Dark Room development was done in in Xcode. I wanted to start fleshing out the engine of the game, and found it rather awkward using OCUnit. I rely heavily on fast feedback loops and incremental evolution. OCUnit did a good job in giving feedback, but fell short when it came to test composition. I refactored often, and what I found was that Objective C and OCUnit just made that an utter chore. I had a copy of RubyMotion, I knew that it had an RSpec style testing framework, and I knew how easy it was to refactor Ruby code. So I put the Obj C version of A Dark Room aside, and fired up RubyMotion.

I was extremely happy with the default template. Testing was baked in, the rake tasks were already in place to run tests. I created a light weight watchr script to run tests whenever I saved a file… everything just gelled really well :-)

As the game progressed, how difficult was it to add and remove features from your code base?

Not knowing RubyMotion, I initially stuck to using “vanilla” Cocoa apis for all my UI work. It was extremely easy to translate Objective C to Ruby. I was able to use all the resources on Stack Overflow whenever I hit a snag. Eventually, I was juggling a number of views and decided to look at ProMotion and BubbleWrap (which I found via the RubyMotion Wrappers site). The refactoring was easy. It amounted to deleting code ;-).

As far as the core game engine, I was able to use all the refactoring techniques of Ruby. All the language capabilities “just worked”: inheritence, class macros, modules/mixins, “send”, blocks, etc. My tests were always running in the background with every change I made.

Your app has been praised as being one of the few games that have are accessible to the blind. What did you do to make sure your app was accessible?

Accessibility changes were surprisingly simple to make. It’s amazing how much iOS does for you out of the box. Most of the first part of the game was already playable via VoiceOver. I ended up using an existing Objective-C open source library called SSAccessibility (it did all the hard work with regards to queueing multiple messages). I used CocoaPods to install the library, updated my Rakefile, and was up and running. The key take away here is that I was able to leverage the existing Objective-C ecosystem. Here is a write up of all the quirks with regards to making accessible apps.

What were some of your greatest, happiest moments during development?

Shipping. It’s hard to believe that the code base was over 12,000 lines. I was happy to get this mammoth out the door.

Were there times that the RubyMotion toolchain was a source of frustration? And how did you get those issues resolved?

I had a couple of instances where RubyMotion would throw a runtime exception without a backtrace (stacktrace). It was always related to the initial load of the app’s UIViews. I’d use git bisect to zero in on what line caused the error. It was tedious work at times.

Will you continue to use the RubyMotion compiler on future projects?

Absolutely. Without hesitation. Idiomatic Ruby wrappers on top of iOS, frictionless workflows, and the “it just works” culture that Ruby fosters, trumps any hesitation I once had. On top of that, I now have a fairly large app to serve as a testament to the platform.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion #inspect 2014: First Batch of Speakers, Lodging Information, Sponsors

In a bit less than two months we will be launching our second annual developer conference, the 28th and 29th May in sunny San Francisco, California!

(Yes, that’s the week before WWDC!)



RubyMotion #inspect 2014 will be a 2-day single track conference, 100% about RubyMotion. We picked an awesome venue, Fort Mason, a former US military post office which offers a scenic view of the famous Golden Gate Bridge.

First Batch of Speakers

We closed our call for presentations and are now working on finalizing the schedule. In the meantime, we already pre-selected some of the speakers and it is our pleasure to list them here!

  • Laurent Sansonetti, Shizuo Fujita and Eloy Durán from HipByte will share a keynote talk in which they will talk about what’s coming next for RubyMotion (we think you will like it!).

  • Clay Allsopp, author of the Pragmatic Programmers’ RubyMotion book and numerous libraries will talk about building build tools that build tools to build apps. Sounds crazy and interesting!

  • Jack Watson-Hamblin, creator of MotionInMotion, the popular weekly screencast, will talk about the RubyMotion community and what we can do to make it better.

  • Lori Olson, author of a RubyMotion book about Core Data, will share her experience in solving real problems using Core Data in RubyMotion apps.

  • Todd Werth, co-founder of InfiniteRed and author of the popular RubyMotionQuery (RMQ) library will talk about what’s new in RMQ. Todd is also co-organizing the event!

  • Jamon Holmgren, owner of ClearSight Studio and author of the popular ProMotion framework, will talk about going from a prototype to a production app.

  • Mark Rickert, owner of Mohawk Apps, is the author of numerous RubyMotion apps, all of which are open-source. Mark also has a lot of experience marketing apps and will teach us a few tricks on how to promote an app in the App Store and through other channels.

  • Ken Miller, co-founder of InfiniteRed, is the author of CoreDataQuery (CDQ), a library which aims at making Core Data easier to use. Ken will talk about CDQ and what’s new.

  • Dave Lee is a contributor to ReactiveCocoa, a framework that provides Functional Reactive Programming to Cocoa apps. Dave will talk about integrating ReactiveCocoa in RubyMotion.

  • Will Raxworthy, author of numerous blog posts about RubyMotion, will talk about 2D game development, using the new SpriteKit framework and integrating with native game controllers, and eventually write a Flappy Bird clone!

We will be announcing more speakers soon. If you submitted a talk proposal, we will get back to you as soon as can. Thanks for your patience!

Lodging Information

The conference is located between the Fisherman’s Wharf and the Marina district. Both are within easy walking distance and both have public transportation.

The Wharf has many places to stay because it’s a tourist location. There are a lot of tourist-area places to eat too. You won’t see a lot of San Franciscans in this area, but there is a lot going on and it is fun.

The Marina is a local neighborhood, but there are a lot of motels/hotels on Lombard street. The Marina is cheaper than the Wharf.

There are plenty of other neighborhoods to stay in too. The Mission district is where a lot of tech workers live and is an Uber car-ride away. Union Square is a popular location and is a MUNI 30 bus away (or Uber). SOMA and Market Street are where many of the startups are.

Check out the lodging section of the conference website for more information and also pointers to places we recommend.

Sponsors

We are delighted to announce that Pixate will be our lead (gold) sponsor this year!

Pixate was founded in the summer of 2012 as a Y-Combinator company with the goal of enabling designers and developers to quickly and easily create beautiful, native mobile applications. Their flagship product, Pixate Freestyle, enables the styling of native mobile applications using CSS.

A few words from our silver sponsors:

Terrible Labs is a design and development shop in Boston. They use RubyMotion to build all of their clients’ iOS applications. They have also used RubyMotion to build their own product, TicketZen, the easiest way to pay parking tickets.

RubyMine, the most powerful Ruby IDE, provides smart coding assistance and advanced testing and debugging features for all types of Ruby projects and cutting-edge technologies, including RubyMotion.

We would like to thank Pixate, Terrible Labs and RubyMine for helping us organizing this awesome event.

We are still looking for a small number of sponsors to share in the support of #inspect 2014. This is a great opportunity to show your commitment to the RubyMotion community and also promote your products or services. If you or your company are interested get in touch.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion Raises Millions, Becomes Free, Introduces Smart Suggestions™

Update: We hope that you folks enjoyed our April Fools prank! We are of course still 100% bootstrapped. We also still intend to grow organically thanks to your continuous support!

(Personal thanks to Josh Ballanco for having had the idea of RubyMotionCoin and MotionInflater.)


We are delighted to announce on this 1st April 2014 that we just closed a multi-million dollar funding transaction with Agile Ventures and Extreme Capital, two top-tier investing firms of Silicon Valley.

This is our first series A round of funding and we are extremely excited about the future of RubyMotion. Make sure to read the coverage on TechCrunch (to be published later today). You can also check a picture of our new board of directors and observe the synergy already at work.

We have been bootstrapping RubyMotion since its inception and were profitable by charging our awesome customers (from here on out referred to as users), but we think it’s now time to shift into the next gear.

Our goal is to grow RubyMotion faster into a 100-people company serving millions of users and bringing you folks tons of innovation. The entire team will also relocate into the San Francisco Bay Area (including Eloy’s new boat which presents a set of interesting logistic challenges).

We are of course still committed to a long-term vision. Unlike the majority of VC firms, our new partners Agile Venture and Extreme Capital are there for the long run and will definitely not require an exit in the next four years. (At least they said so during our meetings.)

Free, Smart Suggestions

Thanks to this funding round we no longer need to get money from you folks, so RubyMotion will become totally free. Awesome isn’t it?

We will also ship with a new feature called Smart Suggestions™ (patent pending). The RubyMotion build system will now show you suggestions of services you might want to use by scanning your project’s source code, sending us a copy, and getting back a list of relevant services. (Please note that the connection to our server is totally secure by using the same cryptography algorithms used in banks, so you should feel safe.)

Here is an example of what a future project build session might look like.

  Compile app/person.rb
  !!! It looks like you are creating a regular expressions on line 42.
      RegexBuilder™ is a new revolutionary tool that makes building
      regular expressions easier.
      Would you like to know more? [Yy]
[...]

We believe that Smart Suggestions™ will significantly increase your productivity, so we are enabling it by default for all users. Please contact our sales team if you would like to disable Smart Suggestions™.

Future Plans

Very soon we will be introducing RubyMotionCoin, a new virtual currency that is mined as a byproduct of the Xcode build system. If you include a CocoaPod in your app that contains Objective-C++ code using templates, your mining rate doubles.

Finally, we will be releasing MotionInflater later this year, a system that will automatically convert your RubyMotion code to Objective-C, ensuring that your app gains the approval of important people and allowing you to experience the inflated ego that can only come from shipping a real iOS app.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

New in RubyMotion: New CLI, WeakRef Zeroing, Background Fetch Testing, Subscripting, Performance

We shipped quite a few releases since the beginning of the year. Let’s dig into the new major features.

New Command-Line Interface

The motion command-line interface has been fully rewritten using the CLAide project.

$ motion 
RubyMotion lets you develop native iOS and OS X applications using the awesome Ruby language.

Commands:

    * account          Access account details.
    * activate         Activate software license.
    * changelog        View the changelog.
    * create           Create a new project.
    * device-console   Print iOS device logs
    * ri               Display API reference.
    * support          Create a support ticket.
    * update           Update the software.

Options:

    --version   Show the version of RubyMotion
    --no-ansi   Show output without ANSI codes
    --verbose   Show more debugging information
    --help      Show help banner of specified command

The new codebase allows better output and more elaborated argument handling. It will also allow us to extend the interface more easily in the future.

WeakRef Zeroing

In previous builds, trying to send a message to a WeakRef object whose internal reference was prematurely destroyed was causing a crash at runtime, since it was attempting to send a message to an invalid object address.

Now, the internal reference of WeakRef objects will properly be zeroed when it is destroyed. Sending a WeakRef object a message whose internal reference has been zeroed will cause a WeakRefError exception at runtime, matching exactly the behavior of CRuby’s weakref.rb standard library.

The WeakRef#weakref_alive? method was also added and will return false in case the internal reference has been zeroed.

autorelease_pool do
  @ref = WeakRef.new(Object.new)
end
@ref.weakref_alive? #=> false
@ref.description    #=> WeakRefError: Invalid Reference - probably recycled

Background Fetch Testing

iOS 7 introduced the notion of background fetch which for example allows your application to check a remote web API if there is any updated content and, if so, fetch it, all while being in a suspended state.

To perform a background fetch iOS will launch your application using the application:performFetchWithCompletionHandler: method. You can now simulate this on the iOS Simulator by setting the background_fetch environment variable, as show below.

$ rake background_fetch=1

Note that while your application is in the background you will not be able to REPL until you activate the application again.

Object Subscripting

As of clang 3.1 Objective-C developers are able to add support for the new Objective-C literal syntax on their own classes by implementing a set of methods.

RubyMotion will now properly handle objects from these classes and allow you to send the #[] and #[]= messages on them as convenience shortcuts.

As an example, let’s take a fictional SubscriptingExample Objective-C class:

@implementation SubscriptingExample

- (id)objectAtIndexedSubscript:(NSUInteger)index;
{
  ...
}

- (void)setObject:(id)object atIndexedSubscript:(NSUInteger)index;
{
  ...
}

- (id)objectForKeyedSubscript:(id)key;
{
  ...
}

- (void)setObject:(id)object forKeyedSubscript:(id)key;
{
  ...
}

@end

The following class can now be used from Ruby code using convenience shortcuts.

obj = SubscriptingExample.new
obj['one'] = 1
puts obj['one']
...

Performance Improvements

As you could see from the release notes our goal of improving the overall performance of RubyMotion apps is continuing steadily.

Runtime primitives (such as the method dispatcher) are faster by 25%. Builtin classes methods have also been optimized, sometimes by a 2x factor. Some of our users reported very positive feedback from their testers.

As mentioned in our previous report, we are still working on a benchmark suite for RubyMotion. Its goal is to let us identify performance problems as well as catching performance regressions. It is still at this time a work in progress and we still intend to publish it once it’s complete.

Jim Weirich

Jim was one of the very early RubyMotion users. He believed in the project and gave us the motivation we needed to keep working on it and launch it.

As the author of Rake, it goes without saying that RubyMotion would not exist without him.

You can watch Jim speaking about RubyMotion at the local Cincinnati Cocoa user group. In this video, Jim demonstrates his legendary joie de vivre as well as his excellent teaching skills.

You can also check out Jim teaching the use of source code control (you do use SCC on your RubyMotion apps, right?) for the Pragmatic Programmers, who have kindly agreed to donate the full proceeds of the screencast to Jim’s family.

Jim passed away the 19th February 2014. He will be deeply missed. Rest in peace, Jim.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.