9 min read
Talk about setting high expectations. The holy trinity, nothing less!
The truth is, mobile app development is costly when you target multiple platforms, because there is no shared code. Apple requires you to code in Objective-C or Swift, Android requires you to code in Java, and WinPhone requires you to develop in .NET, often C#. Add to that the plethora of libraries each platform provides to handle maps, drawing, pictures, or GPS—a massive amount of time and knowledge is required to build a single mobile app.
Needless to say, most startups can’t afford to triple their expenses, and even established businesses can have a hard time justifying the price of entry to the mobile space.
In this article, you will learn how Xamarin Forms, in combination with MVVMCross and SkiaSharp, can be a viable way of building cross-platform mobile apps without compromising familiarity, performance, and uniqueness. The article will review these three technologies and how they can reduce development cost by allowing maximum code reuse across multiple mobile platforms.
An Important Problem
The issue of cross-platform mobile app development is real and, as such, many different solutions have emerged over the years to reduce development costs by sharing code between platforms. In the video game industry, for example, all major game engines provide a cross-platform solution, with even Unreal and Unity targeting mobile phones and tablets.
On the app front, there have been multiple attempts to lead this cross-platform market over the years. Many fell short and have been lost in the abyss, but a couple of them still survive after multiple years. Among these is Xamarin, the only .NET solution offering support for all three mobile platforms.
Native or Not, Here I Come
So there’s a war waging between different solutions and who says war means propaganda!
The war is mostly fought on the front of the big N: being native! You need to be wary of the word because it has no clear meaning. It’s the most used word in the mobile development world nowadays and it’s very trendy. Truth is that nobody agrees on what it actually means.
When selecting a cross-platform framework, all “native” options are not equal so watch out, you might be comparing apples to oranges. For some it’s about the programming language, for others it’s about being able to use the hardware features, others think it’s about the use of platform APIs/UI, and often it’s only about not being a web app.
There are arguments on every side of the debate and I’m not going to dig deeper because it’s useless. Why is it useless? Well, let me tell you a hard to swallow fact: your end users don’t care!
Yes, you read that right, only your programmers care. Your end user will never choose your app because of the underlying technology: they will choose your app because it answers their problem and gives a good experience.
So instead of fighting over the meaning of a word, let’s look at how Xamarin provides an efficient way of giving your users what they care about.
The Father, the Son, and the Holy Spirit
Before we move on, let’s just clarify the three elements that comprise our solution to the cross-platform development problem.
The Father: Xamarin
As previously mentioned, Xamarin is a .NET solution for mobile and desktop app development. It was purchased by Microsoft in 2016 but dated to around four years ago with the Mono project. Nowadays, it features three solutions: Xamarin.iOS, Xamarin.Android and Xamarin.Mac. The other platforms already handle .NET apps by default, being Microsoft solutions. In short, Xamarin offers a direct link to platform APIs in .NET. You can, therefore, use native features from a .NET app. There is also an extension module for Xamarin called Forms which provides an abstraction layer for the UI.
The Son: SkiaSharp
SkiaSharp is a .NET wrapper over Google’s Skia vector graphics library. Skia is Android, Chrome, ChromeOS and Firefox’s native rendering engine. With SkiaSharp, you can use the library in your .NET app to make it cross-platform. This means that the neat shadow that your designer says “will make your app sooooo much better” can be coded only once instead of being repeated for each target platform. Personally, I think its best feature is the ability to render SVG graphics in a way that enables you to prevent duplication of the various form factors while retaining a crisp, pixel-perfect rendering.
The Holy Spirit: MVVMCross
To keep everything well separated and loosely coupled, our sanctified solution will rely on MVVMCross. This framework implements a MVVM (Model-View-ViewModel) infrastructure so that everything can be kept independent. Without getting too technical, apps are generally split into three parts:
- The Model: A memory representation of our data
- The View: Our UI, presenting the data and actions to users
- The ViewModel: The layer that binds our Model to our View and vice-versa
In software engineering, we always strive to keep the view separate from the ViewModel so that the application logic (in the ViewModel) can be reused even if we change the visual representation. MVVMCross helps us achieve just that by handling data bindings and providing patterns and tools for platform abstraction.
What End Users Care About
Just to recap, there are different things that differentiate successful apps from bad ones. A successful app:
- Solves a real life problem
- Offers an enjoyable experience
Point number 1 obviously has nothing to do with the framework that you choose. So let’s concentrate on point number 2. There are three major aspects that contribute to the enjoyability of your app:
Familiarity relates to ease of use and quickly finding your way through the app.
In other words, it’s about using the platform’s different user interface paradigms in a system-wide coherent manner. For instance, simple things like button positions, list context actions, or navigation all contribute to the familiarity of your app.
Familiarity is the main weak point of web apps or frameworks based on a web interface. Xamarin Forms, on the other hand, provides cross-platform mappings to vendor-provided UI elements.
Your users therefore get an experience that conforms to the platform’s general look and feel so they will intuitively feel at ease in your app.
Frankly, mentioning “native” in your marketing propaganda means nothing. Take Jasonette as an example which is “native over HTTP”. The UI is stored on a web server… hello round trips and slowdowns, so we see that native cannot necessarily be presumed to imply better performance!
So with that myth out of the way, when looking at real life benchmarks, Xamarin comes out as the most well rounded solution with regards to performance. Xamarin Forms, not requiring considerably more context switches, offers comparable performance to native language apps.
My conclusion is that your implementation choices are what can slow down your app rather than Xamarin vs. native language. Other options out there are at a clear disadvantage with regard to performance.
The possibility for your designers to create a unique looking app is also very important to consider if you want to provide the best user experience possible and differentiate your app.
Many times, uniqueness implies creating custom looking controls, animations, or gestures. When it’s not readily available in Xamarin, you can use SkiaSharp (a wrapper around Google’s Skia vector graphics rendering library) and take advantage of the custom renderer concept of Xamarin Forms to get as close to the hardware as necessary, while always coding in a single language, something the other solutions are unable to offer.
What You Care for as a Business
At this point, you are most likely thinking that the choice of framework is also a business decision. Apart from factors outside the scope of this article, like human resources availability, Xamarin has a lot to offer, especially when coupled with MVVMCross. I will elaborate on four aspects that you will want to consider in your decision :
- Price and development costs
- Code reuse
- Component availability
- Support and community
Price and Development Costs
Let’s get this one out of the way. Since earlier this year, Xamarin is free for freelancers and small businesses like startups (with Visual Studio Community Edition). For larger organizations, it comes « freely » with a Visual Studio licence which you might already have. Xamarin Forms, MVVMCross, and SkiaSharp are also all free and open source to top it off!
The variety of languages used makes for more context switches and more tools to master leading to decreased efficiency. Xamarin, on the other hand, is an all-in-one solution: from Visual Studio you build, deploy and debug on all platforms.
Although it is not directly related to Xamarin, you also get a lot of features in C# that speed up development by choosing the .Net solution. Namely, you benefit from the great features in C# 4.5+ like easy multi-threading with async/await, closures, and reflection, all of which have been shown to improve efficiency.
You have likely thought about code reuse and most likely you consider all solutions to be somewhat equivalent in this regard. Sorry to say mate, but you are wrong!
The programmers among you might have wondered why on Earth I would propose the use of MVVMCross over the MVVM layer that is built into Forms? Well, here is something to consider: are you really only building mobile apps?
By isolating your app logic with MVVMCross and using the inversion of control it provides, you can reuse a maximum amount of code on mobile, but also on Windows and Mac (because Xamarin.Mac is your friend).
Not only will it save you money, it also puts forward good engineering practices which will lower your code maintenance costs.
Maybe you are not like me, but I hate reinventing the wheel. Therefore, having access to existing components that you can easily integrate in your app is crucial to speed up your time to market and often it will lower your costs at the same time.
Choosing Xamarin and MVVMCross offers you two options to choose existing components from. First, more and more components are available for Xamarin with or without Forms. Xamarin has a Component Store integrated inside Visual Studio where you can find various solutions to common app problems and other companies sell direct, so be sure to search before you start writing your own components (or consider selling these once they are built).
Second, you will want to search Nuget packages because chances are that somebody already wrote code to do what you need. Among those packages, you will find a decent list of cross-platform MVVMCross plugins which will solve common problems like e-mail, GPS, or localization.
If you’re already experienced with C#, you probably have your preferred components. Of course, you don’t want to let them go, they feel so comfortable. Rest assured, you can create C# bindings for existing components and then use them as if they we’re bundled with Xamarin, even in Forms with a bit of help from custom renderers.
Speaking of which, you might want to have a look at the Xamarin bindings Github repository before creating your own.
Support and Community
Finally, access to support and examples is a very important factor in choosing a framework. Xamarin has been around for a while, so the community is of a pretty good size today.
Looking up information on Google usually turns up a fair number of answers (tip: also try your searches for monotouch and monodroid, the ancestors of Xamarin) and Xamarin offers a lot of examples and great documentation on their website.
Moreover, since Xamarin really is just a binding over the vendor APIs, Apple and Google’s documentation is always relevant and will answer many of your questions. You can then create your own MVVMCross service to abstract the vendor APIs inside your shared code.
As for the future of Xamarin, with its acquisition last March by Microsoft, my bet is that it’s not going anywhere except forward. Since that sale, and the matching move to a free-ish model, the community has only grown, support has improved, and the product has kept improving possibly even at a faster pace!
The future looks bright for Xamarin.
Let’s Get Ready to Rumble!
I’m conscious of the fact that I may be opening a can of worms with this article. Now don’t get me wrong, there are other options out there worth considering and I invite you to do so, because my concerns may not be the same as yours.
Keep in mind that if you have a six week timeline and four months later you still don’t have an app ready, you’re not winning. That would leave two and a half months and a lot of money to train somebody in-house or to hire somebody knowledgeable. Insisting on building a “native” app at that point can be quite detrimental for the fate of your project.
Xamarin and these companion technologies provide exactly what your users care about and what you need. I hope this article will help you make a well-informed decision about the framework you may pick for your next mobile app.