Is Xamarin as ideal as it looks like?

Since there are many cross-platform options available on market, it is quite hard to choose the right one for a project. Xamarin sounds like a good option because it is backed by a large company, supports not only mobile platforms but desktop too, is regularly updated and supports nearly everything from native. From our experience, sadly, it’s not as ideal as it looks…

Installation

Xamarin is integrated into Visual Studio. It’s a pretty huge IDE and so long the installation takes. Only the Xamarin package can easily take over 40 GB from your free space. If a machine where Xamarin is installed is used also for native Android development, it’s pretty useful to provide Android SDKs’ path to Xamarin so they won’t be downloaded and installed twice because it can easily take another 30 GB.

Updates

Often and regular updates should be an advantage but almost every Xamarin update results into failed build. Official solutions don’t exist so the only source of information is community on online forums. It’s hard to stay up-to-date when you need to allocate 1 MD after every update to fix the project.

Layouts

Xamarin provides UI Designer but we were never able to make it work. Another option, code representation of layouts — XAML is already used by Visual Studio for example in C# desktop applications. IntelliSense is very nice Visual Studio’s feature providing information about available parameters, components and code completion. Some people were able to make it work with Xamarin but we weren’t. The result was writing a code without any suggestions so we had to look into documentation or remember everything. Another problem is that Xamarin is missing a lot of options provided by view groups or constraints so the only option is to use very ugly hacks to accomplish what designers want.

3rd party

Packages can be installed with NuGet Package Manager integrated into Visual Studio. There are a lot of packages for Xamarin. Basically, there is a support for everything because when Xamarin was released, programmers developed a lot of external libraries to speed up a development for the others. The problem is that most of these packages were never updated so sometimes they are even 3 years old and not compatible with the latest versions of Xamarin or contain bugs. For example, the most of our problems were caused while trying to use camera. Yes, you can write your own platform specific code and make own library but with 200 hours project budget you cannot invest 150 hours into new OCR library.

Real experiences

We had all layouts completed and didn’t make any changes for a long time but one day some screens started looking different. They were missing a search bar. New Xamarin update introduced a new bug — search bar had height equal to 0 until you explicitly set it from code after page was loaded.
Once we reached a point where we had to backup only source code files, delete the whole project, create new project and move our source code into the new project because after all of the updates the project was so broken that before every build we had to clean project and only every second build succeeded.

We implemented a new feature, tested it successfully, committed, pushed and put computer into sleep. The next day project couldn’t be built but Git showed no changes.

Summary

We trusted this cross-platform technology but now we are disappointed that instead of time saved on shared code we ended up with more time used during the development than we would use on development of native independent applications because we faced problems outside the scope of our code.

For more information about our company visit our website www.touch4it.com.

Author: David