Simon says, why we chose MonoTouch to write the Diggify iPhone app

There has been lots of talk about the new restrictions in the latest developer agreement on the AppStore that came about when iPhoneOS 4 was announced. It has been a hotly debated topic to say the least. The new legal text in section 3.3.1 is essentially trying to lock in what languages and tools developers use to build their iPhone, iPod Touch and iPad applications.

I’m not going to rehash the same Apple vs Adobe banter that has been going on. It’s been talked about to death. What I am going to talk about is what I believe in as a developer, and why MonoTouch was chosen to build Diggify.

There has been much confusion among various blogs and publications regarding what MonoTouch is and how it works. This stems from the root of what MonoTouch is, which is a .NET and C# offering for iPhone. When people read .NET they jump to conclusions by associating MonoTouch with Microsoft’s user interface libraries such as Windows Forms or Silverlight. This steers people into believing MonoTouch is a non-native UI toolkit ala Flash or various others. Let me clarify before I jump to the experiences and comments.

What MonoTouch is not:

• Non-native UI toolkit
• Cross-platform UI toolkit
• JIT and Intermediate Language runtime

What MonoTouch is:

• Native Cocoa Touch UI
• Native ARM compilation
• Bindings to iPhone SDK libraries that you can use in C#
• .NET class library
• Ability to wrap any native API in C#
• Fast
• Garbage Collected to simplify memory management
• Debugging over WiFi (Xcode cannot do this)
• Very quick to support new API’s from Apple’s iPhone SDK (usually within 24 hours)
• Fully supported by Novell
• Direct access to Novell software engineers via chat rooms, forums etc
• Vibrant and friendly community

I started with MonoTouch during the closed beta program from the very beginning and can’t say enough good things about the MonoTouch team at Novell. During that time, I decided to write a Digg client app for release on the AppStore. At the time this beta program began I had nearly a year of Objective-C development under my belt. This was not a case of “I will only write iPhone applications if my favorite language somehow gets on the iPhone“. Although C# is the main language I have used through my career, I have many others and am not a 1 trick pony. If MonoTouch did not exist, I would be writing Objective-C based applications.

The app built is called Diggify and is available on the AppStore today which can be found here on iTunes and also has a website describing the application which you can find at http://www.diggifyapp.com.

The goals in Diggify were to make a rich Digg application that had great user experience and visuals as well as good usability for navigating the application while at the same time making it as speedy as possible. All of these goals were achieved.

The reasoning for going with the MonoTouch SDK cover several reasons. As mentioned earlier, C# is the language I know the most which means any previously written non-UI code I have in C# I can leverage on the iPhone. This is huge because if I wish to write Diggify for Windows Mobile (at the time) or Windows Phone 7, I can carry over large chunks of my code but leverage the native UI API’s of both iPhone and Windows Phone 7. Remember from above, MonoTouch is not a cross-platform UI toolkit.

To clarify, this means I can write the core meat of my applications logic, data, REST requests for multiple platforms, while leveraging the powerful native UI on the local device. On iPhone this would compile down to Cocoa Touch API calls in native ARM and on Windows Phone 7, Silveright.

In addition to this, MonoTouch is essentially giving me the iPhone SDK+.NET framework. I am getting both. I can use Apple API’s for things like Core Animation to make my transitions and visuals pop, and use System.Xml, System.Xml.Serialization and System.IO from the .NET framework to parse XML and persist them to the file system. I have 2 SDK’s at my arsenal, while not sacrificing the UI. This is key because Apple does not provide things like XML libraries, or WCF/SOAP libraries. I can lean on the .NET API’s to quickly and easily offer these functionalities to me.

MonoTouch comes with MonoDevelop a first rate developer IDE which integrates very smoothly with Apple’s Interface Builder to build your UI’s with. I believe MonoDevelop integrates more seamlessly with IB than Xcode does from Apple. The MonoTouch team has done a great job at trying to make the productivity of building iPhone applications as good as possible.

When writing Objective-C based applications with the iPhone SDK you do not have the garbage collector that Apple provides on the Mac. This and various API’s missing makes developing iPhone applications more time consuming and error prone. Managing memory is a more difficult task and can cause hard crashes in your application. As you grow in experience you get better at these things, but I found using Objective-C I was spending more time on plumbing than on the application’s features, visuals and user experience.

