Clay Allsopp - RubyMotion

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

A long time ago, Ruby replaced Perl as my favorite high-level language. I have always been a low-level programmer, writing C code on a daily basis, but I was convinced from the beginning that high-level languages such as Ruby were better suited for application development.

For a long time, application development meant desktop applications. I spent a good amount of time trying to make Ruby a first-class citizen for desktop development, working on the Ruby-GNOME, RubyCocoa, and MacRuby projects. While I cant say I achieved the success I expected, at least I tried, and it made Ruby programmers happy.

In March 2008, Apple released the first version of the iOS SDK, allowing developers to finally write custom iPhone applications in Objective-C. That day, as an Apple employee, I dreamt of the day when developers would be able to use Ruby to write iOS apps.

You are holding this book, so you know the story. I left Apple and created RubyMotion. But why on Earth would you want to use Ruby for app development?

There are many practical reasons that make Ruby a much better alternative to lower-level languages for app development, but for me, the main advantage of Ruby is that it triggers creativity.

Ruby as a language allows the creation of layered abstractions, often called domain-specific languages , within the language itself. This feature is definitely not unique to Ruby (I say this as a huge fan of Lisp), but Ruby programmers really seem to like creating abstractions for some reason.

Ruby has dozens of test libraries. Rails comes with several small languages defined within the framework. And just a week after RubyMotion was available, there were already several abstraction libraries for it.

Ruby programmers often call themselves code artists because they can feel the process of creativity when they program in Ruby. If you have programmed in Ruby, you know what I mean, because you have felt it too.

This is why Ruby matters. And this is why writing iOS apps in Ruby matters.

The iPhone and iOS exceeded everyones initial expectations. Over the past five years, independent developers and companies have published more than half a million products to the App Store that have been downloaded more than two billion times. But despite the huge influx of new developers and programming resources, the process of building iOS apps has remained fundamentally unchanged.

The iOS SDK was first announced in early 2008, nearly a year after the first iPhone debuted. Mac developers felt right at home since it used the same Objective-C/Xcode workflow that had existed on OS X for years. For everyone else, that day was probably the first time they heard the term Objective-C .

Objective-C is a robust language, but its verbosity and compiled nature are a bit out of step with the dynamic languages embraced by many of todays developers. Since Objective-Cs inception in the 1980s, programmers have shifted toward Perl, PHP, Python, Ruby, and JavaScript. These scripting languages allowed some of the biggest websites in the world to grow and iterate with unparalleled speed by empowering flexibility and reducing complexity.

So, why havent we seen these languages prosper on mobile yet? I mean, that is why youre here, right? The answer is that there have been no alternatives to Objective-C that allow for that signature iOS user experience while still providing comparable performance...well, no alternatives until now.

RubyMotion (http://rubymotion.com) is such an alternative. Put simply, it allows you to develop iOS apps in Ruby without degrading the user experience. To accomplish this, RubyMotion compiles your Ruby files to machine code; in contrast to traditional nonmobile Ruby, theres no interpreter or garbage collector to hinder performance. Your Ruby code uses the iOS SDK frameworks and classes exactly as intended by Apple, so all existing Objective-C code examples and tutorials are perfectly translatable.

Why Ruby instead of Python or some other language? For one, Ruby is already incredibly popular among web developers because of frameworks like Ruby on Rails; for new developers, coding in a familiar language means an easier transition from the Web to mobile. But most importantly, Ruby is a friendlier and more forgiving language for developers at any experience level. Whether youre a Rails veteran or just getting your feet wet with Ruby, this book will give you the foundations to create gorgeous iOS apps with no compromise in performance or developer happiness.

There are other alternatives to iOS development with Objective-C. HTML-based solutions like PhoneGap (http://phonegap.com) and Trigger (https://trigger.io/) are often attractive because they allow apps to be changed without additional Apple approval. However, this flexibility comes at a cost: the non-native interface elements embedded in the markup often create a jarring experience for users. Notably, Facebook is moving away from HTML5 in its iOS app and migrating to a native version.