Software developers have been looking for “Write once – run everywhere” technology for a long time, but we never really NEEDED it before.

In practice we’ve been able to write software based on where we expected it to be used (meaning what platform). For any server side application, we could live with the operating system best supported the development technology we selected.

Targeting desktop apps for Windows, Mac or Linux was platform specific because, for the most part, our target audiences didn’t span platforms. Business users ran Windows, creative types used a Mac, geeks ran Linux.

But “Mobile” has ruined all that.

Well, not really. The trend that has changed everything is really more subtle.

The nature of computer use has migrated from task oriented business functions to lifestyle integration. More importantly what that means is that WHO uses computing devices has changed.

The audience, which was once the functional processional, has expanded (in the way a goldfish is swallowed by a whale) to include the “consumer”.

For many, many companies that are building applications, this change represents an inversion of the market relative to the success of their software product(s).

Conventionally, one leveraged some subject matter expertise and created a product with some anticipation of how much of the potential audience might be enticed to purchasing that product.

There are some software products that will still succeed using this model. Single Player Games are the obvious example. Build a great game and sell it for a couple of dollars to as many people as possible.

Of course, even that model is declining. The emerging revenue model for games (and many other types of apps) is to offer a free version that uses some advertising or in-app sales mechanism to generate revenue. The success of this model depends on the broadest possible adoption of the application.

This is similar to the application use case that most non software companies have for their apps. It’s not about selling licenses, it’s about getting the largest possible segment of their users to engage with their app.

Think, for example, of an airline that creates an app. The app is always free. The purpose of the app is to increase customer use of their services (and therefore increase revenue) and increase customer satisfaction by allowing users to troubleshoot their own travel experience (and thereby decrease customer service costs by letting the customers solve their own problems without talking to a customer service representative.)

Since, unlike the PC market, the mobile market (phone and tablet) has no clear leader in market share. If you want to reach most of your customers on their devices you MUST reach them on both Apple and Android devices.

And, for an organization like an airline, retail operation, health care provider, etc who has a large percentage of business customers, you probably need to cater to Windows Mobile users too (yes, even at it’s current state of adoption.)

As an alternative to building the same app three times (Android, iOS, Windows Phone) there have been efforts like PhoneGap and HTML5 variants to let us write the app once and distribute to multiple targets, but they haven’t really worked very well.

First, they reduce you application to the lowest common denominator (that functionality which is common to all devices). In practice this means inevitably writing lots of code that says “if Android” do this, “if Apple” do that.

For non-trivial apps this gets ugly fast. We just can’t avoid the fact that the three different mobile platforms we need to support have real differences.

So, there is this guy Miguel de Icaza.

Miguel is not just super smart, he’s super clever.

First, he was the primary author of the GNU Midnight Commander, a text-mode file manager for Linux similar to Norton Commander, without which I may have given up on becoming a Linux user. He went on to start the GNOME project (if you’ve never heard of GNOME why are you reading my blog ?:), and became an early contributor to WINE (for running Windows binaries on Linux).

I use those three every day :)

If you’re a .NET developer you probably know that Miguel was also the founder of the Mono project to bring .NET to Open Source. (Yes, I opposed Mono while I was at Microsoft – and yes I hope Miguel has forgiven me. )

In 2011 Miguel co-founded Xamarin to solve exactly the problem I described above.

DISCLAIMER: I haven’t talked to Miguel since before he started Xamarin so my enthusiasm is entirely independent.

Xamarin has done several things that I consider very clever and, especially with the release of version 3, has a very interesting offering to solve the multi-platform mobile development problem.

First = C#. One language, all three platforms (more really, if you include Windows, Mac & Linux implementations). Even if C# is not your favorite language, yo have to concede that “C” based syntax has become relatively ubiquitous, is a public standard, and is supported and evolved by a stable corporate entity. And, Xamarin just added support for the F# languag as well.

Visual Studio Support.

