In the quest to build mobile apps with one code base, Xamarin just might be an unexpected underdog…
I don’t think it’s any secret that I love C#. It’s easy on the eyes, allows for fast development, robust, has built-in support for asynchronous programming, and so much more. When I need to build a scalable, robust back-end, C# and .NET are my go-to.
The question now becomes “What about mobile apps”? C# is fantastic on the backend and making large improvements on web apps, but what about C# in the mobile space? You may have heard of a tool called Xamarin, which allows you to build mobile applications for Android, macOS, and iOS using C#. Xamarin was always a little bit offputting to me. It’s not as widely used as Flutter or React Native nor is it as well known. After listening to .NET Conf, a .NET Rocks podcast, and going through some videos on the Xamarin Developers YouTube channel, my interest finally peaked, and decided to try it out. While not as accessible as Flutter and React Native yet, I was thoroughly impressed with what I saw and if the Xamarin team can implement what they say they want to, it might just come up from the underdog to a front runner in the mobile world.
My initial thoughts on Xamarin were a bit confusing. There are a lot of templates to use when creating a project. You can target iOS only, macOS only, Android only, or iOS and Android using Xamarin Forms. You can also target more obscure platforms like watchOS. I chose Xamarin Forms just to develop for both iOS and Android.
Upon creating the project, I saw it actually created three new projects in my solution, one for the forms app, one for iOS, and one for Android. This was a bit jarring to me, especially coming from Flutter and React Native where there was one solution and builds for each OS targeted their own folder within the project. Soon, however, this approach became clear when I began to implement Firebase Authentication. Both projects are treated as native apps for each platform.
When I set up Firebase, there were Nuget packages that are per platform and needed to be installed only on their respective project. The authentication scheme for each was slightly different but did allow me to take advantage of a shared service layer. I created an IAuthenticationService interface that contained three definitions, Login, Logout, and IsLoggedIn. These three methods I then implemented in each solution. The nice thing with this approach is I can reuse my service layer for a web app or desktop app. Having a services project in my solution lets me define what kind of methods I need to what functionality and leave the implementation up to each platform. It also lets me have multiple implementations if need be, and just inject the IAuthenticationService where need be. It puts a lot of power in the hands of the developer.
Sharing Code and Development
After deducing why there needed to be three projects, I then got to writing code. The forms app is where the magic happens. You can add your controls and views all in this project. You can write your controls in XAML or C#, or a bit of both. I personally like writing a XAML file for the markup and a C# code behind because it reminds me of Angular and native Android. Each control also resolves itself to native control of either iOS or Android to keep a consistent platform feel should you need it. If you want full control over the structure of an app, you can create a Xamarin Forms Shell app, which lets you override the platform defaults.
The built-in Hot-Reload works really, really lovely. It quickly rebuilds and displays your changes in your emulator. It also rebuilds on the fly when you change your code-behind, something that .NET Core MVC could take a few notes on. The one thing I wish was better that is less of an issue with Xamarin but more with Visual Studio for Mac is the Preview mode was not working for me, so I did not get to test out the drag and drop functionality. However, the shared code between iOS and Android worked well, and binding your UI to your logic is very easy.
One other thing that helps speed up development in .NET is using shared projects that are either .NET 5 or .NET Standard. Xamarin, for now, only targets .NET Standard, which means I can write a project that contains my database objects and use it in my Xamarin app and a web app or wherever else I might need it. This, along with the service layer, really decreases the amount of code needed and decreases any issue of data and data types not lining up as it gets passed from client to server. Being able to access service and data access layers from all my client apps help adhere to Clean Architecture principles and keep my codebase small and reusable.
One other neat tool is that if you are developing for iOS, you are not restricted to development on a Mac, although you still need one. On your Windows machine, you can connect to your Mac from the full-blown Visual Studio and run an emulator on your Windows desktop. So if you are more comfortable developing on Windows, then Xamarin will let you do all your development on Windows.
Xamarin in its current form is very, very powerful but is by no means perfect. One of the disappointments I have, when I created my projects, is that I had to create them in Visual Studio. Currently, Xamarin is not completely integrated into .NET Core, so you can’t run your .NET Core CLI commands to create new projects for it. This means that you cannot build and run projects from text editors like Visual Studio Code. I personally love using VS Code for my development and using the CLI over full-blown IDE’s like Visual Studio and Rider, but that’s my personal preference. I also quickly realized that Xamarin projects do not target .NET Core, but rather a .NET Standard class library. During .NET Conf, the Xamarin team stated that Xamarin will not be apart of .NET 5 but will be in .NET 6, which is a long-term support release. This means that as of now, Xamarin will not be completely integrated into the new, unified .NET ecosystem.
The other drawback I see is having to generate three separate solutions that need to be edited and have their own packages installed. I understand the reasoning for it and love being able to take advantage of the extremely powerful dependency management system in C#. Having this many projects can be overwhelming however and not as intuitive as only having to work on a single codebase and have it build-out to multiple solutions.
Should you use it?
Is Xamarin right for you? As of right now, the answer is maybe. It’s not as intuitive or hot as React Native and Flutter and does have some drawbacks the team is hoping to address as .NET develops. If I had to rank it on my own scale, I would put it above Flutter but under React Native. Those who are more familiar with native mobile development will probably feel more at home with Xamarin than someone who uses React Native.
As .NET continues to grow and become more powerful, I believe Xamarin will have a much wider appeal. As its kinks start being ironed out and it becomes more integrated into the .NET platform, Xamarin will start becoming a more popular choice for mobile development.
There isn’t a better time than now to pick up .NET!