Q&A

Q&A: iPhone Development on MonoTouch

MonoTouch developer and book author Wallace McClure discusses the evolving arena of Mono-based application development for the iPhone.

• By Michael Desmond
• 09/29/2010

McClure offers his takes on the rapidly evolving development space around Mono and the iPhone, and provides insight into the challenges and opportunities developers face in this area.

When Apple relented and loosened restrictions on iPhone development, what was your reaction? Were you surprised?
It was a surprise, but it wasn't a surprise all at the same time. If you go back and look at the statements that came out of Apple back in April, all of the statements were directed at Flash and Adobe. There seemed to be some conflicting statements in the April SDK guidelines. Speculation was that MonoTouch was in the mix, but all of the statements and speculation were on Adobe.

Because of this, our publisher decided to continue producing our print book. We had already completed drafts of all chapters. We were in author review, so all of the hard work for the authors had been completed. Unfortunately, a couple of other publishers were not quite as far along, so they put their MonoTouch projects on hold.

Novell was continuing to enhance MonoTouch with each new beta release of iOS 4.0. The continual enhancement of the programming APIs, with bug fixes as well as support for new calls, was one of Apple's stated concerns about third party APIs. Thankfully, Novell was willing to continue to support new iOS APIs. While all of this was going on, Apple was not actively rejecting any MonoTouch apps or removing any apps that had already been accepted. So, these were all positives.

By late June/early July, Novell shipped support for iOS 4.0 and our book shipped. Apple had not rejected any apps because of MonoTouch. Other publishers were restarting their MonoTouch projects. At DevLink, the talks by Joseph Hill and I were standing room only, so it seemed that the marketplace wasn't too concerned. So, I guess it wasn't a surprise. After all, Apple had never enforced the SDK licensing in anyway.

At the same time, it was a surprise. Early in my career in the early 1990s, I worked in the IT department of one of the top companies in the world. Our dealings with Apple really made us question them. The April SDK changes did seem like the Apple of old that didn't really have an understanding of what it had or the damage that it was doing to its own developer ecosystem. Rarely do companies do a complete 180 degree turn. So, from that standpoint, it was a surprise.

Do you expect this decision to increase dev activity for the platform? In particular, what do you think the impact will be for developers looking at MonoTouch as a way to transition their well-known .NET-compatible code to the iPhone platform?
I definitely think that this will increase development activity on the iPhone. It unofficially opens the platform to .NET developers, those fluent in JavaScript using PhoneGap and AppCelerator's Titanium, and other development tools. I think that this is a good decision by Apple. It will give developers confidence that they can use the best tool for them to solve their problems.

I don't know what Novell's plans are for MonoTouch now, but I would be willing to bet that they are going to put some more resources behind MonoTouch than they had on September 1, 2010. I'm hoping to see some of the latest and sexiest features of .NET on the iPhone, like Silverlight/WPF. I don't know what Novell has planned, but wouldn't Silverlight/WPF on the iPhone be exciting?

One of the problems for a .NET developer looking to build an app with Apple's ObjectiveC and XCode is that not only are they required to learn a new language, they have to learn a new development tool, and they have to learn the idiosyncrasies of the iPhone. While developers like to say that learning a new language is easy, I have not found that to be true. With MonoTouch, I can take my existing .NET/C# language and library knowledge and apply this to the iPhone. I'm not required to learn ObjectiveC, which is a big hurdle. MonoDevelop is the featured development tool. It's not that much different from Visual Studio, which .NET developers know well.

So now, the biggest hurdle is learning about the idiosyncrasies of the iPhone. Learning the idiosyncrasies of a new platform can take time, but now I don't have to learn as much as if I went the ObjectiveC route.

On a personal note, my first experience with MonoTouch was in August, 2009. I decided that I didn't want to write "Hello World." I wrote some code in Visual Studio to go out to a Web service and perform a geolocation lookup for an address. I copied that code into MonoDevelop, hooked up some controls with Interface Builder, and lo and behold, I had a map of the area of the address. With a little more work and some help from my buddy Craig Dunn, I then had a pin on the map.

I guess my total time investment was two hours from the time I started working in MonoDevelop. I'm not convinced that I could have done this in ObjectiveC and XCode without a lot more time invested and pulling my hair out. MonoTouch made me immediately productive.

As a .NET guy, one thing I've always credited Microsoft with is its commitment to wooing developers. Whether it was the browser wars with Netscape or the game of catch-up with Java/Sun, Microsoft has always regarded the developer community as a strategic asset. It seemed like Apple was playing into Microsoft's hands until it reversed course. Do you think Apple can compete with Microsoft when it comes to putting tools, support and know-how into developers hands?
I think that there are a couple of things at work here. As they say, hindsight is 20/20 and I think Apple has learned the lessons of history.

I'm a big fan of CNBC. They have several shows on Apple and the Mac. They spent some time with Guy Kawasaki and he talks about the Apple strategy. The Apple strategy of how they dealt with developers changed over the years. Apple is a consumer company today. Whether it's the Macintosh and OSX or the iPhone and iOS, they are a consumer company. One of the things that struck me from the CNBC interview is that Apple views that if they create great products and have a loyal fan base, developers will come along. If you look at ObjectiveC and XCode, these products show that developers have not been foremost in Apple's mind.

