Xamarin 2.0 reviewed: iOS development comes to Visual Studio

Write your iOS software from within Windows. Yes, really.

Since 2009, it's been possible to develop iOS applications using C# and .NET, courtesy of MonoTouch. But one important detail has always been missing. If you wanted to use Visual Studio—the premier C# and .NET development environment, the one that almost every C# developer calls home—you were out of luck.

With Xamarin 2.0, that all changes. You can now develop and debug apps for the iPhone, iPod touch, and iPad in Visual Studio in Windows. Don't want to use Visual Studio? Xamarin has a new cross-platform IDE, Xamarin Studio. To make apps easier to build, Xamarin now offers a component store, giving Xamarin developers instant access to a range of free and paid pre-built libraries and user interface controls. Topping it all off, there's a new pricing model that starts from free.

I've been taking a look at it for the past few weeks to see how it all works.

The realization of ambition

The company Xamarin rose from the ashes of Novell. When the one-time king of corporate networking was taken over by The Attachmate Group, one of Attachmate's first moves was to lay off large portions of Novell's workforce. Throughout the years, Novell had acquired a range of companies in an effort to move beyond its file and print serving business. Attachmate, however, was only interested in two things: Novell's library of patents and the SUSE Linux business it bought in 2003.

Mono. First developed by Ximian...

One of the victims of these layoffs was Ximian, another 2003 purchase. Ximian was founded in 1999 by Miguel de Icaza and Nat Friedman in order to develop Linux software for the GNOME desktop environment. One of its core technologies was Mono, a project that sought to implement a compatible, open source implementation of Microsoft's .NET Framework and its C# language.

While at Novell, the Mono team developed a version of Mono for the iPhone (MonoTouch) and another for Android (Mono for Android). These allowed developers to write applications for, respectively, the iPhone and Android devices that used C# and Mono's version of the .NET Framework. It provided .NET developers a familiar language and set of libraries as an alternative to Objective-C on iOS, and Java, on Android. While the underlying Mono was, and is, open source, these additional frameworks were not.

... then by Novell...

MonoTouch was first released in 2009. Mono for Android came in April 2011. Within a month of the release of the Android product, Attachmate both bought Novell and booted out all the Mono developers.

Though laid off by Attachmate, de Icaza and Friedman were convinced of the value of Mono—in particular, its smartphone variants. The pair immediately formed a new company, Xamarin, to continue the development of Mono. They also outlined a plan to provide a new set of smartphone-oriented frameworks.

This initially appeared problematic. They could not use MonoTouch or Mono for Android as the basis for their work, as these were owned by Novell and now Attachmate. Worse, due to their involvement in the development of MonoTouch and Mono for Android, it would have been difficult to prove they were not using code belonging to those products in their new frameworks.

... briefly by Attachmate...

Ordinarily, one might expect this to turn into a legal quagmire, but it didn't. Attachmate granted Xamarin a perpetual license to use, maintain, and extend the MonoTouch and Mono for Android products. Xamarin wouldn't have to start from scratch, and it wouldn't have to worry about tainting its code with Attachmate-owned intellectual property either.

Xamarin swiftly released maintenance updates for the Mono products, providing continuity for existing users. The group continued to sell and support MonoTouch and Mono for Android as well. Xamarin's first products were, by necessity, somewhat rushed, as the fledgling company needed to get something on the market fast. Mono for Android development could be done in both MonoDevelop, an open source C# IDE, and Visual Studio, the environment that is the natural home for most C# developers. iOS development, however, could only use MonoDevelop.

... and now Xamarin

In spite of these rough edges, the company found an eager audience and grew rapidly. Today it boasts 12,000 paying customers and close to a quarter of a million developers now using the Mono stack. They're producing a wide range of apps, with the major categories being internal use line-of-business apps and games.

