Freigeben über

Xamarin.Forms using plugins vs. Native UI

  • Artikel

One of these days, I saw a discussion around when a team should use Xamarin.Forms with plugins to access the Hardware or use the Native UI. What would be the recommended approach? What should be most efficient startegy considering not just the present but also the future. And as always the answer is : "It depends"...Let me try to lay down some of the fundamentals behind this reasoning.

First of all, let me start by saying that mind that the plug-in approach can be used with native UI apps too – in fact, it very often is.

Very few (if any) of the plug-ins are Xamarin.Forms specific; most of them can be used in any Xamarin based app so you can utilize some device-specific feature across all platforms in a platform-agnostic fashion. In that way you maximize the code sharing even if your UI itself is done through the native APIs directly.

Xamarin.Forms vs. Native UI typically came down to what type of app are you trying to build.

  1. Do you want it to look and behavior uniquely on each platform? Yes –> use Native UI
  2. Do you want to have a single UI definition that behaves the same on all platforms? Yes –> use Forms
  3. Do you want to integrate a lot of native elements into the UI which aren’t exposed by Forms? Yes –> use Native UI

However, today decision tree isn’t as black and white. As of Xamarin.Forms 2.5 you can mix native and Forms-based UI into the same app structure. So that means you can have some screens be completely native UI and some of them be shared Xamarin.Forms UI.

The addition of Effects and simpler renderers allow you to customize Forms pretty easily now where necessary. Although I’d still lean on #1 above .. if you want a dramatically different UI per platform, definitely you should follow native UI road.

If not, today I’d ask these questions instead:

  1. Is the Dev team already familiar with XAML based UI declaration and UI separation patterns? Yes –> look at Forms first
  2. Is the Dev team wanting to focus specifically on one platform first and not as concerned about cross-platform? Yes –> look at native first

Just do not forget, shifting from one approach to the other used to be complicated, often involving complete rewrites. That’s not the case anymore – you can start down one road and switch to the other if you find it necessary without a huge loss of Dev time.

Well, that's it. Hope this helps!