(For more resources related to this topic, see here.)

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 .hfile, 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 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 diff erence 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)

Let’s start with our Hello World app now. Have the controller in place so we can break away from the lifeless shell application and move more toward a true “Hello World” app. We won’t need to deal with the AppDelegateany longer.

Now we can start placing code in our controller. Remember when I said that this is a framework that calls into our code at given points, here’s where we choose one of those points in time to hook into, and we’ll choose one of the most common UIViewControllermethods, viewDidLoad. So, create a method called viewDidLoad, and let’s put the following code inside:

To find out what delegates are supported by any method and the order of method calls, you can look up the class reference of the object you are extending. For example, the documentation on the UIViewControllerclass’ viewDidLoadcall is identified at http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html.

Running your application at this point (by typing rakein the console) will cause your application to output “Hello World” to the application’s standard output (the command line in this case). There’s nothing too special happening here, we’re using the traditional Ruby putsmethod to give us some feedback on the console.

Running this does start the simulator. To quit the simulator, you can use command+ Q or from the console window, press Ctrl+ Dor Ctrl+ C.

Since our phone doesn’t really have a console to receive the standard output message, let’s take this up a notch by adding a label to the application and configuring it to be a more traditional Hello World” on the device. So, we plan on making a label that will have the text “Hello World”, correct? Let’s create the test for that.

We’ll start by making a new file in our specfolder called hello_world_controller_spec.rband we’ll make it look like the following:

Let’s inspect the testing code from the previous image. Everything looks similar to the other code but, as you can see, there’s no need to make a beforeblock, since we are able to access the controller by simply stating the controller we’re testing on the second line. This shortcut works for any ViewController you’re testing!

The actual testing and use for the variable starts with our specification. We grab the label so we can apply our two requirements on the following lines. We check the text value, and verify that the label has been added to the view. This might seem quite nebulous without knowing what we’re testing, but the logic is simple. We want to make sure there’s a label that says “Hello World” and we want it to be visible. Running these tests will fail, which puts us on track to write the actual “Hello World” portion.

You should add the following code to your project’s hello_world_controller.rbfile:

Summary

There it is! We’ve finally written a real Hello World application! Congratulations on your first RubyMotion application! You deserve it!

Resources for Article :

Further resources on this subject:

• Integrating Solr: Ruby on Rails Integration [Article]
• Building tiny Web-applications in Ruby using Sinatra [Article]
• Getting started with using Chef [Article]