Xamarin's underlying goal has been to create the best mobile development experience. The company wants to marry highly productive tools and development environments to easy cross-platform development, while still allowing developers to tap into all the rich underlying capabilities each platform has to offer. Xamarin 2.0 is the first full realization of that ambition.

The first important thing about Xamarin 2.0 is that the awkward naming has been cleaned up. Instead of the weirdly asymmetric MonoTouch and Mono for Android names, the underlying platform is called Xamarin. The iOS and Android variants are called Xamarin.iOS and Xamarin.Android, respectively. There's also a Xamarin.Mac for producing apps for the Mac App Store.

The platform is split into common parts and platform-specific parts. Common ones include the C# language and the .NET Base Class Library, which provides standard functionality such as network connectivity, data structures, file and database access, and threading. These platform-specific parts wrap the libraries and APIs of the underlying platform. For example, Xamarin.iOS gives Xamarin developers access to APIs such as Core Animation and iAd; Xamarin.Android has things like an API for NFC hardware and another for accessing Google Maps.

Also included in these platform-specific parts are all the user interface APIs. The model for Xamarin is that non-UI parts of the application—communicating to remote servers, parsing files and data from networks, storing information persistently, and so on—should be shared across platforms, built using the Base Class Library (BCL). UI parts, however, should be platform-specific to ensure each UI looks and feels correct on its respective platform.

There's also a large set of functionality that's common to smartphone platforms but not covered by the BCL. For example, all smartphone platforms have GPS APIs, camera APIs, and contact APIs. Xamarin has developed a library named Xamarin.Mobile that encompasses this functionality, to allow cross-platform apps to share more code.

iOS development in Windows, for real

The centerpiece of Xamarin 2.0 is support for Xamarin.iOS in Visual Studio. Xamarin says this was in huge demand, with three-quarters of customers wanting the ability to use Visual Studio for their iOS development. The remarkable part about this is, well, it all just works. Get the software installed and you can create Xamarin.iOS projects in Visual Studio. Visual Studio's usual platform options are extended to include iOS devices, and it gains two special debug targets: the iOS Simulator and a physical iOS device.

Although this is perhaps the most striking feature of Xamarin 2.0, it's also an odd one as there's not actually a whole lot to say about it—because, again, it just works. This is iOS development in real Visual Studio. Visual Studio's key bindings, Visual Studio's text editor, Visual Studio's menus, Visual Studio's autocomplete and IntelliSense—even Visual Studio's debugger—are all provided and work in the usual Visual Studio manner.

Want to use Visual Studio's integration with TFS or the new git integration? You can do that, because you have nearly the full range of Visual Studio features and capabilities available to you. Want to run unit tests with Nunit? Go right ahead. Prefer to use the ReSharper plugin for its richer refactoring and IntelliSense support? That will work just fine. This is truly developing on Visual Studio.

Behind the scenes, things are a little more complicated. The traditional Mono and .NET compilers produced a bytecode called IL (Intermediate Language) which is just-in-time compiled on the end-user's machine. However, this kind of technology is prohibited on iOS. Instead, Xamarin uses an OS X machine to compile its software and deploy it onto hardware. Xamarin development in Visual Studio needs both Windows and OS X available: Visual Studio runs in Windows and it connects over a network to OS X. The OS X machine has the iOS SDK. Visual Studio controls it remotely, using the Mac for all build-related tasks. The programs are actually compiled using Apple's compiler and tools, so they are in every important sense identical to programs written in Objective-C.

The setup I used had everything running on a single system. Visual Studio ran in a virtual machine inside VMware Fusion, with the iOS SDK and Xamarin build components installed on the OS X host. But the two don't have to use the same hardware. If I had a Mac Mini tucked away in a cupboard, that would work too.

The iOS build host is reached over the network. Sometimes I had to use the first entry, sometimes I had to use the second. I don't know why.

