Over the last couple of years, we’ve had frequent enquiries regarding Xamarin.
Interest in the code-sharing software tool has gained traction and clients often have a good idea about what it does and why it’s used. We’ve noticed that less is known about Xamarin.Forms, so with help from our senior developer Phill, we have put together a no-gubbins guide.
Please do contact us if you have further questions about Xamarin.Forms.
What is it?
Xamarin.Forms is a sub type of Xamarin. Xamarin, often referred to as Xamarin native, is a software tool used to build mobile apps for iOS, Android and Windows.
The main benefit of Xamarin is that it allows code sharing between iOS and Android apps, but the result is always still a native app – users wouldn’t know that your app had been written in Xamarin rather than native language such as Swift for iOS and Java for Android.
How is Xamarin.Forms different to Xamarin?
The main difference between Xamarin and Xamarin.Forms is how the UI (user interface) is handled. In Xamarin, native Android and iOS UIs are coded separately, with bespoke code written to combine them.
For Xamarin.Forms, one UI is written and automatically converted into Android and iOS.
What would you use it for?
Xamarin.Forms is an excellent choice for a variety of form and data-based apps.
What are the benefits of Xamarin.Forms?
One of the main benefits of Xamarin.Forms is the code sharing across both business logic (the background code that makes it work) and UI (the code that dictates how it looks and how it’s used).
While this isn’t a primary concern to the user, or even something they would notice, it makes development, testing and maintenance simpler and therefore often has cost benefits throughout the life of the digital product.
As you will see in the next question, Xamarin.Forms does not cover every scenario, but where it does, the following simplified concept applies to the codebase management.
In this infographic, we have narrowed it down to iOS and Android to show the concept, but this also applies to Windows:
If your app is suitable for Xamarin.Forms, as well as potential cost savings for the project, your time to market could also be reduced.
What are the limitations of Xamarin.Forms?
This automatically created native UI is more geared towards data driven or form-based apps. More complicated apps are probably best served with Xamarin native - for example, apps that require functionality around bluetooth and augmented reality or an app making greater use of native features such as cameras.
A quirk of Xamarin.Forms is that in some circumstances, Xamarin.Forms will favour iOS best practice over Android.
An example is for the drop down menu. In iOS, this is presented as a spinning picker. Android uses an overlay list. Xamarin.Forms interprets the iOS is the ‘correct’ native way, as a picker. For Android, it also uses a picker, which is presented to the user as a pop-up. It still works, but isn’t the standard practice.
Does this matter? Some of this is down to strategy and personal taste. Another interesting sidebar to this is the concept of shared experience or single design philosophy, which is something Microsoft believes in. In the future, there could be no such thing as native iOS or native Android.
Can a Xamarin.Forms app be converted into a Xamarin app?
Yes – so another benefit is that you are not ‘stuck’ with the Xamarin.Forms app. If your app grows and more features are required beyond the scope of Forms, you can add to the code. It’s not wasted.
Are Xamarin developers also Xamarin.Forms developers by default?
No. The main difference is the UI, which has its own language and framework specific to Xamarin.Forms. Xamarin developers need to learn and understand this first.