Catching the iPhone in the .net

Smartphones and all other kinds of mobile devices are everywhere, almost everybody has one. Not just for entertainment but also as a client for all kinds of enterprise software. Making choices when developing desktop software was easy, the main discussion usually was restricted to deciding which Windows version to target. Making choices when developing software for mobile is harder. No platform is dominant and each platform has other tools and languages. The nice thing with the Windows Mobile platform is that you can use the same tools and languages (read C# and the .net platform) as used for desktop applications. The nice thing about Apples iPhone is that it has an incredible UI, is also widely used and has a good possibility for developing commercial applications.

Wouldn’t it be nice to have the best of both worlds ? The quality of the tools and language of Windows Mobile and the pleasure of use of an iPhone  ?

A small Windows Mobile rant

I have to get something of my chest first. This is an important reason, besides the iPhone just being sexier :), to  look further than WM.

Building applications for Windows Mobile is, thanks to the .net compact framework, no big deal. For a couple of years my Windows Smartphones were a nice and reliable target. But instead of getting better the Windows Mobile platform has become worse in the everyday use, despite all the “integration” in Windows. Let me sum up my complaints over the last year:

  • Since Vista many a smartphone is no longer recognized when connected over USB. Switch to bluetooth ?
  • After a bluetooth connection with my laptop I have to reboot the phone before it will connect to anything else (like my old a plain vanilla carkit)
  • Office 64 bit does not sync with any Windows Mobile device at all Switch back to Office 32 bit ?

All of these complaints are well known and acknowledged. And will not be fixed. Period. (None of them are a problem when trying to sync an iPhone with MS Outlook) So you are isolated more and more with Windows Mobile. Yes things will be better with Mobile 7. But that’s somewhere in the future and there is no way to migrate existing hard- and software.

The good thing with WM7 is that all software development is based on Silverlight. Which has proven to be a nice development environment with a very good subset of the .net framework which encapsulates the platform. You only have take care about the form factor of the hardware and can forget all about the dreaded OS. For now it’s time to look at the iPhone.

Wrapping up iOS

At first sight the tools for creating iOS (the OS for the iPhone and iPad) applications don’t look very appealing. The API is rich but the language (objective C) is not very friendly. Worst of all you have to do your own memory management. Memory is freed using ref-counting, just like in COM. I have had my share of that working with Delphi in COM and avoid it like the plague ever since. The main problem with refcounted objects is what happens with them when they are passed as a parameter to some other piece of code. Without a clue what will happen to their count while spending some time there. Memory leaks as well as null pointers are usually the result. Trying to avoid that leads to ugly changes in the software’s design, only trying to satisfy memory management.

Here the MonoTouch framework comes to the rescue. It wraps up the iOS framework in a .net style library and adds a C# compiler for iOS. All external resources are wrapped up in the IDisposable pattern. Over the years a garbage collector and IDisposable have proven to be, despite the initial skepticism, quite reliable. And have lead to code which is far simpler.

Building an iPhone app in C#

You need several things to do this, the first is a Mac with the newest version of OS X. It does not have to a monster, for me the smallest Macbook is by far powerful enough. Monotouch runs as a part of MonoDevelop, which looks like a simple Visual Studio for the Mac.


Simple, but all the essentials are included. Monodevelop has integrated nUnit support and refactoring. Don’t expect too much of the latter, it pales compared to that of VS. Not to mention Resharper. Typing code in MonoDevelop is a new form of sports on itself. The difference in the navigation keys itself is enough to drive you nuts in the beginning. And, without Resharper, there is so much more which you have to type.

The good part is that running and debugging the app works like a charm. The iPhone emulator works well, including network support. Which can be another PITA developing for Windows mobile. Just for fun, try watching a Youtube movie in the emulator. The debugger is a way of exploring what’s inside an iPhone. The stability of the environment is good, it takes inspecting null pointers to non managed resources to hang up MonoDevelop. With “Force Quit” in the apple OS (comaparable to the Windows Task Manager) a quick restart of the tool is easy.