The connection between the two was almost seamless. When it worked, it was essentially invisible. I hit ctrl-shift-B to build (or F5 to build, deploy, and debug) and everything happened as expected. The network machinations and remote compilation were invisible. Occasionally I did have some minor upsets where Visual Studio would lose the network connection to the OS X build system, though this may have been some interaction between VMware and the Wi-Fi networks I was using rather than anything to do with Xamarin per se.

That seamless support extended even to the debugger. Set a breakpoint and hit F5 and your app will build, deploy, start executing, and run until it hits the breakpoint. You can then inspect values by using Visual Studio's various debugger panes or hovering the mouse over variables in the text editor. You can change values while the program is paused. You can single step. It offers almost all the functionality that Visual Studio developers have grown to expect, with the same user interface they know and love.

There is one gap. Visual Studio's edit and continue feature that lets you modify code and recompile it without having to restart the program from scratch isn't supported. Given the nature of the compilation and deployment system that's at work behind the scenes, this perhaps isn't altogether surprising.

Deployment for debugging and testing can be on physical hardware or the iOS Simulator that's part of the iOS SDK. Unfortunately, the iOS Simulator isn't made available remotely. It runs only on the OS X desktop. As a result, you'll probably want to make use of VMware's Unity mode (or similar features in other virtualization software) so that both Visual Studio and its debugger and the iOS Simulator can be visible on-screen at the same time.

Enlarge/ iOS Simulator on the right, pretending to be an iPad. Visual Studio on the left, debugging the iPad.

The result is, well, a little uncanny. It feels wrong to have a virtual iPad up on screen next to Visual Studio. But it works.

There is one other important functional gap. At the moment, Xamarin.iOS for Visual Studio includes no user interface editor. Instead, developers wanting a graphical interface editor must use Interface Builder in Xcode. Xamarin says MonoTouch developers are currently split about 50/50 between those who use Interface Builder and those who build their interfaces entirely in code.

Longer term, Xamarin hopes to fill this gap. Xamarin.Android already has: there's a form designer that produces Android's user interface XML to allow drag-and-drop user interface building. Using Xamarin.Android with Visual Studio also doesn't require a counterpart system for building and deploying, as the Android SDK runs directly under Windows. Xamarin says it intends to provide an iOS experience comparable to the Android one in the longer term.

Although it's difficult to imagine the OS X dependency ever going away due to the nature of the iOS SDK and the desire to keep Apple on-side and happy, an integrated forms designer within Visual Studio is a likely future development. In the meantime, VMware's unity mode again enables the Apple software to be used side-by-side with the Microsoft software.

There's one other limitation developers need to be aware of, this time imposed by Microsoft (and applicable to both Android and iOS development). You can't use the free Express version of Visual Studio with Xamarin because Microsoft prohibits the use of most extensions and add-ins in Visual Studio Express.

Well, damn, I was looking to get back into hobby programming, maybe write a small RPG. I was leaning toward C#, but also wanted to dabble in iOS development. Choices have been merged. It's like... like... Wonder Twin powers have been activated. :-)

Not sure I like the subscription model, but, well, $300 a year is not a lot as hobbies go.

@editor since ARC there is (except for resolving cyclic references) no memory management in Objective-C anymore. at least as far as the developer is concerned. it's all done automatically at compile time.c# is not cleaner than objective-c it is simply different... except for NS and @ prefixes...

I wonder if Apple allows it in the OSX license for a company to farm out cloud instances of OSX? Sounds like it'd be a feature for Xamarin to enable indies to write iOS apps without having to invest in Apple hardware.

I became significantly less excited to see that it’s $1000.00 a year to target iOS from Visual Studio. While that seems fine for companies, it’s a bit out of budget for a student that’s interested in development as a hobby.

@editor since ARC there is (except for resolving cyclic references) no memory management in Objective-C anymore. at least as far as the developer is concerned. it's all done automatically at compile time.c# is not cleaner than objective-c it is simply different... except for NS and @ prefixes...

