RubyMotion introduced last September a 2D game development platform for iOS and Android called motion-game. Until then creating games was done using the Joybox gem, which hasn't been maintained for a while. From now on RubyMotion includes a beta version of motion-game which will be maintained, up to date, easy to set up and cross-platform!

In this article we will discover motion-game and I'm pretty sure that you'll want to try it to build smartphone games!

Hello world

First of all you need to install motion-game.

gem install motion-game

As you can see it is really easy. Now we can create our first hello world game.

motion create --template=motion-game hello
cd hello

The project is created with few files which makes it easy to handle.

In this introduction we will have a look at the app folder in which we will develop a minimalistic game.

app/application.rb

class Application < MG::Application
  def start
    MG::Director.shared.run(MainScene.new)
  end
end

app/main_scene.rb

class MainScene < MG::Scene
  def initialize
    label = MG::Text.new("Hello World", "Arial", 96)
    label.anchor_point = [0, 0]
    add label
  end
end

By default, all files in app are loaded by RubyMotion. The entry point and the scene files where the game takes place are named application.rb andmain_scene.rb respectively. The application file launches the main scene (a simple "Hello World") with some basic functionality like setting the font style and the anchor point of a label. Now we can simulate our game on iOS and Android!

rake ios:simulator
rake android:emulator

Once started you should see "Hello World" appearing.

As you can see, it is very easy to create an iOS and Android game with one code only! We can carry on by applying other methods on our label.

app/main_scene.rb

  def initialize
    label = MG::Text.new("Hello World", "Arial", 96)
    label.position = [400, 400]
    label.color = [0, 0.6, 0.8]
    label.rotation = -10.0

    add label
  end

The position method allows us to move the label relatively to its center. Then we change the color and apply a rotation.

Synbioz vs Zombie

We go on by creating a mini game, as an excuse to explore other features. There is already an example of Flappy Bird provided by the RubyMotion team that you should really download.

Our mini game is less elaborated but will allow us to discover interesting methods of the framework.

The game

The goal of our game, "Synbioz vs Zombie", is quite simple. You play a survivor of a team which should dodge a zombie as long as possible. Before you start you will need to retrieve images and audio resources on github.

First step

To create our game we will need the following scenes:

• Survivor choice (survivor_scene.rb)
• Main (main_scene.rb)
• Game over (game_over_scene.rb)

It's time to create our project!

motion create --template=motion-game synbiozvszombie
cd synbiozvszombie

In the app folder we'll add a scenes subfolder that will include the three scene files. You'll have to remove main_scene.rb from the app root to prevent conflicts at runtime.

Choose your survivor

The first scene will allow us to select the Synbioz team survivor that you want to embody in the game.

app/application.rb

class Application < MG::Application
  def start
    MG::Director.shared.run(SurvivorScene.new)
  end
end

Now the game begins on the survivor scene.

app/scenes/survivor_scene.rb

class SurvivorScene < MG::Scene
  def initialize
    add_label
  end

  def add_label
    label = MG::Text.new("Choose your survivor", "Arial", 80)
    label.color = [0.7, 0.7, 0.7]
    label.position = [MG::Director.shared.size.width / 2, MG::Director.shared.size.height - 100]

    add label
  end
end

In the first scene, we add a text label. Under this label we will have the opportunity to choose the survivor.

MG::Director.shared.size.width allows us to get the screen width. Once halved, the text will be centered on x. Finally we add 100px on the top of the screen to improve the rendering.

Now we add our survivor list :

app/scenes/survivor_scene.rb

def add_survivors
  team_synbioz = ["Martin", "Nico", "Victor", "Jon", "Numa", "Clement", "Theo", "Cedric"]

  team_synbioz.each_with_index do |name, index|
    button = MG::Button.new("#{name}")
    button.font_size = 35
    button.position = [MG::Director.shared.size.width / 2, (MG::Director.shared.size.height - 200) - (index * 50)]
    button.on_touch { MG::Director.shared.replace(MainScene.new(name)) }

    add button
  end
end

We added a button for each member of Synbioz. Once selected, we have to replace the current scene by the main one with MG::Director.shared.replace() where the scene takes the name as a parameter. You should see that :

Main scene, the real fun begins!

The main scene will include two elements, a survivor and a zombie. The latter will move randomly on the screen and you'll have to move the survivor by yourself.

Resources

We then need resources. By default, motion-game find the resources in the folder with the name resources in the project root. So you just have to create this folder and add the downloaded resources.

app/scenes/main_scene.rb

  def initialize(name)
    add_zombie
  end

  def add_zombie
    @zombie = MG::Sprite.new("zombie.png")
    @zombie.position = [400, MG::Director.shared.size.height / 2]

    add @zombie
  end

Right now MG::Sprite.new("image") gets images on which we can apply some methods. It's just as easy to play a sound from this folder MG::Audio.play("song").

app/scenes/main_scene.rb

  def initialize(name)
    MG::Audio.play("night.wav", true, 0.5)
    @name = name.downcase

    add_zombie
  end

This song will be played at launch. In order to loop it, you need to set the play second argument to true. Finally 0.5 is the volume. Next, we import the survivor image stored in the folder resources/survivors. We save the name into the @name instance variable which is useful to display the survivor image dynamically.

app/scenes/main_scene.rb

  def initialize(name)
    MG::Audio.play("night.wav", true, 0.5)
    @name = name.downcase

    add_zombie
    add_survivor
  end

  def add_survivor
    @survivor = MG::Sprite.new("survivors/#{@name}.jpg")
    @survivor.position = [100, MG::Director.shared.size.height / 2]

    add @survivor
  end

Once your choice is made you are redirected to the main scene.

Physical objects

We want to launch the game over scene when our characters are in contact. First we will move our survivor to the zombie to see what happens.

app/scenes/main_scene.rb

  def initialize(name)
    MG::Audio.play("night.wav", true, 0.5)
    @name = name.downcase

    add_zombie
    add_survivor
  end

  def add_survivor
    @survivor = MG::Sprite.new("survivors/#{@name}.jpg")
    @survivor.position = [100, MG::Director.shared.size.height / 2]
    @survivor.move_to = ([450, @survivor.position.y], 1)

    add @survivor
  end

For the moment our survivor runs through the zombie, both behave as images. We want physical contact between images to be possible.

app/scenes/main_scene.rb

  def add_zombie
    @zombie = MG::Sprite.new("zombie.png")
    @zombie.attach_physics_box
    @zombie.position = [400, MG::Director.shared.size.height / 2]

    add @zombie
  end

  def add_survivor
    y_position = MG::Director.shared.size.height / 2

    @survivor = MG::Sprite.new("survivors/#{@name}.jpg")
    @survivor.attach_physics_box
    @survivor.position = [100, y_position]
    @survivor.move_to([450, y_position], 1)

    add @survivor
  end

Click on the image below to see the animation.

Now we have a collision between the survivor and zombie! We also note that our characters are experiencing gravity which is very interesting for a 2D Mario like game for example.

Our mini game is closer to a Pacman, so we will remove this feature.

app/scenes/main_scene.rb

  def initialize(name)
    self.gravity = [0, 0]

    MG::Audio.play("night.wav", true, 0.5)
    @name = name.downcase

    add_zombie
    add_survivor
  end

Now that our characters behave as expected, the remaining part is to trigger our game over scene on contact. For this we use the contact_mask.

app/scenes/main_scene.rb

  def initialize(name)
    self.gravity = [0, 0]

    MG::Audio.play("night.wav", true, 0.5)
    @name = name.downcase

    add_zombie
    add_survivor

    on_contact_begin do
      MG::Director.shared.replace(GameOverScene.new)
    end
  end

  def add_zombie
    @zombie = MG::Sprite.new("zombie.png")
    @zombie.attach_physics_box
    @zombie.position = [400, MG::Director.shared.size.height / 2]
    @zombie.contact_mask = 1

    add @zombie
  end

  def add_survivor
    y_position = MG::Director.shared.size.height / 2

    @survivor = MG::Sprite.new("survivors/#{@name}.jpg")
    @survivor.attach_physics_box
    @survivor.position = [100, y_position]
    @survivor.contact_mask = 1
    @survivor.move_to([450, y_position], 1)

    add @survivor
  end

app/scenes/gameoverscene.rb

class GameOverScene < MG::Scene
  def initialize
    add_label
  end

  def add_label
    label = MG::Text.new("Game over...", "Arial", 96)
    label.position = [MG::Director.shared.size.width / 2, MG::Director.shared.size.height / 2]
    add label
  end
end

Now when our survivor touches the zombie, the on_contact_begin block is called and replaces our stage by the game over screen!

The movements

Now we want to move the characters. The survivor will move to the position touched on the screen and the zombie will move randomly within the limits of the screen.

Events movements

First we will move our survivor. For this we need to get the contact details that will be used in @survivor.move_to([x, y], 1).

app/scenes/main_scene.rb

def initialize(name)
  self.gravity = [0, 0]

  @name = name.downcase

  add_survivor
  add_zombie

  on_touch_begin do |touch|
    @survivor.move_to([touch.location.x, touch.location.y], 1)
  end

  on_contact_begin do
    MG::Director.shared.replace(GameOverScene.new(@score))
  end
end

The on_touch_begin block allows us to find the coordinates of our finger during the touch event. This will replace the previous move_to.

Random movements

With the #update method, motion-game includes an easy-to-implement loop system. You just need to define the update(delta) method that you can easily switch on and off with the start_update and stop_update methods.

app/scenes/main_scene.rb

  def initialize(name)
    self.gravity = [0, 0]

    @name = name.downcase
    @zombie_update_position = 0

    # CODE ...

    start_update
  end

  def update(delta)

    @zombie_update_position += delta

    if @zombie_update_position >= 2.0
      @zombie.move_to([random_position[:x], random_position[:y]], 1)
      @zombie_update_position = 0
    end
  end

  private
  def random_position
    {
      x: Random.new.rand(0..MG::Director.shared.size.width),
      y: Random.new.rand(0..MG::Director.shared.size.height)
    }
  end

First we initialize @zombie_update_position to zero, then we start the loop with start_update. The update method has a delta parameter which is the execution time of the loop. Thus, we can get the current time by incrementing with delta. We use this principle to move the zombie every two seconds. Then we specify some random coordinates that stay within the dimensions of the screen to manage the zombie movement.

Add some fun

To add some fun, we will change the scale of the zombie every two seconds, then we will show the survival time on the game over screen.

app/scenes/main_scene.rb

def initialize(name)
  self.gravity = [0, 0]

  @name = name.downcase
  @time = 0
  @zombie_update_position = 0

  add_survivor
  add_zombie

  on_touch_begin do |touch|
    @survivor.move_to([touch.location.x, touch.location.y], 2)
  end

  on_contact_begin do
    MG::Director.shared.replace(GameOverScene.new(@time))
  end

  start_update
end

def add_zombie
  # CODE ...
end

def add_survivor
  # CODE ...
end

def update(delta)

  @time += delta
  @zombie_update_position += delta

  if @zombie_update_position >= 2.0
    @zombie.move_to([random_position[:x], random_position[:y]], 1)
    @zombie.scale += 0.1
    @zombie_update_position = 0
  end
end

private
def random_position
  {
    x: Random.new.rand(0..MG::Director.shared.size.width),
    y: Random.new.rand(0..MG::Director.shared.size.height)
  }
end

We use @time variable to send the score to the game over scene.

app/scenes/gameoverscene.rb

class GameOverScene < MG::Scene
  def initialize(score)
    add_label
    add_score(score)
  end

  def add_label
    label = MG::Text.new("Game over...", "Arial", 96)
    label.position = [MG::Director.shared.size.width / 2, MG::Director.shared.size.height / 2]
    add label
  end

  def add_score(score)
    time = score.round(2)
    score = MG::Text.new("You survived #{time}s", "Arial", 40)
    score.position = [MG::Director.shared.size.width / 2, (MG::Director.shared.size.height / 2) - 80]

    add score
  end
end

Conclusion

With this introduction we had an overview of many motion-game features. If you're interested in, I would strongly recommend that you take a look at the documentation. Other articles are to come and will go into more details!

RubyMotion Starter: 100% free

We are happy to introduce RubyMotion Starter, a fully-featured version of RubyMotion, available for free. Download it today!

RubyMotion Starter comes with full support for iOS and Android development. You can call into the entire set of public APIs, test locally on your machine and your devices, and submit to the respective app stores.

As with the other versions of RubyMotion, Starter will statically compile your Ruby code into optimized machine code, and let you use 3rd-party libraries, with CocoaPods on iOS and Gradle on Android.

Applications built with Starter include a RubyMotion-branded splash screen. To remove the splash screen, a paid subscription can be purchased. Also, Starter does not come with support for OS X and watchOS development.

Cross-platform games

RubyMotion 4.0 now comes with a brand-new, 100% cross-platform engine to write mobile games. You can now write games for iOS and Android with a single code base and using a pure-Ruby API.

Here is the traditional Hello World:

class MainScene < MG::Scene
  def initialize
    label = MG::Label.new("Hello World", "Arial", 96)
    label.anchor_point = [0, 0]
    add label
  end
end

class Application < MG::Application
  def start
    MG::Director.shared.run(MainScene.new)
  end
end

(For a more complete sample, check out Flappy Bird written in 100 lines!)

Our cross-platform game API is fully-featured. It covers audio, sprites, animations, particles, device sensors / events, scene graph / director, UI widgets, and more. It is based on well-tested and solid foundations, such as cocos2d-x and box2d.

Since the API is based on RubyMotion, games are fully compiled into machine code, are able to call into public native APIs for iOS and Android, and can use 3rd-party native libraries. Exactly like regular RubyMotion apps.

At the time of writing, the API is distributed free of charge as a gem, named motion-game, and available in beta. The gem requires RubyMotion 4.0.

$ gem install motion-game

After installing the gem, you can create games from the command-line using the motion-game template.

$ motion create --template=motion-game Hello
$ cd Hello

