Yesterday marked the release of Novell’s MonoTouch. MonoTouch is essentially an iPhone SDK for .Net programmers and its purported claim is to be able to allow the developer to put C# code in one side – and have a fully functional, Apple approved, App Store ready iPhone app out on the other side. It sounds kinda cool, especially if you’ve got a ton of legacy C# code that you want to leverage as an iPhone app. But…does that problem even exist?

I’m usually not one to have a lot of messy layers in between me and what I want to do, and an extra SDK (and possibly an extra IDE) seems like the definition of messy layers. MonoTouch apparently solves some sort of problem that people are having. As near as I can tell it must be one of these:

1. A bunch of legacy .Net code that companies want to repurpose from existing legacy apps into iPhone apps.
2. A true desire to never have to learn Objective-C.
3. A cadre of .Net programmers sitting around and they need to develop an iPhone app. Right now!
4. Cost savings.

Looking at each in turn…

Legacy Code
Your problem is, you want to write an iPhone app that utilizes your existing assets of tested C# code. You don’t want to *have* to recreate the wheel, you want to roll with the one you already own. However, if you have libraries and libraries of C# sitting around, I’m 99.9% sure it was written for another context: a web site, server back-end, or standalone application. If that’s the case, then aren’t you going to have to refactor the code for your iPhone app anyway? Whatever requirements you had for the original application may not translate to the iPhone. For example, let’s say you have a C# application that does 300 cool things. Only 20 of them may be pertinent for the context of mobile computing. This reduction may be because the mobile app is only suited for a subset of your user base or maybe those 20 features are the Top 20 things people want to do when they’re not tied to their desk using your regular foundational application.

Whatever the case, you’re re-writing the application to accentuate those 20 features. New screen flows, some new business rules (e.g. different security modules for the local device, local user preferences, etc.), new layouts, and all the cool stuff that iPhones can do that your standalone app can’t (e.g. location awareness, animations, camera) – are all considerations you now have that your previous code didn’t have to worry about. So while maybe you can reuse some validation logic, web service calls and so forth, a good chunk of that code you want to use will need to be surgically placed within this new SDK. In the end, you have what essentially is a ported app. While it runs on the new platform, it doesn’t take advantage of its capabilities. Was that the intent?

No Learning Allowed?
OK. I’ll admit it. I don’t know C#. I will also admit that before March of this year, I really didn’t know Objective-C either. I’ve spent the last several years more in the Ruby, PHP, perl, SQL, scripting areas doing CLI stuff. So, I expected a monstrously large learning curve picking up Objective-C – especially considering that the last C program I wrote was in the early ’90s. That being said, I would hope that one’s life as a C# programmer would better prepare one for learning Objective-C than Ruby did for me. To my surprise though, learning Objective-C was not the barrier I anticipated. To me, the bigger learning curve in the whole iPhone development arena is the SDK itself. Learning Objective-C simply becomes a side-effect of figuring out how to get your phone to do all of the cool tricks of which it’s capable. The fact that the MonoTouch SDK binds to the iPhone SDK doesn’t seem to buy you anything because you still have to learn their SDK! You’ll probably need to learn the iPhone SDK too just because there will be issues that come up that the only way you can find answers is by searching through Apple-focused forums and web sites.

The questions that remain for me (and if you can answer them, tell me as I truly don’t know) are:

1. What are the things you can do in the .Net framework (in general) and C# (specifically), that don’t translate. For example, is inheritance the same from C# to Objective-C? Are there subtle tricks in your current code that take advantage of the .Net framework that just don’t translate that you’ll need to rewrite or even re-architect?
2. What about the converse? Are there things in Objective-C that cannot be done in C# that you will simply have to recognize that you can’t do? Essentially these become self-imposed limits or force you to code to the lowest common denominator. Yuck.
3. Adding extra layers almost always add headaches. Is this bug in my code? The MonoTouch SDK? The Apple SDK? Any thoughts on this?
4. What about performance hits or memory issues? C’mon, there has to be something here.
5. Lag time between new iPhone SDKs and an updated version of the MonoTouch SDK. If you’re looking at MonoTouch as a time-to-market advantage, you definitely just lost it the first time Apple adds something cool to its foundation and you have to wait for Novell to catch up.

So your “net-net” after you do all of this is: you now know C# a little better, you know how to conform your MS code into something the iPhone will understand, and you know an SDK that shields you from actually having to touch the real SDK. What happens you go looking for an iPhone job? Do you look for only those shops that run MonoTouch? Are you qualified for shops that do iPhone development on bare bones Xcode and Objective-C? Maybe that’s the litmus test of this particular value proposition.

Get Me to Market!
If I’m a company, chomping at the bit to sell my products or services in a mobile marketplace, the iPhone is probably the first place I’m going to look. Anything I can do to get my programmers up-to-speed quicker and get my product out the door is an advantage I’ll jump on every time. If that’s a true statement (and it typically is) – why not contract out that work to people that are already trained? If time-to-market is that important, then even your staff learning the MonoTouch SDK is a waste of market minutes. If time-to-market is not that important, any time savings you think you’re going to gain from going with a MonoTouch should be irrelevant.

Also, with new code, you aren’t encumbered by the legacy constraints listed above. If you’re trying to access legacy libraries, then your time is probably better spent it writing JSON or RESTful wrappers over them which will extend their useful lives by making them accessible to all the *other* new technologies coming towards you instead of trapping them inside a static bubble.

Cost Savings. Really?
From a cost standpoint, you still need a Mac, you still need Xcode, you still need to pay your $99/year SDK fee – on top of your software fees to Novell. Unless you’re looking at it from a whole department that would need Macs in order to get your squad productive, this argument holds no water. And even in the instance where you’re trying to push your entire group in to iPhone development, any savings you gained from not buying them proper equipment would be negated from the extra hoops you would have to potentially jump through as mentioned above. So, perceived cost savings seems to be a non-starter as well.

Maybe If…
Now, if this is a first step by MonoTouch into providing an abstracted layer over the Palm Pre, Blackberry and Android in addition to the iPhone – then this makes a lot of sense and I would consider learning C# to make multi-platform a reality. Other than that though, for me, coding an iPhone app is a pure joy. I enjoy Xcode. I enjoy Objective-C. Everything seems to work the way you expect it to. And maybe that’s just me as I know some people really loathe it. I just hate for anyone to artificially deny themselves of that joy by adding unnecessary layers of Goretex to an otherwise streamlined environment.

The iPhone is a different context. If you’re trying to leverage all of your other contexts to save on development here, then you’re missing the point, goals, and possibilities of that different context. The deltas here between what you’ve been doing and where this is all going – far outweigh the similarities. This is not simply a different computing platform – it’s different computing. There’s a reason they call it “game changing”. Different games have different rules. Learn to play by the new rules, and you’ll find yourself closer to winning.