C# / .NET for Mobile Development: Worth a Second Look

Over the past few years I believe that Microsoft, and their Xamarin partners, have created a compelling, quick, stable, and rich ecosystem for native development across Android, iOS, and Windows 10. It is finally time for native app developers to double back and take a look at C# / .NET based code for their native app platform needs in iOS, Android, and Windows 10.

This shift has occurred along the following fronts:

• A settling down of Microsoft’s own native platform strategy via the Universal Windows Platform and the very real consumer level popularity of Windows 10
• Stable .NET runtimes across iOS, Android, and Windows 10 provided by Microsoft and Xamarin
• Developer tooling via Visual Studio 2015 and Xamarin Studio has reached a good usability and stability point
• Easy reuse of existing native libraries within C# via PInvoke
• C# async / await features now across all platforms
• Third party portable library support allows you to truly create one business object model which can be re-used across all .NET runtimes across all platforms
• In my experience app performance on iOS using Xamarin.iOS has been on par with the Apple-offered Swift runtime.

I am a true believer of Swift within Xcode for iOS development, but I also believe that C# / .NET / Microsoft / evil empire type stuff is totally worth a second look for mobile application development.

Many of you have probably puckered your lips in disgust, rolled your eyes in betrayal, and have already tried to click the browser back button to remove the pixels of this article from the screen as quickly as you possibly can.

I would implore you: Please, hang around, you might be surprised.

Let’s face it. Microsoft has not done the greatest job of explaining its native platform development strategy over the past 5 years. Microsoft has made these solo random treks off into the wilderness. Each time the engineers at Microsoft emerge from the dark forest it seems as if native developers for Windows have had to deal with yet another set of stories and frameworks.

It doesn’t take too much Googling to see the weird web of tech they have stumbled out of the wilderness with: Windows 8 Store + WinRT, Silverlight for Windows 8 Mobile, Windows 8.1 Store + WinRT, Windows 8.1 Mobile + WinRT, and now Universal Windows Platform across all Windows 10 variants (Store, Mobile, Xbox, HoloLens, Windows 10 IoT …).

In all honesty, the above confusion even percolates up into Microsoft’s own API documentation on MSDN.

Even worse, the above confusion hides the great cross platform C# / .NET runtime story that you could be taking advantage of today.

It has been a time of churn for Microsoft, but the one saving grace has been the general predictability of the variants of the .NET runtime that run your C# code.

Over the past 5 years there have been many variants of the .NET runtime:

• Microsoft .NET Core – Linux and Mac OS X
• Microsoft .NET Core – Universal Windows Platform
• Microsoft .NET Core – Windows 8.1 Platform – Store and Mobile
• Microsoft .NET Framework 4.6 (and older)
• Mono
  • MonoDroid
  • Xamarin.iOS

The good thing is that the underlying .NET runtime shifts have been mostly transparent to developers as they were coding in C#. The great news is that the support within each .NET runtime has been crystallizing for years. This solidification has led each of these runtimes to be more ready than you might think for most native programming tasks across Android, iOS, and Windows 10.

C# / .NET now works across all major platforms via one or another .NET runtime
or enabling technology:

• iOS via Xamarin.iOS + CocoaTouch wrappers
• Android via MonoDroid + Android wrappers
• Windows Desktop via Win32 all the way back to Windows XP
• Windows 10 Mobile, Store, Xbox, HoloLens applications via the Universal Windows Platform

Xamarin.iOS, MonoDroid, and Universal Windows Platform projects are easily managed and developed with Xamarin Studio and/or Visual Studio 2015. Xamarin Studio is well supported and often updated by Xamarin. It has become a very good tool for native application development for iOS and Android, especially on Mac OS X. Visual Studio 2015 continues to be a best of breed tool that supports UWP / Windows 10 and Android development. Xamarin really does their best to support iOS development within Visual Studio 2015, but it really isn’t 100% there yet. Many tasks in iOS development (i.e. Storyboard editing, plist editing, and other key things) are just best done via Xamarin Studio and Xcode on Mac OS X and not on Visual Studio 2015. In talking with Xamarin support it sounds like most of these Visual Studio 2015 iOS development fixes and workflows are in their future feature pipeline.

Xamarin.iOS and MonoDroid both provide ways to use existing iOS code via the Mono runtime on non-Microsoft platforms:

• On iOS via a Xamarin.iOS application you can reuse almost any CocoaTouch object exposed via a static library
• On Android via a MonoDroid based application you can reuse almost any Java object

In the future there may be a single Microsoft supported .NET Core that works across iOS, Android, Universal Windows Platform, Windows Desktop, Mac OS X, and Linux. As of this writing we are close to Microsoft realizing this vision, but not quite there yet as we still need the Mono runtime provided by Xamarin.

The Mono runtime is no slouch though. Xamarin continues to advance the Mono runtime using the open sourced .NET runtime.

In many cases the enabling technology for this per-platform binary reuse is the old school PInvoke, something many Windows developers may already be familiar with. I feel your pain if you have ever heard the terms ‘struct sequential’ or ‘pinned’ in relation to PInvoke. It’s OK, the newer PInvoke isn’t that bad. I promise.

Now that async / await has also solidified across all C# / .NET variants, you get the easiest in-language expression of async behavior this side of Javascript promises. If the current Swift open source discussions are to be believed, the Swift language won’t have in-language async expressions / behaviors until around June 2017. Your users don’t have to wait for seamless async support in their apps, and you don’t have to suffer with a kludgey Grand Central Dispatch based implementation in the midst of all that clean Swift code. You can have clean async / await today with one code base across Android, iOS, and Windows 10! Much of the async / await support is largely free via the .NET runtime you run against and the portable libraries you choose to base your code on.

In a recent experience I was on a project where we made use of a series of portable libraries to create a cross platform business object layer to access back end server data and handle OAuth based user logins. We then recycled this whole business object layer into pure native applications for iOS, Android, and Windows:

Notice that we coded an app per platform using the Xamarin wrappers provided for that platform. We did not choose to use a cross platform UI solution (i.e. Xamarin Forms). For our purposes we found Xamarin Forms too limiting and unwieldy for our specific application.

In Conclusion

I think that now is the time to go back and re-evaluate the use of C# / .NET as the core to your future native applications.

Native development has finally settled into a stable and known quantity across Windows, iOS, and Android. Yes, there are instabilities and ‘gotchas’, but the core for most tasks is now stable. For the most part any problem can be worked around fairly easily.

C# and the .NET runtime variants provide an established, polished, and speedy platform to access the full native functionality and raw speed you need across all of Windows, iOS, and Android. It is able to deliver on all of your needed user experiences across all your device types using the raw per-platform API sets that you need access to.

Next week I will dive into some specific details around issues of app performance, other language considerations and a sample catalog that we used in our solutions.