motion-game projects are quite different from traditional RubyMotion projects, in the sense that they are cross-platform. The app directly contains code that will build for both iOS and Android, and the Rakefile exposes all iOS and Android tasks under the respective :ios and `:android: namespaces.

For instance, to build your game for the iOS simulator then the Android emulator, use the following tasks.

$ rake ios:simulator
$ rake android:emulator

That's it! For more information, check out the following resources:

• API reference
• Samples repository

We are very excited about motion-game. We are releasing an early preview and hope you will give it a try and report us problems you may find.

watchOS 2.0

Apple introduced WatchKit in November of last year, allowing developers to write apps for the Apple Watch. (And we supported it a few days later.)

In the first version of WatchKit, apps were actually running on iPhone devices and were not using true native APIs. Apple addressed these limitations when previewing watchOS 2.0 at WWDC.

As of 4.0 RubyMotion now provides support for this new platform. You can create new projects targeting watchOS 2.0, utilize all the native APIs, deploy them to your Apple Watch, and prepare App Store submissions.

We have been working hard on this and while the support is still in beta, we would like you to start using it, and report us issues you may find. Please refer to the new Apple Watch Guide on our developer center.

We will be improving the watchOS support over the following months. watchOS 2.0 itself is currently still in developer beta and presumed to be released later this year.

JetBrains is a long-time RubyMotion supporter. They have provided support for RubyMotion in RubyMine from the beginning, and they have sponsored our annual conference every year it’s been held. We are very thankful for their commitment to our community.

Today, we are announcing that HipByte and JetBrains will be working more closely together on a variety of technical and marketing projects.

RubyMine collaboration

The RubyMotion integration in RubyMine has been extracted as a plugin and will be very soon available on GitHub under an Open Source license.

We are committed to help with maintaining the plugin and ensuring that RubyMine is able to make use of all existing and future RubyMotion features.

Additionally, RubyMine will provide a one-click experience to setup a fully working RubyMotion environment.

Cross-promotional efforts

Both companies have agreed to start a series of collaborative efforts in order to better promote our respective products.

We are thrilled to be working with JetBrains on these new projects and very excited about the future of RubyMotion and RubyMine. Stay tuned!

If you are not familiar with Code Climate, it's a static analysis tool for monitoring the health of your code. It came out of the Ruby community but now supports a whole host of languages and frameworks -- and it's all open source!

The RubyMotion analysis "engine" for Code Climate lives at the HipByte/codeclimate-rubymotion repository on GitHub, and is implemented by extending Rubocop to create custom bug risk and quality checks for RubyMotion. It's easy to get started using the Code Climate CLI with your RubyMotion project. Here's how:

$ brew tap codeclimate/formulae
$ brew install codeclimate
$ codeclimate init
$ codeclimate engines:install
$ codeclimate engines:enable rubymotion
$ codeclimate analyze

You will then see analysis results for your RubyMotion project. We currently check for some crucial issues in iOS projects that could result in runtime crashes. We will working in the soon future on extending the engine with more rules, adding support for Android projects, and integrating the engine as part of our build system.

If you are interested in contributing to our analysis engine, we would definitely love your help! You can sign up for the Code Climate developer program HERE, or open issues and contribute pull requests on our GitHub repository.

We love that all RubyMotion users will now be able to take advantage of the best static analysis tooling that the opensource community develops, and we hope you love it too!

Photo by Lima Pix on Flickr.

The conference will be happening at Ecole 42, a private software programming school with over 1700 students. 42 is funded by Xavier Niel, a French entrepreneur and businessman active in the technology industry in France.

The conference is 2-day, single-track and all talks will be 30-min long. We will be welcoming guests with a breakfast and serving an awesome French lunch. There will be breaks between each talk to give you the opportunith to talk with the speakers and network with the attendees. There will be a Paris Ruby meetup at the end of the first day, and we will be celebrating the conference with a party / drink-up at the end of the second day.

If you haven't got your ticket already, we still have a few tickets left at the Early Bird pricing (33% discount over the regular rate). Grab your ticket today!

Today we are announcing the remaining batch of speakers:

• Jamon Holmgren, owner of ClearSight Studio and creator of ProMotion, will continue Todd's talk on RedPotion (the "Rails for RubyMotion for iOS") with a second part, this time focused on production use and how the integration between the various helpers allows for clean application architecture that makes sense.

• Niels Liebisch, Managing Director of Optimal Consulting, will discuss a case where his consulting business had to rewrite an existing Objective-C application in RubyMotion to improve the stability and long-term maintenance and share tips, tricks, pitfalls and learnings.

• David Larrabee, lead engineer at MeYou Health, will talk about implementing integration testing on RubyMotion apps. He will share his experience testing production apps: what worked and what didn't.

• Will Raxworthy, developer at Alphasights, will talk about taking over the world with SceneKit, Apple's 3D framework that he used at InfiniteRed to develp a seven-foot 3D highly interactive globe with RubyMotion. He will explain how it was implemented, what was used and tips they picked up along the way.

• Gant Laborde, co-founder of Iconoclast Labs, will cover the validation of user input in RubyMotion apps and how the RMQ gem makes the process easier.

• Mark Rickert, full-time RubyMotion freelancer, will share his life experience, cutting away his 9-5 job to focus on traveling, living his dreams and working in RubyMotion full time. The talk will focus on what you need to do to prepare, tips for how to engage the RubyMotion community and techniques on how to find clients.

They will join the previously-announced speakers:

• Laurent Sansonetti, creator of RubyMotion and founder of HipByte, will cover the current state of the RubyMotion ecosystem and what's planned for the future of the platform.

• Amir Rajan, creator of A Dark Room and The Ensign for iOS, will talk about his experience writing a RubyMotion app that has been downloaded several million times and been featured as the number 1 paid app in the US App Store for weeks.

• Todd Werth, co-founder of InfiniteRed and creator of RMQ (RubyMotionQuery), will talk about RedPotion, an effort to build the "Rails for RubyMotion for iOS", a common set of high-level abstractions to make mobile development easier. Todd will cover the rationale behind the project and build a small app as well.

• Darin Wilson, software engineer at InfiniteRed, will cover the Android equivalent of RedPotion, conveniently called BluePotion (not yet released at the time of writing). Darin will give an overview of the BluePotion components and demonstrates how the API closely mimics RedPotion, providing a "learn once, write everywhere" approach to native mobile app development. A small app will also be built.

• Boris Bügling, software engineer at Contentful and Senior VP of Evil at CocoaPods, will provide an introduction on developing WatchKit and Android Wear apps using RubyMotion. We will learn about the differences between both platforms, what kind of possibilities the smartwatches bring to extending your application and how to share some code for your watch app between both iOS and Android versions.

• Paul Sturgess, programmer at Kyan will talk about his recent experience writing Title Challenge, a football management game written in RubyMotion.

• Rich Kilmer, CEO of CargoSense, will talk about how he uses RubyMotion to build an innovative solution to address issues in the logistics market.

We would like to thank everyone who submitted a talk proposal via our CFP form. Sadly we received too many proposals and we had to make a selection.

A tentative schedule is published on the conference website. We are pretty excited about the program! Video games, wearables, community libraries, practical tips... should all be very interesting!

We hope you can join us in Paris. Grab your ticket today!

We are also still looking for a small number of sponsors to share in the support of #inspect 2015. 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.

After Bart Myers and Peter Arzhintar sold SideReel in 2007, they decided to apply their experience and knowledge towards an app that enables a powerfully direct and immediate form of democracy. Countable is an app that gives U.S. Citizens a way to learn about what issues are being discussed in Congress, and enables them to take immediate action.

We endeavor to make Countable the most important app you use. It does something that has never been done before: give people an easy and portable way to see what is happening in government, get your voice heard and, in near real time, make sure your Representatives are listening. Nearly every attempt that has been made to do this was attempted with a politically savvy insider in mind as their audience. We endeavor to take the politics out of it and make it about governing - moving us closer to a direct democracy - where our representatives become an extension of our will.

What background did you come from when you started to build Countable?

The Countable team includes folks from both consumer internet and journalistic backgrounds. We’re not political insiders by any means and were largely trying to build a product that the average American could use to understand what’s happening in Congress and give us a way to effectively evaluate our Representatives.

What can users accomplish with your app?

We built a simple iPhone app that presents key legislation before Congress in an easy to understand manner - with big pictures, a clear, concise description, a pro and con argument, and resources to learn more. We give you a single action to take - vote YEA or NAY on the bill. Once you vote you can send your vote to your representative with one click and then you can share that you voted easily to FB or Twitter.

From there you can look at how your Representatives have voted on legislation, browse legislation by topics or issues that you care about, and generally stay informed. Users dig it.

Why did you choose RubyMotion?

The team is very comfortable with Ruby, we are using it extensively, and RubyMotion was really a no brainer as it solved a few key problems for us: rapid development, little retraining, and a native experience with access to key iOS functionality like notifications.

How did RubyMotion help accelerate your development?

First and foremost, being able to use the editor of my choice rather than Xcode while developing this app was HUGE. We did lose autocomplete, but being able to manipulate text programmatically in Vim sped up development by quite a bit. The other major win that we got from RubyMotion was to be able to write legible simple code. Objective-C code always seems to look just like a ridiculous garble of square brackets. Converting copied Objective-C into Ruby just felt happy. I would frequently go from a half dozen of complicated nested data manipulations to 5 clearly labeled simple methods.

What parts of RubyMotion development would you like to see improved?

We had a couple of issues with memory management. The way Objective-C determines whether or not it can remove an object is based on how many objects are attached to it not based on whether is even accessible to the current thread. Leaving any instance variable set on an object would just keep that object around in memory. We ended up writing a solution that nils out all instance variables when destroying an object. It would be great if RubyMotion acted a little more like Ruby here. The other thing we felt needed some work was the logging. If a method unintentionally called itself, the process would fail silently. It would be excellent if the process could actually throw a SystemStackError: stack level too deep exception. We can run the process with debug=1, and get trapped in a debugger where the fail exists, but even that debugger has a lot of garbage in its stack trace. Exceptions in general are not actually handled very well. We tried to send google analytics exception backtraces - locally calling exception.backtrace worked fine, but on the actual device, it returned nil. It would be fantastic if the Ruby file backtraces could be returned from a device.

How did you get help when you ran into a stumbling block?

For the most part, Stack Overflow was our friend. The debugger was occasionally helpful for finding line numbers, but we used a lot of print statements.

Did you take advantage of any third party gems or CocoaPods?

We did, we used ProMotion as our main framework, which did give us a few helper methods that we liked, but largely felt like it was not entirely well thought through. Once we pulled in SugarCube, everything came together really well. SugarCube is awesome. The animations, colors, gestures, and notifications helped us write code that felt good. I would still like to spend some time setting up a framework for our app with a proper event driven system using sugar cube's events.

If you haven't got your ticket already, we still have a few tickets left at the Early Bird pricing (33% discount over the regular rate). Grab your ticket today!

Today we are announcing 3 new speakers:

• Todd Werth, co-founder of InfiniteRed and creator of RMQ (RubyMotionQuery), will talk about RedPotion, an effort to build the "Rails for RubyMotion for iOS", a common set of high-level abstractions to make mobile development easier. Todd will cover the rationale behind the project and build a small app as well.

• Darin Wilson, software engineer at InfiniteRed, will cover the Android equivalent of RedPotion, conveniently called BluePotion (not yet released at the time of writing). Darin will give an overview of the BluePotion components and demonstrates how the API closely mimics RedPotion, providing a "learn once, write everywhere" approach to native mobile app development. A small app will also be built.

• Boris Bügling, software engineer at Contentful and Senior VP of Evil at CocoaPods, will provide an introduction on developing WatchKit and Android Wear apps using RubyMotion. We will learn about the differences between both platforms, what kind of possibilities the smartwatches bring to extending your application and how to share some code for your watch app between both iOS and Android versions.

They will join our existing lineup of 4 speakers:

• Laurent Sansonetti, creator of RubyMotion and founder of HipByte, will talk about what's coming next in RubyMotion. You probably don't want to miss this!

• Amir Rajan, creator of A Dark Room and The Ensign for iOS, will talk about his experience writing a RubyMotion app that has been downloaded several million times and been featured as the number 1 paid app in the US App Store for weeks.

• Paul Sturgess, programmer at Kyan will talk about his recent experience writing Title Challenge, a football management game written in RubyMotion.

• Rich Kilmer, CEO of CargoSense, will talk about how he uses RubyMotion to build an innovative solution to address issues in the logistics market.

We are still accepting talk proposals, so please feel free to submit one.

We are also still looking for a small number of sponsors to share in the support of #inspect 2015. 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.

Automatic setup of Android environment

To get started with RubyMotion for Android, a proper Android environment is needed, and we used to ask users to download and setup numerous components by themselves.

We now provide a single command that will automatically download and setup all the required components for you:

$ motion android-setup

The command will download the Android SDK and NDK, configure RubyMotion to use them, then run the Android UI to let you select versions of Android you want to develop for.

RubyMotion supports all versions of Android covered by the SDK, including the very latest API 22 (Android 5.1).

RubyMine supports RubyMotion for Android

Our friends at JetBrains are providing RubyMotion for Android support in RubyMine as part of the Satsuki Early Access Program.

You can now enjoy intelligent code-completion and toolchain integration when writing Android apps in RubyMine.

These are early-access builds, please keep in touch with JetBrains if you are running into issues.

Multi-architecture support, Intel, Genymotion

RubyMotion for Android projects can now be built for multiple architectures instead of one. Previously-supported architectures were armv5te and armv7, and we now support x86 (Intel 32-bit) as well.

You can specify the architectures you need by changing the app.archs setting in the Rakefile of your project:

Motion::Project::App.setup do |app|
  ...
  app.archs = ['armv5s', 'x86']
end

Intel support is not enabled by default, but can be added if you want to use a faster emulator. The built-in Android emulator is notoriously slow, but 3rd-party products such as Genymotion provide faster alternatives.

To use Genymotion with RubyMotion for Android projects, you simply need to download it (it's free for personal use), then create a virtual device, and make sure it is launched. After that, configure your RubyMotion project to build for the x86 architecture, and use the default rake task which will talk to the default Android emulator.

$ rake emulator
$ rake           # shortcut for 'rake emulator'

The application will show up immediately in the Genymotion device and the interactive console (REPL) will also be connected to it.

3rd-party Java dependencies with Gradle

Gradle is an advanced build tool that can be used to manage 3rd-party dependencies in a Java-based project. As it seems to be highly popular in the Android world we decided to abstract this functionality into a RubyMotion gem: motion-gradle.

motion-gradle lets you easily describe 3rd-party Java dependencies in your app, similar to motion-cocoapods in an iOS project.

In order to use it, you need to install Gradle first (you can do this via homebrew) and make sure the gradle executable is in your $PATH. You also have to add the motion-gradle gem in the Gemfile of your project.

The gem exposes a new API to define dependencies, following is an example:

Motion::Project::App.setup do |app|
  # ...
  app.gradle do
    dependency 'com.mcxiaoke.volley', :artifact => 'library', :version => '1.0.10'
    dependency 'commons-cli'
    dependency 'ehcache', :version => '1.2.3'
  end
end

After that, you can run the gradle:install task which will download the required dependencies from the main Gradle repository and make sure they are properly vendored in the build system of the RubyMotion project:

$ rake gradle:install

After this command, all the Java APIs in these libraries should be available from your Ruby code.

Build system improvements

We extended the Rakefile project configuration object with the following settings:

• app.manifest: a special object that will be used to create the AndroidManifest.xml file during the build. You can configure the entire manifest from there. More information on the Project Management Guide.

• app.optional_features: same as app.features except that they will be exported as optional in the manifest file. This could for instance be used when your app may require camera access, if it is available.

app.optional_features << 'android.hardware.camera'

• app.support_libraries: a convenience way to specify the Android support libraries to be included in your app, instead of manually vendoring them.

app.support_libraries << 'google-play-services'
app.support_libraries << 'android-support-v4'

• app.theme: lets you set the theme of the app. The default value is Theme.Holo.

app.theme = 'Theme.Holo.Light'

Also, Bundler is now integrated in new projects. Dependencies can be added to the Gemfile as usual.

Finally, we improved the build system to make builds faster. Ruby files are now compiled in parallel jobs, exactly as in iOS and OS X projects, and the link phase (when generating the machine code library) was also shortened.

Despite these features and improvements, the Android support of RubyMotion is still in active development, compared to the more stable iOS version. We are fully committed in supporting Android and we will keep releasing builds on a monthly basis, which we have done since we publicly launched it in December.

Interesting in meeting the RubyMotion community and also discovering future directions of the product? Join us the 1st and 2nd July in Paris, France for our annual developer conference. Grab your ticket today!

Photo by Lima Pix on Flickr.

The conference will be happening at Ecole 42, a private software programming school with over 1700 students. 42 is funded by Xavier Niel, a French entrepreneur and businessman active in the technology industry in France.

We will be using the same format as before, a two-days one-track schedule, and we will be setting up a party at the end of the second day to celebrate.

Today we are pre-announcing 4 speakers:

• Laurent Sansonetti, creator of RubyMotion and founder of HipByte, will talk about what's coming next in RubyMotion. You probably don't want to miss this!

• Amir Rajan, creator of A Dark Room and The Ensign for iOS, will talk about his experience writing a RubyMotion app that has been downloaded several million times and been featured as the number 1 paid app in the US App Store for weeks.

• Paul Sturgess, programmer at Kyan will talk about his recent experience writing Title Challenge, a football management game written in RubyMotion.

• Rich Kilmer, CEO of CargoSense, will talk about how he uses RubyMotion to build an innovative solution to address issues in the logistics market.

We need more speakers. If you are interested in speaking at the conference please consider submitting a call for paper!

We are also looking for a small number of sponsors to share in the support of #inspect 2015. 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.

We are now offering in limited quantity Early Bird tickets at €229 (a 33% discount over the regular admission ticket). We always sell out the conference, so grab your ticket today!

To those interested in getting help learning RubyMotion, we will be organizing a one-day workshop the day before the conference (30 June) where we will introduce the basics of iOS and Android programming with RubyMotion. You can buy a workshop ticket as well.

The forum replaces the Google Group which has been around since we launched, 3 years ago. It was time to switch to a newer alternative offering a better user experience, and we decided to go with a Discourse forum.

We would like to thank Will Raxworthy of InfiniteRed for setting this up.

Please join us and create an account today!

Fandor decided to go with RubyMotion to build their iPhone and iPad apps.

What were the goals for the redesigned Fandor app?

Our film database is full of classic and avant-garde films, so our first version of this redesign includes features most important for watching these films, as well as sharing them, saving them for later, and searching our extensive database.

Why did you choose RubyMotion to build this version?

RubyMotion allowed us to move quickly, and rebuild our app from the ground up in a matter of months with limited resources.

What were the features of RubyMotion that allowed you to build your app so quickly?

First, RubyMotion is Ruby. Everyone at Fandor comes from the Rails world. Being able to write in Ruby and use Ruby idioms let us code faster. We know how to write beautiful Ruby code. While learning the iOS SDK, we didn't have to simultaneously discover what beauty means in Objective-C (if there is such a thing).

Second, RubyMotion is developer-environment agnostic. By using RubyMotion, we also removed the overhead of learning Xcode. Our engineering team felt like Xcode was bloated and confusing. We each used our own IDE of choice. I can't imagine not using RubyMine - the ease of being able to jump to method or class definitions makes code reading (of both our own and external libraries) incredibly easy.

Using RubyMotion, did you run into any issues integrating native or third party tools?

The only issue we had was with the ARAnalytics Objective-C library - I wanted to use its method swizzling to centralize our analytics. We tried a few times to get it to play nice with us, but there were some confusing low-level Objective-C integration problems that became too costly to solve.

What native frameworks did you use to build your media player?

We used MPMoviePlayerViewController - it was the most straightforward option available to us. There have been some product requests that have come in recently to change the player functionality, so if those keep coming, we may explore a more low-level option like AVPlayer.

What were the biggest challenges building your app?

Getting acquainted with the iOS SDK was quite difficult at times - the system felt significantly more opaque than the open-source Rails world.

Learning how to code idiomatically was also costly. We threw away a lot of the code we wrote in the first few weeks. We sometimes came up with solutions that didn't use the hardware effectively or introduced memory leaks.

Additionally, there were a some genuinely difficult programming problems that came up. Our designers had some pretty ambitious initial designs for the layouts of the film that were algorithmically intense.

How did you research answers to issues when they came up?

Here are the resources we used, in order of frequency:

1. Stack Overflow
2. Apple Documentation
3. Third party blogs / gists
4. Apple example applications

And when all else failed, we used the amazing Infinite Red consulting company as a backstop to our own knowledge.

What open source tools would you recommend to other RubyMotion developers?

We used RMQ extensively in our app, and it made creating layouts significantly faster. I recommend it.

What kind of programming were you doing when you started using RubyMotion?

I have been a Front-end developer for 10 years now, starting with Java, then .Net and now focusing purely on Web, iOS and Mac. Over the years, I have also developed good taste in design, so these days I see myself as a Designer/Developer hybrid.

How did you get started on QuickLens and RubyMotion?

Before RubyMotion announced support for OS X in their 2.0 version, I was coding away in MacRuby and Objective-C. Although MacRuby was great for prototyping, it was lacking the maturity and polish of RubyMotion. When 2.0 came out, it totally changed my world. I immediately jumped on it and was able to build the first version of my app within 3 days! In fact I even tweeted about it at that time.

The ride on the RubyMotion train wasn't always scenic. I had a few memory related issues, API incompatibility with frameworks like Carbon and the occassional regression. But thanks to the fantastic support, all of these were fixed very quickly. Overall I have been very happy with the productivity. Frankly, without RubyMotion, I would have taken much longer to ship 1.0 of QuickLens.

Speaking of support, what did you do when you ran into issues with the compiler?

This has happened a few times, especially early on when RubyMotion just announced support for OS X. I had issues with certain function signatures (esp. those involving blocks) or some weird crash in Cocoa/Carbon API, which was hard to debug. Most often I would hit up motion support and file a ticket. Eloy, Joffrey or Shizuo would generally respond within a day and sometimes file a separate ticket on YouTrack. Sometimes even Laurent would chip in with some work arounds. I also had some trouble with the Pointer class when using with some Carbon API. For example, here is a snippet that took me several days to figure out, with lots of help from Laurent!

This snippet is part of the Carbon API that reads the default keyboard layout. I use it in my custom control for recording Global Hotkeys.

currentKeyboard = TISCopyCurrentKeyboardInputSource()
layoutDataPtr = TISGetInputSourceProperty(currentKeyboard, KTISPropertyUnicodeKeyLayoutData)
keyboardLayout = layoutDataPtr.to_object.bytes.cast!(UCKeyboardLayout.type)

layoutDataPtr is an instance of Pointer. The last line where I apply a chain of methods was quite hard to figure out!

What is it about RubyMotion that makes you feel so productive?

I think its a combination of the command line tools, REPL, the Ruby language and the awesome and vibrant community. I have learnt a lot from the experiences and code shared by folks. Reading the code of libraries such as: Bubblewrap, Promotion, Sugarcube, RubyMotionQuery and many others has been quite illuminating. It has given me enough impetus to structure my own code. I sure want to contribute back in my own little way, hopefully by open-sourcing some of the reusable parts of my app.

I should also mention that the Apple frameworks, especially AppKit, Cocoa, Quartz, QuartzCore are very well designed. With the Ruby language, they become more approachable and easier to use.

What features in Cocoa or Xcode did you feel were difficult in RubyMotion?

As I mentioned earlier, it was the early battles with block based Cocoa APIs and some Carbon APIs. A particular block-based Cocoa API which troubled me was:

panel = NSOpenPanel.openPanel
panel.beginSheetModalForWindow window, completionHandler: ->(result) do

end

The first time it was a compiler issue not identifying the block signature properly. Then it was fixed in the next RM release and then there was a regression and finally fixed in a later release. It was an interesting roller-coaster ride with that API :-)

Using Interface Builder for designing some of the views and windows was also a bit of challenge. In the end I created an empty XCode project with all the xibs and a simple Stub.h file that had the interfaces for all the Views, Controls, ViewControllers and Windows. Luckily IB picks up changes to the Stub.h in real-time, so the workflow is not that bad.

Are there any tools that you recommend to new RubyMotion developers?

I have personally used the JetBrains RubyMine IDE with great success, so that is definitely recommended. Other than that, I would encourage learning some Objective-C as well, which will help when converting some APIs into Ruby. Once you get comfortable with the RubyMotion toolset, it really comes down to understanding the AppKit, Cocoa and other framework APIs. I have really spent a disproportionate amount of time in the Cocoa and Quartz API docs for this app. RubyMotion is really fun once you get a good grip over the Apple Frameworks! Know Thy API.

Instruments is one other tool that every developer should know well. Effective use of Instruments is the key to identifying and fixing memory leaks and performance issues.

Now that you've built the entire app using RubyMotion, would you choose to use it again if you had to start over?

In light of the recent WWDC announcements, it may seem that Swift is a natural choice for new apps. Although the syntax and features are great, it is still very new and has lots of issues with Cocoa APIs. I did some of my own experiments and found it very tedious with all the type-casts for Cocoa/Quartz APIs. That coupled with the crashes and poor editor support in XCode really makes it a frustrating experience. I am sure Apple will improve this over time but as of now, it is pretty bad. Actually it seems worse in contrast to the experience I've had with RubyMotion and RubyMine IDE.

Additionally from a language point of view, Ruby seems more suited for UI development than Swift. Add in some meta-programming ideas, and you have a powerful system in your hands.

Thomas Fuchs began his programming career with a 4MHz behemoth, and is now the proud owner of Slash7, a bootstrapped company that he started with his wife Amy Hoy.

They built Freckle, a friendly online time tracking system, and decided to go with RubyMotion to build an OS X app for it.

Can you tell us a little about your company, Slash7?

We’re a proudly bootstrapped mom & pop company (my wife Amy Hoy and I own and run the company). We founded Slash7 in 2008 (the same year we got married, and my wife moved internationally!), and financed our build-a-product endeavors by doing high-end consulting for lots of companies you probably have heard of (among them Nokia, Ford, Pepsi, just to name few).

After 2 or 3 years or so of bootstrapping, and then moving internationally again (this time to Philadelphia), we finally could live off the profits from our main product, Freckle. Amy is doing the high-level feature planning, design and marketing of Freckle. I’m mostly down in the trenches and do most programming, lots of details design and I keep the servers running. I also dabble in marketing. We have 3 employees now, so it’s like a real company or something.

My wife also runs a business course for people like us who want to run product-based, sustainable businesses (30x500.com), and we have a yearly conference on this (baconbiz.com).

Tell us about Freckle

Freckle is a web-based SaaS for time tracking and invoicing. We built it based on the pain we experienced as consultants using time tracking software (ugly, clunky, lots of configuration, can’t track unbillable work, etc.) and wanted something that’s friendly, requires zero upfront configuration, is forgiving and fast and stays out of your way when you don’t need it. We’re definitely not passionate about time tracking (if anyone tells you they are, they are lying). We’re passionate about making our customers more awesome, by giving them a tool that helps them make more money and live better lives.

Over the years it became clear that we needed to augment it with native apps, for both iOS (most of our customers have iPhones) and Macs (about 60% of our customers are on Macs!).

Freckle is a Rails app, and I’ve been a Rails user since before 1.0 was released (I also was a member of the Rails core team for quite a while back in the day). My open source library script.aculo.us, together with Sam Stephenson’s Prototype.js formed the backbone of early Ajax/Effects support on Rails.

And the OS X version?

Back to the present, when RubyMotion was released with support to create Mac OS X apps I knew that it would be the right to develop a Menubar Mac App for Freckle, which is something we wanted for a while but never got around to do it. I never could get myself to get into Objective C, and I don’t like working in an IDE either. Long story short, after just a few weeks and maybe 100 hours or so of work, we know have our app in the App Store and our users are loving it and giving it rave reviews. :)

Were there any surprises going with the hybrid native-app / web UI approach?

No biggies, just a few curious decisions in the design of Appkit’s APIs. The most annoying problem is the lack of proper APIs for NSStatusItems on multiple screens. As you might know, Mavericks added support to show the menubar on all attached screens, but they didn’t bother with adding APIs to enable menu items manually—it all magically works but only if the user actually uses the mouse and clicks on the item (Appkit figures out the screen and clones your status item’s window somehow). Because we provide a global keyboard shortcut (something only possible with the old Carbon APIs!), I spent quite some time figuring out how to properly show our app on the right screen, return to the current app when closing it, etc. That actually took up most of the development time.

I also was honestly surprised how buggy the WebView class is, especially with hardware-acellerated compositing. There’s a lot of issues with this especially on Mountain Lion, whereas Mavericks works pretty great. I can see why Yosemite will bring a completely new unified class to use WebKit in applications. This is great news for companies like us who primarily have a web-based app and want to ship great native apps to compliment it.

What is your development cycle when you work on the RubyMotion app?

I use SublimeText 3, the Terminal, and Dash, there’s not much more to it. :) We did have a beta test phase where we used HockeyApp, which worked great. The combination of RubyMotion and AppKit is very stable, we barely had any crashes that we had to debug. One interesting crash is happening on Yosemite, I’m still investigating that… joy! ;) I keep several older Macs around as we support 10.7 and up.

How did you find resources to help you build your first Mac app?

A lot of the online resources for Objective-C programming, especially fixing issues with API bugs and omissions are unfortunately pretty crappy (for example on StackOverflow). More Mac and iOS programmers should blog! It’s easy to translate Objective-C example code to RubyMotion (usually shedding 80% of superfluous code in the process) and to adapt code examples from Apple. Apple’s docs are pretty great and normally API calls map to RubyMotion in a straight-forward fashion.

So, please blog more, people! I plan to do a write up of the internals and structure of our menubar app once I get a chance!

Are there any tools or abilities that you would like to see added to RubyMotion

I’d love to see some code analysis tools that warn me about API incompatibilities and things that could be problematic in the App Store. I wouldn’t say no to CodeClimate support!

If you build another app, will you write it in Obj-C, RubyMotion, or Swift, and what influences that decision?

While I like the direction Apple is taking with Swift, it’s not a real replacement for Ruby, which I love. We’re actually working on another application using RubyMotion, a 2.0 of our iPhone app (the current one is just a Cordova wrapper around our mobile website, which works but could be so much better). We’re going a full-hybrid approach, with native navigation but web content, similar to the Basecamp app. I hope to launch that some time this summer!

Android Platform

The RubyMotion Android support that we released in public beta a few weeks ago has been integrated into the stable release.

If you have been following our pre-release channel you might have seen that we have been doing several updates and following several customers using it. We now believe that the support is good enough to be used by everyone, and we woulc like to encourage that.

As of RubyMotion 3, we support all versions of Android, up to the latest one (5.0 Lollipop). You can call into the entire set of Java APIs for these platforms, and you can also integrate 3rd-party Java libraries.

The interactive console that you know and love from iOS is available when running in the emulator and in the device.

A debugger interface, based on ndk-gdb, is available. You can simply pass the debug=1 argument to the rake emulator or rake device tasks. You can set breakpoints, inspect backtraces, variables, and more. This is possile since our compiler generates proper DWARF metadata for your Ruby code.

$ rake device debug=1
...
(gdb) break main_activity.rb:16
Breakpoint 1 at 0x5ec294d0: file main_activity.rb, line 16.
(gdb) continue
...

Finally, a spec framework is available. This is the exact same framework used in iOS and OS X projects, so you should feel at home. Specs can run on both the emulator and the device, using the respective rake spec:emulator and rake spec:device tasks.

$ cat spec/main_spec.rb 
describe "Main activity" do
  it "has a title" do
    main_activity.title.should == "Hello"
  end
end

$ rake spec:device
...
I/com/yourcompany/hello( 2024): Main activity
I/com/yourcompany/hello( 2024):   - has a title
I/com/yourcompany/hello( 2024): 1 specifications (1 requirements), 0 failures, 0 errors

For more information about the Android support in RubyMotion, check out the following guides:

• Getting started
• Runtime
• Project management
• Debugging
• Testing

As a side note, now that Android support is in the stable release we recommend that you update your RubyMotion Android projects to point to /Library/RubyMotion/lib (and not /Library/RubyMotionPre/lib).

WatchKit Apps

As of 3.0 RubyMotion lets you write Apple Watch apps in Ruby using WatchKit.

A WatchKit app is linked to an existing iOS app, as an extension. To create a WatchKit app in RubyMotion, you will first need to install the latest build of Xcode 6.2, which comes with iOS 8.2 Beta. Then, simply use the ios-watch-extension template inside an existing iOS project.

$ motion create --template=ios MyHostApp
$ cd MyHostApp
$ motion create --template=ios-watch-extension MyWatchApp

Then, configure the project's Rakefile to include the WatchKit extension:

Motion::Project::App.setup do |app|
  ...
  app.target "./MyWatchApp", :extension
end

Finally, you can run the watch app in the simulator:

$ rake watch

WatchKit support is still in development and will be improved in future updates. For more information about WatchKit, make sure to read Apple's WatchKit Programming Guide.

Finally, there has been several recent important changes that we didn't cover in our blog.

iOS 8 Extensions

iOS 8 introduces extensions, which let apps extend their functionality and become available to users while they are using other apps.

RubyMotion lets you create iOS 8 extensions through a myriad of templates:

• ios-action-extension
• ios-custom-keyboard
• ios-document-picker
• ios-file-provider
• ios-photo-editing
• ios-share-extension
• ios-today-extension
• ios-watch-extension

For more details, check out the ExtensionsAndFrameworks project in our samples repository.

iOS 64-bit

As you might have heard, the iOS App Store will require apps to be compiled for 64-bit before a submission in February 2015.

RubyMotion supports ARM 64-bit since some time. We recently improved the 64-bit support in both the compiler and the runtime, and as of RubyMotion 3.0, iOS apps will now compile for 64-bit by default.

If you enabled 64-bit in your project Rakefile, you can now safely remove that, since it will build for 64-bit.

Application Size Reduction

RubyMotion apps are statically compiled into machine code. If your project has a lot of Ruby files, this can lead to a pretty big binary at the end.

We have been working on reducing the code size of the object files that the compiler generates. In a recent update, the size of RubyMotion executables has been reduced from 30% to 60%, on average.

We are not done yet and we will keep improving the toolchain to generate apps that are as small as possible.

After a lot of thinking we decided to split our pricing model into three plans. We will go through them now then cover questions you might have at the end.

Indie

Indie is our cheapest plan. It comes with support for all platforms, as well as full software updates. It is cheaper than our previous plan.

Indie customers can access the community forum, a public place where members of the RubyMotion community, including the engineers working on RubyMotion, help each other.

Professional

Professional is our medium-entry plan. It comes with support for all platforms, software updates, and access to our private ticket system.

Professional customers can contact us directly and privately with a support ticket. We usually reply within 3 business days, and often sooner.

Enterprise

Enterprise is our high-entry plan. It comes with support for all platforms and software updates. Please contact us for a quote.

We provide 1-day reponse time to support enquiries from our Enterprise customers as well as hot fixes through a dedicated software update channel.

FAQ

Platforms Support

All plans come with support for iOS, Android and OS X. We believe that cross-platform mobile development is very important at this age and we don't want to segment the RubyMotion community.

Existing Customers

Existing RubyMotion customers will be moved to the Pro plan, and once their subscription expires, will have the opportunity to stay in Pro at the discounted rate for an additional year.

Thank You!

We would like to grab the chance to thank all of our awesome customers for their continued support. Without it we could not be a fully bootstrapped company.

RubyMotion for Android

After long deliberation, the team decided that RubyMotion should be a single product that supports iOS, OS X, and now Android as well. It is our belief that the vast majority of mobile developers have to (or would like to) target both iOS and Android. Therefore it makes more sense to us to provide support for all platforms in a single package over selling multiple separate packages.

Thus, there will be no extra charge for the Android version of RubyMotion. Yes, you read that right, 0 extra euros, dollars, or even yen!

With just a one-click purchase, one will be able to write iOS, Android and Mac apps, all using the same toolchain, language and text editor.

Updates and support renewal

In the past, RubyMotion has been a one-time purchase that came with one year of updates & support and it was possible to renew the updates & support at half the price of the full license. However, with several thousand customers, the math makes it so that this is no longer sustainable over the long term.

For one thing, we have been answering many support questions concerning more than just the RubyMotion toolchain. We take pride in being able to do this because we care about our customers, and we want everyone’s experience building RubyMotion apps to be a good one. As a nice side-effect, this has allowed us to respond to your needs by putting out regular monthly software updates that improve the total experience for all our customers. We believe it is in everyone’s best interest to keep doing this, but the fact is that we are now increasing our workload by a factor of 2 with the addition of the Android platform.

Therefore, RubyMotion license renewals will now be priced at the same price as a new licenses. This will help us better scale our organization for the development, maintenance, and our support of RubyMotion for everyone going forward into this new bright future.

To summarize, annual charges will be set at $199,-. That’s only $16.50 a month. We personally spend more than that on coffee ;)

Thank you all for your continued support! Without it we could not be a fully bootstrapped company, free of investors saying what we should do over what we think is important for you, our customers.

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!

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!

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:

• Fixnum is based on java.lang.Integer
• Float is based on java.lang.Float
• String is based on java.lang.CharSequence
• Array is based on java.util.ArrayList
• Hash is based on java.util.HashMap
• Regexp is based on java.util.regex.Pattern
• Thread is based on based on java.lang.Thread
• etc.

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!

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.

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!

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.

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.

(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.

(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.

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.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas nec volutpat diam. Nullam mollis bibendum odio sit amet pharetra. Integer tristique, justo eu accumsan vulputate, justo metus scelerisque ligula, sit amet porttitor odio lectus non velit.

Nulla mattis, enim id luctus molestie, magna orci iaculis justo, aliquet bibendum nisi dolor sit amet ipsum. Donec eu ornare sem. Sed rhoncus, eros nec convallis mattis, nibh neque dapibus lacus, ut semper leo augue non ipsum. Integer fermentum aliquam arcu, non

Jekyll also offers powerful support for code snippets:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.

The app was recognized as Best of 2013 by Apple and is fully developed with RubyMotion! We sat down with Christoffer Tews, one of the folks at Jimdo responsible for the app.

Can you tell us a bit about you?

My name is Christoffer Tews. I started at Jimdo ~2 years ago with a student job during my Master of Science in eCommerce . I wanted to do something in the mobile development because my bachelor thesis had been about implementing an iOS shopping app with Appcelerator Titanium and the whole mobile development is just exciting.

So I came to Jimdo and started to work as a student on the very first day on the iOS app of Jimdo with Mark Frawley (Developer) and Jan Schlie (Designer). The team grows up to 10 people later. While doing my masters thesis (building a usability framework for iOS) I decided to join Jimdo as a full time employee, because I loved the product especially the iOS app and the dev team around it. And I still freaking love it! ;)

What is Jimdo the company?

Jimdo is the easiest way to create a website. With a simple, intuitive interface, Jimdo enables anyone to create a unique website with a blog and online store. Our motto—Pages to the People!—sums up our mission: Put the power of website creation into everyone’s hands. Whether you want to start a business, promote your music, or simply share photos with your friends and family, you can create your home on the web with Jimdo.

Since it was founded in Hamburg in 2007 by young entrepreneurs Christian Springub, Fridtjof Detzner, and Matthias Henze, Jimdo has grown tremendously. We’ve helped people build more than 10 million websites and Jimdo is now available in 12 languages. Our team of 170 people come from 15 different countries and work in 4 offices worldwide.

If you want to know how much fun it is to work at Jimdo just look at this page.

What did you make with RubyMotion?

Our iOS app allows users to build a complete webpage for themselves or their business on directly from their mobile device. It’s not like other apps, where you can just edit some parts of your website and maybe don’t even see your site because of a „special user interface“ to edit the content.

With the iOS app of Jimdo you can edit the website simply by touching an element on your website e.g. a headline, some text. You can also structure your entire site’s content with our simple, gesture-driven in-app navigation editor.

What role does the Jimdo iOS app play in your business, and related to that: why did you decide to build the app?

So from the business point of view it has two primary goals. First, it is a value-added service to the existing Jimdo web service, allowing our users to easily update their site with rich media and text while away from their desktop. Secondly it serves as a new platform for organic discovery of our brand, a way for new and different demographics to discover us. We offer the iOS app for free - it doesn’t matter if you are using the Jimdo Free package or the Pro/Business package. The only difference between the packages is, that Pro or Business users will get some extra features in the app that are not available for Jimdo Free users, e.g. Statistics (page views, visitors, etc.), extended Shop features etc. These extra services will grow with the time and we will also always enhance the core app features for Free users to stay true to our core value Pages To The People!.

Given your experience using Appcelerator Titanium, why did your team choose RubyMotion to build the Jimdo app?

So we must admit that we chose Titanium Appcelerator in the beginning (before RubyMotion was released), because Jimdo is a web product with lots of front end web development experience and it seemed a good choice to build a cross-platform app which we could re-use instead of building a native app for just one platform.

However, after about 2 months we regretted choosing Titanium. It was sometimes slow, not very flexible (there were issues customizing TableViewCells and other native UIKit components without writing Objective-C). The support for newer iOS SDK features always lagged months behind Apple releases, and so it impeded our ability to quickly new version-specific features. In short it became clear that building a high- performance app with a huge amount of (UI)-customization wasn’t clearly feasible with Titanium.

Apart from that, developing a complex hybrid app with Javascript was clearly no fun at all. In particular, some things that bothered us were: Lack of proper namespaces, classes, accidental global declaration, minor syntax errors passing without warning, undefined variables discovered at runtime etc.

After a new evaluation of possible alternatives we found the freshly distributed RubyMotion framework. We were a little bit afraid of choosing a brand new framework especially because we wasted 2 month of development at this point, but it’s implementation of the Ruby language is directly based on the Cocoa APIs and data types. Therefore, and because it is compiled ahead of time, it’s performance is much closer to standard Objective-C. Also, the possibility to vendor in Objective-C (3rd party) libraries with one line of code, was and is, just awesome. Also at this point ARC wasn’t completely released yet and the built-in garbage collection from RubyMotion made our code very terse in comparison to Objective-C.

Even our UI-Designer started to write code. We built our UI without using Storyboard, our entire UI is built with a mix of reusable procedural code and Teacup stylesheets.

What technologies from iOS did you use, and did you have any issue accessing those in RubyMotion?

That is kind of a tough question, because we really use the whole spectrum of iOS technologies. I think there is almost no UI element that we haven’t implemented and customized in our app.

We make heavy use of RubyMotion’s excellent support for Objective-C Categories, which makes implementing delegate protocols very simple. In terms of Apple Frameworks, we use CoreData for non-sensitive data, and Keychain Services to save sensitive data securely on the phone. We also completely redesigned our app to adhere to iOS 7 design guidelines, which includes blurred background images, transparency, flat UI where it makes sense.

We’d like to extend our thanks to the RubyMotion team here for supporting the iOS 7 APIs since its beta stages and for the constant (weekly) updates to fix bugs. We only faced limitations when we tried to (ab)use the Runtime class of Objective-C for meta=programming patterns like method swizzling but this could be solved by writing our own wrapper in Obj-C and vendor it in.

Apart from that we really weren’t confronted with many bugs in RubyMotion and even when there were, our mails and pull requests were answered promptly and the fixes were usually implemented in the next weekly update. We wonder if Laurent gets much sleep because his response time answering emails was never longer than 15 minutes whatever time it was ;) Thanks for that!

What gems, CocoaPods, and other libraries did you use, and which did you find the most useful?

First of all: Teacup! It is just great for designing the UI, decouple the code from the views or controllers and makes it easy to customize elements for different iOS versions.

And we use the following Pods and libraries: SSKeychain, AFNetworking, AdjustIO, Thrift, Crittercism, Reachability, Google Analytics, and much more…

What did you learn from writing this app in RubyMotion that you will remember the next time you need to write an app?

We had a lot of learnings there. Some were about code quality and trying to use patterns like MVC correctly in Cocoa. Others were about how to create useful, maintainable automated tests. We decided very early to establish automated tests but our focus was more on Acceptance Tests written in Cucumber format with the Frank Framework. This was and is still a good solution to our needs but an actual test run take almost 1 hour.

So we decided to increase our unit test coverage with the inbuilt “rake spec” MacBacon framework that ships with RubyMotion. These tests of which we have several hundred already only take a couple of seconds to execute which gives us more immediate feedback.

One of our learnings so far is, start writing unit tests for your iOS app as soon as possible and as much as possible - it really makes you think about your class/module interfaces and encourages you to decouple views, controllers and methods so as to be more testable. It just makes your code better and more solid. You also don’t start to panic on your next upcoming release, if there’s a bug, because you can just test it.

Would you recommend RubyMotion to other developers who are going to start learning iOS app development?

Definitely yes! As mentioned in the intro, we started of with 3 people on the mobile team. All 3 of us hadn’t much experience with Obj-C or Ruby. RubyMotion empowered us to learn both in a very short time. Learning Ruby is quite easy, even combined with learning the iOS Cocoa APIs, it has a flatter learning curve than adding Objective-C into the mix.

From my personal point of view I would even say if you want to learn writing native iOS apps, RubyMotion is the fastest, most technically solid way to do it. I personally also recommend it to academic courses which are usually of a 2-3 month duration (one semester) - a period where it’s hard to additionally learn Obj-C and write a good working prototype in parallel.

When you needed to find out an answer to a tricky problem, how did you get the help and answers you needed?

The support at the RubyMotion Google Group is really good and the response time there is also fast (max. 12h until first response). As some of us had already met Laurent at the BubbleConf in Amsterdam, we just sent him emails directly, but we try to do it only when it really gets technically deep into the RubyMotion implementation or if we have found some curious bugs. I’m pretty sure he thinks “Arrr! This Jimdo dudes again” ;), but as mentioned, his responses were fast and he’s still polite. He doesn’t send standard phrases like “Please open a support ticket at…”, even if maybe he should sometimes to stay sane. Also Colin is really active and helpful in the Google Group.

For a company of this small size, with what I imagine is a huge customer base, HipByte is really responsive. Thanks again for that!

RubyMotion #inspect is our official conference. It is organized for and by the RubyMotion community and aims at covering all the technologies that surround the RubyMotion ecosystem. This is the place where RubyMotion enthusiasts can finally meet face-to-face to chat, connect, hack together and learn what’s happening in the community.

Last year #inspect was organized in Brussels, Belgium. We definitely had a blast. Many guests told us it was the best conference they ever attended. This year we will change a few things and try to innovate with the conference format.

We booked an awesome venue for the event, Fort Mason, a National Historic Landmark right in the Marina district of San Francisco. We will be scheduling at least 16 talks as well as workshops, informal panels, and more activities. Like last year, we will also deliver awesome food and celebrate the end of the event with a great party.

We already pre-selected 8 awesome speakers. If you would like to speak at the conference we definitely want to hear from you.

Early-bird tickets are available, at 25% off the regular admission price, in limited quantity. Don’t wait too long. Like last year, the conference is designed to be small and intimate, and will likely sell out before the event.

To those interested, we will also be running a 2-day training right before the conference. It will be a shorter version of our official training program and will be delivered by core RubyMotion engineers. We conveniently provide a Training+Conference ticket.

Finally, we are 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.

We will be posting more information about the event very soon. Stay tuned and see you in San Francisco!

Device Crash Reports

It is an unfortunate reality that applications crash. This is even more so the case during development cycles.

Until today, the best way to deal with device crash reports during development was to use the Xcode organizer. As a lot of you already know, the user experience was far from ideal and symbolication did not always work as expected.

As of RubyMotion 2.18 we are happy to introduce a long-awaited Rake task to deal with device crash reports: rake crashlog:device.

The task will:

1. Connect to your development device
2. Retrieve all crash reports generated by your app
3. Symbolicate them using the .dSYM bundle created by our build system
4. Save the final reports on your file system
5. Open the last generated report in Console.app

Let us show you an example. We create a new RubyMotion project and slightly change the application delegate method to trigger one of those UIKit-level exceptions which will crash the process hard.

class AppDelegate
  def application(application, didFinishLaunchingWithOptions:launchOptions)
    NSArray.arrayWithArray(42)
  end
end

As expected, running the app on the device causes a crash.

$ rake device
[...]
    Deploy ./build/iPhoneOS-7.0-Development/foo.ipa
*** Application is running on the device, use ^C to quit.
Dec 29 21:01:49  foo[936] : -[__NSCFNumber count]: unrecognized selector sent to instance 0x17da1190
Dec 29 21:01:49  foo[936] : *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFNumber count]: unrecognized selector sent to instance 0x17da1190'

Since this is a lower-level exception happening on the device the terminal output does not contain its full backtrace. We could easily get it by connecting a debugger, but let’s use another way! Since the application crashes a report was generated on the device. We can use the new rake crashlog:device to retrieve that report and see what happened.

$ rake crashlog:device
New crash report: /Users/lrz/Library/Logs/RubyMotion Device/foo_2013-12-29-210200_lrzs-iPhone.crash

The command saved a new crash report file and opened it in Console.app. This is what we can see (some of the lines have been trimmed out for better readability):

Last Exception Backtrace:
0   CoreFoundation                  0x2f013e7e __exceptionPreprocess + 126
1   libobjc.A.dylib                 0x393706c2 objc_exception_throw + 34
2   CoreFoundation                  0x2f0177b2 -[NSObject(NSObject) doesNotRecognizeSelector:] + 198
3   CoreFoundation                  0x2f0160aa ___forwarding___ + 702
4   CoreFoundation                  0x2ef64dc4 __forwarding_prep_0___ + 20
5   CoreFoundation                  0x2ef4d70c +[NSArray arrayWithArray:] + 40
[...]
9   foo                              0x00097008 rb_scope__application:didFinishLaunchingWithOptions:__ (app_delegate.rb:3)
[...]

As we can see, the last frame from our application (highlighted here) in this exception backtrace was in the app_delegate.rb file, line 3, which coincides perfectly with our wrong arrayWithArray: call.

Just by typing one command in the terminal we were able to determine what went wrong on the device. Pretty cool, isn’t it?

Pretty Vendor Build Output

The RubyMotion build system invokes the xcodebuild tool in order to build Xcode-based projects. If your project uses CocoaPods or manually vendors Xcode-based libraries you already know that the build terminal output can be messy sometimes.

As of RubyMotion 2.18 the build output of Xcode-based projects will be consistent with the rest of the build. Here is an example of the new output of a project that uses CocoaPods.

     Build ./vendor/Pods/Pods.xcodeproj [SORelativeDateTransformer - Release]
   Compile ./vendor/Pods/Pods-SORelativeDateTransformer-dummy.m
   Compile ./vendor/Pods/SORelativeDateTransformer/SORelativeDateTransformer/
           SORelativeDateTransformer.m
      Link ./vendor/Pods/.build/libPods-SORelativeDateTransformer.a
     Build ./vendor/Pods/Pods.xcodeproj [Pods - Release]
   Compile ./vendor/Pods/Pods-dummy.m
      Link ./vendor/Pods/.build/libPods.a

This feature would not have been possible without integrating the awesome XCPretty project, created by Marin Usalj and Delisa Mason.

Proc#weak!

Since RubyMotion relies entirely on the underlying iOS’ retain count memory model, creating cyclic references is unfortunately possible.

In order to help developers avoid the creation of retain cycles, in the past we introduced the WeakRef class which can be used to create weak-references in Ruby and also a cycle detector that can resolve basic cyclic references at runtime.

Sadly it was still possible to easily create cyclic references using blocks. Let us explain why.

A block in RubyMotion keep a strong reference to the object it was created from, bound as self, which prevents said object from being destroyed before the block can send messages to it.

class Test
  def foo
    lambda { bar }
  end
  def bar
    p :here
  end
end

o = Test.new
b = o.foo
o = nil
b.call

In this case, the Test object will remain alive until the Proc object dies.

This behavior has the side effect of easily creating cyclic references.

class MyController < UIViewController
  def viewDidLoad
    @b = lambda {}
  end
end

In the snippet above, the Proc object keeps a reference to the MyController object, and vice-versa, resulting in a cyclic reference. Because the cyclic detector is at this point not able to detect cycles outside autorelease pool contexts, both objects will leak.

This is where Proc#weak! can come handy. This method makes sure the given Proc object does not keep a strong reference to its self binding anymore.

The method always returns a reference to the receiver and can be safely called multiple times. The snippet above can be rewritten to prevent a cycle:

class MyController < UIViewController
  def viewDidLoad
    @b = lambda {}.weak!
  end
end

Now, MyController will still keep a strong reference to our Proc object, but the later will not. MyController can then be safely destroyed when it is no longer needed, along with the Proc object.

We believe that the addition of Proc#weak! was the last remaining piece to help RubyMotion developers prevent cycles in their apps. Some popular libraries (such as BubbleWrap) and high-profile apps (such as Bandcamp) are already successfully using it.

Performance

As you might have already seen from the previous build release notes, we have been working on performance improvements for the past few weeks.

We have been internally building an intensive performance suite. Our objective is to run it periodically against previous versions of RubyMotion in order to catch performance regressions. We are also running the suite against CRuby 2.0 with the goal of providing better performance results in every possible scenario.

This is a long process and we are not done yet, but we will publish the suite and the data online as soon as we have something we are pleased with.

In the meantime, if your app or library is experiencing performance issues, please let us know via a support ticket, attach some code and we will add it to the suite!

Bandcamp recently launched their new iPhone application and it has been written with RubyMotion. We sat down with Daniel Dickison to talk about his recent experience using Ruby to build an iOS app.

So Daniel, you’re at Bandcamp, what’s your role over there?

I am a programmer and sort of, the way we do things is all the engineers do a little bit of everything. We’re not too specialized, but obviously I’ve been working on the mobile app, so that’s been my thing for the better part of this year.

It’s been a solo endeavor?

Mostly, although definitely wasn’t totally solo. We have two dedicated designers on the team. So the designers did the design and I did most of the coding. Though a couple other people helped out during the process.

Tell me a little about Bandcamp, what kind of a company is it?

We do music. It’s a music platform for mainly independent artists and also labels. So it’s a platform for people to put their music up and distribute it and get paid directly from fans for buying music. That’s sort of the main thing we do.

Is it a pretty big startup?

I don’t have much of a sense of whether we’re big relatively. I don’t have much of a context. Let’s see I think we’re something about 15 employees now. We just celebrated our 5th anniversary, 5th birthday of Bandcamp was just a couple weeks ago, so we had a special blog post.

That’s right! With very cool ASCII art.

Oh yeah that’s Moni, our designer, he’s the ASCII art master.

Oh very cool!

He does a lot of ASCII art stuff in the group IRC that we’re always on.

It’s one of those things you’d expect to be a lost art, and instead it proliferates.

Mmhmm. It’s kinda fun, I don’t know how people make those, but I’m always impressed when it’s animated.

I’m wondering more about the “Bandcamp platform”. Is that to say that people build applications using your platform, or is it that you can build multiple applications with?

Oh I meant platform, not in the technical sense, but as artists using the site to promote their own music. We don’t set prices, artists basically control their own Bandcamp page. They can give music away for free, or for pay, name your price is like “the big thing” these days.

So the web application has been around for five years?

Yes, that’s basically what it was, exclusively, until the app. And the app itself is a compliment to the site.

What led to the mobile app? What was lacking?

There’s really, the one big thing was, when fans buy music on Bandcamp, before the app, you would basically get a download for the music, whether it’s a track or an album. If you wanted to listen to it on your phone you would have to download it on your computer, then load it onto itunes, then sync that to your iphone, which works, but is 5 steps more than we want people to have to do just to listen to what they bought on their phone.

So the big idea is if you buy something on the site, then you should be able to seamlessly listen to it on your phone, which is the first and main problem that we wanted to solve on the app.

Gotcha, so you wanted a way to download directly to the device and play it, pretty much be one action.

Yup!

What led to the decision to use RubyMotion for the iOS app?

That’s an interesting story! So the site’s written almost all in Ruby, on the server side, so all the engineers here know Ruby. Personally I’ve done some iOS development, so I would have gone with Objective-C and written it that way, but Joe, who is head of engineering, I think he was familiar with MacRuby from before, so he heard about RubyMotion and suggested it, and the big plus is that it’s a lot easier for other engineers to jump on the project. It’s a different API but the language is what we’re all used to doing on the server side already. So really that’s the big reason.

Has anyone else reviewed your iOS code?

Yeah, so actually after v1 went out, we’re working on new features, we actually have another guy that’s doing iOS stuff almost full time now for features, and Joe was another one who spent a good chunk of time working on the iOS app.

How was it, introducing them to the organization of the code, and where things go, what was that learning curve like for them, for the new developer?

I’d say, there’s still a learning curve, because the UIKit stuff, it’s a pretty big API to wrap your head around, but it definitely seems like it’s a lot easier to add new features. We look through the code and the syntax is all straight up Ruby.

So the language isn’t getting in the way.

Yeah, kind of an interesting aside, back when we were still prototyping the app, I had an idea to do the UI as a Web view. If that had panned out, it would’ve been really cool because the backend code would’ve been all Ruby without a lot of the UIKit layers. It would’ve been very straight up server type code on the backend with Ruby, and the frontend would’ve been HTML/Javascript. We didn’t end up going that way in the end, because it worked pretty well, especially on iOS, it works really well, but it didn’t work that well on Android. You lose most of the gains of doing it cross-platform anyways.

Gotcha. Let’s talk more about early prototyping. Were you able to use RubyMotion to your advantage there?

I think so, a lot of simple things get really simple. I’m thinking the basic whether you’re matching regular expressions with strings, or iterating your arrays or working with hashes, that stuff is so much less verbose, doing it in RubyMotion. And the other, I guess it’s both a pro and con, is not having to work in Xcode. I use Sublime Text myself, but it’s nice being able to drop right in to the editor you already have customized and not having to have this gigantic IDE. Although, it’s not so bad and definitely getting better.

Actually for a while I was using Sublime Text and switching to Xcode to compile, I would switch back and forth. But it is a difference. For me, Xcode doesn’t become part of my work flow as well. I can integrate iterm and Sublime Text, I can have them talk to each other very easily.

I feel like if you want to use Xcode to the full extent, you have to let Xcode be the world. Use storyboards, do everything in Xcode because everything’s integrated well.

What kind of RubyMotion tools were helpful, like what’s your workflow look like?

We didn’t use a lot of CocoaPods or anything like that, this was a decision I made early on, because I’m familiar with Ruby and I’m familiar with UIKit and Foundation and all that, a lot of the nice Ruby wrappers I just wanted to write myself, just for maintainability, because you guys are iterating pretty quickly, and iOS SDK’s change, not as drastically but you do kinda have to stay on your toes to keep up to date with new APIs that come out, and get deprecated. So it seemed like it might be a good idea just to do it all in our own custom code that we have a good understanding of and can easily change if we need to update it for various things.

My workflow is basically a terminal window open that’s firing off rake every time I need to compile, and a Sublime Text window and Dash is awesome for documentation because when you don’t have the Xcode, I dunno what you call it, the assistant window, and option-click to get documentation, it’s super super useful to have Dash.

I would agree that’s the thing that I would love to see implemented, is autocompletion. I guess RubyMine has a very good one but I haven’t seen one for Sublime Text. I don’t know how’d you do that anyway, that analysis.

Yeah, maybe this exists already but it’s probably possible to just hook up a key binding to take whatever string your cursor’s currently in and hand that off to Dash. Which I should probably look into, that would be pretty useful.

What I would love is if I started to type UIControl and then I could choose StateNormal, and it would flow off my fingers. Though, for that specific example I use SugarCube of course, it has helpers for that.

I noticed recently that the Sublime Text plugin for RubyMotion recently updated for Sublime Text 3, I haven’t installed that yet, I should probably check that out because I think a lot of it would just be having autocompletion for a lot of the constants.

Do you use any gems or CocoaPods?

No we don’t actually, we do use some third party libraries, which are pure Objective-C. FMDB is Objective-C wrapper around Sqlite, and Reachability wrapper, just real simple Objective-C stuff. We wrote some Objective-C ourselves. There’s a few parts, there’s an audio player, one of the main features we have, that we wanted, is to play a track we just bought, streaming, from the server, but we also wanted it to be cached for subsequent plays. It turns out you can’t do that with the built-in AVPlayer API. It’ll stream, but it won’t give you the data to cache it at the same time. So we wrote a little audio player, using the audio queue API. So that’s a C API. It may have been possible doing it in Ruby, but it was just easier just to drop into pure Objective-C and C. So we have that.

You expose that with Objective-C classes?

Yeah it’s basically an Objective-C wrapper around the C API. It basically takes a file and we can play audio from a file as it’s being written out from the server. So that’s a low level thing we had to write in Objective-C.

Another thing that RubyMotion contributes to is the ability to organize code differently than you would in Objective-C, I wondered if you had any thoughts on that.

Yeah, actually that’s kind of interesting, I hadn’t thought too much about it… not having .h files for everything is quicker when you’re writing code, you can just start pounding out code without having to switch back and forth, making sure your header and your exposed APIs, and worrying about that stuff. So it’s definitely faster, I think.

Any other metaprogramming techniques that you rely on?

Oh yeah let’s see, I think there were some. There’s some utility base classes that, depending on whether TestFlight SDK is defined or not, if it isn’t it’ll stub it out with a dummy class that pretends like TestFlight SDK is there. There’s definitely little funky Ruby meta-programming stuff that we can do that we throw in there.

Were there any issues with RubyMotion things that hung you up?

There’s definitely one thing that was a huge time sink which was the memory management, especially with blocks and multi threading. I filed some bugs with you guys about this, and a lot of it got sorted out.

Any feature requests, things you’d like to see, in terms of RubyMotion?

Let’s see… that’s a good question I mean the profiling one would have been a huge one but you guys got it already, that would’ve been one. You know it’s actually pretty solid. I think once you guys get this retain cycle and memory management stuff solid, I think that would make it, without question a solid platform to develop in.

Great! Any questions for our side?

I’m curious, are you guys a distributed team?

Yeah we’re all over! I’m in Denver, I pretty much step in for the interviews, for community projects, kind of poke around the mailing list as much as I can. Most of the team is in Europe, though we’ve got Watson in Japan, in Tokyo. So he and Laurent have been the main, core developers, though Eloy Duran is also entered into that world.

We’re also distributed, it’s interesting to hear about other teams that do that. We do a daily Google Hangout meeting to give status, to keep up to date, I was wondering if you do stuff like that?

Nothing so formal, we are always in HipChat, and it’s actually kinda fun because the sun never sets on the HipByte chat, because it transfers from Japan to America to Europe, and there’s this perfect 8 hour difference between each one, it just depends on who’s awake. There’s always at least one person to hand it off.

I think we’re pretty close to that! We have a guy in Australia who keeps the lights on when everyone else is out, and then a guy in Oxford, and the rest of us are scattered around the Americas. It’s pretty good for us, too, because if there is an emergency, there’s usually someone around there’s usually someone around to take care of it.

We don’t get to take advantage of that, there’s usually not compiler emergencies, like there is on the web.

Haha emergencies accumulate a little more slowly.

A little, yeah, and you can always fall back to a previous compiler version, usually that resolves it for the short term. Well Daniel I don’t have any more questions for you, I really appreciate you taking this time. And I hope you continue to make apps using RubyMotion.

Oh yeah we’re in it for the long haul with this app. You’ll definitely hear from us, I’m sure.

Great, congratulations again on shipping!

Thanks! Have a good one!

MotionInMotion is launching very soon, and will be one of the screencasts of choice for many to expand their skills and keep them up to date.

I’ve been working away at getting ready to launch this as a new regularly released screencast for RubyMotion. To make sure I was creating good content you would be interested in, I got together 20 people for an early access group, and I’ve been getting great feedback from them as they’ve enjoyed the screencasts.

I’ve put together a pre-launch episode about Nick Quaranto’s motion-layout wrapper, and how I use it to take control of Auto Layout and quickly get it working in my iOS apps.

Everyone that sign’s up to the launch list on the coming soon page, will get a 20% lifetime discount on their subscription when they subscribe in the first week after launch.

Enjoy!

OS X 10.9 Mavericks

RubyMotion is now fully compatible with OS X’s latest release, Mavericks. The iOS toolchain works on Mavericks and you can also create Mavericks OS X apps with it.

In case you have been waiting for the green light to update: feel free to do so now! Make sure you also grab the latest Xcode from the App Store and install the command-line tools.

The RubyMotion toolchain still supports 10.6 Snow Leopard but we highly recommend upgrading to a newer version of OS X at this point.

#eval for OS X

Originally, RubyMotion was iOS-only and the #eval method was not implemented by design, as we did not want RubyMotion apps to interpret/compile code at runtime on iOS devices.

Now, RubyMotion can be used to make OS X apps and Macs do not have the same constrains as iOS devices. Therefore, we are making #eval optionally functional for OS X projects.

In order to enable #eval for your OS X project, you can set the app.eval_support variable to true in your Rakefile.

Motion::Project::App.setup do |app|
  ...
  app.eval_support = true
end

Enabling #eval will copy the RubyMotion JIT compiler inside your application’s bundle, increasing its size by 28MB.

Please note that #eval support for OS X is experimental and is not properly optimized in terms of runtime speed and memory usage, so use it carefully and report us any problem you find!

Instruments

The RubyMotion build system now exposes a set of Rake tasks to profile your project with Apple’s Instruments application. Symbols metadata (such as source file/line) are also integrated.

On iOS, the rake profile:simulator and rake profile:device tasks can be used to attach Instruments to either your application running in the iOS simulator or in your iOS device. By default, rake profile will target the simulator.

$ rake profile # same as profile:simulator
$ rake profile:device

On OS X, the rake profile task will attach Instruments to a development build of your OS X project.

All tasks will profile a development build of your project, making it easy to get going and not have to deal with code-signing. However, before submitting your application to the App Store we recommend you profile a release build instead. For this you can use the rake profile:release task for OS X apps or set the mode environment variable to release for iOS apps:

$ rake profile mode=release

When Instruments.app starts you will have the ability to select a template that should be used for the profiling session. The Allocations template can be used to measure memory allocations and the Time Profiler template will sample the runtime activity of your process.

In case you would like to configure the template that should be used from the command-line, you can set a value for the template environment variable.

$ rake profile template="Time Profiler"

Xcode Asset Catalogs

Since RubyMotion 2.11 we have introduced support for Xcode Asset Catalogs.

These allow you to manage your image assets without having to name your image assets with the many filename modifiers required to support the various devices (e.g. @2x, ~ipad, etc). When an asset catalog is placed in the resources directory of your project, RubyMotion will automatically compile it into your application and you can simply reference the assets by their base names.

Currently RubyMotion supports general image sets and application icon image sets, launch image set support is still forthcoming.

Many of you may already be familiar with Eloy. He is the creator and one of the maintainers of CocoaPods, the best way to manage library dependencies in Cocoa projects. A long time Ruby and Cocoa-ist, Eloy joined the RubyCocoa project in 2006 and later on the MacRuby project in 2008. Eloy then got to work with RubyMotion since it was still under heavy development and he also contributed its functional testing framework.

When he does not make computers do things, Eloy likes to make music, play video games and gesticulate. He lives with his lovely wife and cat and dog on a canal houseboat in beautiful Amsterdam, the Netherlands.

Getting Eloy on the team is a special milestone for us, as we have personally worked with him for a very long time. He was naturally one of the best candidates we could think of to join us on this journey and we have no doubts he will be a great addition. Eloy will be contributing full-time to the RubyMotion toolchain by working on the existing feature-set as well as some new functionality that we have in the pipeline.

As you may already know, CocoaPods is a crucial piece of infrastructure in the RubyMotion ecosystem, as it provides a convenient bridge to the open source Cocoa community. We are therefore also happy to mention that Eloy will get to work on CocoaPods on company time. HipByte however does not intend to change the way CocoaPods is developed and CocoaPods will remain an open source community project.

Eloy comes to us after a 5 years tenure at Fingertips, a design and development consulting agency that does not need to be introduced and that we highly recommend.

HipByte is deliberately 100% bootstrapped without outside funding and our revenues are growing every month, thanks to your support and the licenses you have purchased. The direct result is that we get to grow the team organically while strengthening our commitment that we are really here for the long term.

Frontback got an excellent coverage in the tech press since its launch: TechCrunch, The Verge, CNET, The Next Web, and many more. It was also featured on Bloomberg TV and users of the app include Twitter creator Jack Dorsey and prime minister of Belgium Elio Di Rupo.

The app is excellent, and was lovingly built using RubyMotion. We had a chance to hear how its creator, Melvyn Hills, created the app. Melvyn lives in Brussels. He helped create Checkthis using Ruby-on-Rails, Slim, CoffeeScript, and Sass after leaving the world of Flash/ActionScript. Like many programmers, he got his start on a programmable calculator (a CASIO, if you must know).

What was the inspiration to create Frontback?

3 months ago, Frédéric did a post on Checkthis app with two pics, one with the front camera & one with the back, with only a “Front Back” title. On that weekend there were dozens of other “Front Back” posts, and a lot still afterwards. This made us think about a simpler product for just that purpose: me & what I see, right now. The Selfie with an excuse.

You take the first picture in front of you in the first top half of the screen, then one at the back of your phone: you. Then you select your current location, choose where to share it and that’s it. By connecting your 3rd party social networks, you auto-follow all your friends on Frontback and can browse a feed with their frontback posts and some staff-picks.

What made you decide to use RubyMotion?

We wanted to build a quick prototype, so I first did a bit of research about whether it was doable with Web technologies on iOS… but no :) I already had heard a lot about RubyMotion through Yannick Schutz & Laurent Sansonetti and even went to the awesome #inspect conference in Brussels, and I have a bit of experience with Ruby (none with Obj-C/iOS) so I thought about giving RubyMotion a shot. After a few days, I enjoyed it so much, it was so easy to get on tracks simply by reading the iOS APIs docs, it was very clear for me that I was going to build the whole app with RubyMotion. I really felt at home with my AS3 & CoffeeScript background.

So you came to iOS development from a frontend-web background. What were some of your early challenges?

The main challenge I had to deal with was memory/cache management & performance for many pictures. Our app consists mainly of an infinite feed of full-screen pictures. I had to deal with async infinite loading, image download & decompression in a background thread to keep iOS users happy with their beloved 60fps smooth scrolling they’re so used to. I finally ended up using BubbleWrap HTTP module with a custom NSCache wrapper with disk caching fallback. At first I used a UITableView, but I needed more than two cells (automatically handled by UITableView) so I used a paginated UIScrollView with a custom cell-pooling technique.

Once you had a better grasp of the framework, what helped you be the most productive?

Other than Apple’s iOS documentation & StackOverflow, BubbleWrap was a great help for many things such as HTTP, Pub/Sub, JSON, Location, timers,…

Mattt Thompson's libs and blog helped a lot too. AFNetworking (but later switched to BubbleWrap), AFUrbanAirshipClient, …

Reveal app is a great tool to debug your views. And CocoaPods is awesome, I used much more pods than gems actually.

What would you say to someone who was trying to choose between RubyMotion and traditional iOS development?

With RubyMotion, it’s easier to get on board. Every line you write is needed application logic, nothing more. It’s cleaner & easier to read & write, especially if you come from a Ruby/Python/CoffeeScript background. The fact you don’t have to use XCode is a big win. For debugging, however, it’s a bit more difficult. Dealing with GDB isn’t easy. I’m trying RubyMine right now, it seems to help.

What lessons did you learn from building Frontback? In other words, what will you do differently when you go to build your next app?

I’m quite happy with our codebase & overall quality of the app. I’d probably abstract some of basic & repeating functionalities. I’d also might use some view layout/styling abstraction like Teacup. I didn’t use it this time because I wanted to first really understand how layout & view management works on iOS. Our app is visually simple & has a clean flat design, so it wasn’t too much of a hassle to code by hand.

If you had one request for the HipByte team, what would it be?

Write a thorough article about threads & GCD with RubyMotion. And another about memory management: how to properly cache stuff, release objects & handle memory leaks. These are the most difficult topics I think, coming from a web development background.

The new version of your app brings lots of new features. It was even featured in Bloomberg TV! How difficult was it to add these features to an existing code base? Did you have to plan for these features, or was it easy to add them on as needed?

Yes indeed, the app is getting some pretty good coverage and momentum right now. The new version brings many new features to add a real social layer: likers view, profile view, followers/following view, friends finder and a single post view, all navigable from one to another.

We didn’t plan everything from the beginning, as we first observed our user base usage of the app before deciding what was the next features we wanted to add. We didn’t encounter any problem for adding those features into the existing codebase, which was already quite well decoupled and structured. The nice thing I like about Ruby, compared to Obj-C, is that the codebase remains smaller and cleaner: no header file for each implementation (half the number of files!), smaller lines, methods and classes. This makes code refactoring much easier.

The biggest change I had to do was to handle global navigation throughout the app: how the UINavigationControllers handle the horizontal browsing, combined with the different sections that can be presented modally. I ended up with a pretty nice base class for my UIViewControllers with some simple methods to navigate everywhere in the app, using global notifications transparently under the hood.

Hi everyone! We are again preparing a great class for you! This time, it will take place in Mexico City between the 25th and 29th November 2013. More information on this page.

It is our classic 5 day class, but we have been working on improving it and synchronizing the material with the latest versions of RubyMotion and iOS. Laurent and Norberto will be the instructors.

We are going to give the class in English and Spanish (Laurent has been working very hard to improve his Spanish). Non-Spanish speakers are therefore very welcome to the class.

The weather in November in Mexico City is great, the temperature is normally at 21C / 70F.

The cost of the course includes:

1. Breakfast
2. A Rubymotion training license
3. An assistant certificate

You can purchase a seat today. At the time of this writing the class is already half full, so hurry up! We are also running a discounted price until the end of October.

If you have any question feel free to drop us an email. We can also assist you if you need help and tips to travel to Mexico.

This RubyMotion training would not be possible without our awesome sponsor, Diverza.

See you there!

Faster Builds

As the RubyMotion ecosystem matures, projects tend to include more and more libraries. Some of you guys have been experiencing long build times, especially on lightweight hardware.

As of RubyMotion 2.8, the compiler has been significantly improved to reduce build time by a factor of 3 on average. A lot of internal changes have been introduced to improve performance and the compiler also emits straight assembly, which helps eliminate one compilation phase.

We also ported the compiler to the latest stable version of LLVM, version 3.3, which was released in late June of this year. This version matches the one Apple uses inside Xcode, and it is also relatively faster than the older version that we were using previously.

The iOS build system will also target the lowest device architecture possible in development mode, so that rake device does not have to create a fat binary.

64-bit iOS

You may have heard that iOS is going 64-bit! The new iPhone 5s will feature an impressive 64-bit ARM architecture. The iOS 7.0 SDK has also been accordingly updated with 64-bit libraries.

RubyMotion 2.8 is able to create 64-bit binaries for both the simulator and the iPhone 5S, respectively targeting the x86_64 and arm64 architectures.

64-bit iOS executables should have greater performance compared to 32-bit ones. The range of Fixnums and Float immediate objects is doubled, allowing the runtime to not allocate extra memory when creating large numeric types. Also, the compiler can now make use of zero-cost Itanium/C++ exceptions to implement Ruby exceptions, allowing handlers to have a zero runtime cost during the normal execution of the app.

Given the fact that iOS 64-bit has just been announced 2 days ago and that a lot of 3rd-party libraries may not have been updated yet, RubyMotion will not compile 64-bit apps by default. If you’re interested in doing so, you can add the following lines in your Rakefile.

app.archs['iPhoneOS'] << 'arm64'
app.archs['iPhoneSimulator'] << 'x86_64'

It’s pretty experimental, so give it a try and let us know if you experience anything weird!

iOS 7.0 GM

RubyMotion supported every beta version of iOS 7.0 as they were being released. Two days ago, Apple finally announced that iOS 7.0 will be available to everyone on September 18th, and provided a last SDK build, the gold master.

RubyMotion 2.8 provides support for iOS 7.0 GM. You can finally go ahead and submit your iOS 7.0 apps!

Versioning

RubyMotion now offers a way to let you save older versions of RubyMotion on your computer. Older versions of RubyMotion can be used on a per-app basis. This can be useful when you want one of your apps to target a specific version of RubyMotion, because it hasn’t been well tested with newer versions or because of a known issue in newer builds.

To save an older version of RubyMotion, you can pass the —cache-version flag to the motion update command.

As an example, let’s say we have an app that must target RubyMotion 2.6. First, we retrieve that specific version of RubyMotion.

$ sudo motion update --cache-version=2.6
Connecting to the server...
Downloading software update...
######################################################################## 100.0%
Saving current RubyMotion version...
Installing software update...
Restoring current RubyMotion version...
RubyMotion 2.6 installed as /Library/RubyMotion2.6. To use it in a project, edit the Rakefile to point to /Library/RubyMotion2.6/lib instead of /Library/RubyMotion/lib.

As you can see, we now have RubyMotion 2.6 in /Library/RubyMotion2.6. We can now edit the Rakefile of our app to point to that version. You should see the following line at the top of the file.

$:.unshift("/Library/RubyMotion/lib")

We can change it to the following, and we are done.

$:.unshift("/Library/RubyMotion2.6/lib")

When you no longer need to keep RubyMotion 2.6 around, you can simply delete the /Library/RubyMotion2.6 directory.

Bundler

New iOS and OS X RubyMotion projects now automatically integrate with Bundler, which had not been the case before. Projects will now include a Gemfile that you can edit to add your dependencies, and the Rakefile will require and initialize Bundler.

After running a quick poll on Twitter we realized that the vast majority of our users wanted this integration. For those who are not using Bundler, don’t worry, new projects will keep working as before if you do not have the Bundler gem installed in your Ruby distribution.

Run on Device

The rake device task has been improved to run the application as soon as it is installed. Logs printed by the app (using the NSLog function) will also appear in the terminal.

$ rake device
    Deploy ./build/iPhoneOS-7.0-Development/Timer.ipa
*** Application is running on the device, use ^C to quit.
Aug 26 15:27:36 lrzs-iPhone Timer[1493] : user clicked start
Aug 26 15:27:38 lrzs-iPhone Timer[1493] : user clicked stop
[...]

The app will quit as soon as you press ^C.

In case you do not want to run the app after installation, you can set the install_only option to any value.

$ rake device install_only=1

Before this change the only way to run the app on the device was to attach a debugger (passing the debug=1 option), which wasn’t a great user experience.

Device Console

The motion device:console command has been added, which will open the logs on the USB-connected device and print them in real-time.

All messages from the device will be printed, including those from other apps or the system itself. This command can be useful when investigating an environmental issue with your application, as you get to see what’s happening on the device.

Better iOS 7 Support

RubyMotion 2.7 comes with better support for iOS 7. First, we synchronized the toolchain with the latest Xcode 5 and iOS 7 beta builds.

The mouse-over functionality in the REPL that lets you select views has been implemented in the Retina simulator, which is the default when targeting iOS 7. Note that it will work only if the simulator has a 50% scale (use command+3 to enable this).

Attaching the LLDB debugger, which is the default and only provided debugger as of Xcode 5, is now working on apps running on the device. The rake device debug=1 task will work as expected on iOS 7 devices, the only exception being that we will attach lldb and not gdb. This feature, while being functional, is still under development as there are some performance issues when communicating with the device debug server.

The build system has been improved to recognize and handle SpriteKit texture atlas files. Please check the relevant documentation in the Apple developer center to know more.

Finally, we changed the compiler to work around a possible regression in the iOS 7 runtime which was appearing when using certain APIs from MapKit.

After the successful first edition of BubbleConf in 2012 also in 2013 Phusion and Nedap are organizing this inspiring tech conference. BubbleConf is a conference for tech startups by tech startups. Although Nedap is a publicly traded tech company they have managed to keep the startup culture deeply embedded in their DNA.

“How is this conf going to be any different from the other million confs currently out there?” you might be wondering. Well for one, BubbleConf is dedicated to covering a wide range of topics instead of committing to a single one. They are topics that the organization believes are essential for today’s tech startups ranging from design, development to even the legal aspects of having a startup. Needless to say, a select number of speakers that are considered experts in their field have been selected to share their war stories with you.

The folks behind BubbleConf went all out in securing some of the best speakers in the business for the 2013 edition of their conference. Zed Shaw, the prolific programmer who gave up coding for various enterprises to work on teaching people to code, will once again take the stage at BubbleConf. This will be his last talk however as he will be retiring from speaking at tech conferences after BubbleConf 2013. His “Learn Code The Hard Way” Series have been read by over a million people from all over the world. Designers will be delighted to learn that Dribbble founders Dan Cederholm and Rich Thornett will be speaking at BubbleConf about arguably the hottest design community currently out there. They will share their thoughts on bootstrapping, design and pretty much anything you want to ask them in a Q&A session. Apple Design Award winners Koen Bok and Jorn van Dijk, also known as the founders of Sofa, will also be there. Next to these interesting speakers there will also be founders and prolific folks from companies such as GitHub, Facebook and so forth to speak at BubbleConf.

Tickets are limited, so if you want to be a part of this awesome event you should get your tickets quickly. This year, we were able to organize special ticket prices for existing RubyMotion customers. You pay only €160,- instead of €220,- (all prices are VAT included). If you want to go to BubbleConf with this nice discount, you can file a support ticket. The RubyMotion support team will send you a special URL where you can purchase discounted tickets.

BubbleConf aims to bring as many talented people together as possible from a variety of fields. This not only holds true for the speakers, but also for the attendees. Who knows, you might be able to find your designer or developer co-founder there as well! In fact, the organization is once again planning on encouraging people to team up by providing the stage to a select number of lightning talks as well. And a beautiful stage it is indeed.

The idea behind Joybox has always been to help you focus on the things that matter while creating a game, such as the game play or the game mechanics, instead of dealing with collisions logic or ray casts. At the time it was introduced I knew that for this to become a reality, a good documentation had to be created.

We are launching today a totally new website with complete documentation, examples and learning tracks. Today, Joybox 1.1.0 is also released with a lot of new features like the Physics Debug Draw, support for Tile Maps and Physics Sprite Actions. You can read more about it in the Joybox 1.1.0 release announcement.

The following article is a preview of the easy-mode learning track. It will step-by-step guide you through the basics of game development as you build your first game!

Joybox Asteroids

The game we will be building is a remake of the Asteroids video game created in 1979 by Atari. However, it will have its particular differences that you will notice as we move forward.

I assume that you have already installed Joybox on your computer. If this is not the case you can visit the Getting Started guide on our website.

Creating a new Joybox project

Lets start by creating a new Joybox project. Note that we are using thejoybox-ios project template.

$ motion create --template=joybox-ios asteroids

You can then copy the following sprites into the resources folder. Since we are building an iPad game, we have to add the following lines into the Rakefile.

app.name = 'Asteroids'
app.interface_orientations = [:landscape_left]
app.device_family = [:ipad]
app.icons = ['icon.png', 'icon@2x.png']
app.prerendered_icon = true

Creating the game layer

Now we are ready to start developing our game! The first thing we need to do is create a Layer subclass, in which all the actions will happen. To accomplish this let’s create a new file named game_layer.rb into the app folder, and write the following into it:

class GameLayer < Joybox::Core::Layer
  scene

  def on_enter
    background = Sprite.new file_name: 'background.png',
        position: Screen.center
    self << background

    @rocket = Sprite.new file_name: 'rocket.png', position: Screen.center,
        alive: true
    self << @rocket
  end
end

In this code we are creating a new subclass of Layer, named GameLayer. In it we define the on_enter method which be called when our new layer is presented on the screen, which is a perfect timing for adding two sprites. The first sprite will be the background image of the game, and the other one the user’s rocket.

As you may notice the rocket sprite is being created with another option: alive. This is a custom value - you can pass custom parameters to Sprite#initialize and they will be stored along with the object. This value will help us determine if the rocket has collided with an asteroid or not.

Creating the director

The next step is tell the director to present our layer. You can think of the director object as the person who directs the making of a films: it manages everything that happens in the game: from what is being presented on the screen, to the game loop, a concept that we will explain a little further.

You can open the app_delegate.rb file and add the following lines:

def application(application, didFinishLaunchingWithOptions:launchOptions)

  @director = Joybox::Configuration.setup do
    director display_stats: true
  end

  @navigation_controller =
      UINavigationController.alloc.initWithRootViewController(@director)
  @navigation_controller.navigationBarHidden = true

  @window = UIWindow.alloc.initWithFrame(UIScreen.mainScreen.bounds)
  @window.setRootViewController(@navigation_controller)
  @window.makeKeyAndVisible

  # This line tells the director to present our Layer when the game starts
  @director << GameLayer.scene
  true
end

What you are seeing in this method is all the necessary configuration needed for our game to run. For the purpose of this tutorial we won’t be focusing much on it, but if you are curious you can look at the director page on our documentation section.

First run!

Now, let’s run the project for the first time! You should see the following on your iOS Simulator:

Controlling the Rocket

The basic idea of the game consists of the following points:

• A lot of asteroids will fly through the screen in different directions, from different locations.
• The user controls a rocket and should dodge the asteroids using his/her finger to move the rocket.
• When an asteroid hits the rocket the game should be over.

Let’s start with the number two of the list: moving the rocket around when the user touches the screen. For this we need to add the following code into our game_layer.rb file:

class GameLayer < Joybox::Core::Layer
  scene

  def on_enter
    background = Sprite.new file_name: 'background.png',
        position: Screen.center
    self << background

    @rocket = Sprite.new file_name: 'rocket.png', position: Screen.center, 
        alive: true
    self << @rocket

    # The following block will be called when the user touches the screen
    on_touches_began do |touches, event|
      # We retrieve the touch location and assign it to the rocket position
      touch = touches.any_object
      @rocket.position = touch.location
    end
  end
end

In this code we are updating the position of the rocket based on the touch location generated by the user, but if you run it you will notice that something weird is happening:

Oops! The rocket moves instantaneously and it does look like it is being teleported instead of naturally moving. To fix this we can introduce a Move action to update its position:

on_touches_began do |touches, event|
  touch = touches.any_object
  # The move action will update the rocket position frame by frame until it
  # arrives at the desired location
  @rocket.run_action Move.to position: touch.location
end

If we run the game again the rocket should now move through the screen instead of being teleported.

Asteroid rain!

Now is time to focus on the first point of the game: make those asteroids fly through the screen. This is the biggest part of the tutorial and is divided into two main characteristics:

• Define where the asteroid should be spawned and where they should be moved to.
• Maintain a constant number of asteroids flying on the screen: not too many, because it will make the game impossible to play, and not too few, because it will not be challenging at all.

Creating asteroids

Let’s begin with the first part, which is defining an asteroid starting and ending position. For this, it is better to isolate that part of the code in another class named AsteroidSprite which should be a subclass of Sprite. Let’s add the following into a new file named asteroid_sprite.rb:

class AsteroidSprite < Joybox::Core::Sprite
  def initialize
  end
end

Now if you look at our resources folder, you should see four graphic files for ou asteroids (they are numbered from 1 to 4). They are different in size and shape, in order to add a bit of complexity into the game while keeping it simple. It will not be practical to have four different classes of asteroids to manage only a different image, so it is better to implement a more simple solution inside the initialize method:

def initialize
  @random = Random.new

  # We define what kind of asteroid by using a random number
  kind = @random.rand(1..4)
  # We can now get the appropriate image
  file_name = "asteroid_#{kind}.png"
end

Well, that should be it! Using a random number to retrieve the image takes the multi-class problem away. Now we can think about the starting and ending positions of our sprite.

We can use a random number to get a starting position as well, but they would spawn everywhere (like teleporting). We need the asteroids to spawn outside the screen and move to the other side, for this first we need to know on which side of the screen they should appear:

def initialize
  @random = Random.new

  kind = @random.rand(1..4)
  file_name = "asteroid_#{kind}.png"

  # Using a random number we can define in which side of the screen
  # it should appear. 1 for left, 2 for top, 3 for right and 4 for bottom.
  screen_side = @random.rand(1..4)
end

Now we can create a method that will generate the exact initial position of the asteroid based on the side of the screen:

# This is the maximum size of any of our asteroids, because their images are
# rectangles only one value is needed.
# We need this value to make sure that the asteroid will not appear on the edge
# of the screen.
MaximumSize = 96.0

def initial_position(screen_side)
  case screen_side
  when 1
    # In case it spawns on the Left:
    # The X axis should be outside of the screen
    # The Y axis can be any point inside the height
    [-MaximumSize, @random.rand(1..Screen.height)]
  when 2
    # In case it spawns on the Top:
    # The X axis can be any point inside the width
    # The Y axis must be higher than the screen height
    [@random.rand(1..Screen.width), Screen.height + MaximumSize]
  when 3
    # In case it spawns on the Right:
    # The X axis must be greater than the entire screen width
    # The Y axis can by any value inside the total height
    [Screen.width + MaximumSize, @random.rand(1..Screen.height)]
  else
    # In case it spawns on the Bottom:
    # The X axis can be any value of the screen width
    # The Y axis should be lower than the total height
    [@random.rand(1..Screen.width), -MaximumSize]
  end
end

Using the initial_position method we can obtain the first location point of the asteroid according to the side of the screen it should be spawned. Please take notice that the code can be greatly optimized, but we will keep it simple to make to easier to follow.

Now, we need to do the same logic for the final location point. Wait! Why don’t we just add the entire width or height? Well! If we do that then the asteroids will only fly in straight paths, which will reduce the difficulty and make them look like they are on rails instead of flying naturally. It’s better to take a similar approach as for the initial position:

def final_position(screen_side)
  case screen_side
  when 1
    # In case it spawns on the Left:
    # The X axis must be bigger than the total width
    # The Y axis can be any point inside the height
    [Screen.width + MaximumSize, @random.rand(1..Screen.height)]
  when 2
    # In case it spawns on the Top:
    # The X axis can be any point inside the width
    # The Y axis must be lower than the initial screen height
    [@random.rand(1..Screen.width), -MaximumSize]
  when 3
    # In case it spawns on the Right:
    # The X axis must be lower than the start of the width
    # The Y axis can by any value inside the total height
    [-MaximumSize, @random.rand(1..Screen.height)]
  else
    # In case it spawns on the Bottom:
    # The X axis can be any value of the screen width
    # The Y axis should be higher than the total height
    [@random.rand(1..Screen.width), Screen.height + MaximumSize]
  end
end

As well as for the initial_position method, this code can be optimized but we will keep it this way for simplicity sake.

Now that we can obtain an initial and ending position for our asteroid, let’s use these methods to initialize the sprite:

# We will need access the final position later on our GameLayer
attr_accessor :end_position

def initialize
  @random = Random.new

  kind = @random.rand(1..4)
  file_name = "asteroid_#{kind}.png"

  screen_side = @random.rand(1..4)
  # Let's create the start and end position for our asteroid
  start_position = initial_position(screen_side)
  @end_position = final_position(screen_side)

  # Initialize the Sprite using the asteroids file image and the start position
  # This is the same as do Sprite.new file_name:, position:
  super file_name: file_name, position: start_position
end

The code will first generate the starting and ending point for the asteroid, and more importantly it will initialize the sprite using the appropriate graphic file which was obtained by using the kind of asteroid.

After doing this, we can now say the code in the AsteroidSprite class is complete!

Launching asteroids

Now it’s time to launch these asteroids through the space! But if you remember, there is a condition we need to meet: maintain a constant number of them on the screen.

The easier way to do this is to check at certain intervals of time if they are enough of them on the screen, or we need to launch more. The concept of the Game Loop was created for such scenarios. It will make periodic calls to our classes (in this case the GameLayer) so we can update the logic of the game. To make sense, let’s implement it in the game_layer.rb file:

# Class GameLayer
def on_enter

  ...

  # The game loop will call the following block every time it passes, regularly
  # sixty times per second.
  schedule_update do |dt|
    # The following method is not implemented yet
    launch_asteroids
  end
end

If we take a look at the previous code: We are calling the schedule_update method with a block, this will set up the Game Loop for the layer. The block we are passing will get called every time the game loop runs, which means that the launch_asteroids method will be called a lot of times, allowing us to validate the number of asteroids on the screen.

Now it’s time to implement the launch_asteroids method:

# Defines the max. number of asteroids that can be on the screen at the same time.
MaximumAsteroids = 10

def launch_asteroids
  # In the following array we will contain the asteroids
  @asteroids ||= Array.new

  # Checks if we need to launch more asteroids
  if @asteroids.size <= MaximumAsteroids
    missing_asteroids = MaximumAsteroids - @asteroids.size

    # Let's create a new asteroid for each missing one
    missing_asteroids.times do
      # Create a new instance of our AsteroidSprite class
      asteroid = AsteroidSprite.new

      # Like the rocket, we move the asteroid using the Move class
      asteroid.run_action Move.to position: asteroid.end_position,
          duration: 4.0

      # Add it to the array and the layer to present it on screen
      self << asteroid
      @asteroids << asteroid
    end
  end
end

What we are doing here is first checking if more asteroids are required, if so we create a new instance of our AsteroidSprite class. Then we add it to the layer so it can be rendered and to the array so we can keep control of how many asteroids we have.

Also, we move the asteroid through the screen using the Move action, as you remember this is needed because we don’t want the movement to be instantaneous.

Finally we can run our project!

Yeah, it works! But… the asteroids only appear once!

To fix this, we need to determine when the asteroid movement is finished so that we can remove it from the array. We can use two more actions to perform this. The first one is named Callback and its function is to call a block, and the other one is Sequence, which will help us to run first the move action, and when it finishes, the callback action.

Let’s update the launch_asteroids method accordingly:

def launch_asteroids
  @asteroids ||= Array.new

  if @asteroids.size <= MaximumAsteroids
    missing_asteroids = MaximumAsteroids - @asteroids.size

    missing_asteroids.times do
      asteroid = AsteroidSprite.new

      # First we need to create the Move action
      move_action = Move.to position: asteroid.end_position, duration: 4.0

      # Second using the Callback action we create a block that will remove the
      # asteroid from the array. As you may notice the block will receive as
      # parameter the sprite that run the action
      callback_action = Callback.with { |asteroid| @asteroids.delete asteroid }

      # Finally we run both actions in sequence first the Move action and then
      # the Callback one.
      asteroid.run_action Sequence.with actions: [move_action, callback_action]

      self << asteroid
      @asteroids << asteroid
    end
  end
end

Finally, if we run it this time the asteroids should appear over and over again! Yeepee!

Crashing the rocket

We are almost there, it’s now time to implement the third and final point: detect when the rocket crashes with an asteroid. The Game Loop will help us here too, we can create a method to check if the rocket’s bounds are being intersected by any of the asteroids bounds.

To begin with the collision detection we should update the game loop block as following:

# Class GameLayer
# Method on_enter
schedule_update do |dt|
  launch_asteroids

  # The following method is not implemented yet
  # We only need to call this method if the Rocket is still alive, its value
  # was defined when the @rocket sprite was created
  check_for_collisions if @rocket[:alive]
end

Final step! We need to implement the check_for_collisions method, that will check if the bounds of the rocket intersects with the bounds of any asteroid. In order to get the bounds of a sprite, we will use the bounding_box method, which will return the minimum box that can contain the sprite image.

Let’s add the following method to the game_layer.rb file:

def check_for_collisions
  # Iterate through every asteroid in the screen
  @asteroids.each do |asteroid|
    # Check if it's bounding box intersects with the rocket
    if CGRectIntersectsRect(asteroid.bounding_box, @rocket.bounding_box)
      # If true finish the game
      # First stop the movement on all of the asteroids
      @asteroids.each(&:stop_all_actions)

      # Set the alive property of the rocket to false, this to avoid that the
      # collision is checked again
      @rocket[:alive] = false
      # Give the rocket a nice retro blink!
      @rocket.run_action Blink.with times: 20, duration: 3.0
      break
    end
  end
end

In this method, we first check if any of the asteroids are intersecting with the rocket, and if we find one, we stop the movement on all asteroids and give a little feedback to the user using the Blink action. It’s our way to show that the game is over.

The game is now complete! Let’s run it.

We hope you enjoyed this tutorial! You can download the full code here.

Let’s improve the game!

As you may have noticed they are lots of things that can be improved in the game, some of them will be added in the Easy Level on the Joybox site. But until that time, you are welcome to experiment, polish or create your own version of the game!

RubyMotion + games = happiness

Using Ruby for creating games is a great experience, but what makes it amazing is the ability to deploy them to great platforms. Thanks to the RubyMotion team for making it possible!

Temple is the brainchild of Todd Werth and Ken Miller, of InfiniteRed. We decided to sit down with them to learn more about their story.

Can you tell us a little bit about your startup, InfiniteRed?

InfiniteRed is located in San Francisco and was founded by Todd Werth and Ken Miller in April of 2013. We had worked together in the past and discovered that we saw eye-to-eye on software design and philosophy, and decided to create a company that was based on an honest relationship with the people who use our software. We’re trying hard to avoid outside investment or advertising, at least as our main priority, because those things tend to take away from giving the customer’s experience top billing.

We’re thrilled to have a real app, in the App Store, that real people are paying money for, that’s almost 100% Ruby!

Temple definitely embodies that philosophy; it’s unlike any fitness app I’ve seen before!

We’re incredibly proud of Temple, but believe me, it’s just the beginning. We have more product ideas, as well as some open source contributions to announce in the near future. We also take on select clients from time to time, so if you have an idea, feel free to drop us a line.

What are your backgrounds? Are you designers-turned-developers? The other way around?

Todd Werth: I’m fairly unusual in that I’m both a graphic designer and a programmer. I’ve been in San Francisco building products professionally for 16 years. Earlier in my career I was a consultant doing hard-core architecture and programming in everything from Delphi, to Java, to c++.

I then moved into the startup world and focused on UX, design, and front-end, which suits me best. When I write a low-level library, I create a logo first, which is kind of absurd if you think about it, but art and engineering are different shades of the same color to me.

Ken Miller: Professionally I’ve been around since the Dot Com boom in the late nineties, doing mostly backend Java and Ruby and leading teams for the last 10 years, but I’ve been into computers practically my whole life.

My dad is a scientist turned programmer, and my mom is a scientist turned artist, so I guess I just merged all that into a love of making beautiful software. And for me that means both how it’s designed—how it looks and how it works—but also the quality of the code itself. As a backend guy, that’s where I have most input, and that’s why I’m so mad for Ruby: its combination of expressiveness and a sort of practical humility is unlike any other language I’ve tried, and I’m the kind of guy who learns new languages as a hobby. I was an early adopter of Rails, but obviously mobile is a huge part of the future, so when RubyMotion came out, I was ecstatic.

What was the inspiration behind building Temple?

TW: I’m into health and fitness, and I couldn’t find an app that I liked. Most were too complicated [KM: I cook a lot, and I’d end up weighing my broccoli], or had poor design, so I thought up the basic idea of Temple, then Ken and I designed and built it.

The concept is simple, when you do something during the day which is health or fitness related, just tap the portion that’s closest. So if you eat a banana, tap “snack”. If you drink a tall glass of iced tea, tap “bottle”. What you give up in precision, you get back in sustainability and consistency. Then you can track your progress over time. We start our customers out with Fitness, Fluids, and Fuel, but it’s completely customizable, so you can use Temple for any goal you have.

Why did you choose to use RubyMotion over traditional iOS development tools?

We both like Ruby a lot, but more than that, it’s that we’re both pretty die-hard fans of a console-based workflow. We’d rather grow the language to express what we want than rely on an IDE, and we just fell in love with the workflow. Being able to tweak values from the console and see them live is amazingly powerful, much more so than drawing a static, lifeless version in Interface Builder.

What aspect of building your app was the most challenging, and what was the most enjoyable?

Most challenging for us was just that we were learning a whole new platform almost from scratch, and there’s a fair bit of learning curve there. Core Data in particular gave me fits at first, but I like it now.

The most enjoyable… There’s the point where the whole system starts to “click” and you can start riffing, refactoring, teasing out the shared structure, and turning that learning into libraries that will let us, and hopefully others, go faster next time. That’s the real joy of programming for me. But now that the app is out, the positive reactions from users is really what keeps us going.

Were there some open source tools that helped you build your app quickly?

KM: Does Vim count? I’ve been using it for 20 years, so it’s pretty baked into my fingers at this point. BubbleWrap and Teacup got heavy use. We had some performance issues with Teacup, especially startup time, but in terms of its basic mode of interaction, keeping sets of inheritable properties and having fine-grained control over your views, I can’t imagine making an app any other way now.

We’re actually working on a couple of our own, to be announced shortly.

TW: Like Ken said, Vim would be #1. When I’m not in Photoshop or Omnigraffle, I’m in Vim. In Temple we used Teacup, Bubblewrap, and MotionSupport, which all worked well for us. I started developing RMQ (RubyMotion Query - to be announced) in Temple, it’s using about half of it at this time. In the future, for front-end stuff we’ll be using RMQ.

What advice do you have for people who are building apps today?

Start small and get something you can stand behind as quickly as possible. Promoting it is going to be at least as hard as writing it in most cases, assuming you’re going it alone, and you want to get started on that as soon as you can before you invest more time in coding. That’s part of the beauty of RubyMotion. We’re able to move so fast that we can cut down the time from idea to execution and then test it in the market as soon as possible.

What tools would you like to see added to the RubyMotion toolchain?

KM: Integration with Instruments would be nice. So rake profile:simulator would bring the app up connected to Instruments from launch.

TW: I love RubyMotion, however I’d love to have full integration testing built in. Also, exception reporting has sometimes been less than helpful, so we’re excited to see the changes in 2.5.

Thanks guys!

You can watch them all. If you have time to only view one, may we suggest watching Juan Karam announcing the awesome Joybox framework?

In making it possible for you to use Ruby to write great iOS applications, we were faced with a number of constraints imposed by limitations of the iOS runtime. As a result, when we launched RubyMotion there were a number of edge cases that developers had to be careful about in order to avoid leaking memory or running into memory related crashes.

As part of our efforts to constantly improve RubyMotion and provide the best possible platform for iOS development, we are happy to announce RubyMotion 2.5 which should resolve a large number of these edge cases. The end result is that you can now build your iOS apps with the confidence that they will work right the first time and won’t waste resources.

Blocks Rewrite

Blocks in Ruby are everywhere. Blocks can be created on the fly, for example for a method iterator callback, or transformed into a object of the Proc, for later use. Variables defined in a block can refer to local variables and change their content; we call them dynamic variables.

The initial implementation of blocks in RubyMotion came from MacRuby, a project we created several years ago. The main idea behind the implementation was to map dynamic variables as pointers to the stack, and automatically relocate them into heap memory when the block would escape the scope of the current method. Also, because the Objective-C garbage collector had a slow memory allocator, we were heavily caching the block structures, which made invalidating dynamic variables later harder and also recursively calling into existing blocks.

RubyMotion shipped with this implementation and presented right away an important limitation; block variables, including self, would not be retained by the block structure. Calling a block that escaped the scope of the method it was created from would cause a crash if it was using a dynamic variable. The known workaround was to use instance variables instead, which always created a strong reference.

Now this is history. As of RubyMotion 2.5, blocks have been completely rewritten. Dynamic variables are always allocated as heap memory and the block keeps a strong reference to all of them, including self. The block data structure and the Proc class are now internally the same data structure, an object that is properly reclaimed by the iOS runtime when no longer used. Blocks created on the fly are not cached anymore. Local (non-dynamic) variables are still allocated on the stack and potentially optimized into registers.

def sum(x, y)
  lambda { x + y } # `x' and `y' are now hosted inside the Proc object.
