Archgrove

Over at his blog, Shawn Burke is running a series on “iPhone SDK vs Windows Phone 7 Series SDK Challenge”. He takes examples from Apple’s iPhone SDK, and shows how to create them using the Windows Phone 7 SDK, taking care to crow about supposed advantages of the Microsoft approach. In this post, I figured I’d examine his first “Hello World” example, and see how accurate the result is.

Note beforehand that I’m not disputing the power of WPF and C#. Given the choice of C# of Objective C, I’d probably rather work with C#. However, these types of language/API comparisons are rarely useful, nearly always mistaken, and correcting the record seemed an interesting task.

The first problem is that the title is inaccurate – it’s “iPhone SDK Hello World Tutorial vs ad-hoc implementation in WP7 SDK”. To show this, he goes through the tutorial and shows the same result prepared in WP7, with the banner claim being “4 lines of Code for Windows Phone 7, 44 for iPhone”. This is, at best, disingenuous. In the following video, I make the iPhone “Hello World” application using exactly the same number of typed lines of code as Shawn’s blog post. It’s not monumentally fascinating, but might show some Interface Builder features that are not widely known.

He makes two other points I’ll call out before exploring why he might make these mistakes.

“I was surprised that the User Interface Designer in XCode doesn’t automatically create instance variables for me and wire them up to the corresponding elements”

As shown, you can have Interface Builder create instance variables you need them. Regarding the automatic generation of instance variables, this is, I suppose, a matter of opinion – but years of Windows Forms programming has taught me that automated generation of instance variables for all UI elements is a nightmare. Your namespace is cluttered with dozens of instances you never need to reference and just add noise to your code.

“10% of the code, 1 file instead of 4, it’s just much simpler”

As shown, the amount of code you have to write it identical. 1 file instead of 4 is just wrong – if you download his sample program, there are 2 XAML files and 2 C# files. Counting the NIB file and main.m files as part of the iPhone solution, there are 6. So it’s 4 vs 6 in terms of files in the project, but identical in terms of the number of files you need to edit (1 XAML and C# vs 1 NIB and M file).

Why make the errors?

Shawn based his comparison on the Apple Tutorial. Why doesn’t the iPhone “Hello World” tutorial do it my way? Because Apple tutorials teach you the “Apple way” of development; “Best practice iPhone development”, if you will. Cocoa is, for better or worse, as much a philosophy as an API. If you don’t buy into the MVC approach, if you don’t structure your code in a Cocoa friendly way, you’ll be able to develop – but you’ll find it painful. As in it’s products, Apple tries to guide developers into the “right” mindset. Therefore, a fairer comparison would have been “iPhone Hello World vs Best practice WP7 Hello World”.

This is not to say there aren’t real missing features from the iPhone development environment compared to the new Windows 7 setup. Largely, this is down to Apple being conservative with the runtime features they provide for the iPhone OS. Partially, they’re feeling their way as they go. More importantly, they’ve been working on relatively limited hardware. The latest iPhone OS still supports the original iPhone, which had only a 412Mhz ARM CPU with 128Mb of RAM. Windows 7 will mandate a minimum of an ARMv7 Cortex/Scorpion with 256Mb RAM, giving the OS and application runtime a minimum of twice the memory and compute resource to play with.

If we compare against Cocoa/Objective C for OS 10.6, we see a lot of features that are waiting to be ported to the iPhone: Blocks (i.e. lambda functions for C), garbage collection, and API improvements. Given the ever progressing iPhone hardware (and new iPad), I’m expecting these shiny developer tools for iPhone 4.0 – personally, I’m voting for blocks, though a lot of people would prefer garbage collection). I’m also expecting Apple to keep forward porting Application Kit features that are currently missing – Cocoa bindings being the big one. With these, Interface Builder for OS X can build the “Hello World” desktop app without ever writing a single line of code (in fact, by typing only “Hello World” and “Hello” at the keyboard).

As a cross platform developer, I’ll continue reading the series with interest. I do hope, however, for rather fairer comparisons in the future.

EDIT: Woops, first version claimed there are, in fact, no missing features in iPhone development. Now clear that I’m not under RDF influence.