Follow Up: Andrew Whitechapel on Developing for Windows Phone and iOS

In the October issue of MSDN Magazine Andrew Whitechapel undertook a really interesting experiment. In his feature “Building an App for Both Windows Phone and iOS,” he set out to develop the same application for both Windows Phone and iOS using native tools. The idea was to learn how the two platforms compare from a developer experience standpoint and to help inform decisions on building apps that support both platforms.

I had a chance to pose a few questions to Andrew. Here is what he had to say.

Michael Desmond: What motivated you to do a side-by-side comparison of the dev experience between iOS and Windows Phone?

Andrew Whitechapel: Two reasons. One, I wanted to see for myself how hard it would be, what would be involved, and I was curious about the differences and similarities.

Two, at a higher level, it’s apparent that there’s a divided market. That is, some developers target iOS and others target Windows Phone, but a relatively tiny proportion target both. I wanted to explore this, and try to figure out whether there were good technical reasons for this, or was this just another facet of ‘technology religion.’

Desmond: So, what did you find out? And what advice do you have for developers who might want to move their apps from WP to iOS, or vice versa?

Whitechapel: I’m sure that some managed developers are put off at the thought of learning Objective-C and are unaware that it has evolved to have many similarities with C++/C#. But the learning curve is not too bad at all now. The logistics of setting yourself up as a registered developer are roughly comparable across the two platforms, so there’s no real obstacle there. The technical capabilities of the two platforms are different but comparable, so I don’t foresee any major problems for any competent developer there.

I firmly believe that Windows Phone developers can transition relatively easily to encompass iOS also. On the other hand, the reverse is not so simple. Having talked with many iOS developers, it’s clear that they’re often reluctant to broaden their coverage to Windows Phone because they feel the Windows Phone market is too small to be worth the effort. It’s true that there are more iOS apps in the marketplace than there are Windows Phone apps, but there are still more than 100,000 Windows Phone apps, which is a perfectly respectable number. Furthermore, a less-saturated market actually represents an opportunity. On the transition from Objective-C to C# (and Xcode to Visual Studio), I frankly can’t account for the reluctance. The transition is easier than the reverse direction (from C# to Objective-C), the API feature sets are comparable, the SDK tools are comparable and app certification is comparable. This one is a mystery to me.

Desmond: You came away noting that developing for the two platforms is more alike than different, with shared characteristics in the form of MVVM, XAML/XIB, and the like. Still, wouldn't a tool like MonoTouch bring a lot of benefits to dev shops that want to unify the code base and work with a single programming language?

Whitechapel: Yes, I know that many people use MonoTouch and get great results. At the back of my mind was the tiny thought that I might do a follow-up article or blog post on working with MonoTouch. So while I mentioned this as an option, I didn’t say anything else about it in the original article.

Desmond: Did you run across any surprises in the course of your exploration?

Whitechapel: I first looked at Objective-C many (very many) years ago, and hadn’t really kept in touch with its development over the years. So I was very pleasantly surprised to see how much it has evolved, and how easy it is to use. I was especially pleased with the Automatic Reference Counting (ARC) feature, which seems to work extremely well. I was half-expecting Objective-C development to be painful and fragile, but I found quite the opposite. The new Xcode is also very impressive and easy to use.

On the other hand, I’m a little more ambivalent about the introduction of dot notation in Objective-C. The message notation makes sense, and I feel it’s consistent with the design of the language. While dot notation is a welcome convenience for developers used to other languages like C++ or C#, it does seem slightly redundant.

There were a few differences that were mildly surprising – like the lack of a standard DOM parser in iOS, for instance, or the nice way you can integrate in iOS with the global phone settings (which you can’t do in Windows Phone). But my surprise there was really just because I’m more used to the Windows Phone platform – as I tried to make clear in the article, I was very careful to avoid cultural bias. There are differences in the platforms and in the tools, but there’s nothing that can’t be worked around in either platform. I definitely came away with a very positive feeling that developing for both platforms is eminently feasible, and something that more developers should seriously consider.

Desmond: Obviously Windows Phone 8 is on the horizon. Any insight into how WP8 might change the conclusions you drew in this feature?

Whitechapel: I can’t talk in detail about Windows Phone 8 just yet, although some features are already public. Obviously, Windows Phone 8 introduces support for native development, which of course should make it even easier to cross-target iOS and Windows Phone. There’s definitely another follow-up article in that one feature alone.