end

sum.call(40, 2)

Another major issue is that passing a Proc object to an iOS API expecting a C-level block would cause the object to leak. It was due to the fact that the C-level blocks created by the runtime would keep a strong reference to the Proc object and never be destroyed.

As of RubyMotion 2.5, C-level blocks are now created by the compiler on the stack. They do not keep a strong reference to the Proc object, and they implement the copy/dispose helpers as defined in the Blocks specification to properly transfer the ownership of the Proc object when needed.

class MyObserver
  def initialize
    @obs = {}
  end

  def register(name, &b)
    @obs[name] = NSNotificationCenter.defaultCenter.addObserverForName(name,
        object:nil, queue:nil, usingBlock:b)
    # `b' is now retained.
  end

  def unregister(name)
    NSNotificationCenter.defaultCenter.removeObserver(@obs.delete(name))
    # `b' is now released.
  end
end

Retain Cycle Detection

RubyMotion exclusively relies on the existing retain-count-based memory management system implemented in the iOS runtime. It is the exact same mechanism used by Objective-C applications. Each object starts with a retain count of 1, and its value is properly incremented and decremented when a reference to it is created and destroyed.

The main problem with this system is that cyclic references are possible. A cyclic reference is a set of objects where the last object references the first.

Objects that are part of a cyclic reference graph are never released and leak memory. Detecting and debugging cyclic references in code can also be a challenging task, especially when the graph is large. Ruby, as a very expressive programming language, also makes it quite easy to create cyclic references.

