Xamarin Forms : When to/not use it
1) Introduction
Making the decision about whether or not to use Xamarin in mobile development requires being aware of some key factors. This article will discuss these factors in details and try to give a magic formula to help you making the right decision.
2) What is the difference between Xamarin and Xamarin Forms
Lets make it clear here about the difference between Xamarin and Xamarin Forms. Xamarin Forms make it easy to share not only business logic code, but also UI code. This means having one shared code that will be cross-compiled to generate iOS, Android and Windows UWP apps. It uses the common user controls like Button, Label, Entry, ListView, Image, StackLayout, Calendar, ContentPage, MasterDetailPage, TabbedPage... Just tell it you want to create a Button and it will figure out how to call the native button for each platform. That is thanks to the usage of Binding Library. That allows calling Java or Swift code from C# ! With Forms, around 60–90% of the code could be shared. That means you can save up to around half the project budget/time/developers/management.
However, with Xamarin (native), only logic code could be shared, but not UI code. This latter should be created twice for Xamarin.iOS and Xamarin.Android. This is because it accesses both system API’s without passing through custom renderers.
Logic code is the code for calling web services, accessing local database, invoking hardware capabilities and managing the state of the application.
UI code is the code that creates the user interface, including pages, controls like button, labels, lists…
I assume that the amount of logic code that could be shared in average mobile applications is about 40%. For UI code, it is 40%. The rest 20% is custom UI and logic code specific for each platform.
3) Xamarin Forms vs Xamarin
Xamarin native is so powerful for creating complex and advanced UI. But only around 40% of the code could shared. And the development team have to master each platform separately. This requires more time for learning or it ends up having two teams for iOS and Android.
Forms is rather used for apps with no much constraints on the UI. This allows 80% shared (UI+Logic) code and no need neither for more time for learning neither having two teams.
4) When to use Xamarin Forms
a) Apps with minimal UI (Prototypes/MVPs/LOB/Internal apps)
This means the requirement focuses on building a functioning app more than a fancy and pixel perfect UI with advanced animations and effects. This is valid for the case of prototypes, MVPs, LOB and internal apps. These apps are not meant to be used by thousands of demanding users, instead they are used by hundreds of the company’s employees or users focusing on validating the functional aspects. Examples include delivery apps, expenses apps, internal HR apps…
This excludes core business apps. Those are the apps the company heavily depends on to make revenue. These companies must deliver the best user experience and prefer paying more than taking small risk. Examples are banking, finance or shopping apps.
b) The team’s development experience
Forms uses C#/XAML/.NET technology and Visual Studio (for Mac or Windows) as an IDE. For .NET developers, they are already in house as they’ll reuse their existing skills. If they have developed XAML based apps like WPF, Silverlight, Windows UWP or Windows Phone, then that is a good advantage. Otherwise, a small learning time should be expected to learn the mobile specific paradigms.
If the team has no experience with .NET, then it have to invest large amount of time learning it. Forms is not so interesting in this case. This team should look for IONIC or React Native if they are experienced in front web apps with JS frameworks.
Lets take the case where the development team have experience only in building native mobile apps with Java/Kotlin or Swift, and they are asked to develop a minimal UI app for both platforms. Here it becomes a trade off. In one hand they can split in two teams to develop two apps with two different languages, IDEs and platforms to finish in X time. In the other hand, they can work together as one team to ship the two apps written in one language and IDE in almost the same (X/2 + T) time. x/2 because they are one team working on one project and code base. T is the learning time. It is clear here that T is the main factor for making the decision (may be my youtube channel could help you achieving this goal).
Another case here which is there is no Xamarin developers at all or available in the team. One solution could be hiring a new Xamarin team. A truth should be known is that Xamarin developers are very rare.
5) The formula for making the decision
Decision = TeamDevExp + UiReq
TeamDevExp stands for Team development experience in .NET and Xamarin development. The value is (2) if the team have experience in Xamarin development. (1) if the team have only experience in .NET apps. (-1) if the team didn’t used .NET before. This is negative because it will need more time for training.
UiReq stands for UI required. The value is (1) if UI requirement is minimal and (-1) if complex.
Decision stands for the decision whether or not to use Xamarin Forms. If the value is positive, then decision is too. Negative means no go. Zero means this is a trade off.
5) Conclusion
Discussed above are the main two factors for making the decision of wether or not to use Xamarin Forms. But there are some other factors with no big impact (compared to those two ones) like the platform evolution, support and stability.
