Xamarin.Forms vs Xamarin Native: What’s The Difference?

Despite the apparent desire of Apple, Samsung, Google, and Microsoft to enclose all users in their respective mono-brand walled gardens, we live in the era of multiplatform consumer tech. The joy of choice and the active competition pushing progress forward are among the many benefits of this era.

One of the downsides, though, is the need for application producers to build and maintain many identical products for various platforms. It’s often paramount to support at least two or three different ‘ecosystems’ from the get-go or risk shutting out large portions of potential audiences.

When platform coverage is crucial but it’s not possible to maintain several native applications, deploying multi-platform development frameworks is the next best thing.

There are many frameworks to pick from: React Native, Ionic, Cordova, Flutter, and many more, all with their own strengths and weaknesses. One of the most popular choices is Xamarin, in large thanks to its UI design tooling—Xamarin.Forms.

Creating a consistent, snappy and native-feeling UI is the usual sticking point for many cross-platform frameworks. In the “classic” Xamarin development, the approach is to create a single shared access to the business logic and database, and then build distinct UIs for Android and iOS in C#. This is achieved separately with Xamarin.iOS and Xamarin.Android, so no UI is actually shared.

The benefits and shortcomings of this approach are quite clear. On the one hand, you still get the benefit of a single technology stack to use for both platforms in order to produce a native UI with an absolute fidelity down to every platform-specific element and function, no corners cut.

On the other hand, the need for building every element twice (or more) can put an obvious damper on how your project progresses, especially in a business setting.

This is where Xamarin.Forms comes in.

So far, 2019 has brought major updates to Xamarin and Forms in particular. This year, Microsoft has introduced:

• Additional styling, navigation, search, and hierarchy options for Xamarin.Forms with Shell.
• Xamarin.Forms fast renderers, which improve performance through creating fewer objects, thus simplifying view tree and freeing up memory.
• Startup tracing, which effectively addresses the common lag when starting up Xamarin apps.
• Further integration capabilities for Xamarin.Forms and Xamarin Native, including significant updates to Native Forms, which allows the usage of Xamarin.Forms elements in Xamarin Native applications.
• Substantial improvements to Xamarin.Forms Messages and overall app performance.
• Numerous updates to Forms UI tools, including collection view, new content view classes, new and updated elements (search bar, switches/toggles, buttons, etc.), CarouselView, refreshView and pull-to-refresh functionality, third-party controls support, theming, and more.

In addition, many open-source Xamarin projects expand on the framework’s capabilities. For example, the Uno Platform that allows creating Xamarin apps for the web.

The choice to use the Xamarin development framework can be made through comparing it to alternatives and carefully considering in-depth reviews. Or maybe you already have an experienced in-house C#/.NET development team who swear by their technology stack.

But when is it better to use Xamarin Native, and when to stick to Forms instead? It depends on the type of app and UI you’re going for.

Xamarin.Forms will be enough for clean apps with native look and feel, with more or less standard grid/list views and animations and not too many platform-specific features. The need for minor fine-tuning can always be expected, but for most standard business apps, Forms would be a decent choice.

These are some of the features and elements easily achieved with Xamarin.Forms in order to create smooth and near-native cross-platform interfaces:

• Information display and search

• Messaging

• Items showcase, multidirectional scrolling

• Image display

• Data sectioning

• Login and signup forms

• Media playback, and so on.

Tight time and/or budgetary restrictions can also be another cue to choose Xamarin.Forms as a speedier and more easily maintained multiplatform development option.

Going for Xamarin Native will provide more flexibility and options for custom feature development. Forms is still far from the best when it comes to unique UI design or complex hardware- and platform-specific requirements.

If your primary reason for using Xamarin is less about high-level code sharing and budgeting but more about keeping the development within the C#/.NET ecosystem, Xamarin Native will likely be a better choice. The same goes for apps that are supposed to have many custom and platform-specific features.

Allegedly, Google holds big plans for Flutter; React Native has expansive new features and coverage planned, and native development is as strong as ever.

Xamarin’s next frontier is not in incremental updates either. In the grand scheme of things, the framework definitely seems to be in an interesting place.

Having many options to go about things can sometimes be disorienting, but usually having choice is good. Competition gives platforms an extra push to release more options and become better. It also gives app developers ways to find their preferred tooling and development environments.

Xamarin isn’t only a choice in itself. It also provides further choices within the framework. Its biggest strength lies in its flexibility. You can pick Forms for maximum code shareability and reusability, or, if need be, try and use Xamarin.iOS/Android for fully unique solutions that can embrace almost all specific capabilities of each platform—without ever needing to touch Objective-C, Swift, Java, or Kotlin.