The RubyMotion runtime has been improved to detect and break basic cyclic references. We implemented a simple algorithm that should be able to handle most circular references present in real-world apps, without introducing a significant performance or memory usage penalty.

# An example of a cyclic reference now detected by the runtime.
# MyController -> Array (@events) -> Proc (self) -> MyController

class MyController < UIViewController
  def action
    register_event { do_something }
  end

  def register_event(&b)
    (@events ||= []) << b
  end
end

In order to preserve acceptable performance, we added limitations to the cycle detector. Only objects instantiated from Ruby classes are scanned for cyclic references. An object is only scanned for cycles when the autorelease pool it was created from is drained. The runtime will not keep track of the object after that point. Only Array, Hash and Proc objects present in the graph are visited. For performance reasons, we limited the number of iterations; a cyclic reference containing more than 20 objects will not be released.

The cycle detector is enabled by default in RubyMotion 2.5. We ran the test suite of pretty much every RubyMotion project and library we could find and did not identify any problem. We also seeded the build to some of our developers who reported very positive feedback. However, in the event that your app doesn’t work anymore due to the cycle detector, you can disable it by setting the ARR_CYCLES_DISABLE environment variable to any value.

Better Crash Reporting

Your app will eventually crash. It has to be expected. What’s important is to properly investigate the cause of the crash and make sure it doesn’t happen anymore. We took the opportunity to improve the crash reporting story in RubyMotion 2.5.