With MonoTouch I was able to really spend a lot of time fine tuning UI and performance. Rich iPhone applications can tend to be a little sluggish if not done right. Like on any mobile device, squeezing performance is skill. You do not have 2ghz dual cores on these phones. This is why apps like Tweetie do so well. Their using rich visuals while blazing fast. I was able to do the same with Diggify by having a rich dynamic user interface while maintaining fast scrollable lists that looked great.

To say this simply: I was able to focus on building a great application rather than spending all my time on low-level book keeping.

When Diggify launched on the AppStore Digg had already released their Digg application a week or so previous, and for free. I had planned and did price Diggify at 99c. In reality Digg’s free app hurts our chances because it was free and obviously it is their own app and they have the platform to market it on their own website to millions of users.

Even though the Diggify application is richer in visuals and user experience (in my opinion and several others from feedback given), one interesting thing happened on the official Digg app launch. The app was rampant with bugs. The AppStore reviews were terrible and the complaints of the app crashing constantly were the common theme. Twitter was also full of comments about how crashtastic the application was. I was able to boost my sales by simply tweeting to people encountering this difficulty (and there were many of them) and making them aware that Diggify existed. Since our marketing is very small and awareness was the largest issue, this helped a great deal.

Using this tactic we had reached as high as 8th in the top paid news category.

In addition to this, all of the feedback we were receiving was all about adding X, Y feature. Not one comment was about a crash or performance issues. The users simply wanted more. One tweet was as follows:

benny_b0i
Got @diggify and like what I see. Transition FX and upcoming are cool, and it’s fast! Would like to be able to digg and see comments tho.
4:53 AM Apr 6th via Twitbit for iPhone in reply to diggify

After initial launch we were able to quickly add some UI tweaks and small features right away based on other user feedback received.

Steve Jobs recently posted an article clarifying his opinions and stance on the topic and although I do agree with parts of what he is saying, there are a couple statements I disagree on. Steve on his article states the following:

“We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.”

MonoTouch is a 3rd party SDK however Diggify vs Digg’s official app is a no contest regarding which is the more stable application. Much of this is credited to MonoTouch’s garbage collector, type safety, etc.

Steve goes on to add:

“Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms”

MonoTouch adds new API’s when Apple releases them within 24 hours. If I didn’t like Novell’s quality in their SDK or support I have the choice to go elsewhere or back to Objective-C.

The initial release of the official Digg app’s main issue was a start-up crash. How that got past QA I don’t know. From there most updates have been fixing various crashes and issues.

We submitted the first app update mostly based on user feedback of UI tweaks they requested 2 days after the initial AppStore approval. Let’s compare the Digg/Diggify updates:

Based on the experience, the quoted statements above from Steve are not the case and is actually the opposite. We are receiving inherited benefits from using a 3rd party SDK which also builds on top of the iPhone SDK. MonoTouch is adding value to the iPhone SDK, not an alternative.

My opinion comes down to this. Bad developers write bad applications. The official Digg application was a bad application to release at the time. It was bug filled. They have refined it over time, but during that time I had 0 complaints, and was moving forward. Since MonoTouch uses the native iPhone API’s and compiles to native ARM, there is no risk in Apple allowing us to write applications in C# via MonoTouch.

Languages and compilers are tools. Do I not get to choose which hammer I wish to use when hitting a nail? In the end as long as we are using documented API’s (which MonoTouch is) and native UI, Diggify is no different than any other iPhone application. Not even 1 user has said that the application feels different. No cycles were spent on making it feel like a native iPhone application simply because, that is what it is. Diggify is calling the same API’s. No extra work is needed. The source language that the application is written in has nothing to do with the look and feel or usability of an application.

By no means is this a post against Objective-C. I simply feel the diversity which is the development world should be embraced not suffocated. MonoTouch was chosen for Diggify for the reasons above. Perhaps you have reasons for using Objective-C or any other language, I believe that it should be our choice.

Perhaps the team writing the official Digg app had unrealistic time constraints and this was the end result. Regardless, from our experience MonoTouch gave us a product that allowed us to focus on the app, preventing us from repeatedly shooting ourselves in the foot all while our time to dedicate to the project was limited.

I feel if Apple truly wants to go the proper route to filter out crappy apps, the path is through QA, not by banning the source language the app was written in.

Apple, let’s work together as a community to rise the level of quality on applications in an effective way that retains the freedom of choice and creativity that developers love rather than lock handcuffs on our wrists.

Update:

As pointed out in the comments below from @redth, I forgot to mention MonoTouch has a btouch tool. btouch allows us as the developer to wrap any native API ourselves in C#. If we need something Novell does not yet provide or binding to an external Objective-C library we can do so. This is an important fact to remember.