Xamarin.Forms can take your Xamarin.Native skills even further, but there are times it makes more sense than others.
Xamarin.Native (Xamarin.iOS and Xamarin.Android) is a great way to achieve code re-use and make the most of your .NET skills when creating a mobile app. You can take those time and cost savings even further with Xamarin.Forms, but when should you, and why wouldn't you?
What is Xamarin?
If you are at a point where you are considering the choice between Xamarin.Native and Xamarin.Forms, then you are likely familiar with what Xamarin is. For completeness, however, let’s have a brief recap.
Xamarin is an open-source platform from Microsoft for building iOS and Android apps with C# and .NET. It began way back in 2011 with Mono for Android and MonoTouch.
Xamarin extends the .NET framework with specific libraries for iOS, macOS, Android and others.
With traditional native development, creating an app for iOS and Android would be two completely separate projects. The iOS app would likely be created in Swift from start to finish—the Android app with Java. Separate tools, languages and very different skills.
Using Xamarin, the entire app is written in C#. Business logic and backend code is fully shared and has complete access to the underlying platform.
With Xamarin.Forms, that code re-use even extends to the user interface. iOS and Android have very different approaches to user interface layout. You can, of course, still use C# for the UI but code re-use at this layer will be necessarily limited.
Xamarin.Forms, however, provides an abstraction of the underlying platforms UI components and exposes them in an easy-to-use markup language.
The combination of Xamarin.iOS, Xamarin.Android and Xamarin.Forms could get you upwards of 90% code sharing depending on the complexity of your application.
Xamarin.Forms (XF) UI
So, using Xamarin.Native you have shared backend code, a single language, an easier learning curve for .NET developers and big savings already. Then comes the UI…
Every component from this point upwards in the stack is back to being written individually for each platform. Of course, this is no worse that being in a fully native stack—at least you have a common language and development environment—but now it’s time to make that decision. How much of your pixel-perfect native UI can you sacrifice in order to achieve that goal of fully cross-platform?
Well, given the current rate of progress that the Xamarin.Forms team is making, with the help of the open-source community, it might not be as big a sacrifice as you think.
Of course, there is no single answer, but we can look at a few main use cases and weigh up some pros and cons.
Existing .NET developers?
Both Xamarin.Native and Forms have got this covered, but with XF your UI is created with an easy-to-use flavor of XAML. You might even get that old Silverlight developer on board! On the other hand, if you have a team with some solid Android and iOS experience, then Xamarin.Native could pay off and allow you to push for some really polished experiences.
Internal corporate apps?
Don’t waste time and money writing these apps more than once. XF will pay off in a big way. The apps don’t have to be ugly or unintuitive—just put some thought into to what XF can give you and work with your designers to develop within the boundaries. Trust me, fighting the framework will just cause headaches. Use the framework as intended and the results will probably surprise you.
Complex animations and UI interactions?
If your app absolutely has to have the most fluid and complex interactions available on the underlying platforms, then you may need to go Xamarin.Native. Don’t jump too soon though. Check out the many “Xamarin.Forms UI challenges” that many developers have undertaken recently. You will be surprised at what XF can do with a little ingenuity.
Check out Kym Phillpotts’ YouTube channel for some great examples of how powerful XF really is.
Limited budget or timeframe?
Mobile apps are expensive. If you need a mobile app for minimum cost, then Xamarin.Forms is probably the way to go. For an MVP or an app that uses lists and clean, consistent layouts extensively, then XF is hard to beat. Two or more platforms from one code base, including the UI, is a proposition that many businesses wouldn’t ignore.
Maintenance and updates
Why fix something in two places when you could have just done it once? With XF, your single UI will be beautifully laid out before you in XAML—fix the bug once and all your platforms are fixed.
Need to get platform specific sometimes?
Xamarin.Native might be the obvious go-to here, but don’t forget that you can drop out of the XF framework and get platform-specific whenever you want. Create your page with XF and write a couple of platform specific renderers for a control to get that detail that only iOS or Android can provide.
What about application size?
App sizes are significantly larger with the Mono and XF overhead. There are ways to mitigate this, but there’s no avoiding it completely—your Xamarin apps will be larger than equivalent native ones.
Xamarin.Forms or Xamarin.Native, as you can see, is not a particularly easy question to answer. It’s a question of balancing costs, time and polish.
For the most performant, beautiful results—if you have the skills, budget and time available (that’s a big “if”)—then go fully platform native.
Xamarin.Native will get you there too, and save you a heap of time and money by sharing a lot of code—if you have the .NET and platform skills.
Finally, working within the tighter boundaries of Xamarin.Forms gets easier with every release. If you have access to pre-built components such as Telerik UI for Xamarin, then those limitations are lifted even further. You need to carefully consider the slight performance hit and work with your design team on detail and polish of the UI, but the prospect of 90% code reuse is very hard to ignore.