The Exception class is now a subclass of NSException and properly implements its builtin methods, such as name, reason, callStackReturnAddresses and callStackSymbols (simulator only). Thanks to this change, crash reporting tools can now analyze crashes from RubyMotion apps due to uncaught exceptions without any additional logic.

We also removed unnecessary exception handlers created by the build system and the runtime so that an uncaught exception will crash the process as naturally as possible.

Finally, we introduced the rake crashlog task that you can use to open the latest crash report file that was generated by the system.

Thanks to these changes, RubyMotion apps should now be more solid and use less resources. We hope that you will enjoy these changes. We would also like to thank Joe Noon (Localini) and Matt Massicotte (Crashlytics) for their help during the development of this release.

You can watch them all, and if you have time to only watch one of them, may we suggest Accessibility and RubyMotion by Austin Seraphin?

As the team behind PhraseApp we work really hard to make internationalization of web and mobile applications less painful. Especially when building iOS apps developers typically spend a lot of time managing localization files, entering new translations and sending translations back and forth. At the same time, localizing an app becomes more and more essential for the success of a mobile software project as translated user interfaces increase the reach and customer satisfaction of those apps.

Multi-language iOS apps

Localizing an iOS application sounds simple: Just replace all occurences of NSString with NSLocalizedString, copy all translations into text files (or let some tool generate them for you) and keep all of your Localizable.strings files in order.

