Tech logos

Radically Cross Platform with Xamarin


Shared cross platform development is a concept that resonates very positively with all of us as programmers. It’s a nice outworking of the DRY principle, and seems like it would free engineers up to accomplish more.  So why is it so rare that we do it?

I recently asked myself that question while planning a personal mobile project, and here’s what I came up with:

Why Not Cross Platform?

  1. Often the project only needs to support one or two platforms, and the others don’t really justify serious effort.
    Why bother to dual-support (for example) iOS and Windows Phone, if 95% of the profits would come from iOS?  If only Mac users would be interested in your shiny gizmo app, why drag it kicking and screaming into the Windows world?  If your app lives by its own rules, it probably won’t have much of a life outside the permissive Android ecosystem.  So these are fair considerations for the publisher/developer to think about.  Budget is limited, and supporting other platforms “just because” is not a good enough reason.
  2. Cross platform dev frameworks are often awkwardly limiting and buggy.
    And sometimes they are downright ugly, because non-native.  I’m trying to think of something else insulting to add about the frameworks’ mothers, but nothing comes to mind.
    Every platform can display HTML, right?  So your typical cross platform framework or toolset will package every app into an embedded web browser along with close imitations of the UI controls re-implemented in HTML and javascript.  Accessing the advanced APIs of the underlying platform becomes something of a shaky proposition, as you’re now at the mercy of this third party toolset.  The UI is likely to be slow and ugly, because it’s HTML pretending to be something else. And when the underlying OS updates its native UI, the whole scheme is unmasked because you no longer look like the rest of the operating system.  But you probably don’t care at that point, because you’ve lowered your standards so far that you’re just happy when you can get it running without crashing.
  3. Adopting a cross platform framework often requires rewriting the application logic in a dynamic language like javascript.
    Javascript is one of the few languages that is well supported (after a fashion) on all platforms.  But who wants to code their app in javascript?
    I recognize that there are some people who are enthusiastic about dynamic languages in general, and javascript in particular.  (This includes some of my really smart colleagues whom I frequently gently rib, but would never disrespect.)  That’s great for them, but there’s a strong segment of developers who value the more strict static typing that comes along with the mainstream languages on respective platforms.
    For the above reasons, developers will often create several basically separate code bases in Objective C, Java, C#, and/or C++.

X is for… (Finally an Alternative to Xylophone!)

For the last several years I’ve had my eye on Xamarin and its push to bring the C# language and the Mono .NET replacement onto modern mobile platforms.  My personal project seemed like a good opportunity to give it a try, so I downloaded Xamarin.iOS and Xamarin.Android, dragged my shared code files into some new project containers, and started working through the compile errors.

Xamarin’s approach to cross platform GUI development is different from the above mentioned HTML+javascript toolsets.  For one thing, choosing Xamarin means conceding the point up front that it’s futile to try to create a polished GUI without using the native controls and frameworks.  What Xamarin does instead is to create bindings between the C#/Mono layer you’re programming and each of the separate native frameworks.  Want to display something on iOS?  You’ll use a UIView.  Doing the same thing on Android?  You’ll have an Activity.  But you’ll do it all in C#.  In theory, there’s nothing you can do on the native system that you can’t also do or invoke from C# with Xamarin.  I have to say that the bindings they generate are the friendliest and most elegant I have ever seen for a framework integration of this scope and magnitude, given the drastically different styles of the iOS, Android, and Windows worlds.

But importantly, this means that full cross platform GUI development remains an elusive goal for ordinary apps.  Xamarin lets you use a single language and use shared business logic libraries cross platform, but still requires that you interact with the native API to develop a custom GUI or front end for each platform.

If you really, really like programming in C# (as I kinda do) then Xamarin is an interesting choice to evaluate.  But if you hoped that it would mitigate the need to learn each native mobile platform API, then I think I’ve explained why that’s a misunderstanding.  If you aren’t familiar with developing in Objective C for iOS, then you’re probably not ready yet to do anything deep with Xamarin.iOS — and similarly with Java and Android.  You really can’t avoid the need for specific platform knowledge in each case.

If you were hoping to be delighted by groundbreaking news at this juncture, I’ll just say "sorry".

Two train platforms; two warning pylons

XNA and Xamarin’s Nifty Alternative

Getting back on a positive note, there is one genre of app that is an exception to the above rule, and which has consistently experienced really good success with cross platform GUIs.  And that is games and other highly graphical apps.  These apps already avoid using the native GUI controls of each platform in favor of their own image based buttons, sprites and effects.  They are also typically written in C++.  Now, I use C++ for mobile development when I have to, for example to implement low latency audio apps on iOS.  But I really dislike C++.  So moving right along…

For my personal project, I decided to try out Xamarin in combination with MonoGame, an open source C# reimplementation of Microsoft’s XNA game framework.  My goal was to create a game engine that I can then use to write a variety of 2D games and other graphics heavy apps.

And just for the heck of it, I went against my own professional advice I am always giving clients about 1.0 efforts, and set an ambitious initial goal for my cross platform experiment.  I wanted my game engine to run on all the major platforms from a single source code base, supporting:

  • Google Android (via MonoGame and Xamarin.Android)
  • Apple iOS (via MonoGame and Xamarin.iOS)
  • Apple OS X (via MonoGame and Xamarin.Mac)
  • Windows desktop (via Microsoft XNA and .NET)
  • Windows 8 “Metro”/RT (via a slightly messy mix of Monogame/XNA and WinRT)
  • Windows Phone 8 (via Monogame/XNA and .NET)
  • Amazon Kindle (really a simple variant of Android)

So far it’s worked out well.  I’ve tested my game engine’s runtime successfully on all the above except for OS X (just haven’t gotten around to that one yet, and hey, it probably works).

But Is it Fast Enough?

When you talk about highly graphical multimedia app or game development, performance questions quickly become paramount.  How does C#, a managed language with garbage collection, measure up for this task?

In my experience from developing my game engine, the primary setback is simply the overhead of loading the extra Mono libraries on top of the native system.  After you pass that hurdle, you can mitigate the effect of garbage collection by manually managing your own object pools, and defining all your most heavily churning objects and data as structs (value semantics) versus classes (reference semantics).  Garbage collection is no longer a benefit but a liability; however the closely related side effect that you’re compiling managed code remains a benefit in terms of additional safety checks.  (There are actually multiple important constraints to my C# programming style I had to make to optimize memory management; but the nitty gritty will have to wait for a future post.)

In particular on iOS, Xamarin has done a remarkable job of inserting their product as far as possible into the operating system as a first class citizen.  They’ve been fighting Apple for years to let them publish to the platform at all, and along the way they followed what I consider a more difficult, but ultimately rewarding path than they have for other platforms.  Xamarin actually compiles your C# code natively to ARM under Apple’s iOS development framework and doesn’t rely on any runtime JIT code generation.  And of course they couldn’t rely on JIT-ing even if they wanted to, as Apple still disallows dynamically emitting native code.  On a side note, this does put a damper on a developer’s ability to supply app updates without pushing new binaries through the approval process of the official App Store.  I got around that in my game engine, as others have, by creating my own scripting language, which I compile to a pseudo code format and run with my own interpreter.

A Good Fit

Obviously Xamarin is hoping that the industry at large will embrace their vision of writing most everything in C# on all the major platforms.  As I’ve discussed above, it’s not a magical way to get around the need for platform API knowledge, so the jury is still out on how much market share they will capture, in terms of toolsets used for general mobile development.

For my needs (multimedia intensive OpenGL/DirectX based apps) it is a perfect fit that allows me to use my favorite language in a radically cross platform project.

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more