Kevin Sylvestre

Lessons Apple Should Learn from Ruby and Rails

I’ve been a practicing iPhone and Mac developer for a few years now and I love many aspects of Apple’s platforms. The interface design software is incredible, programs run fast even on mobile devices, and the the code debugging tools are great.

However, with experience comes bitterness. Perhaps my undoing is that I have also been writing Ruby (on Rails) code for about the same amount of time. Rails has introduced me to a variety of conventions that I think should be in the Cocoa frameworks. So, I’ve decided to compare and contrast Cocoa and Rails and list my two biggest issues.

The first issue with Mac development is the language. Objective-C might have been the hottest thing in town in the 1980’s but it has ‘cooled off’ over the last 20 years. One of my biggest frustrations is with the amount of code required to get started. For example, compare these two class declarations:

Ruby:

Objective-C:

I feel like the above code should explain where my frustration stems from. Having lots of code is a liability. It is difficult to read, difficult to troubleshoot, and easy to do wrong. It seems impossible to practice Objective-C programming and follow the DRY (don’t repeat yourself) paradigm.

The second major problem with Apple development is that the framework designers went in with bad goals. I first learned Cocoa by watching presentations from Apple Engineers and can remember hearing “Cocoa makes the easy things easy and the hard things possible” as a mantra. As Robert Martin stated in his 2009 Rails Conference presentation in “What Killed Smalltalk Could Kill Ruby Too” this is incorrect. The real motto should be something along the lines of “make the easy things trivial and the hard things easy”.

A great example of making hard things easy can be found in how Rails handles persistent storage. Active Record was integrated into Rails to make saving, storing and updating database records a breeze. Core Data was designed by Apple to torture developers. For example, see some of the steps required to make the previous example persistent:

Rails:

Cocoa:

This isn’t a language limitation, this is a framework problem. Core Data could have been designed to give developers the same one line access to data that Rails has, but good defaults were never selected. As such flexibility was created at the cost of many developers sanity. Apple should have set out with a set of goals for doing basic CRUD operations without ever having to look through copious amounts of documentation.

Although you probably think that I hate Apple, let me assure you that the opposite is true. I understand that the hardware and software shipped by the company over the past five years will be marked as some of the best ever created by consumers. I only hope that someone in Cupertino is still thinking about the developers.

NSError Is NSAwful

Is it just me, or is NSError one of the worst features of the cocoa framework? Who thought these are these better than exceptions? Don’t developers see that these are just fancy return codes? Here are some major problems:

1. Most developers don’t handle errors. Exceptions add due pressure to not let things slip. With ‘NSError’ it is so easy to pass NULL or never check the return.
2. Mobile devices don’t have any easy way to display errors. Sure desktop applications have ‘NSApp’ that can present them, but what about mobile users?
3. Most documents don’t detail what errors can occur. For example, the documentation for ‘NSFetchedResultsController’ states ‘contains an error object that describes the problem’. Great.

Non-Blocking Long Running Tasks on iPhone

iPhone and iPad applications containing long running tasks - such as HTTP requests or data processing - that block the main thread are annoying and often appear sluggish.

The following snippet fixes this issue:

Cocoa Copy Paste Menu

I spent some time earlier today playing with the UIMenuController offered in the iPhone SDK and realized two thing: sometimes Apple’s examples suck and having an environment that often gives no feedback is terrible.

In this case, I implemented a copy of an example that was supposed to present a semi-modal cut / copy / paste menu. It didn’t. After spending nearly an hour trying to realize why nothing was happening, I found I had missed copying a line. Anyways, for the record, here is the concise example of how to present a UIMenuController:

Cocoa Extensions

Cocoa extensions provide a great way to modify existing classes with additional functionality. Here is a good example of extensions in action:

Accessing extensions is simple: just import the header file. In the case above, easily readable dates are now at the finger tips!

A Few Reasons Cocoa Isn’t That Hot

Over the past half-year I have been developing software for the iPhone (and recently iPad). Although I feel that Cocoa is excellent overall, a few rough edges prevent it from being a truly great experience:

The Language

Objective-C is the language of choice for most Cocoa developers (Cocoa can be accessed through bridges by Ruby, Python and a handful of other tools). It provides a thin layer on-top of the C program language, adding support for dynamic typing and messaging.

Objective-C’s very fast execution speeds do not compensate for the amount of code required to perform trivial tasks (especially compared with Ruby or Python). Issues such as memory management and duplicate feature sets (NSString and string, NSArray and [], etc.) can leave developers wanting something better.

The Controls

Interface builder is one of the best GUI designers available. That said, the iPhone and iPad controls are not nearly as verbose as the Mac desktop application controls. The lack of support for grids, checkboxes, colour pickers, and even good looking buttons does not make any sense. It is obvious that Apple had to exclude tools that will not work on the mobile platform, but their over-zelous axing of features ultimately ended up increasing the workload for developers.

Although Cocoa offers great customization of controls, developers must revert to code to get certain core features working. A great example is creating form elements within a table (something done in thousands of applications, including the ‘Settings’ app). Developers will need to setup delegates, protocols, and data-structures for something that should be drag-and-drop. For static forms, this is wasteful and time consuming.

The Ecosystem

Having recently spent some time developing in Ruby on Rails, I feel confident stating that the Cocoa ecosystem is terrible. Although a few great libraries and extensions exist (Three20, BWToolkit and Pinch Media), the non-existence of a package manager (such as RubyGems) means that third-party software is few and far between.

Installation of almost anything introduces dependency headaches and is completely non-strandard. A look through the 10-20 step guides required for any framework will make some cringe and others cry.

Conclusion

Given Apple’s reputation, it is a wonder better options are not available for Mac and iPhone development. The benefits of releasing a 25 year old language on brand new mobile devices or not upgrading existing SDK’s with new languages (Microsoft has gone through at least four) are very limited. Further support for projects like MacRuby are required, and hopefully existing open community frameworks can be better integrated with Cocoa in the future.