But this can get quite tedious and difficult when you are dealing with larger apps, lots of languages and frequent updates. After all, no developer likes managing translations in text files, constantly changing texts and translations for their clients or dealing with corrupted files caused by a missing semicolon. Instead they would like to focus on the actual development of beautiful user interfaces and the app’s business logic.

This is where PhraseApp shines. Clients, translators and managers edit their translations in the web-based editor. And developers just get their valid translation files directly from the API via a command line tool. Happy Developers!

Adding the gem

To get started, you need to sign up for a (free) account with PhraseApp. A wizard will guide you through the first steps of the registration process. You can skip the wizard after you have selected the locales for your project since we will add all translation resources later without any effort at all. Instead, grab the auth token from the PhraseApp project you have just created. You find your auth token on the project overview page.

Next, add the motion-phrase gem to your project using bundler:

gem 'motion-phrase'

or manually:

$ gem install motion-phrase

and require it in your Rakefile.

Initializing your project

Now, let’s tell PhraseApp a little bit about the app we’re building. With a simple rake task we will tell PhraseApp that we want to connect our RubyMotion project to the service:

$ rake phrase:init AUTH_TOKEN=YOUR_AUTH_TOKEN

Let’s add the auth token to the app’s Rakefile as well and enable the service in development mode only:

Motion::Project::App.setup do |app|
  app.name = "MyApplication"

  app.development do
    app.phrase do
      app.phrase.enabled = true
      app.phrase.auth_token = "YOUR_AUTH_TOKEN"
    end
  end
end

Strings go global!

We have to tell the strings in our app that they should be translatable into other languages. Fortunately, this can easily be done by calling the #.__ method on the String/NSString class that is implemented by motion-phrase:

"Hello World"

now becomes:

"Hello World".__

Call that method on every string in your app that requires to be localized.

Talking to PhraseApp

When you start your app in the simulator motion-phrase automatically sends all strings (and all translations that are found in your Localizable.strings files) to PhraseApp. All you have to do is to browse the views that contain localizable strings. As soon as they are accessed, PhraseApp knows about them and allows your team to translate them within the web editor.

When all of your translations are completed in PhraseApp it’s time to bundle them with your app. You can fetch all translations from the API and store them in our RubyMotion project simply by using the following rake command:

$ rake phrase:pull

It will download valid localization files and create a LANGUAGE-NAME.lproj folder for each locale that contains a Localizable.strings file with all the translations you have stored in PhraseApp.

If you already own completed translation files, it would be a good idea to tell PhraseApp about them:

$ rake phrase:push

This will upload all Localizable.strings files inside your resources folder to your PhraseApp project. A good way to get started quickly if you already have some translations in your project that you want to keep.

Your app is now officially localized ;-)

More Information

Read some more detailed instructions in the README.

About PhraseApp

PhraseApp speeds up the translation of web- and mobile applications. The cloud-service is developed by the engineers of Dynport GmbH, located in Hamburg, Germany.

PhraseApp is free for small and open source projects.

We are glad to report that ShowKit’s newest release now supports RubyMotion! Embedding the ShowKit SDK into your RubyMotion app is as easy as vendoring it, you can refer to the documentation for instructions.

When I started writing my first RubyMotion application, I almost immediately wanted to use a Ruby gem to accomplish a certain goal. After setting up my Gemfile, running bundle and rake in the Terminal, I soon discovered that it wasn’t possible to just require any random gem I wanted to: it had to be aware of it being required in a RubyMotion app.

Suddenly, my next open source project became a fact. I wanted to create a gem which allowed you to require any Ruby gem in a RubyMotion application. My first attempt was the LockOMotion project. It gets the job done but it wasn’t test-driven enough and the code wasn’t well structured. Enter MotionBundler, a complete rewrite with a 100% test-coverage.

I am a big fan of using and writing libraries and gems that are as unobtrusive as possible. I did not want to force the developer to follow special conventions (e.g. using another method than require to load up code). And MotionBundler does just that.

Setup and Usage

MotionBundler is intended to be easy in installation and usage. You need to setup your Gemfile by separating RubyMotion-aware Ruby gems from the ones that are not. Put the RubyMotion-unaware gems in the :motion Bundler group, as shown here.

source "http://rubygems.org"

# RubyMotion aware gems
gem "motion-bundler"

# RubyMotion unaware gems
group :motion do
  gem "slot_machine"
end

[...]
require "motion/project"

# Require and prepare Bundler
require "bundler"
Bundler.require

Motion::Project::App.setup do |app|
  # Use `rake config' to see complete project settings.
  app.name = "SampleApp"
end

# Track and specify files and their mutual dependencies within the :motion 
# Bundler group
MotionBundler.setup

Finally, you can just run the bundle command then the default rake task to build and run the application. And that’s all about it!

Requiring non-Gem Sources

Just like a regular Ruby project, you are now able to require source files. It can either be a relative path on the file system or a Ruby standard library source file. As an example, let’s require the cgi Ruby standard library file and use the CGI.escape_html method in a RubyMotion controller.

require "cgi"

class AppController < UIViewController
  def viewDidLoad
    puts CGI.escape_html('foo "bar" ')
  end
end

Looks familiar, right?

How Does MotionBundler Work?

MotionBundler traces require, require_relative, load and autoload method calls in your code when invoking MotionBundler.setup. All four methods eventually are delegated to the require method which MotionBundler hooks into. MotionBundler calls MotionBundler::Require::Tracer::Log#register which traces the calling Ruby source and registers the source file being loaded.

When MotionBundler.setup invokes Bundler.require :motion, all required files and their mutual dependencies are registered. Aside from the Ruby gems defined in the :motion Bundler group, MotionBundler also uses Ripper::SexpBuilder to scan for require statements (like motion-require does) in the Ruby sources defined in ./app/**/*.rb so it can trace requirements using MotionBundler::Require::Tracer::Log.

Console Warnings

When I was writing LockOMotion it was very difficult to debug certain errors. I have been able to override certain core methods to print warnings which contain useful debug information.

These are only printed in the iOS simulator console. When running from the device, MotionBundler does not interfere when an error gets raised. As an example, let’s check out a warning printed in the console when dealing with a runtime require statement.

[...]
   Warning Called `require "base64"`
           Add within setup block: app.require "base64"
2013-05-21 13:45:26.851 SampleApp[17300:c07] app_controller.rb:48:in `viewDidLoad': uninitialized constant AppController::Base64 (NameError)
    from app_delegate.rb:5:in `application:didFinishLaunchingWithOptions:'
