Pros and cons of Xamarin Native and Xamarin Forms development — from a native viewpoint.

This year I’ve been fortunate enough to be given the opportunity of developing for both iOS and Android, using Xamarin Native and Xamarin Forms. Xamarin is a cross-platform development package, now owned by Microsoft, that uses C# and .NET. The aim of the Xamarin is to make developing for iOS and Android more streamlined and easier to maintain (it also has Windows Phone compatibility, but I’m gonna take a wild stab in the dark and say thats not why you’re here).

There are two routes you can take when looking to develop for mobile using Xamarin, all requiring the use of Visual Studio (avaialble for both OS X and Windows).

Xamarin Native

Overview

Xamarin Native development divides your Visual Studio solution into three parts (assuming you’re developing for both iOS and Android). Firstly, you have your iOS and Android projects, where you will write and edit two separate stand-alone code-bases. Xamarin has C# wrappers built for the Android and iOS SDK that you use to write the app.

The third project in your solution is what is called the Portable Class Library (PCL). Code in here is sharable and can be written using .NET frameworks. Need a network layer? Sure, write it once using .NET’s HTTPClient framework and consume the shareable models in both you’re iOS and Android projects. Need the same business logic for both platforms? Write it once and test it once in your PCL. Really magical stuff, and very easy to see the allure to this technology, especially to existing C#/.NET developers.

Pros

  • As mentioned above, shareable code. Having both platforms being able to plug into the PCL is really great, and saves a lot of time on development. Only having to write your models out once, write your networking layer out once, and write your business logic out once, is just, well, incredibly handy.
  • It just works. The native mobile SDKs have C# wrappers built around them, which 9.9 times out of 10 have been wrapped thoughtfully and logically that you can usually get started writing your project after only a couple hours dabbling in C#.
  • Performance doesn’t appear to take a hit. We ported a reasonably resource intensive Swift framework to C#, and we were getting very similar, if not identical results when benchmarking that framework.

Meh

  • Binary sizes are larger than what you’d get natively. Its never been too bad with anything I’ve worked on, so its kind of hit the backlog in terms of problems to solve, but if thats something thats of absolute importance, you might want to do some research into how to bring your binary size down whilst using Xamarin.
  • Community isn’t as great for Xamarin as it is for native development, but that isn’t a huge problem for Xamarin native development because the wrappers are so aligned with the native SDKs that you can usually solve your problem by looking in the Apple/Google docs and translating that to the C# wrappers.
  • The UI design tools included in Visual Studio aren’t the best. I usually open Xcode/Android Studio to do any UI design work as I know how they work and in my experience, they work better then the Xamarin counterparts (as you’d expect really). I think it would be great it the Xamarin team focused on making other parts of the IDE more stable, rather than building something that most developers will ignore and revert to the tried and true tools.

Cons

  • Visual Studio for Mac is not great. Its certainly serviceable, but its pretty common to have to restart a couple times a day, or to not be able to build, or to have weird, obscure error messages popping up. Updates seem to fix problems, but without fail introduce other issues. My understanding is that a lot of these problems disappear when using the Windows version of VS, given that its a much more mature product, but its definitely hit or miss on a Mac.
  • C# is pretty similar to Java, and certainly nicer than Objective-C in my opinion, but if your used to programming in Swift, I think you’ll probably find yourself disappointed with some of the things C# doesn’t have. Whilst Swift undoubtedly borrowed a lot from more functional languages — like C#- its additions are definitely missed (optionals, functions and computed variables in enums, extensions are better separated, immutable/mutable properties, custom operators, etc).

Xamarin Forms

Xamarin Forms aims to abstract the development of both platforms into its own self-contained project. The idea is that you write code once for both platforms, so you avoid touching any of the native frameworks for either platform (however, the option to write native code is there if needed). Once built, you get a native application, that uses native UI elements, and code compiled to platform specific code.

Xamarin Forms uses its own markup language in the form of XAML to build the UI of the app. If you’re coming from the Android world, you’re going to feel more at home here, but its not exactly a massive learning curve either way.

Forms works best using the Model-View-ViewModel (MVVM) architecture and as such incorporates data-bindings to manipulate and update your UI.

Pros

  • Super quick to build basic applications. The XAML notation removes some of the complexity presented in native land, and when it works, its pretty seamless.
  • MVVM is lovely. Honestly, once you go to data-binding, and the forced separation of concerns (which can sometimes get a bit muddy in MVC), its pretty hard to see any other way of programming for mobile. Its quick to pick up and feels very logical.
  • Ability to be able to drop down into native development if you have to using custom renderers and interfaces.

Meh

  • As with Xamarin Native development, app size may be concern.

Cons

  • All the above native cons come for free in Xamarin Forms.
  • The community is tiny and the content surrounding the platform online is pretty poor compared to native development, so if you encounter a problem, be prepared for the answer to not be readily available.
  • Xamarin Forms is its own development platform and should be treated as such. If you’re coming to Forms after having worked on native projects, be prepared to look at things differently. I’ve encountered lots of bugs, seemingly built into the Forms abstractions of the native components, that you wouldn’t see whilst developing for the platform natively. This can be massively frustrating.
  • If you want to do anything that goes outside the very basics of app development, be prepared to drop down into native code. I’m talking quite basic stuff too (i.e. performing events when the user has pressed the back button on an Activity/ViewController will require dropping down into native code. Adding a floating action button — a key component to Google’s Material Design arsenal — requires writing your own native code for both platforms). It makes you question how worthwhile it is to have a completely shared, abstracted codebase, when you have to keep writing native code.

Conclusion

Nothing beats native development. I don’t think it matters on the size of the project — if you have the time and the resources, go the native route and you’ll produce a better app in the long run. Also, as a disclaimer, there is no guarentee Microsoft will upkeep the Xamarin platform for as long as you need it, so you may be forced with having to perform a complete rewrite of you app if Microsoft did stop supporting it.

However…

The Xamarin Native development tools genuinely shocked me. They are pretty amazing, and if you’re undertaking a project for both iOS and Android, I’d certainly consider it a viable option. The ability to share code is a massive timesaver, and the Xamarin team obviously care about the wrappers they write.

Xamarin Forms is a harder sell in my eyes. If you’re building a basic demo app, I can see its uses, but there is a learning curve you’ll have to muster to get the app ready for viewing. For an app you want to put out to more than just a few people, I’d recommend putting your time and resources into doing one platform really well, and coming back to the other platform if its still required. There really is a lot to learn, and the ideals of having one code-base for a project haven’t been fully realised yet.