Not to start a flamewar, but it is cleaner. There's obviously no objective measure to determine how clean a language is, but there are markers. Separate header and code files are a thing from the days of young compilers. Objective-c can be considered to be burdened by it's C legacy. It's by no means a bad language though, but it isn't as clean as modern alternatives.

It would seem you did not understand the article. The iOS app is BUILT on a Mac. Visual Studio, on the Windows side, it purely an IDE and a convenience for people who like Visual Studio. Everything is as per a NATIVE iOS App. If you don't want to use Visual Studio or Windows you don't have to. Just use the Xamarin Studio IDE and build everything on a Mac instead. Lots of options .

iconmaster wrote:

I'm sorry, I wouldn't trust an app produced in this way. The best iOS devs are the ones willing to invest in the platform; and that still means buying a Mac.

I'm not saying an app built on a Windows PC would be noticeably flawed. I'm saying there's a difference in commitment that will show in the end product.

I became significantly less excited to see that it’s $1000.00 a year to target iOS from Visual Studio. While that seems fine for companies, it’s a bit out of budget for a student that’s interested in development as a hobby.

I would have loved to see the Visual Studio support in the $300 version, but it is worth pointing out that you've got to pay for Visual Studio too, since the free versions aren't extensible by third parties either.

I understand that this gets muddied for students, however, as they often have access to the expensive versions of Visual Studio without having to pay.

Could someone explain to me why this is better than existing tools such as the Corona SDK or Titanium Appcelerator, both of which allow you to develop mobile apps for multiple devices with one code base. I also believe they both compile into native code for each device (unlike phonegap as per my understanding). (Other than the fact it can be used with Windows).

@CartBlanche - It would seem you did not understand his comment. He wasn't saying the app isn't native, but that it's likely not as good. If you're determined to stay with the tools you're comfortable with, you're probably less likely to embrace the conventions and gestalt of the iOS platform. I tend to agree with him.

Given that you need a Mac with Xcode installed to build the software, $400 to $1000 a year seems quite a lot. Granted there's a large time investment to learn Objective C; on the other hand, that's mostly a one time event.

I became significantly less excited to see that it’s $1000.00 a year to target iOS from Visual Studio. While that seems fine for companies, it’s a bit out of budget for a student that’s interested in development as a hobby.

They do offer a student price. Check with them as I know others who have bought as students.

Separate header and code files are a thing from the days of young compilers.

Quite frankly, having to deal with some C# developers, having the public interface and source mixed willy-nilly makes reading C# a royal pain in the ass. Of course, that's nothing compared to their obsession with absurd XML comments... Seriously people, XML is not human readable!

@CartBlanche - It would seem you did not understand his comment. He wasn't saying the app isn't native, but that it's likely not as good. If you're determined to stay with the tools you're comfortable with, you're probably less likely to embrace the conventions and gestalt of the iOS platform. I tend to agree with him.

Please explain why your choice of IDE (essentally a fancy text editor) will affect your ability to embrace a platform? I think that would mean that person is not a decent developer. In order to get the best out of the platform you must understand it, not necessarily suffer for it. Just my HO.

@CartBlanche - It would seem you did not understand his comment. He wasn't saying the app isn't native, but that it's likely not as good. If you're determined to stay with the tools you're comfortable with, you're probably less likely to embrace the conventions and gestalt of the iOS platform. I tend to agree with him.

Please explain why your choice of IDE (essentally a fancy text editor) will affect your ability to embrace a platform? I think that would mean that person is not a decent developer. In order to get the best out of the platform you must understand it, not necessarily suffer for it. Just my HO.

It's a lot more than an IDE, though. It's the language, the libraries, doing the UI in code vs. IB, etc. I'm guessing you've never worked on a project with a "non-native" developer. It's like saying that someone whose native language is Chinese can write a novel in English b/c "It's just words. How can the choice of language affect your ability to write a novel?" Is it possible this mythical person expresses themselves in English better than you or me? Sure. It's just less likely.