You can use Xamarin Studio (a fine IDE in it’s own right) on Mac or Windows. Or you can use Xamarin Extensions for Visual Studio, which is generally considered to be the bast IDE available on any platform.

Of course, in Xamarin IDE and in Visual Studio, Xamarin gives you a user interface builder.


But then I think it really starts to get interesting.

Xamarin is not trying to solve the UN-SOLVABLE problem of trying to provide tooling that developer will use to build an application once and deliver a great application on all three platforms.

What they are doing instead is (as I see it) identifying which artifacts in our apps can be defined commonly and abstracting as many of those as possible into a single model while accepting that fact that some artifacts will always remain unique to the target platform and providing facilities to make it as easy as possible to work with those platform specifics.

Take, for example, SHARED PROJECTS.

Microsoft announced support for shared projects in Visual Studio 2013 Update 2 and Xamarin subsequently added support in Xamarin Studio. 


If you click on the above image and view the full size version you will see a graphical representation of the shared model.

Common or “SHARED” code and project specific sections for Android, iOS and Windows front ends.

What you can’t see in the image is that the IDE “just gets it” so we don’t have to play all kinds of directory games to keep shared inclusions working.

New in version 3 of Xamarin includes Xamarin.Forms.



Xamarin.Forms is cool enough on it’s own but what I find really interesting is this slide from a recent Xamarin webcast on Xamarin 3 which highlights Xamarin.Forms but, for me, serves as a graphical representation of Xamarin’s excellent strategy of moving as much developer functionality as possible into functionality that can be shared across all run-time targets WITHOUT requiring the developer to reduce the experiential quality of his or her app to the “lowest common denominator”.

You can watch the webinar mentioned above [ HERE]

And you can get the slides from the Webinar [ HERE ]

There are a couple of items the detractors point to when discussing Xamarin and I’ll take a moment to address those concerns before I conclude.

The first objection you might hear is cost. “It costs two thousand dollars per seat!!!’

This isn’t actually true. The starter version for individuals is FREE and comes with everything you need to use Xamarin Studio to develop small apps and deploy them to the various marketplaces. (But without Xamarin.Forms)

To step up to the version that can create apps of unlimited size it’s $299 per year (…. and you get Xamarin.Forms)

If you want to use Visual Studio, do in house / enterprise deployment, or use System.Data.SqlClient or Windows communication Foundation (WCF) in your app the price bumps to $999.

Only if you want “Enterprise” level support (like a one day SLA), is the price $1899.

While I am an open source fan (or fanatic) I firmly believe that some forms of software can really only be successful as commercial products.

At $299, or even $999 for Visual Studio and Advanced .NET feature support – the price is only a minor consideration for commercial development (yes, I know, X-Code and Android Studio are free and individual developers don’t like to pay for anything.)

I read a survey recently that suggested the AVERAGE cost for a company to employ a developer for one hour is $100 (which seems conservative to me.)

Therefore, to recover the cost of the Business Edition of Xamarin ($999) it only needs to save me 10 hours of labor. It seems impossible to me that ANY non-trivial application effort wouldn’t easily recover that cost. (Especially since Java & Objective-C have never been primary languages for me.)

There other objection I sometimes hear about is that Xamarin apps are “bigger” so they load slower and take longer to download.

To that I say, so what?

If there is a size difference, it’s usually no more than a couple of megabytes (referring to version 2 examples).

My iPad has a 64bit processor and 128 gig of storage. I just purchased an Android tablet for $299 and it has a quad core processor. (It came with 16 gig of RAM to which I added a 64Gig Micro-SD card).

Significant apps get downloaded once (who really cares how long it takes) and update periodically.

Those minor differences in download and start-up times (if they exist in a noticeable fashion at all) are immaterial as they pertain to real commercial applications.

I don’t think Xamarin expects to displace the use of X-Code or eclipse (etc) for EVERY developer, but if you’re building non-trivial apps and need to get to your customers on whatever devices they choose to own and use, Xamarin is really worth a look. (Especially if you haven’t looked yet at version #3).

I’ll keep you updated on my continuing evaluation.