Is Xamarin the future of cross-platform development ?
What is actually Xamarin?
Functional apps are usually cross-platform and in the mobile operating system market, these are currently iOS (iPhone/iPad) and Android. Although both platforms have a (nevertheless distant) relationship with their proximity to Unix, the development of cross-platform applications with the platform’s own tools is complex and, above all, not very efficient.
An elegant way to solve these problems is development platforms that allow cross-platform applications. In this way, a uniform program code can be written, which is then compiled by the development platform into native apps for the respective operating systems. One such development platform is Xamarin, a subsidiary of Microsoft since 2016.
The Xamarin development team is not unknown in the programming community. In the year 2000, the developers of a company called Ximian thought about implementing the .NET framework in Linux, which was presented by Microsoft in the same year. The result was “Mono”, which was presented as an open-source project one year later.
In 2011, the former Mono developers launched a company named Xamarin to create a cross-platform development environment in the emerging mobile operating system market. The product of the same name, introduced a year later, enabled the use of the C# programming language to develop cross-platform applications for Windows, but also for macOS. From version 2.0, which was introduced in 2013, the mobile operating systems iOS and Android were added as target platforms, so that programs for macOS, iOS, and Android could now be developed from Visual Studio.
In the meantime, the Xamarin tools have been integrated directly into Visual Studio precisely through the purchase of Microsoft and enable a highly efficient way of working when developing apps. The development effort is limited to a central program code so that program releases can also be published largely simultaneously for all corresponding operating system platforms. With the possibility of creating uniform user interfaces that are also firmly integrated into Xamarin, the user experience can also be significantly improved, because individual adaptations for individual operating systems are largely unnecessary.
There are various solutions for the cross-platform development of mobile apps. In addition to web-based approaches, which mainly live in the browser, Xamarin has also spread in the meantime.
It differs from web apps primarily in that it offers the possibility to program natively and thus promises good performance and access to the latest features of the respective platform. We worked with it for half a year and were initially very enthusiastic. Technically speaking, Xamarin works. On top of that, it is now free of charge. We had paid for it because we believed in the concept. But in the end, we decided to rebuild the project natively in Android because Xamarin has too many disadvantages. How did the decision come about? The five most important points that bothered us from a developer’s point of view are the following.
1. The labor-saving is marginal
Xamarin allows business logic to be developed only once and used on all platforms. The UI logic can and should be developed natively for each platform. The framework of each platform has been translated into C# by the Xamarin team for this purpose. The problem here is that business logic makes up a very small part of the work on mobile apps. This usually consists of requests to a REST service. These REST requests can also be developed across platforms. In principle, this works well, but here too, peculiarities of the respective platforms have to be taken into account in some places, for example by compiler directives. Especially Windows Phone was a problem. The resulting data must be displayed in the UI. This UI has to be developed separately for each platform. For standard cases, there are so-called Xamarin forms. The UI is then programmed only once and automatically converted to a native UI by the Xamarin framework according to the design guidelines of the respective platform. However, this only works for strict standard cases, for example for list display of simple texts with a simple master-detail flow. However, if a display requires a precise or creative arrangement of UI elements, this option cannot be used. Unfortunately, this is almost always the case. So we never had such a standard case and so we admittedly never got around to using the Xamarin Forms. A rough estimate is that the amount of business logic for which you save yourself the extra work is only about 20-30% in mobile apps. This percentage can be kept as low as possible by a cleverly structured REST-API. In our opinion, the additional work that results from the following points is not worth it.
2. Translated code.
The Xamarin team translates the code of the Android and iOS framework to C#. This means that they have to reprogram their updates to keep the framework up to date. Surely they use automatisms for this and so far it seems to work well. But this creates another source of errors, which in the end means additional work.
3. Smaller community.
A significant problem: Just like with the previous point, the Xamarin team has to translate not only the framework code but also all the libraries that the communities produce. Of course, this is a huge effort for Xamarin, so only the important libraries are there. A lot of them. But there are also missing some that could be used. But the Xamarin community is following up on this. If a library exists in Java, there are still possibilities to compile and integrate it semi-automatically. That means however again additional expenditure.
4. The IDE leaves much to be desired.
We had used the Xamarin plugin for Visual Studio. Visual Studio is good. When you develop for Windows. But the plugin is unfortunately not very stable and especially when comparing it with Android Studio the difference is huge. Absolutely clear: Android Studio is developed by Google especially for Android. The tooling is excellent and speeds up the work tremendously. The Xamarin plugin can’t keep up with that. What bothered us most was the layout designer. We can’t describe it any other way: It is simply bad. In the end, we designed the layouts in Android Studio and copied the result to Xamarin. That can’t be in the sense of the inventor and certainly not in the sense of the user. This was anything but satisfactory and again meant additional work (and trouble).
5. Windows phone is dead.
Microsoft has officially announced to focus on Windows Phone only on enterprise customers. Therefore it is rarely worth developing for it. So you only develop for two platforms instead of three. If Windows Phone would be a factor, Xamarin would still be worth considering. Otherwise, the benefit you can get from it would be even less.
For a cross platform mobile development solution, we would not currently use Xamarin. Maybe the future will change again. But at the moment it doesn’t look like it. we would rather go in the direction of Web Apps. They are developed once and look the same everywhere. Of course, there are disadvantages here, too, but the cost savings are in a better proportion. So the best alternative in our opinion is still native apps from the ground up.