Xamarin Native vs Xamarin Forms

Choosing the right tool for the job is always a tricky task. There are so many things to take into consideration. The saying “choosing is losing” is certainly applicable here. Every choice has its pro’s and con’s, and as a colleague said: “you will always be looking for the one thing that’s harder to do in the choice you made”. All it boils down to is making a choice, and sticking to it for a while. Since development lifecycles go so fast, expecially open-source, there might even be a better choice by tomorrow. This can create something we all know as “developers block”, not being able to deliver a single thing. And you will drive yourself crazy over all the options. Same goes for the choice between Xamarin or other platforms, and even for choices within the Xamarin platform itself. In this case the choice between Xamarin Native vs Xamarin Forms.

At my current employer every team member has a solid .Net background, so the choice for Xamarin is something that came naturally. React Native was considered for a while, but the Javascript knowledge wasn’t as solid for everyone. Now I had to make a choice between Xamarin Forms and Xamarin Native for our daily development tasks. Our mission is to be “quick and efficient”, so while the looks of an app are still important they are not the main factor to consider. We also wanted to use the MVVM architecture (Model – View – ViewModel) in most of our apps. So that had be taken into consideration as well.

According to Xamarin you should consider 20% of your application to be shared code with Xamarin Native, while that becomes 80% shared code with Xamarin Forms. These numbers are just a rule of thumb, so your mileage may vary.

Xamarin Native

Xamarin Native clearly has a couple of advantages for someone who has specific platform knowledge.

Reuse platform knowledge

Being able to build things as you would in the “normal way” for every platform is something that is very powerful in itself. If you have been developing apps for iOS with Swift or Objective-C for a while, it is very easy to reuse that knowledge.

However, this also leads to the fact that you need a thorough understanding of all 3 major platforms. iOS for example uses a completely different way of describing layout than Android or Windows Phone does, which has a steep learning curve to do correctly. So this is not something every developer in a team can pick up easily. Knowing everything about Intents (Android), Fragments (Android), ViewControllers (iOS), Segues (iOS) and all the other platform specific terms is very time consuming. When you haven’t touched a platform for a while, that knowledge is also pushed to the background, making it even harder.

Create pixel-perfect UI’s

Xamarin Native makes it possible to create pixel-perfect UI’s, since the UI’s are being created specifically for each platform to support. Much more sophisticated animations are possible as well. But you need to have the knowledge of all the platforms.

MVVM frameworks

If you are committed to using Xamarin Native, and you want to use MVVM you have yet another choice to make. There are many MVVM frameworks available, that all have their pro’s and con’s as well. Some of the more popular are MvvmCross (steep learning curve, but seems to be the most popular), MvvmLight (which is not on GitHub but on Codeplex, which is unfortunate), ReactiveUI or if you just want bindings there is Bind.

Xamarin Forms

For those of us who have been around long enough to see the first version of Xamarin Forms, it might have been a let-down to see what Xamarin Forms meant in the early stages. Some of us have formed an opinion about it and never reconsidered to use it again. But Xamarin made real progression lately, making it worth to reconsider once more.

Faster development

The big difference between Native and Forms is that you can define your UI once, in a language many .Net developers are familiar with from WPF: XAML. While it can be quite challenging to learn the XAML language, it can be a game changer. Writing the UI once (for the most part, more on that later), and running it on every platform, is something that can appeal to many businesses. The context switch between the platforms is much less frequent, so you can focus more on the task at hand instead of platform specific implementation details.

Platforms going their own direction

The challenge that Xamarin Forms has, is being able to make a common metaphor for all platform specific implementations. For the moment it is managed quite well. But who knows what the future will bring.

Yet another abstraction layer

Xamarin itself can be seen as an abstraction layer. But Xamarin Forms creates another abstraction layer on top of that, which can contain other unexpected bugs. When you encounter such a bug, all gains in development speed can be cancelled when trying to fix it or finding a workaround. The big problem in my opinion is that Xamarin Forms is not open source. So you have to rely on the Xamarin developers to fix the issues and work around them for the time being. I have only been in this situation once until now (where a WebView wasn’t scaled properly when the device’s orientation changed on iOS). The community and the forum can be really helpful in this case.

This abstraction layer does not prevent you to get to the platform specific code by using Renderers and Services with Dependency Injection. So you can still implement parts of your Xamarin Forms app with Native implementations.

Many plugins available

Xamarin Forms has an open-source initiative by the name of XLabs that makes it easy to implement things that aren’t supplied by Xamarin Forms itself. Think about accelerometer or camera services for example. While the Xamarin Forms Labs plugins certainly have their issues (251 open issues at the time of writing), you can help by submitting Pull Requests. It can take some time before a PR is merged, but helping the community is always good (see one of my PRs for an example).

There are also lot’s of plugins available that are not part of Xamarin Forms Labs.

MVVM

Xamarin Forms has been built to be able to use the standard ICommand’s, NotifyPropertyChanged events and so on to support MVVM out of the box. While you can still use other MVVM frameworks like MvvmCross of Prism Forms, there is no absolute need for it. Prism Forms is worth taking a look at, since it’s footprint is so small, it’s very easy to get started with.

Updated frequently

The Xamarin Forms release cycle has improved a lot over it’s lifetime. WIth the release of version 2.0 just lately, and their Sport showcase app, the potential of the platform is illustrated nicely with 93% of shared code. The release notes for the preview of Xamarin Forms 2.1 are already available as well, which shows another nice set of enhancements to the platform.

Conclusion

Both Xamarin Native and Xamarin Forms have their pro’s and con’s. For my employers needs, we have taken the plunge to use Xamarin Forms for at least a couple of months and evaluate and reconsider after we have completed a few projects using the technology. The development speed that can be achieved for internal applications where UI is less important (not unimportant!), is the big selling point for now.

When your priority is to have absolute control over how your app looks, Xamarin Forms is not for you. Or if you only need to support a single platform, you might be better off using Xamarin Native. In this case I would even reconsider the usage of Xamarin altogether.

So is Xamarin Native better than Forms or vice versa? In my opinion: no. They both have their usages and will always co-exist.