Kevin Sylvestre

I’ve been a practicing iOS and Mac developer for a few years and I love many aspects of Apple’s platforms. Apple’s interface design software is incredible, programs run fast even on mobile devices, and the debugging tools are fantastic. However, with experience comes bitterness. My “grass is always greener” beliefs comes from having also been writing Ruby (on Rails) code as well. 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 a few snippets of 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:

class Person
  attr_accessor :name
end

Objective-C:

#import "Foundation/Foundation.h"

@interface Person : NSObject 
{
    NSString *name;
}

@property (nonatomic, retain) NSString *name;

@end


#import "Person.h"

@implementation Person

@synthesize name;

- (void)dealloc
{
    [name release];
    name = nil;
    [super dealloc];
}

@end

The above code explains where my frustration stems from. Having lots of code is a pain. It is difficult to read, difficult to troubleshoot, and easy to do wrong. I often struggle with programming in Objective-C and follow DRY (don’t repeat yourself) paradigm.

The second problem with developing in Cocoa is that the framework designers went in with some questionable 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 insane. 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:

Person.all.each do |person|
  puts "Hi #{person.name}"
end

Cocoa:

NSManagedObjectModel *managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:[NSURL fileURLWithPath:@"model.mod"]];
NSPersistentStoreCoordinator *persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
NSManagedObjectContext *managedObjectContext = [[NSManagedObjectContext alloc] init];

[persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:[NSURL fileURLWithPath:@"data.sqlite"] options:nil error:NULL];
[managedObjectContext setPersistentStoreCoordinator:persistentStoreCoordinator];

NSFetchRequest *request;
NSEntityDescription *entity;

request = [[NSFetchRequest alloc] init];
entity = [NSEntityDescription entityForName:@"Person" inManagedObjectContext:context];

[request setEntity:entity];

NSArray *people = [context executeFetchRequest:request error:NULL];

for (Person person in people)
{
  NSLog(@"Hi %@", person);
}

[request release];
[managedObjectContext release];
[persistentStoreCoordinator release];
[managedObjectContext release];

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

I don’t 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. I just hope that someone in Cupertino is thinking about the developers as the frameworks and languages continue to progress.