Associated with that, this leaves opportunities for third parties to fill a need. MonoTouch is one of several companies that are providing development tools to fill this need.

Apple has been in this situation before. In the late 1980s, they had the better GUI over Windows 2.x. They didn't take advantage of this then and became marginalized by not solving customer problems, including developer problems. Developers want easy tools to use, allow them to use their existing knowledge as much as possible to solve problems.

Supposedly, the next version of Apple's development tools will improve productivity. I think that they are available under NDA, so I don't know all of the specifics. As I understand it, there are supposed to be some productivity enhancements in the next version. Apple is listening; however, they have a long way to go to create development tools that are embraced by a large number of developers.

How is the increased competition in the smartphone space changing the picture?
Competition in the Smartphone marketplace has really taken off in 2010. Android has 200,000 activations every day. Windows Phone 7 is about to ship.

Given their past history, I think Apple had to allow more developers access to the iPhone. They need more friends in the marketplace, not less. They need more apps for their platform, not less. They need more developers for their platform, not less. By explicitly allowing MonoTouch apps on their platform, they are opening their platform to the largest group of developers out there. I think that this is a great decision by Apple. I think it will show with an increase in the number of apps for their platform.

Even then, I could see that mobile was going to be a big deal. I kept working with various mobile apps, but I never actually got on the iPhone. I was very nervous regarding ObjectiveC and XCode. In April, 2009, I was working on a cloud application on Windows Azure. I was talking with someone at Microsoft and they really felt like my apps should be interfaced to mobile and specifically on the iPhone.

I spent some time working with PhoneGap, and then Novell announced MonoTouch. I knew that was where I needed to be. Right around that time, I sent an email to one of my editors at Wrox about MonoTouch and putting it in their eBook format. They told me to get started immediately.

Once my eBook shipped, about two weeks later, the editors called me and said that sales were really good, so they wanted to do a larger print book. I pulled Craig Dunn in along with Martin Bowling and Chris Hardy in on it. Rory Blyth joined us a few weeks later. And from that point, we sprinted to get our book out. Those guys were great to work with.

What is it about Mono and MonoTouch that provides unique value to developers looking to write apps for the iPhone platform?
Mono and MonoTouch really are .NET and C#. You get the .NET features provided by MonoTouch that you are used to.

When garbage collection was first put into .NET, I doubted the value that it provided. Over the years, I have come to the conclusion that it solves problems. I think that in a mobile environment, resources -- especially memory and processor -- are a big deal. You can't just bleed memory in an app, especially a memory constrained mobile device. With garbage collection, you don't have to worry so much about memory management long-term in your application.

.NET developers are also used to a great set of Base Class Libraries. MonoTouch gives you many of the BCLs that developers are used to. Think about how easy LINQ makes life. With MonoTouch, you have LINQ support on the iPhone.

Finally, think about how easy calling Web services in .NET is. Visual Studio has IntelliSense support for these Web services. With MonoTouch and MonoDevelop, you get a similar design-time experience.

Just think about these three features. How much time would it take for you as a developer to recreate these features or just some part of these features?

What has most impressed you about the latest version of MonoTouch? What has most disappointed you or what do you feel is still missing from MonoTouch at this stage?
The latest version of MonoTouch provides full support for iOS4. I sat down one Sunday afternoon and in about an hour, I had a multithreaded app running on iOS4. Novell made it really easy. I read through the Apple documentation, put a couple of things together and boom, I had support for location changes just as Apple documented it.

There is one thing in MonoTouch that is clearly missing and that is the IDE is definitely lacking. It's not that MonoDevelop doesn't have good features. MonoDevelop is clearly a work in continual progress. It's not that it's bad, but it's still buggy.

Can you think of any common mistakes .NET developers make when they first start working with the iPhone platform? Any advice for these developers?
The biggest misconception that I hear from .NET developers when we first talk MonoTouch is that they think that MonoTouch runs on Windows, installs in Visual Studio, and somehow allows you to write Winforms/WPF apps that run on the iPhone.

With MonoTouch, you are creating native iPhone applications. These apps are using the native iPhone controls in the iPhone SDK. The iPhone SDK only runs on the Mac and OSX. As a result, you have to have a Mac. While you can use Visual Studio for a few things, for iPhone-specific functionality as well as the final compile, you must do this on the Mac.

More than a decade after Java gave us ‘write once, run anywhere', the mobile space is forcing developers to make hard platform choices. Can MonoTouch help avoid these hard choices?
We all want one development tool on one platform that allows us to create one application that takes full advantage of the features and functions of the platform you are on. With mobile devices, we have lots of choices. With MonoTouch and MonoDroid (Mono for the Android platform), we will be able to share business logic between iOS, Android and Windows Phone platforms.

I'm hoping that Novell, Microsoft or others will help us solve more of these problems on other platforms. As long as the code doesn't have something particular to a given platform, the source code should be shareable across platforms.