Apple support

The App Store is a way to sell your apps. Before an app is accepted for resale it is tested and scanned by Apple. A lot has been said about Apple banning apps not created with Apple’s own SDK. Monotouch apps compile to native iOS code and Apps built with Monotouch are reported to be accepted to the appstore. Working for the appstore takes some investments. Beside the mac hardware and an entrance fee to the store there is $500 for a Monotouch licence to deploy your apps to an iPhone or the store. Apps built with the free (trial) version only deploy to the emulator.

Taking the bait

Having explored Monotouch I have taken the bait. As with every new thing the first steps on the curve are hard. There are a lot of resources on the web, the quality varies. As a first step I started with refactoring the examples. By hand… Soon the result was astonishing. Most examples are in a very chatty syntax; refactoring the noise to auto-properties soon revealed the intention of most of the code. And quite soon I found my way. I’ve got the iPhone in my .net. For now I can only advise you to, in case you have a Mac, take a look at Monotouch. Enjoy! More on my experiences later.

This entry was posted in Coding, Mobile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • pvanooijen

    $399 for MonoTouch + $99 for Apple makes 498 together, almost 500. The amount in my post is almost right, the specification isn’t.

    And for a short period of time the total amount is not even right. To celebrate Apple’s new policy Novell offers a 15% off for a short time.

  • Manoj Waikar

    Thanks for the info. Peter. BTW, Miguel de Icaza has posted ( that there won’t be any issues with MonoTouch apps going forward, now that Apple has removed the restrictions.

    Which MonoTouch edition are you talking about which costs 500$? Their professional edition is 399$ and enterprise is 999$? Plus Apple single developer license is 99$ right? Could you please clarify.

  • pvanooijen

    There more of discussion on that on As it looks now Monotouch apps are accepted, also for iOs 4. I trust that, else I wouldn’t make these investments.
    Technicaly speaking Monotouch is, as I understand it, native code, as it compiles to x-Code.

  • Franklin

    With my limited knowledge, Apple doesnt allow code generated from languages to be allowed into their applications

    Check this

    John Gruber of Daring Fireball pointed out the change in the new iPhone Software Developer Kit license for iPhone OS 4. This provision was added: “Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).”


  • pvanooijen

    That is in objective-C for Leopard. This is iOS..

  • Bobby

    Objective-C has had garbage collection for a while. You should research-better


    The above comments seem to skip past the pleasantries and dig their claws right in, so i’ll add some retrospectively:

    Thanks for a really useful article!

  • pvanooijen

    @Justin I wasn’t fishing for Andoid (yet) Having mono for that platform as well makes Monotouch even more appealing

    @Rennie Even more than 1 on that site. There is a lot to be found on the web, the community is growing. I’m joining :)

  • Rennie

    Here’s another blog article on the same subject:

    I’m working up my courage (and trying to find time in my calendar) to take the plunge myself. After 40+ years in this business I’m totally in love with C#, and find it difficult to imagine having to switch languages ever again.

  • Justin


    I guess you forgot to mention MonoDroid. It allows you to develop Android apps for Android.

  • pvanooijen

    HTML5 ? Will be nice and crossplatform. Provided the browser offers good support. But it would be Javascript instead of C# and the .net framework. Wanting to work with that was the point of my post.

    The only way to find out if a Monotouch app is really accepted is by trying. I trust the sources. My first app is completely in my own hands, it will be small. In case it is rejected I have invested time, money and effort in something which didn’t work out. I will tell myself I have learned something and will tell you I appeared to be wrong.

  • Kelly

    I’m surprised you didn’t mention HTML5 as a possible development platform.

    I’m also surprised that your willing to accept ‘Apps built with Monotouch are reported to be accepted to the appstore’ as assurance that all your hard development work will not simply be rejected and go to waste.

    What would you tell your client in that case?