Here at Red Gate we've been running a "New Business" division for a while. The goal of New Business is to try things that Red Gate wouldn't normally try. With each idea we hope to succeed, of course, but if we fail we want to fail quickly. After the release of SQL Monitor 2 I moved to New Business, and that's how I found myself learning to Xcode.

Over the last four weeks, Tom and I have developed Out of Office, a simple app for setting your Outlook out of office message from your iPhone. As a C# developer, it has been a lot of fun, a great learning experience, and I've changed my opinion of Objective-C along the way. I'd like to share the experience, and maybe get you to try Xcode yourself.

Xcode IDE

The first thing that hits you when you start writing for iOS is, of course, Xcode. I do feel more productive in a good IDE than in a text editor, but learning a new one is painful.

So is Xcode 4, in my experience, a "good" IDE? In fact, I was pleasantly surprised by it. Sure, everything is in the wrong place, but it wasn't too hard to find. Kind of like switching to the Mac: the problem is unlearning what you are used to, not the Mac itself. In the end, the user experience seems quite well thought out.

For example, I like the "assistant editor" that stacks to the right of the file that you're currently working on. You can get it to automatically display the "counterpart" file (.h file for a .m file, and vice versa), the superclass, a sibling, a subclass, etc. It's a good use of the space on a widescreen monitor.

Perhaps more controversially, Apple have done away with the concept of "open" files. Unlike Visual Studio and most of the text editors that I've used, single clicking a file in the project browser immediately shows that file in the editor. Select another file and it replaces the first, automatically saved and accessible via the back button. In practice I found that it works quite well.

So what don't I like about it? There isn't anything that I found particularly shocking - apart from the lack of "replace in selection", which led to this slightly exasperated tweet. Compared to Visual Studio 2010, Xcode has SVN/Git integration out of the box, and the "intellisense" is pretty good too.

But comparing it to vanilla Visual Studio seems a bit unfair, because one of the great things about Visual Studio is the number of plugins that are available. Resharper by JetBrains makes me feel much more productive than I do with either IDE out of the box. Yes, it costs money, but we're professional software developers. Similarly I much prefer VisualSVN to the SVN integration in Xcode, and Beyond Compare to its diff viewer. There just aren't many plugins for Xcode.

Maybe that will change in the future. For the moment, I'll be watching JetBrains' Objective-C IDE with interest.

Objective-C

Ah, Objective-C. It's the language that everyone loves to hate. Without Apple, no one would still be using it. But as they're currently selling 100M iPhones per year, it's hard to ignore.

I certainly took a big hit in productivity when I switched from C# to Objective-C, but a month on, is that still the case?

Sure, it has most of the disadvantages of C, like a weak type system, header files, forward declarations, manual memory management, obscure linker errors, and a lack of namespaces and method overloads. It feels dated. But in reality, it's better than I expected.

Memory management

Manual memory management in Objective-C is not as onerous as the bad old days of Win32. To be fair, this is mainly a problem with Win32, not C. For example, RegQueryValueEx has the delightful error code ERROR_MORE_DATA, which means "I'm going to throw away the 64KB of work I did for you because 64KB wasn't enough. I'm not going to tell you how much you actually need though. Better luck next time."

In Objective-C, however, objects are reference counted. There is a strictly-observed naming convention that lets you know whether you're responsible for releasing them. This allows functions like RegQueryValueEx to allocate memory themselves but pass the cleanup responsibility to you.

Once I understood these rules, memory management was actually quite simple. And until I understood them, Xcode has fantastic tools for detecting leaks both statically (with the clang static analyzer) and dynamically (with the Leaks instrument). It's still a waste of developer time, and a security risk, but it could be worse.

Type system

At runtime Objective-C is dynamic and duck typed. C# might make a distinction between the Add() methods on DateTime and ICollection, but in Objective-C there is no difference.

The static vs. dynamic debate tends to be a religious issue among developers, and you probably already know which side of the line you fall on. Personally, I am a proponent of static type systems: when I refactor C#, the type system is great at pointing out my (many!) mistakes. I was not looking forward to duck typing.

However, it turns out that Objective-C has static type checking too. Compiler errors in C# ("class does not contain a definition for Add") are just warnings in Objective-C ("class may not respond to -add:"), but I didn't find that this caused any bugs.

The main thing that I miss from C# is generics - all that type safety vanishes once you put anything into a collection. Maybe C# has made me too reliant on the compiler, but this was the cause of bugs for me, even in our four-week project.

My hope is that generics can be added in the future. It's certainly possible to add generics to a language without changing the runtime: Java did it with type erasure, and C++ did it with class templates. It has been proposed for Objective-C before, though it's hard to see what syntax could be used.

Lambdas a.k.a. "blocks"

A nice surprise for me, and a huge improvement over plain C, was that Objective-C supports lambda functions. In Objective-C they're called "blocks", but they're real closures: like C#'s lamdba functions, they can capture the values of local variables that are currently in scope. The compiler generates all the memory management code for you, too, so they save even more boilerplate than lamdbas in C#.

They're quite new in Objective-C, so the library hasn't caught up yet. But thanks to Objective-C's "categories", which allow you to dynamically augment a library class, you can add block APIs yourself. Here's an example category that adds block support to NSTimer:

@implementation NSTimer (NSTimerExtensions)

+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds
                    handler:(void(^)(NSTimer *timer))handler
                    repeats:(BOOL)repeats {
    void(^copiedHandler)(NSTimer *timer) = [handler copy];
    NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:seconds
                              target:self
                            selector:@selector(runHandlerBlock:)
                            userInfo:copiedHandler
                             repeats:repeats];
    [copiedHandler release];
    return timer;
}

+ (void)runHandlerBlock:(NSTimer *)timer {
    void(^handler)(NSTimer *timer) = (void(^)(NSTimer *timer))timer.userInfo;
    handler(timer);
}

@end

Cocoa Library

The Cocoa library is my major complaint with the iOS platform. Things that I've come to depend on in .NET are just not available in Cocoa.

For example, for the Out of Office app I had to communicate with Exchange Web Services in SOAP. In .NET this is trivial: just import the service description .wsdl in Visual Studio, and it generates type-safe marshalling code for you. The code is ugly and I'd want to hide it behind my own classes, but it does the boring bit.

In Cocoa there is no SOAP support, so I had to handle the XML manually. But what XML did I have to write? In fact the easiest way to discover this was to code up the service calls in C# (this took 20 minutes), fire up the excellent Fiddler, and record the HTTP conversation!

Then I came to write the XML in Objective-C, and realized that the XML support is poor, too. There's a reader, but no writer. So I had to download a third party library, Google's Objective-C data client.

When it comes to the library, .NET spoils us.

Final Thoughts

I like Jonathan Rentzsch's summary of his Skeptic's Introduction to Objective-C (PDF): "Now I'm coding in Objective-C, but only where it makes sense." Like him, I "actively resisted" learning Objective-C, but the truth is that it's not that bad. There are even things that I like about it - for example, the "keyed arguments" that interleave the method name with the parameter list allow for descriptive method names.

I wouldn't choose Objective-C to write a large application like SQL Monitor, but on the iPhone, the code forms a surprisingly small part of the product. Mobile apps tend to have pared-down, simple UIs (a good thing!) and do one or two tasks well. With our app, the user experience design, the artwork and the product website took us as long as the actual code.

So if you've been thinking about writing an iPhone application, but you've been put off by learning Objective-C, just do it!