@CartBlanche - It would seem you did not understand his comment. He wasn't saying the app isn't native, but that it's likely not as good. If you're determined to stay with the tools you're comfortable with, you're probably less likely to embrace the conventions and gestalt of the iOS platform. I tend to agree with him.

Please explain why your choice of IDE (essentally a fancy text editor) will affect your ability to embrace a platform? I think that would mean that person is not a decent developer. In order to get the best out of the platform you must understand it, not necessarily suffer for it. Just my HO.

It's a lot more than an IDE, though. It's the language, the libraries, doing the UI in code vs. IB, etc. I'm guessing you've never worked on a project with a "non-native" developer. It's like saying that someone whose native language is Chinese can write a novel in English b/c "It's just words. How can the choice of language affect your ability to write a novel?" Is it possible this mythical person expresses themselves in English better than you or me? Sure. It's just less likely.

Most LOB apps are geared at data entry/retrieval. They don't need to scale, they don't need to win design awards. These are not geared towards consumers who have a choice, they are geared to employees who don't. They will be just as awesome as LOB apps have been for the past 20 years. No one cares if you don't like that it was developed on a PC. They only care that it solves a business problem efficiently enough to give them an advantage over their competition.

I would have loved to see the Visual Studio support in the $300 version, but it is worth pointing out that you've got to pay for Visual Studio too, since the free versions aren't extensible by third parties either.

Except that the full versions are freely available for BizSpark and DreamSpark users.

Finally comes to Visual Studio? I think Embarcadero Delphi Prism XE allow iOS development inside VS Shell. And if that didn't suit you, you could carry the projects into MonoDevelop which runs on Windows or Mac.

iOS, with its Objective-C development, and Android, with its Java/C/C++ development, are wildly different platforms. This poses a great challenge for developers who want to share the core logic of their applications between apps. There are essentially only two solutions to this conundrum. The first is using HTML and JavaScript (using software such as PhoneGap, or the Web). The second is Xamarin.

You forgot C/C++. Both iOS and Android can execute that natively without any third party tools.

And I wonder if GNUStep could be ported to android? It only took me a few hours to get my (very simple) iOS app to build/run on Linux Mint in Gnome.

Frankly I don't see the point. Objective-C is a good language and Objective-C 2.0 is a great one. I've never used C# but it doesn't look any better than Obj-C.

I've never seen anyone who actually knows objective-c say it's a bad language, and it is easy to learn as long as you uderstand how computers actually work.

Most LOB apps are geared at data entry/retrieval. They don't need to scale, they don't need to win design awards. These are not geared towards consumers who have a choice, they are geared to employees who don't. They will be just as awesome as LOB apps have been for the past 20 years. No one cares if you don't like that it was developed on a PC. They only care that it solves a business problem efficiently enough to give them an advantage over their competition.

You're making my point. "We don't care about quality or aesthetics, just make it (mostly) work and do it cheap." is not embracing a platform.

I've used MonoDevelop a bit in the past and found it a bit clunky. There are a few workarounds for using Visual Studio to make monotouch apps that exist already, so if you're blanching at the 1k a year, you can always go down the unoofficial route.

Most LOB apps are geared at data entry/retrieval. They don't need to scale, they don't need to win design awards. These are not geared towards consumers who have a choice, they are geared to employees who don't. They will be just as awesome as LOB apps have been for the past 20 years. No one cares if you don't like that it was developed on a PC. They only care that it solves a business problem efficiently enough to give them an advantage over their competition.

You're making my point. "We don't care about quality or aesthetics, just make it (mostly) work and do it cheap." is not embracing a platform.

I wouldn't consider the ipad version of Bastion to be shoddy, and guess what that was built with?

But who cares if LOB apps aren't embracing the platform? Most of them won't be seen outside the corporation that built them.

