Let's take a moment to explore what RubyMotion is. We can explore RubyMotion by understanding where it came from, with origins reaching deep into the beginnings of two amazing programming languages: Ruby and Objective-C. We can explore these languages, and how their roads converged to create RubyMotion.

If you're reading this, you're either searching for an understanding of how RubyMotion can give you the keys to make iPhone, iPad, and OS X applications, or you're simply looking for further depth in your understanding of Ruby and Objective-C development. Either way, you're in the right place. To start this journey, we need to understand the basics of these two respected, but philosophically dissimilar, technologies and how a path has been beaten between them.

Starting at the base, Apple development for iOS has traditionally been handled in Objective-C. Though Apple products have grown in popularity, Objective-C has not always been the first choice for application development. There's a long and torturous road of developers who have given up their app ambitions because of Objective-C. It is clear that for the greater part of over two decades, Objective-C has generally been the only programming language choice available for apps with Apple.

Objective-C was made popular by Steve Jobs' company NeXT, for licensing Objective-C from StepStone in 1988. You'll often see evidence of this in the naming conventions of fundamental objects prefixed with NS for NeXTStep/Sun. This history renders the language a business decision as much as it was ever a developer-based decision. At the time Objective-C was licensed, the Ruby programming language was just an unnamed idea in Matz's head (Yukihiro "Matz" Matsumoto, inventor of Ruby). Objective-C has evolved, grown, and survived the test of time, but it ultimately remains verbose, without standardization, and programmatically rigid. In today's world, developers can afford to be opinionated with their programming language preferences, and a lot of them choose Ruby.

Ruby is a standardized, dynamic, and general object-oriented programming language that takes inspiration from a long list of successful languages. Ruby is known to support a myriad of programming paradigms and is especially known for yielding elegant code. It's also often the cool programming language. Compared to the verbose and explicit nature of Objective-C, Ruby is a far cry and extremely opinionated language that programmers often adore.

Let's take a moment to identify some core differences in the syntax of these two programming languages, starting with Objective-C.

Objective-C is strongly typed. Counter to what some believe, strongly typed doesn't mean you hit the keys really hard, it means your variables have restrictions in their data types and how those variables can intermix. In Objective-C this is strictly checked and handled at compile time by a .h file, the end result being that you're usually managing at least two files to make changes in one.

Though you'll often find Objective-C methods to be long and capitalized in CamelCase, Ruby clashes with a Python-styled lowercase brevity.

For example:

It's by no accident that I've shortened the method name in the preceding example. It's actually quite common for Objective-C to have long-winded method names, while, conversely Ruby methods are to be as short as possible, while maintaining the general intention of the method. Additionally, Ruby is more likely to sample functional and meta-programming aspects to make applications simple. So, if you're wondering which of these paradigms you will need to use and be accustomed to, the answer is both!

I've seen a lot of RubyMotion code, and some people simply abandon their Ruby ways to try and make their code fit in with Objective-C libraries, all with great haste. But by far, the best method I've seen, and I highly recommend, is a mix. All Objective-C and Cocoa foundation framework objects should remain CamelCase, while all Ruby remains snake_case. At first glance this seems like twice the work, but it's really next to no effort at all, as your custom objects will be all written in Ruby by you. The advantage here is that upon examination, you can tell if a function, object, or variable should be looked up online on the Apple developer site (http://developer.apple.com/library/ios/navigation/) or if it should be searched for in a local code or Ruby code (http://www.ruby-doc.org/). I kind of wish I had this benefit with other Ruby languages, since I can instantly return to an older project and distinguish which code is purely mine and which is framework.

Another key difference is the translation of code from messages to parameterized styling. I'm going to use some of the examples from RubyMotion.com to elaborate this issue. To properly convert the Objective-C:

[string drawAtPoint:point withFont:font];

You will have to simply slide everything down to the left. The parameter to string is a method on it, and the rest become parameters. This yields the following code:

string.drawAtPoint(point, withFont:font)

Simple enough! The first example is Objective-C and the second is Ruby (with named parameter emulation via hash).

If you're looking for more examples of this simple translation, I recommend a blog post I wrote at http://iconoclastlabs.com/cms/blog/posts/starting-with-rubymotion-delegates-and-messages.

Translating Objective-C to Ruby is relatively easy, but may take a little practice. Fortunately, I will not give you any Objective-C that is not translated in this book, but the ability is priceless when you find code that is not Ruby that you would like to learn from or adapt.

Unlike most cross-over languages, the code you write in RubyMotion is not scripted to be fully interpreted at runtime. Much like MacRuby, your code is compiled and sits directly on top of native Objective-C objects. RubyMotion actually static compiles your code based on a Low-Level Virtual Machine (LLVM), so your original source code is never available in the application bundle. This adds a level of speed and security to your finished product!

Compiled products are usually problematic for debugging; though the RubyMotion crash reports are well annotated, the benefit of RubyMotion comes in with a fully-functional debugger. We'll cover more about this in the Top 3 features you need to know about section.

The RubyMotion official web page boasts that most applications weigh less than 1 MB, and this is without downloading or interpreting any external code. The product can be sent directly to Apple as nearly indistinguishable from a native Objective-C application. Basically there's no cost to use RubyMotion.

There is one aspect of the Ruby community that generally benefits all Ruby flavors, and even such wonders as RubyMotion. Ruby is tightly coupled with code packages called Gems (RubyGems is part of the standard library of Ruby Version 1.9). RubyGems manages Ruby code libraries through a standard format for distributing and implementing code.

The allure of RubyGems is that you can easily package and leverage code written by open source communities, directly in your current project. Many Ruby developers often give back to the community by breaking reusable portions of their code into a Gem, both to simplify the management of their code and simultaneously making a name for themselves in the open source community. We'll cover some popular RubyMotion Gems later, and directly show you how it can take common and cumbersome iOS functionality and translate it into maintainable Ruby.

Gems can be installed locally via the gem command, or included in the bundling process using the common Ruby bundler. So, Gems can be maintained and updated easily.

Not all RubyGems are compatible with RubyMotion. As unfortunate as that sounds, it's simply because RubyMotion is a dialect of Ruby that must be statically compiled (remember?), and therefore, some gems behave unpredictably if they utilize Ruby methods that are deliberately omitted (such as eval and require). This isn't usually a big issue, considering you're likely to be using Gems written specifically for RubyMotion that would be pointless in most other Ruby projects (unless it is MacRuby), or you have utilized some of the new functionality provided by motion-require or motion-bundler to help transition these Gems.

RubyGems have been one of the driving factors for Ruby on Rails developers for years now and has flowed eloquently over to RubyMotion. In the Top 3 features you need to know about section of this book, I'll be covering some very common Gems and their usage.