2013-05-21 13:45:26.855 SampleApp[17300:c07] *** Terminating app due to uncaught exception 'NameError', reason: 'app_controller.rb:48:in `viewDidLoad': uninitialized constant AppController::Base64 (NameError)
    from app_delegate.rb:5:in `application:didFinishLaunchingWithOptions:'
[...]

Here, the base64 file is missing from the build system. You can fix that problem by adding the following code in the Rakefile.

MotionBundler.setup do |app|
  app.require "base64"
end

RubyMotion Runtime Limitations

Unfortunately, you still cannot just require every file that works within a regular Ruby environment. You cannot require C extensions and you cannot evaluate Ruby code passed in a String (e.g. the eval method). This is why MotionBundler cannot ensure that you can require every Ruby gem out there. They have to be RubyMotion friendly, for example like SlotMachine.

But as a last resort, MotionBundler offers you to possibility to mock source requirements by loading drop-in replacements written in pure Ruby.

Mocking Sources

Let’s say you want to use a Ruby gem which requires the stringio extension. Because stringio is a Ruby C extension, and that RubyMotion doesn’t support Ruby C extensions, that Ruby gem will not load up in RubyMotion. However, as mentioned earlier, MotionBundler offers a possibility to bypass this problem by mocking the library.

Instead of requiring the stringio.bundle file, MotionBundler is able to mock it with a pure Ruby implementation of it, taken from MacRuby. At the moment, MotionBundler also mocks strscan, zlib and httparty (only its basic features).

Aside from mocks being defined within the MotionBundler gem, you can also define your own mocks within your RubyMotion application. Just add a directory called mocks within the root directory of the application and put the mock sources in it. The relative path of the mock source within that directory ensures a certain Ruby file being mocked during compile time.

Let’s say the root directory of your RubyMotion application is ~/Sources/sample_app. If you want to mock require "yaml", create a file at ~/Sources/sample_app/mocks/yaml.rb containing the mock code. If you want to mock require "net/http", create a file at ~/Sources/sample_app/mocks/net/http.rb.

You aren’t supposed to mock entire Ruby gems of course, that would be crazy. But you would rather mock fundamental Ruby standard library sources (like stringio.bundle) so you don’t have to dismiss a certain Ruby gem for use in your RubyMotion app on forehand.

Please Try MotionBundler!

MotionBundler is available on Github. The repository provides a sample application. You can clone the repository, navigate to the sample application directory, run bundle followed by rake. Please check out MotionBundler! Pull requests, remarks or requests are very welcome! You can also contact me on Twitter :-)

Finally, I would like to say thanks to Laurent, Nick Quaranto and Dave Lee for giving me some feedback and suggestions.

You can discuss this post on the RubyMotion google group.

Paul Engel is a software developer living in beautiful Amsterdam, Netherlands.

Last August I started working on a new RubyMotion app. I quickly realized that one of UIKit’s most frequent pain points is working with UINavigationControllers, UITabBarControllers, and UIViewControllers — it just took too many lines of code to move around in my app. That led to the idea behind ProMotion: abstracting the screen and navigation handling in a Ruby-like way.

It has been a great experience building it and I’m going to show you how ProMotion could make your next iOS project a lot easier (with lots of code examples!). The source is also available on GitHub.

ProMotion subclasses UIViewController and UITableViewController to provide a ton of new functionality and abstraction and calls them ProMotion::Screen. (You can also use ProMotion with Formotion or your own UIViewController).

Note: from now on I’ll refer to ProMotion by its shortcut alias, PM.

class HomeScreen < PM::Screen
  title "Home"
end

Pretty simple. What about viewWillAppear:animated and other Obj-C methods? We implement simpler versions of those for your use:

def on_init
# Fires right after the screen is initialized
end

def on_load
# Fires just before a screen is added to a view for the first time.
end

def will_appear
# Fires every time the screen will appear
end

def on_appear
# Fires just after the screen appears somewhere (after animations are complete)
end

def will_disappear
# Fires just before the screen will disappear
end

def on_disappear
# Fires after the screen is fully hidden
end

When you create a screen you can pass in attributes. One of these is nav_bar: true which creates a UINavigationController and pushes the screen onto it. You don’t have to manage the navigation controller at all.

open HomeScreen.new(nav_bar: true)

Within that screen you can open other screens and they’ll be pushed onto the UINavigationController automatically.

open SecondaryScreen

If you pass in a class instead of an instance, ProMotion will instantiate it for you.

Opening and managing a UITabBarController is a pain in Objective-C. ProMotion makes it very simple and natural.

class AppDelegate < PM::Delegate
  def on_load(app, options)
    open_tab_bar HomeScreen, AboutScreen, ContactScreen, HelpScreen
  end
end

# in app/screens/home_screen.rb

class HomeScreen < PM::Screen
  def open_another_tab
    # Switches to the AboutScreen created above if its tab title is “About”.
    open_tab “About”
  end

  def open_new_screen_in_another_tab
    # Programmatically switches to the HelpScreen
    # and pushes the SecondaryScreen onto its UINavigationController.
    open SecondaryScreen, in_tab: “Help”
  end
end

Split view controllers are as easy as tab bars.

open_split_screen MenuScreen, DetailScreen

From the left-hand part of the split screen it’s easy to open a child screen in the right. Just add in_detail: true to the open command:

open SomeDetailScreen, in_detail: true

This is ignored if there isn’t a split screen so it’s ideal for use in universal apps.

You can easily build list views (“tables”) in ProMotion. Formotion is excellent for building forms, but sometimes you just want a menu or list of information. That’s where ProMotion’s built-in TableScreen works well.

class HelpScreen < PM::GroupedTableScreen
  title "Help"

  def table_data
    @help_table_data ||= [{
      title: "Get Help",
      cells: [{
        title: "Email us", action: :email_us
      }]
    }]
  end

  def email_us
    mailto_link = NSURL.URLWithString("mailto:jamon@clearsightstudio.com")
    UIApplication.sharedApplication.openURL(mailto_link)
  end
end

When the Email us cell is tapped, ProMotion fires the email_us method.

For plain tables, you can add searchable and refreshable easily:

class StatesScreen < PM::TableScreen
  title “States”
  searchable
  refreshable

  def table_data
    # list of states
  end

  def on_refresh
    # refresh your data here, usually async
    some_async_call do
      # update your data
      stop_refreshing
      update_table_data
    end
  end
end

Everybody has their favorite iOS styling system and ProMotion works beautifully with all of them. Pixate, NUI, and of course RubyMotion’s Teacup are all very good choices.

For those who want a simple, Teacup-lite styling system, ProMotion comes with one built-in.

set_attributes self.view,
  background_color: UIColor.grayColor

add UILabel.alloc.initWithFrame([[10, 10], [300, 45]]),
  text: “Welcome to ProMotion!”,
  resize: [ :left, :right, :top ],
  background_color: UIColor.clearColor,
  text_color: UIColor.whiteColor,
  shadow_color: UIColor.blackColor,
  number_of_lines: 0,
  text_alignment: UITextAlignmentCenter,
  font: UIFont.boldSystemFontOfSize(18.0)

This UILabel is added to the view and all the attributes are set. Snake case is converted to camel case automatically when appropriate. There are also some nice helpers like the resize setting for UIViewAutoresizingMasks.

ProMotion is already being used in production apps around the world and is becoming quite stable. It’s likely that version 1.0 will be coming soon without major changes to the API.

Without RubyMotion, it’s very unlikely that a system like ProMotion would exist. There’s nothing like it in the Objective-C world and the community is a lot different there. It’s a testament to the RubyMotion community as well as Laurent and his team for making this possible.

This is just an intro to ProMotion — head over to the GitHub repo to learn more. I hope you take a look at it for your next project!

Jamon Holmgren (@jamonholmgren) is the owner of ClearSight Studio, a mobile app and web development studio located near Portland, OR.

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!

Project Templates

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.

Command-Line Plugins

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.

Weak References

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.

It was the first conference we ever organized. We would like to share our experience in this post as well as cover what happened!

The Venue

We wanted the first conference to be friendly, diverse and exclusive. We initially fixed the maximum number of attendees to 100 because we knew that over this limit it would have been difficult for everyone to meet up and chat. We eventually raised the limit to 130. Despite the fact that the majority of RubyMotion users are located in the United States, we also knew that we wanted the conference to happen in Belgium, for practical reasons.

It took us quite a bit of time to find the conference venue. We visited a few venues but they didn’t really match what we had in mind. We wanted the venue to be special, unusual, and at the same time professional and prestigious. We also wanted the venue to be in the historical center of Brussels, because the area is full of hotels, restaurants, bars, and tourist attractions. Organizing the conference in a hotel near the airport was therefore out of the question.  

The Grand Place is Brussels’ main square and also the center of its historical center. We started looking around for potential venues and we eventually figured out it was possible to rent a house on the Grand Place itself! We quickly jumped on the opportunity.

We got 130 visitors from every continent. A lot of different accents were heard, making the event very diverse. Most of the attendees were visiting Belgium for the first time, so they got to taste our awesome beers and chocolates!

The Schedule

The conference featured a single track over 2 days. We pre-selected 10 speakers for the announcement and opened a call-for-papers. We originally wanted 18 presentations.

Pre-selecting as many speakers was probably a mistake because we received close to 80 talk proposals. We didn’t expect to receive as many talk proposals and it was very tough to decide on the remaining selection. We had to reject a lot of very interesting talks.

We eventually decided to go with 20 presentations, which means we had to fit 10 talks each day, and still leave enough room for breaks and lunch. We took over the challenge and eventually managed to finish the conference on time!

We decided not to print the schedule on paper and preferred to have an iOS app instead. We teamed with the awesome folks at Epic, who already made the conference website, to create an iPhone app for the conference. The app was obviously written in RubyMotion, using the Teacup and Sugarcube libraries. You can find the full source code on GitHub.

The Food

Offering delicious food was extremely important to us. We did not want to give away dry sandwiches that you can find in most conferences.

We welcomed visitors with fresh pastries (cooked onsite), coffee, tea and juices. Each attendee also received chocolates from Benoit Nihant's Haute Couture selection. Benoit is one of the remaining true chocolatiers of Belgium.

For lunch, our attendees had access to a full Belgian buffet which included cured meats, steak tartare, duck, various salads, fresh vegetables, salted waffles and more. A huge assortiment of homemade deserts was also available, including chocolate mousse, fruit tarts, tiramisu, and more. And we of course served beer!

Most attendees told us they had the best conference food experience ever.

The Shirt

We designed the conference shirts by ourselves. We didn’t want to go with a traditional “conference name + date” shirt, so we iterated quite a bit on the design.

We finally ended up choosing to represent a coat of arms. The logo we went with features two wyverns (an homage to the LLVM project) supporting the existing RubyMotion logo on a white shield, crowned with a sparkling ruby.

The motto is written on a white ruban and reads "#inspect RubyMotion 2013".

The Presentations, 1st Day

A Brave New World: Learning iOS for the Ruby Refugee, by Nick Quaranto (slides available). Nick covered his experience using RubyMotion to write a couple sample projects (which eventually turned into the official Basecamp iPhone app) and talked about the motion-settings-bundle and motion-autolayout gems he extracted in the process. We later recorded an interview with Nick that you can also check out. 

Behaviour Driven Motion using Calabash, by Karl Krukow (slides available). Karl introduced the Calabash framework and how you can write acceptance tests for RubyMotion apps with it, using the motion-calabash gem. (Note: A few days later it was announced that LessPainful, Karl’s company, was acquired by Xamarin.)

Controlling the Real World with RubyMotion, by Rich Kilmer (slides available). Rich talked about the history of bluetooth, starting from the first specification up to the bluetooth4 standard, and described the APIs that you can use to interface from RubyMotion. And before you ask, yes, Rich was wearing white pants.

Elevate your Intent, by Matt Green (slides available). Matt talked about the complexity that can rise when designing iOS apps and offered a solution through his elevate gem that we recommend checking out.

Accessibility and RubyMotion, by Austin Seraphin (slides available). Austin, a blind developer, talked about accessibility and how RubyMotion makes it easier for blind people to develop apps. Undoubtedly one of the most acclaimed talks of the conference. Austin also covered his trip to the conference in 3 blog posts that we highly recommend: An Unexpected Journey, #inspect 2013, and The Journey Home.

CoreData For The Curious Rubyist, by Jonathan Penn (slides available). Jonathan introduced CoreData, Apple’s framework for data persistence. He covered what CoreData is, when to use it, and the builtin framework classes you will have to deal with when integrating it in your app. Demo code available.

The Life and Times of an Object, by Joshua Ballanco. Josh started with a simple app that was crashing and investigated the crash using low-level tools such as gdb and malloc-history. Eventually, it turned out that the bug was in the RubyMotion runtime!

Concurrency in RubyMotion: Use the Multicore Luke!, by Mateus Armando (slides available). Mateus talked about how it is necessary to use concurrency and the various approaches to it, such as GCD and NSOperationQueue.

Get More From RubyMotion with RubyMine, by Dennis Ushakov. Dennis didn’t have any slides, he simply started developing a RubyMotion app straight within RubyMine and demo’ed the excellent RubyMotion integration we (HipByte and JetBrains) have been working on together, featuring smart auto-completion, debugging on simulator and device, refactoring, documentation viewer, and more.

Crafting iOS Dev Tools in Redcar, by Delisa Mason (slides available). Delisa talked about Redcar, an open-source editor written in Ruby, and introduced its very extensible plugin infrastructure. She eventually showed how she managed to integrate RubyMotion in Redcar.

The Presentations, 2nd Day

NSRevolution: How Ruby hackers built the new Objective-C Open Source community, by Mattt Thompson (slides available). Mattt talked about the influence of the Ruby community on the younger iOS community. 

More Than You Need to Know About CocoaPods, by Eloy Duran (slides available + video 1 and video 2). Our hero Eloy talked about CocoaPods, the missing package manager for Objective-C libraries, and also featured a sneak-peak at their sister project, CocoaDocs.

Wrapping iOS in RubyMotion, by Clay Allsopp (slides available). Clay covered various techniques you can use to create elegant and nice Ruby wrappers on top of iOS API patterns, such as callbacks, delegates and enumerations.

Goodbye IB, Hello Teacup, by Colin Gray (slides available + video). Colin started talking about Teacup, a library to style user interfaces, and eventually announced motion-xray, a powerful iOS inspector running inside RubyMotion apps that can be opened using a device gesture.

Using BubbleWrap to Quickly Build RubyMotion Apps, by Marin Usalj (slides available). Marin gave a nice overview of the Bubblewrap project, which aims at becoming the ActiveSupport of RubyMotion.

Mixing CoffeeScript in RubyMotion apps, by Michael Erasmus (slides available). Michael talked about his experience building a cross-platform mobile app where CoffeeScript was used to build the common logic.

Building Interactive Data Visualization Charts, by Amit Kumar (slides available). Amit talked about the various libraries one can use to integrate interactive charts in an iOS app, and eventually announced the motion-plot gem, a nice RubyMotion wrapper sitting on top of the CorePlot framework.

Cocos2D, an Easier Way, by Juan Karam (slides available). Juan talked about his gaming experience, basic game programming concepts, and eventually announced Joybox, a RubyMotion gaming library integrating the popular Cocos2D and Box2D frameworks. He even wrote a simple game during his talk!

Let’s Move with CoreMotion, by Akshat Paul and Abhishek Nalwaya (slides available). The inseparable friends gave a speedy talk about CoreMotion, Apple’s framework for motion sensors integration. They talked about the core builtin classes and how you can use them from RubyMotion.

RubyMotion: Past, Present and Future, by Laurent Sansonetti. Laurent gave the final conference presentation. He talked about what made him create RubyMotion, the current state of the project, and what the future holds.

The Party

We concluded this wonderful conference with an awesome party! 

Our friends at GitHub graciously sponsored the party. We booked the entire Hoppy Loft room of the Delirium Cafe, one of Brussels’ legendary pubs, which features thousands of different beers.

Conference attendees were able to taste quite a lot of delicious Belgian beers. We ended the party at around 4AM!

The Sponsors

RubyMotion #inspect 2013 would not have been possible without the support of our great sponsors.

Our lead gold sponsor. Heroku is the first and best multi-language cloud application platform, or platform-as-a-service. Heroku allows developers to deploy, scale, and manage their apps without needing to think about servers or systems administration. Over one million applications have been deployed to Heroku.

One of our silver sponsors. JetBrains is a world leader in smart development tools that help software developers simplify their challenging tasks and automate the routine ones. 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.

One of our silver sponsors. Here at Cyrus, our team of forward-thinking developers are continuously expanding their skillsets to incorporate the latest tools in software development. With RubyMotion, Cyrus is once again at the forefront of innovation helping our clients cut down both development time and costs.

One of our silver sponsors. Nedap is a manufacturer of intelligent technological solutions for relevant themes. Sufficient food for a growing population, clean drinking water throughout the world, smart networks for sustainable energy are just a couple of examples of themes Nedap is working on.

One of our silver sponsors. Boxcar is a push notification service. Boxcar provides real time push notifications for the services you love.

One of our bronze sponsors. At The Pragmatic Studio, we help programmers continually improve their skills and their careers through hands-on training courses.

One of our bronze sponsors. Founded in 2008, Belighted is a leader in the use of Ruby on Rails technologies and agile methodologies. 

Summary

Organizing a conference is hard. But we believe we did a pretty good job on this one! Nothing catastrophic happened, people enjoyed the event, the Wi-Fi didn’t work, and budget-wise we should break-even. 

RubyMotion #inspect 2013 would not have been possible without our helpers team: Stephanie Sansonetti, Stephane Wirtel, Yannick Schutz, Franck Verrot and Marc Lainez.

We published the official photos of the conference, check them out! Also, all presentations have been recorded, we will let you know once they are available.

Finally, we would like to announce that there will be a RubyMotion #inspect 2014 conference. We can already tell you it will happen on the other side of the Atlantic ocean and that it will be even more epic.

Stay thirsty, my friends!

We are glad to report that they just announced that they will support RubyMotion!

We worked together with the folks at Algolia on a RubyMotion integration gem that lets you easily integrate their offline SDK.

The Algolia folks also graciously agreed to donate 5 White Label licenses (custom branding) to the firsts to email hey@algolia.com. Hurry up!

While RubyMotion continues to build momentum, it’s obvious that not everyone can attend such endeavors as RubyMotion #inspect or the public RubyMotion training in the San Francisco Bay Area. Fear not! From the community of RubyMotion developers we’re happy to announce a new monthly online meetup for everyone, worldwide, called MotionMeetup.

This online meetup will spotlight a developer from the RubyMotion community or general RubyMotion ecosystem to interview and interact with the community.

Meetups will, as of now, occur once a month and consist of at least 30 minutes of live discussion via video conference. The discussions will cover a wide array of topics generally consisting of each spotlighted guest’s projects all the way to their opinions and philosophies.

You’ll also be able to ask your own questions in the #rubymotion IRC channel on freenode and interact with featured guests and fellow developers while the video conference is going on.

If you would like to be notified on updates please fill out the sign up form at MotionMeetup. If you’re interested in being a featured guest for a future meetup or would like to see a topic addressed, please contact the coordinators of MotionMeetup, the good people at Iconoclast Labs.

As you may have already heard, the Basecamp app is written in RubyMotion. Since Nick Quaranto was speaking at our conference last week, we decided to take advantage of the opportunity to record a quick interview with him about the experience. Check out the video and the transcript below! 

You just announced the motion-layout gem tonight, has it been a long time coming?

(Laughs). Kind of. When we wrote the Basecamp app at 37signals we didn’t really use Interface Builder at all.

There is a new API in iOS6+ that provides auto layout for views, and specifically there is an ASCII-art style format string. It’s really weird that Apple let programmers design ASCII-art languages. So, the gem wraps that kind of verbose API that Apple provides.

So I guess it’s kind of been a long time coming, it has been 2-3 months in the making, it’s really not complicated, it’s just a little gem.

Speaking of the Basecamp app, when did that get started? When did you put that into your bosses’ ears?

That’s kind of an evolution. I started using RubyMotion in June, and RubyMotion came out in May. I basically got that month – I was very lucky to get a whole month to just work on iOS.

I hadn’t done any iOS work before, I had only done Ruby and Rails, and before that, I had a Microsoft background. (Laughs)

You don’t have to admit that here (Laughs)

I feel bad now. (Laughs)

Anyway, the first app we worked on was kind of a prototype. It was to learn how iOS apps worked. That got rejected, we ended up not going forward with that.

How was that initial learning experience?

Good! I feel like I really got a lot from that whole month. I learned how to make an app, how to ship it on TestFlight, I learned gestures and how hard it is to write an app, images and all sorts of other stuff. The different layouts, and how things are supposed to work.

We didn’t go forward with that very specific idea, because we were kind of prototyping the idea, but we kind of merged together two ideas that were coming forward. I had an idea: in that little prototype app we used HTML inside a small part of the app, and it felt very native, and at the same time we were working on web views for Basecamp, so that if you were on Safari on iOS, or Android, or any other browser you could see your stuff in Basecamp, so we kind of decided that, wow this is really native, it felt very native on the phone even if it was HTML.

We had all these views, and we kind of combined these two into an app. It wasn’t Basecamp at the start, we actually started just by solving specific problems, for example just to get an update on your phone when something was happening on your projects.

The app was focused on that at first, then we realized it kind of stinks that this is all you have, and we wanted to jump between things in your projects, and see all your TODOs, or all your files, so it kind of evolved from there and eventually it became the Basecamp app. We didn’t start by saying “we are going to make a Basecamp app”, it was more started like we have these problems when we’re on the run with Basecamp, and we want to fix those.

What did your RubyMotion toolbox and workflow look like?

Pretty normal, we do use a mix of Cocoapods and gems, we use some URL caching, there is just a few others… date formatter stuff that we use as well.

On the Ruby side we use Bubblewrap which is a great resource for anyone that’s starting with RubyMotion, just for iOS development in general, it saves a ton of time.

There are a few gems that I extracted along the path like motion-layout, I also have another one to make settings-bundles, called motion-settings-bundle. So it’s kind of a mix of both, and I think that it’s very healthy that we can get all of these great libraries from the Objective-C world and use new Ruby stuff as well.

You are a very seasoned Rails and Ruby developer, what were the challenges working with RubyMotion? And Laurent won’t hear this. (Laughs)

(Laughs). I didn’t have any big problems with RubyMotion, the challenges were mostly iOS, and I think that’s… you can’t get around it, you have to learn the Apple APIs, you have to deal with that, you have to understand the patterns that are in Objective-C in Ruby, and that was a big source of conflict for me, because there is a conflict between the style we see in Ruby and the style in Objective-C, and they kind of butt heads all the time.

So I think that that was the hardest part for me, understanding and internalizing the patterns that are in Objective-C and all over Cocoa and libraries, such as delegates, the list goes on an on, like constants and enums, the list doesn’t end, you have to know all these things, you have to be fluent in both to be useful, but I did it (Laughs).

So I think it’s definitely possible to come from basically zero iOS knowledge and do an app with RubyMotion.

Is there anything that you learned along the way – I am sure there are some things! – so when you start you next app, what are the things you learned that will make you start quicker?

I am going to start testing more (Laughs). I need to admit that I didn’t do any good job at all and we are definitely going to fix that, because the Basecamp app is something that we care about and we need it to last for years. So that’s a big thing I wished I looked into sooner.

Another thing… I always learn this lesson again and again: test on the device sooner! Obviously if you are making a mobile app you should be, but it’s very easy to be tricked thinking that the simulator is the real thing, when it’s not. There are performance problems that you see on the device that aren’t in the simulator, and I feel like I got reminded of this on a weekly basis.

Was there anything from the conference that just finished that you were excited about? You mentioned testing…

Yeah there were lots of great testing talks, a lot of crazy things came out, people really showed stuff I was impressed by.

One of the later talks was about Cocos2d, which is a game wrapper called Joybox, and it’s really neat, the guy basically made an Angry Birds clone in like 10 minutes in front of us, it was kind of crazy!

There was a testing talk about Calabash, which is really neat. Despite using Cucumber (and I have written a lot of Cucumber code), so I understand how difficult it is and how people’s opinions vary on it, but the coolest thing was that internally you had this nice API to do testing. You could drag things, you could look inside of web views, which is a big deal for us, you can do all sorts of stuff, and it’s backed by cucumber but beneath it is this cool Ruby thing that I need to look into!

I was really impressed by the quality level of talks and the stuff people showed off.

If you were starting your next app, how would you convince your boss to use RubyMotion?

Well, that’s really a good question. (Laughs)

Luckily I didn’t have to do too much convincing. Showing them how much easier it is is always a good thing, like the before and after, here is how it is in Objective-C, and here is the much-improved-less-verbose version in Ruby.

Another thing, that I think is the biggest win, especially for people that are coming from Ruby and Rails background, that if you’ve already got a team of people who know Ruby on Rails, the jump is a lot smaller to this new brave world, right, because you can leverage all of the toolchain that they know, they can use whatever they have been using in Rails, it’s the same language, there are maybe a very little differences but it’s still Ruby, you get all of the awesomeness that is Ruby, but you can’t get around learning the iOS APIs.

So I guess that if you are coming from a Ruby and Rails side, that’s it. If you’re coming from an iOS team I guess it’s probably a bit of a harder sell. Since personally I don’t have experience with that it’s harder to speak on, but I hope that if you are an iOS developer looking at RubyMotion you get a solid look at the code, like the comparison, how much easier it would be, and especially all the new things that are coming along that help you make a RubyMotion app, and that you can’t really use in Objective-C. So I hope that you give that a look if you’re trying to convince your boss.

Are there any tools, any tricks that you would like to see come down the pipeline?

It would be really nice if every-gem-ever worked, that’s very unrealistic, but I like Ruby gems a lot, so it would be very cool, it’s also a hard problem and it’s definitely been an MVP-style thing for the RubyMotion team. Just the fact that already we can make these really awesome things without having the bulk of Ruby gems available is a really good sign.

Besides that, Laurent mentioned code reloading in the roadmap, if that worked that would be a huge win. I went through a lot of links with one of the first prototype apps I made, to completely reproduce my web workflow, to the point where I remapped shake device in the simulator to Command+R, to get a reload, so if there is a better workflow for that, where you can basically say, here is what you’re used to, and here is the awesome new way of doing this, that supports the same thing, because I run rake and reload my app countless times, I should’ve kept a count, that would make a huge difference, that would make me a lot faster. Because you don’t have to wait! It’s just there. That would be huge.

Thank you Nick!

We sat down with Dan McFarland to talk about Inktera and their experience using RubyMotion. 

What is Page Foundry’s goal?

Page Foundry was founded with a very simple vision: Deliver the most robust digital content platform available. Page Foundry has been able to empower global organizations like ASUS, local businesses (authors, publishers and local booksellers) and others to connect with their customers in really meaningful ways.

How does the Inktera platform accomplish this?

The vision for the Inktera platform was very simple: help businesses acquire customers by offering a suite of branded digital content services that extend our customer’s brands, services and core values. The platform has evolved into a very robust offering that includes the ability to quickly and easily launch ebookstore apps. By quickly and easily we’re talking days - possibly even hours in some cases - not weeks or months.

What unique features does Inktera provide?

The app is completely unique in that it offers in-app purchasing for ebooks. No apps, other than Apple’s own iBooks app, offer this feature. The Inktera iOS app connects directly to the Inktera cloud which manages the reader’s library, stores their bookmarks, notes, and personalization features.

The framework for the Inktera iOS app is completely customizable by Page Foundry customers via the Inktera platform. They can add social media features, select which types of books to offer, set featured items, etc.

How do you apply the different interface customizations on the device?

The only real difference we consider is iPad vs iPhone with the use of UISplitViewController in the former. BubbleWrap’s Device.ipad? is the only convenience method we use for the detection. All layouts are done programmatically without NIBs.

We made use of LayoutManagers-Fork to get over an initial learning curve and because we were familiar with Android’s LinearLayouts. After understanding iOS’s views more, we used it because it was a similar way to lay interface objects out without trying (or having) to use DSL’s for them.

What RubyMotion tools did you take advantage of? (gems? editors?)

We have been using RubyMine since version 4.0. The latest 5.0 version finally added code completion of iOS core methods/selectors/constants which saves us one trip to Xcode’s Docs. We made a decision to not over do gem usage to avoid using something we couldn’t understand/appreciate. Our gem list is:

gem 'cocoapods'
gem 'motion-cocoapods'
gem 'bubble-wrap'
gem 'motion-testflight'

SugarCube and TeaCup look very interesting and we’ll probably incorporate them now that we have our first app under our belts.

How did RubyMotion speed up your development?

After checking our SCM, our project went from first RubyMotion check-in to Ready for Sale in 10 man weeks. Considering we had no prior iOS, C, Objective-C experience, we project this would not have been possible without RubyMotion or a significant amount more in human resource / development investment dollars.

RubyMotion was not easier than Android mainly due to our prior experience with Java. Android ADT makes creating flexible layouts very intuitive and storing the layouts in XML makes understanding structures easier. That said, the RubyMotion and iOS networking libraries with caching blow Android out of the water. RubyMotion also makes doing network on the main thread almost impossible so keeping the application responsive was a non-issue. RubyMotion certainly makes iOS development easier if the developers have Ruby experience. For Java developers Android is hard to beat. $199.99 to avoid writing method calls like arrays is priceless.

How does the iOS app integrate with the rest of the Inktera platform?

The iOS app integrates through a private Restful API. All networking between the two uses ASIHTTPRequest.

What was the biggest challenge during development?

There’s a tie for the biggest challenge. The first challenge was the integration of Adobe’s RMSDK. The RMSDK project is composed of a dozen other projects and has a very specific build process. The first weeks were spent getting RubyMotion to be able to call into all of RMSDK. This is not a trivial task. The second challenge was memory management. The team was constantly stumbling on situations where retain cycles were getting created by trivial and routine code. Saving things in instance vars helped, but then we had to remember to unset them.

What is it like using RubyMotion on an application so complex?

Overall, we could not have built what we built without RubyMotion given our time constraints and desired investment. We are a Ruby shop so being able to stay in that mind set and leverage existing skills was critical to expediting the process. RubyMotion doesn’t magically remove crash logs or the need to understand iOS concepts, but having readable code that we could write from REPL console helped the project grow with confidence.

This is a 5-day class that will teach you everything you need to know about iOS and RubyMotion, from the very basic concepts to advanced topics. Experience with iOS is absolutely not required.

At the end of the training you should be able to start writing full-fledged apps for iPhone or iPad in Ruby.

This is a hands-on training. You will get to write a few iOS applications during the course. You will also be given printed material and access to a dedicated forum where you can discuss with the instructors and other students.

The full program can be read from our training page.

You can purchase a seat for the training today. If you have any question or need any help don’t hesitate to contact us. See you in San Francisco!

We sat down with Bora to talk about his experience using RubyMotion.

First, please tell us a little bit about your app, Jukely

Jukely is the brainchild of me and Andrew Cornett, my co-founder, who’s one of the first designers and employees at Kickstarter. He had a hand in the design and development of the Kickstarter web and iPhone apps since the beginning days. We had hit it off as hacking partners years ago, worked on a bunch of music hack day stuff and other music related projects. We’re both heavily into live music, especially in the discovery and notification space. We love discovering new bands and making spontaneous decisions about what shows to see. We don’t like planning for shows months in advance. We feel like there is a beautiful and loved brand missing in the world of live music. We want to be it.

What’s your background in programming?

I’m an engineer turned architect turned product manager turned back into engineer, all the while a concert organizer as my second persona. I started with VB6 then .NET, J2EE then stopped programming for a long time while I went to the dark side, management. Discovered Ruby in 2007 and fell in love with it. I’ve been hacking on music related projects ever since.

What convinced you to use RubyMotion?

I took an iOS class last year and got completely intimidated by Objective-C. It felt like I had to write a lot of code to do simple things and in my mind’s eye any potential app idea I would want to work on was getting crushed before I could even take it seriously. When RubyMotion came out, I said heck yes! and started developing a sample app on the first day it was released. Given the elegance of Ruby and my enthusiasm for building native iOS apps, it was love at first sight.

What value does the user get out from using Jukely?

Jukely is your personal concierge for live music shows. It is powered by curation and music taste algorithms. We learn what our members like and what their friends like, make recommendations when there is a high match, and have the ability to put them on the guest list if they want to go.

How do you collect and combine the user’s music preferences?

We currently allow people to connect their Facebook, Spotify, Rdio, Soundcloud, Last.fm and Hype Machine accounts. I spent the summer writing a recommendation algorithm in Ruby. We have tons of workers that run on Heroku to sync people’s and their friends’ music listens across different music services. Then we have our own sauce that decides how shows should be recommended.

How did you integrate the server-side API using RubyMotion?

I used BubbleWrap for JSON calls to our Ruby back-end API. Also the Parse framework for reading and saving data to Parse.

What does your RubyMotion toolbox look like?

Editor: Textmate

Pods: Mixpanel, Reachability

Frameworks: Parse for database, HockeySDK for crash management, CardIO + Stripe for scanning credit cards and processing them, PassSlot for PassKit integration to create passes for shows.

My favorite has to be Parse as using it allowed us to skip writing our own code to do things like loading and saving things using background processing, signup, login, Facebook/Twitter integrations, push notifications, file uploads, as well as having image loading in tables working smoothly out of the box.

What feature of RubyMotion was the most helpful?

I would say being able to use Textmate, writing Ruby, Terminal based workflow and automated memory management were really awesome.

What was the biggest hurdle during development?

Mysterious crashes are my biggest nightmare. Being still new to iOS development, I still don’t have a full grasp on how to nail down and fix crashes that don’t identify themselves easily and only happen occasionally. Getting push notifications working was a major major pain. The steps you have to go through, my dear, and if you make one small mistake the notification is not delivered and you have no clue where you went wrong. I think I shed a few real tears when they finally ended up working.

When you hit a serious snag, where do you go with support questions?

I’ve definitely used the RubyMotion Google Group numerous times as the community there is really great. Also I’ve found increasingly more answers on Stack Overflow. As a fallback I used the support for RubyMotion and it has been very helpful.

What feature of the app was the most fun to build?

Once I learned how to do animations I introduced them in a few places. Those were really fun. Fade in loading image loading was quite pleasant and I still really like seeing those fade in transition images in the app. Also there was a lot of joy when I got the audio and video playback working using the MPMoviePlayerController class.

We may have some tickets left in case of cancelations. Let us know if you want us to notify you in this case.

Last Speakers

We are finally announcing our last speakers:

• Rich Kilmer, which we don’t have to present, will be talking about his new project that involves RubyMotion and Bluetooth LE sensors, probably wearing white pants.

• Akshat Paul and Abhishek Nalwaya will be joining us from sunny Gurgaon, India to talk about CoreMotion and how you can make intuitive apps with it. They both work for McKinsey & Company and are also working on an upcoming RubyMotion book.

We are super excited to have a total of 20 great speakers for our first conference.

If you sent a talk proposal and didn’t make it we are very sorry. We received 5 times the number of proposals we expected and it was very tough to make the selection!

Schedule

A tentative version of the schedule is now available online on the conference website.

We are also working with the nice folks at Epic on a much better way to present you the schedule during the conference, stay tuned.

New Sponsors

Heroku agreed to join us as the lead sponsor of the conference!

Finally, the big party on Friday will be covered by a secret sponsor that we will unveil in the next few days!

We started importing bugs to this new platform and while the process isn’t complete yet, we believe that we have already listed the most important bugs. At this moment bugs can only be added by team members, so we ask you to still use the support ticket system to report bugs.

We are quite excited about this move and we hope it will make the development of the toolchain more transparent to everyone.

The bug tracker is powered by YouTrack, yet another awesome product from our friends at JetBrains. 

Colin is a software developer from Denver, CO and, as the author of both Teacup and SugarCube, a popular figure in the RubyMotion community. Colin is also very active on the Google group and our #rubymotion IRC channel on the freenode network.

Colin agreed to help us build an amazing community around RubyMotion. You will read more from him very soon on this blog and other channels!

Incidentally, if you are coming to our upcoming conference you will get to see Colin talking about a top-secret project he has been hacking on!

Joffrey is a French software developer and the author of one of the most widely used iOS app in France, 02 Minutes d’Attente, which has been sitting in the Top 10 Free Apps category of the local App Store for a while. Of course, the app is entirely written in RubyMotion.

Joffrey masters the toolchain very well and has agreed to help us by joining our support team on a part-time basis. If you are reporting support tickets you may get to talk to him eventually now!

Before you ask, that’s the best picture we have of Joffrey. By the way, did you know there were sharks behind him?

We are so excited! Two entire days of 100% RubyMotion talks! 

New Speakers

We are announcing 4 new speakers!

• Delisa Mason is a software developer living in Ohio and the creator of the RubyMotion plugin for Redcar, the ruby editor. She will talk about customizing an iOS development workflow using rubies all the way down.

• Austin Seraphin is a blind programmer. In his talk, you will discover exactly how a blind person uses an iOS device and how RubyMotion makes writing accessible apps easier.

• Michael Erasmus is a software developer living in South Africa and also one of the guys making the motioncasts.tv screencasts. In his talk he will cover mixing RubyMotion with CoffeeScript.

• Juan Karam is an iOS developer working for Raku, a consultancy agency in Mexico. In his talk he will unveil the mysteries behind Core Animation and cocos2d and how you can leverage them in RubyMotion.

You can refer to the conference speakers page for the full list of speakers. We are not accepting new speakers proposals at this point.

We will be publishing the final schedule soon, stay tuned!

Few Tickets Remaining

At the time of this writing there are very few tickets left, so we highly recommend that you grab a ticket as soon as possible if you want to come to the conference. We will likely sold out in the next few days.

We are also selling one additional ticket to the training as one of the attendees sadly won’t be able to make it.

They have been working on integrating their SDK with the RubyMotion toolchain and published their results:

RubyMotion is a revolutionary tool.  It not only offers developers a new way to build iOS applications, but also shows great experimental spirit.

Check out the demo app! Also, if you are looking for a higher-level wrapper, make sure to check Motionscan (which is a work-in-progress).

We were so impressed by the work of the Pixate folks that we worked closely with them to create a RubyMotion-Pixate gem which nicely integrates the Pixate framework in RubyMotion projects. Check out how it works by watching this screencast made by Pixate co-Founder Paul Colton.

It will be a 2-day, one-track conference full of short, 100% RubyMotion talks. It will undoubtedly be awesome!

Please see our our previous post for more information about the conference.

Early-Bird Discount

The Early-Bird tickets have been going fast, so you better hurry if you still want to take advantage of the 20% discount on the ticket price.

We will be running the Early-Bird discount until January 20th.

New Speakers

We are announcing 4 more awesome speakers!

• Mattt Thompson is the Mobile Lead at Heroku, and the creator & maintainer of AFNetworking and other popular open-source projects, including Postgres.app & Induction. He also writes about obscure & overlooked parts of Cocoa on NSHipster. He will talk about how Ruby hackers built the new Objective-C Open Source community.

• Matt Green is a software developer living in DC and a very early adopter of RubyMotion, as the author of Nitron and webstub. He will discuss how layering can simplify your development process, and show off the new RubyMotion gem he has been working on secretly!

• Marin Usalj is a freelancer iOS developer living in San Francisco. He is one of the maintainers of BubbleWrap, one of the most used RubyMotion library, and he will talk about how using it to quickly building apps with networking, persistence and more.

• Karl Krukow is the CTO of LessPainful, a Danish company that specializes in test automation for mobile. He is one of the core developers of Calabash, an automated test framework for iOS and Android, and he will talk about how it can be integrated with RubyMotion projects.

You can refer to the conference speakers page for the so far full list of speakers. As you can see, the schedule will be excellent!

We will be announcing more speakers soon. If you are interested in sending a talk proposal please do so relatively soon as we will be closing the form by January 20th.

New Sponsors

Since our last update, three more awesome companies decided to help us organizing the conference: Nedap, ProcessOne and Belighted. So exciting!

If your company wants to help us by sponsoring the conference, let us know as soon as possible.

We delivered our very first RubyMotion training in late December of last year in spicy Gurgaon (Delhi), India. What a great way to finish an awesome year.

We trained during 5 days about 15 software engineers from McKinsey & Company IT, ThoughtWorks and Tata Consultancy Services to the RubyMotion platform and iOS development APIs.

Laurent and Norberto are amazing instructors. Their easy manner and depth of knowledge helped them adjust to the specific needs of the people in the room. The exercises were rich and enlightening, and the course was very interesting and informative. Overall, five days of training was definitely a worthwhile investment!

- Abhishek Nalwaya, Tech Lead at McKinsey & Company IT

Check out the pictures!

If you are interested in setting up an in-house RubyMotion training in your company offices, contact us. If you are a small company or an individual developer, you will be glad to know that we will also announce public trainings in different locations around the globe very soon, stay tuned! 

This is a 40-page PDF that teaches you how to integrate both AFNetworking and RestKit with a RubyMotion project and build a client/server REST architecture.

The book is full of code snippets and we recommend that you grab a copy if you need any help connecting a RubyMotion app to a server API.

The author of this book is not just anybody. Clay Allsopp has been a very active member of the RubyMotion community, writing an excellent tutorial and having worked on several wrappers. Clay is also working on Propeller, a RubyMotion-based product that lets you build mobile apps simply with drag-and-drop.

Clay will be speaking at the upcoming RubyMotion #inspect conference in Brussels, 28-29 March 2013, which you should really attend. Hurry up, the early-bird tickets won’t last long!

The book features a foreword by Laurent, the author of RubyMotion.

It is safe to say that, if you have been interested in RubyMotion but never really had the chance to start learning the platform, you should grab a copy of this book right away.

We are thrilled about the release of this book. In addition to the training program and the ongoing conference, the RubyMotion ecosystem is now quickly maturing and we can already be very confident about the future of the platform.

Two days. Single track. 100% RubyMotion. A limited number of early birds tickets are now on sale with a 20% discount!

A 100% RubyMotion event

RubyMotion has been around for about 8 months but the community around it has been growing so fast we believe it now deserves its own event. And this event is called #inspect.

We want #inspect to be the place where RubyMotion enthusiasts can finally meet face-to-face to chat and learn what’s happening in the community. Quality time for attendees to connect and hack together will also be scheduled in the program. 

The program

The conference will be spread over two days and feature a single track that will include several short talks by some awesome speakers. 

We pre-selected 10 speakers for this event. These folks may not be familiar to you, but we assure you they know what they’re talking about.

However, we need more speakers! If you have an idea for a RubyMotion talk please let us know by filling out the form on the conference website.

We will also be giving a RubyMotion training the three days before the start of the conference. It is a shorter version of our training program that has been specifically tailored for the conference. We conveniently offer a single training+conference ticket that will provide admission to both the training and the conference. 

The location

We wanted the inaugural edition of #inspect to be special, which is why we decided to organize it in Belgium, the birthplace of RubyMotion. 

Brussels is the capital of Belgium and the de-facto capital of the European Union. It is located right in the heart of Europe. Brussels has an international airport featuring 
direct-flights from major cities in Europe, the US, and Asia.

The venue we selected is, by itself, a splendid location. We booked a classical house right on Brussels’ main square, known as the Grand-Place. The entire area is a UNESCO World Heritage Site and often described as one of the most beautiful squares in the world.

We will be serving Belgian food and beverages at the conference venue. This will be a bit different than your traditional conference sandwiches, we promise. 

Finally, an awesome after-party is planned on Thursday evening, and for those interested, we will be visiting a  local gueuze brewery on Saturday.

Come with your family! Brussels is a great city and there are many things to be seen. And we should have good weather.

The sponsors

RubyMotion #inspect is presented by HipByte, the company behind RubyMotion, as well as a community of volunteers. As you may already know, organizing a conference can be expensive.

We are looking for a small number of sponsors to share in the support of the event. This is a great opportunity to show your commitment to the RubyMotion community and also promote your products or services. We need your help to make this event as awesome as it should be. Contact us!

We are super excited to unveil JetBrains, Cyrus Innovation and The Pragmatic Studio as our first sponsors! 

RubyMotion API Reference

As RubyMotion compiles down to iOS and uses the exact same APIs as Objective-C, a RubyMotion developer has to discover and learn the official APIs. This is often done by browsing Apple’s official documentation on developer.apple.com. However, users have been complaining that it was not easy enough and that the APIs are still described using the Objective-C syntax.

Well, this used to be a problem, but not anymore. We are now delivering a complete RubyMotion APIs reference in our online developer center.

The documentation has been generated using a modified version of yard, an excellent alternative to RDoc, and should cover the basic iOS frameworks and their APIs. We also cover C-based APIs such as structures, functions, enumerations and constants, as well as Objective-C protocols. Finally, builtin RubyMotion APIs such as the Dispatch module or the Pointer class are also documented.

Command-line Documentation Browser

The 1.28 release extends the motion command line tool with a new ri command, which works similarly to the official Ruby ri command. You can use that command to quickly query the documentation of a given class or method from the comfort of your terminal.

$ motion ri UIButton
-------------------------------------------- Class: UIButton < UIControl

    An instance of the UIButton class  implements a button on the touch
    screen. A button intercepts touch events and sends an action message
    to a target object when tapped. Methods for setting the target and
    action are inherited from UIControl. This class provides methods for
    setting the title, image, and other appearance properties of a
    button. By using these accessors, you can specify a different
    appearance for each button state. 
[...]

Dash.app Docset

For those who prefer an UI to read API references, Dash.app is an awesome documentation browser for your Mac. We personally use it on a daily basis, we highly recommend it and obviously we had to generate a docset for our API reference.

The great deal about Dash is that it lets you query the API reference extremely easily. Queries are so fast you will not believe it. Get the RubyMotion Docset here!

Smart File Dependencies

If you have been programming with RubyMotion long enough you know that it is different than traditional implementations of Ruby in the sense that all the project files must be passed to the compiler at build time and that the order can be important, if for example you define a class in one file and subclass it in another one.

The build system will compile files using the regular filesystem order and exposs the files_dependencies method that you can use to explicitly set a dependency between two files.

Motion::Project::App.setup do |app|
  # ...
  app.files_dependencies 'app/bar.rb' => 'app/foo.rb'
end

Clearly, this has always been a temporary solution. In RubyMotion 1.28, the build system has been improved to automatically detect dependencies between files for you, so that in most cases, you won’t have to use files_dependencies.

What the build system does is that it will scan the source code for specific tokens that could be interpreted as a symbol definition or usage, then accordingly build a map of dependencies. 

This is a fairly experimental feature and we expect bugs around, so we proactively added the detect_dependencies variable that you can set to false in your Rakefile to disable the feature, in case it causes a problem. Let us know if you do so!

The training program has been tailored for Ruby developers with no experience with iOS. The course should teach you everything you need to know about RubyMotion and iOS so that you can start developing full-fledged iPhone and iPad apps in Ruby.

We have not scheduled a public training yet, but if you are interested, please fill out this form and we will get back to you once we have more information. If you have a company or other organization that is interested in a RubyMotion course, we can also provide customized on-site training, just contact us.

RubyMine is a Ruby IDE developed by JetBrains. It offers many interesting features such as context-aware auto-completion, refactoring, code analysis, and many more.

We have been working with the great folks at JetBrains on this and while there are still bugs around, it is already quite usable and very convenient. Just check out the demo video!

RubyMotion is highlighted in the Languages & Frameworks section in the Assess ring, which encompasses technologies worth exploring with the goal of understanding how it will affect your enterprise.

Introducing a Ruby compiler and toolchain for developing iOS applications, RubyMotion has unsurprisingly caused quite a stir in the ThoughtWorks development community. There continues to be a need to understand the underlying iOS APIs and some Objective-C when building applications, but there are clear benefits for those who find working with the Ruby language and tools more comfortable.

Not bad, given that RubyMotion has only been released 6 months ago!

iOS 6 SDK

This release adds support for the iOS 6 SDK.

Unlike some other mobile development platforms, RubyMotion is a pure native toolchain that can automatically support new SDKs, just like Apple’s Objective-C. Therefore, RubyMotion already supported the iOS 6 SDK the same day it was announced at WWDC 2012.

However, the support for iOS 6 wasn’t shipping as part of RubyMotion for legal reasons, as it was still under NDA. Until yesterday!

To program with the iOS 6 SDK you will need to download and install Xcode 4.5 from Apple’s developer center. There you will also find exhaustive documentation about the new frameworks and APIs of iOS 6. UICollectionView, a new UIKit class that can be used to easily create view layouts, is brand new in iOS 6. We could not resist porting one of the WWDC samples to RubyMotion: CircleLayout.

iPhone 5

You probably heard about the new iPhone 5 which was announced last week!

The iPhone 5 features a 4-inch retina display. The RubyMotion build system was improved so that you can specify the retina resolution the simulator should use, by providing different values for the retina option.

$ rake retina=4   # starts the 4-inch simulator (iPhone 5)
$ rake retina=3.5 # starts the 3.5-inch simulator (iPhone 4S and older)

If a true value is provided for the retina option, the build system will default to 4-inch in case the simulator target is 6.0, otherwise 3.5-inch.

On the technical side, the new iPhone 5 has a new processor architecture called armv7s. The RubyMotion compiler now supports this new architecture. Applications built for iOS 6 will contain code for both armv7 (iPhone 4S and older) and armv7s.

Debugger

This has been one of the most requested feature. As of 1.24, RubyMotion comes with debugging facilities based on GDB, the GNU project debugger. The RubyMotion compiler has also been improved to statically emit the appropriate DWARF debugging metadata for the Ruby language. 

The debugger lets you set source-level breakpoints, inspect contextual variables, backtrace frames, threads, and control the execution flow.

Debugging is supported on both the simulator and the device. You can start the debugger by setting the debug option to the appropriate rake tasks.

$ rake simulator debug=1
$ rake device debug=1

In the simulator target the debugger will replace the read-eval-print-loop interactive console. In the device target you will notice that the debugger will start right after the application has been installed and run the application. This is already a significant improvement over previous RubyMotion releases as you will see the application logs in your terminal window. 

$ rake device debug=1
(in /Users/lrz/src/RubyMotionSamples/Hello)
     Build ./build/iPhoneOS-6.0-Development
    Deploy ./build/iPhoneOS-6.0-Development/Hello.ipa
Switching to remote-macosx protocol
[...]
^C
Program received signal SIGSTOP, Stopped (signal).
0x3304eeb4 in mach_msg_trap ()
(gdb) break hello_view.rb:10
Breakpoint 1 at 0x26d84: file hello_view.rb, line 10.
(gdb) c
Continuing.

Breakpoint 1, rb_scope__drawRect:__ (self=0x208495f0, rect=0x20851260)
    at hello_view.rb:10
10            bgcolor = UIColor.blackColor
Current language:  auto; currently minimal
(gdb) pro self
#<HelloView:0x208495f0>
(gdb) pro rect
#<CGRect origin=#<CGPoint x=0.0 y=0.0> size=#<CGSize width=320.0 height=480.0>>
(gdb) n
14          bgcolor.set
(gdb) n
15          UIBezierPath.bezierPathWithRect(frame).fill
(gdb) n
17          font = UIFont.systemFontOfSize(24)
(gdb) n
18          UIColor.whiteColor.set
(gdb) pro font
#<UICFFont:0x2084c040>
(gdb) n
19          text.drawAtPoint(CGPoint.new(10, 20), withFont:font)
(gdb) pro text
"Touched 1 times!"
(gdb) c
Continuing.

To know more about the new debugger check out the new Debugging RubyMotion Applications article in our developer center.

The debugger is at this time quite rudimentary and will be significantly improved in the next updates. We also understand that GDB is not for everyone. We are however very excited about this new debugging facility and we see it as a first step towards a higher-level, friendlier debugger that will eventually be integrated into the existing read-eval-print-loop interactive console. 

Misc

Module#define_method is now implemented as of RubyMotion 1.24. This method lets you dynamically define a new method and is often used in DSLs / meta-programming. Please note that, because of technical limitations of the static compiler, it is not possible yet to use #define_method to overwrite an existing Objective-C-level method.

The libdispatch’s dispatch_once() function is now exposed via the new Dispatch.once method. This method accepts a block that is guaranteed to be yielded exactly once in a thread-safe manner. dispatch_once() is often used in Objective-C programs to create thread-safe singleton objects and the same can be done in RubyMotion apps now.

class MyClass
  def self.instance
    Dispatch.once { @instance ||= new }
    @instance
  end
end

Last but not least, this update brings performance improvements in the String class and fixes several bugs in the other builtin classes. 

HipByte, the company behind RubyMotion, is deliberately 100% bootstrapped without outside funding. Thanks to the support of RubyMotion users and the licenses you have purchased, we are ready to start growing the team!

Today we are glad to announce our first full-time addition to the team: Shizuo Fujita, aka Watson.

Those of you familiar with MacRuby most likely know Watson already. He joined in 2010 the MacRuby project and is now its most active contributor. He is familiar with the entire MacRuby stack (compiler, VM, runtime, library) and has been using RubyMotion since the very first beta builds! He is also involved in RubyMotionJP, an effort to promote RubyMotion in Japan.

Watson lives in Tokyo, Japan and will be helping with the RubyMotion maintenance as well as working on exciting new features.

Follow him on Twitter and GitHub and check out his website (in Japanese)!

Hi Mark! Thanks for taking the time to talk to us. Could you introduce yourself?

I’m a 20 year-old Electronic Engineering student from Madrid (Spain), who also happens to be a programmer. I’m currently on an internship as a software developer at Cabify and bootstrapping LEAPto3D, a company focused on 3D Printing which is going to launch very soon.

What is Cabify exactly?

Cabify offers a customer orientated urban transport service. You can request a high-end car with chauffeur from your mobile phone or website, at very affordable rates. You simply select the pick-up and drop-off points, have a great ride in a quality car, and only pay for the distance and time, seamlessly and securely using your credit card.

You guys are using RubyMotion there in production. Could you tell us a bit more about your experience with RubyMotion as well as how RubyMotion is used at Cabify?

I started learning Ruby on Rails about a year ago, and I enjoyed Ruby so much that I decided to use it for more than web applications. Shortly after that, I started using MacRuby.

I was preparing to give a MacRuby talk at our local Madrid Ruby group last May, when RubyMotion was released. I thought ‘Why not add RubyMotion to the talk?’, so I bought a license, and I’ve been using RubyMotion ever since.

Cabify is predominantly a Ruby and Rails shop, with a bit of Node.js on the side. After battling with iPhone development for the best part of a year they were starting to get really frustrated with the amount of effort required to get high quality apps.

They contacted me shortly after my presentation to see if I would be interested in working with them over the summer to develop their driver application on iPhone using RubyMotion. This is the app that the drivers use to update their position and accept new hires. The idea was to test the waters and see if it worked out.

My boss was blown away by the results :-) After just four weeks I had a working application with concise easy to read and maintain ruby code. They were so impressed in fact that they scrapped the new Objective-C rider app they were working on (the one customers use to request a car) and moved completely to RubyMotion. We hope to launch a new completely redesigned app in the next few weeks, as opposed to months!

Why did you chose RubyMotion over another toolchain?

While apprehensive at first to try something other than the Apple supported XCode, seeing RubyMotion in action and given the passion for Ruby in the development team, it was an easy decision!

How was your workflow with RubyMotion? What code editor did you use? Did you get to use any 3rd-party library or gem?

I use Sublime Text 2 as code editor, with the SublimeRubymotionBuilder and SublimeLinter configured to work with RubyMotion’s syntax.

Adding 3rd party libraries to your app is easier than with XCode, where there is no standard way to do so.

We’re using AFNetworking, QuickDialogs, SVProgressHUD, and of course, Teacup, a RubyMotion gem and DSL for styling views.

What are your favorite features of RubyMotion? How do you see RubyMotion in the future?

Being able to use my favorite programming language to develop applications for iOS!

The REPL really impressed me the first time I used it. I think it can be extended to make it much more powerful. Also, I’m looking forward to on-device REPL and debugger.

As opposed to XCode, RubyMotion’s build tools are open source, so you can modify them to fit your needs and even send pull-requests.

I think people are going to release very innovative apps using RubyMotion. The flexibility of Ruby and the faster development time make RubyMotion a great platform for experimenting with new ways of creating iOS applications. At Cabify there is certainly no going back!

Thank you Mark!

If you are using RubyMotion in production and would like to participate to our success stories series, contact us! We would love to hear about what you are doing.

Check it out here: http://rubymotion-tutorial.com

The tutorial will help you getting started with RubyMotion and introduce you to fundamental iOS programming concepts such as views, controllers, containers, tables, animations, models, and so on!

There is no doubt this is the best tutorial about RubyMotion available out there, so feel free to give it a try and spread the word about it!

For those interested about submitting feedback or contributions, the source code for the whole tutorial is available in the clayallsopp/rubymotion-tutorial GitHub repository.

Hi Francis! Thanks for taking the time to talk to us. Could you introduce yourself?

I’m the co-founder of Ignition Soft. We are a small team focused on crafting mobile apps.

You just shipped EverClip, a pretty cool app for Evernote. The app got nice reviews and it is ranking #1 in various categories in the Japanese App Store. Congratulations! Could you tell us more about the app?

We want to save part of a web site, ebook, or images from various apps and store them permanently. We want to do that without switching back and forth between apps. We want to easily search and share this information.

Our solution is a pasteboard app that handles rich text (HTML) and posts it to Evernote.

EverClip is built entirely in RubyMotion. How much time did it take you to build the app? How did you find the experience using RubyMotion?

The first version with a minimal feature set took a few days. It took 2 months to have a version we felt was ready for production.

RubyMotion is a new product, we treated it with care and selected a smaller, experimental project to write our first app with it. It worked surprisingly well.

At the same time, as we were working on our app, we found bugs in different areas: compiler, build tools, external tools or missing documentation. We could see the toolchain was being constantly improved, the bugs were being fixed, and the documentation was being improved.

I’m quite happy to hack and see a great project evolving. That said, if I’m not familiar with iOS and ruby, or if I am working on a client project that are having hard schedule, I will probably find this ride too exciting and distracting.

You are an experienced iOS developer. How did RubyMotion compare to traditional tools (Xcode / Objective-C)?

At first, I found it not much different from Objective-C. You use the same APIs, but with a different tool and language. I often do the translation between Objective-C and Ruby. It is constantly evolving though, people build different wrappers, libraries and tools that make it feel more idiomatic ruby. I prefer the idiomatic ruby way, Ruby code can be much more concise and easy to read. Just check the BubbleWrap gem to see some samples.

How was your workflow with RubyMotion? What code editor did you use? Did you get to use any 3rd-party library or gem in EverClip?

I use Sublime Text 2 with the RubyMotion plugin which is extremely handy. I use bundler to manage gems, and CocoaPods to manage Objective-C open source libraries. I create view controllers and initialize views using the SimpleView gem, and handle events or notifications with BubbleWrap.

I use many 3rd-party libraries. Without DTWebArchive (handle rich text format in Safari), WebContentView (display HTML content), QuickDialog (quick form drawing) and libtidy (HTML cleanup), EverClip would not exist.

What are your favorite features of RubyMotion? How do you see RubyMotion in the future?

The toolchain. It is open source and easily extensible. I see many creative ways of using it, such as adding colors to the output of unit tests, or include gems/cocoapods in projects. I spend a night to hack a UIViewController generator that works with the ib gem, it is really easy with existing ruby tools and frameworks. The power for people to write or change their tool is really amazing and this is not going to (easily) happen if we are using XCode.

With more people writing production apps using RubyMotion, I can see people extracting the core of their app to create something like Rails for iOS app development. This may not be happening very soon, but the community around RubyMotion is very strong and active.

Will you use RubyMotion for your next app?

I am not throwing away XCode yet, but I’m going to develop more RubyMotion apps in the future.

Thanks Francis!

If you are using RubyMotion in production and would like to participate to our success stories series, contact us! We would love to hear about what you are doing.

This layer is added on top of the existing testing framework and leverages the functionality of Apple’s UIAutomation framework. This video gives a quick overview to get you started:

Compared to the traditional usage of UIAutomation the experience here can be slightly different, as you get to write your tests in Ruby instead of Javascript, have access to the actual objects and you don’t need to use the Instruments application to run the test suite.

describe "The Timer view controller" do
  tests TimerController

  it "has a timer label" do
    view('Tap to start').should.not == nil
  end
end

This feature was engineered by our friends at Fingertips and ships today in RubyMotion 1.15. You can learn more about the new APIs in the Testing RubyMotion Apps article in our developer center. The source code is also available in the HipByte/RubyMotion repository on GitHub.

We were told that this is one of their most popular episodes with over 40 thousand listens in just under a week! Check it out and let us know what you think!

If you like podcasts you can also listen to us on Ruby Rogues and iDeveloper Live. We had a lot of fun there too!

We had a lot of fun presenting RubyMotion last week at Ruby Lugdunum (aka RuLu) in sunny Lyon, France.

It was also our first opportunity to meet RubyMotion users and exchange great ideas! We would like to thank the organizers for setting up such a great event.

Cascadia Ruby (August 3-4)

We will be at Cascadia Ruby in Seattle, WA to talk about RubyMotion. We will also investigate if the coffee there is really as good as people say!

Lone Star Ruby Conf (August 9-11)

A few days after we will head straight to Austin, TX to present at Lone Star Ruby Conf. This will be our first time there too!

GOTO Aarhus (October 1-3)

We are super honored to have been invited to speak at GOTO Aarhus about RubyMotion, as part of the Modern Client App Architecture track.

Interested in attending? You can use the sana1000 promotion code during registration to save DKK 1000 (approximately £115 / €135 / $180).

ArrrCamp (October 4-5)

Ahoy! Come to beautiful Ghent, Belgium for ArrrCamp to learn more about RubyMotion and rum (and probably Belgian beers too!).

As some of you might already know, we are based in Belgium. Try to visit the country if it’s your first time here, Belgium has a lot to offer. Let us know if you need tips!

BubbleConf (October 12)

Last but not least, we will be speaking at BubbleConf in Amsterdam, Netherlands.

This event is special as we will not talk about RubyMotion from a technical point of view but more about the startup side of the project. We will attempt at covering our recent experience in bootstrapping a software company and launching a product, with the hope that other entrepreneurs can learn from our successes and mistakes.

BubbleConf is also the first conference co-organized by our really good friends at Phusion. There is no doubt this will be an epic event and we encourage you to grab a ticket.

We are simply amazed by how quickly a community has formed around RubyMotion since the very first day it was released.

RubyMotion is about to turn one month old and there are already more than 100 projects on GitHub, including sample projects, DSL libraries and support for various text editors. A big Thank You to you guys!

Open Source

After much thought and deliberation, we decided to open parts of RubyMotion. We believe that this will make it even easier for the community to contribute to and extend the RubyMotion platform, leading to a better RubyMotion for everyone.

Today, we are opening the “lib” directory of RubyMotion, which contains the build system, project Rakefile, the configuration object and also the project vendoring system. Check out the HipByte/RubyMotion repository.

We are also releasing the Developer Center documentation under a Creative Commons license. It contains the guides and articles. We will be adding new articles soon. Check out the HipByte/RubyMotionDocumentation repository.

App Store

Since the last post there has been 3 more RubyMotion apps in the App Store!

Birdemia is a simple video game that features attacking birds. Explosions included. Made by Alexey Prohorenko. Source code available on GitHub.

Got my app out of the door with RubyMotion in just 2-3 hours. Went through approval very smoothly, no problems or concerns at all, so thumbs up for #rubymotion.

Greta Sans explores the Greta Sans typeface through an intuitive interface. The app includes HTML5 code. Made by Thijs van der Vossen.

ZAC is a sport app (Dutch only). Made by Dimitri Tischenko and Joachim Nolten.

The experience was great! Even for me, without any previous iOS or mac dev experience. Concept to App Store in ~3 days.

Updates & Support

We are focusing on polishing the existing features as well as fixing the occasional minor bugs reported so far. Our objective right now is to make sure RubyMotion works greatly for every customer. We’ll introduce more features a bit later.

Having attracted so many customers so quickly, we are currently dealing with a few growing pains, particularly when it comes to scaling our in-house support platform. We are evaluating other support solutions at the moment. We apologize if you haven’t heard back from us in a while and invite you to send us an email directly at support@rubymotion.com.

Early Bird Discount

If you or someone you know wants to purchase RubyMotion and take advantage of the Early Bird Discount (25% off) you need to hurry up and buy it. The Early Bird Discount ends Monday, June 4th.

Mustachio, a RubyMotion app, is now available in the App Store. The app is free and the source code is available on the HipByte/Mustachio repository on GitHub.

Mustachio is an improved version of the Mustache sample code. Improvements have been contributed by professional gesticulator Eloy Duran of Fingertips (these guys are amazing!).

As you can see this is a pretty basic app. Its sole purpose was to demonstrate that RubyMotion apps can be successfully delivered to the App Store. Okay, we also had a bit of fun writing and using it!

Software Update

RubyMotion 1.4 is available. Besides bug fixes, this update improves the build system to handle the compilation of Interface Builder Storyboard files and Core Data model files.

Due to the demand, it also adds support for the iOS 4.3 SDK and introduces a way to start the simulator in Retina mode.

We received a significant number of bug reports through support tickets. We will keep addressing them in further software updates.

Weekly Newsletter

RubyMotion Weekly is a free weekly email digest of RubyMotion news, tutorials and articles curated by Rob Zolkos.

Check it out if you want to keep up with everything RubyMotion-related!