Xcode is crap, it wouldn't surprise me people spend tons of money to escape from it. The debug watch window didn't even support arrays until a few weeks ago, you can't imagine how frustrating xcode is coming from Visual Studio where shit doesn't suck. And you don't have to update your entire toolchain everytime a new iOS release comes out. And don't get me started with Objective C and Cocoa's inadequacies. There's a reason an entire industry exists around getting .net onto the platform at any cost.

I wouldn't consider the ipad version of Bastion to be shoddy, and guess what that was built with?

Citing one example out of the hundreds of thousands proves my point. I never said it wasn't possible to produce a quality app. Just less likely.

But why is it less likely?

A shit developer will make a shit app, whatever they're using. There are thousands of crappy apps in the App store built with Objective-C.

A good developer will more likely make a good app whatever the platform.

You're also missing the number one reason why people will use this platform. Sharing of virtually all Non UI code. That's a huge win for a developer wanting to pursue a simultaneous iOS Android release strategy.

It would take me probably 2-3 weeks to become comfortable with Objective-C, and probably a lot longer to master it. If it does take me 2-3 weeks of leanring Objective-C before i can build an app, then that's $6k in wages up the swanny. Suddenly that $1k a year for the VS integration isn't looking so bad.

Could someone explain to me why this is better than existing tools such as the Corona SDK or Titanium Appcelerator, both of which allow you to develop mobile apps for multiple devices with one code base. I also believe they both compile into native code for each device (unlike phonegap as per my understanding). (Other than the fact it can be used with Windows).

The Xamarin toolset allows you to create truly native apps on the platforms that you target. The bonus I see is that if you use 1 language, in this case C#, then you can share business logic ( assuming you follow decent enough design patterns ) across platforms (iOS, Android, Mac, Windows). Thereby ensuring you have more time to work on giving your users/customers the best user experience you can on that platform.

Hitcents, the developers behind Draw a Stickman : Epic, a game available on iOS, Android and Windows 8, claim that they shared 95% of their codebase across the 3 platforms (http://www.monogame.net/case_study_stickman) they released on, simultaneously! Sure games can be a special case, but even apps can have high code reuse. Look at Frank Krueger's post about shared code and he targets 5 platforms using C# http://praeclarum.org/ .

Personally I'd rather spend time writing new app/games than learning a different language for each platform I want to target. I'm weird that way .

This for sure. LINQ is sweet delicious nectar from the gods. Ok, maybe I'm overstating it a bit, but I do love me some LINQ.

Also, this seems like an excellent option for LOB app development. There are substantial numbers of in-house development teams using Visual Studio and .Net. This solution would be ideal for leveraging existing tools and skillsets. It also allows those teams to continue to meet business needs without having to ramp up and support multiple platforms, especially with the increasing popularity of the whole "bring your own device" trend.

iOS, with its Objective-C development, and Android, with its Java/C/C++ development, are wildly different platforms. This poses a great challenge for developers who want to share the core logic of their applications between apps. There are essentially only two solutions to this conundrum. The first is using HTML and JavaScript (using software such as PhoneGap, or the Web). The second is Xamarin.

You forgot C/C++. Both iOS and Android can execute that natively without any third party tools.

And I wonder if GNUStep could be ported to android? It only took me a few hours to get my (very simple) iOS app to build/run on Linux Mint in Gnome.

Frankly I don't see the point. Objective-C is a good language and Objective-C 2.0 is a great one. I've never used C# but it doesn't look any better than Obj-C.

I've never seen anyone who actually knows objective-c say it's a bad language, and it is easy to learn as long as you uderstand how computers actually work.

I know objective C. It is a bad language, riddled with bizarre keywords and terrible memory management (as well as being absurdly slow) - there is a reason NOBODY else uses it. After 20 years deving AAA games I also know how computers actually work Not trying to start a lang war, but your comment is pretty patronising.

I must confess I got excited about this before I saw it was Mono only - being able to dev all versions inside VS would have been heaven...