Xamarin VS Native Apps part 2/2

 Xamarin VS Native Apps

Xamarin VS Android and iOS (iPhone and iPad) native app development. Second part is about development communities, memory management & garbage collection. 

This is the second and last part of the Xamarin VS Native Apps blog serie. If you haven’t read the first part you can read it here (link). In this blog post I’m going to compare the different development communities and languages, and touch on problems associated with memory management and garbage collection. 


Development communities / IDE’s  

I’m going to focus on the three most available standard IDEs for OS X. They have their advantages and disadvantages, but they are overall good and pretty advanced.  

  • Xamarin Studio is a little slower to build and deploy that the two others. Especially for Android the assembling time can be very long after having edited in the ressourcefiles. Also on iOS where the deployment time is done within seconds, you’ll have to get used to things taking a little longer. Xamarin Studio is a heavy program and uses a lot of resources when its running which clearly can be seen when using a laptop. There is also some overhead in connection with the editing of Storyboards, when Xamarin opens a Xcode instant to edit them. 
  • Xcode has the worst possibilities for refactoring and codegenerating. Byt they have on the contrary some really good tools for memory and CPU debugging, good simulators and other build in helping tools. Xcode has also the fastes building time of the three development communities. It includes some of the markets best tools for refactoring and codegenerating.
  • The Android emulator has at the same time gone through a tremendous performance boost, which means that its no longer dependent on third party solutions like Genymotion. 



One of the biggest advantages with Xamarin is that it is set in c# with a lot of available .NET libraries. C# is one of the most advanced languages that is very modern and includes many of the features that we as programmers are demanding. It’s also a big advantage that its possible to use the same programming language for both Android and iOS development. 

In Native iOS-development its lucky that we reasonably got Swift since the aspiration date for Objective C was long overdue. Swift is a strong and modern language, which however still feels new compared to C# which is in comparison is a more established language. But with a couple of years behind Swift I’m sure that Swift is going to be the best programming language on the market. 

Java is the primary language for Android development. But after SUN was bought by Oracle in 2010 a longer periode of decline in the development of Java has happened and they are first now gaining the lead which C# has created in the meantime. 

Illustration over memory consumption and garbage collection in Xamarin compared to native Android and iOS apps. 

 Xamarin VS Native Apps:  Memory consumption & garbage collection


Memory consumption & garbage collection

Xamarin uses Mono’s simple Generational garbage collector. That is not necessarily a bad thing since its a fine garbage collector. The problems arise when its being introduced. There are different problems for respectively Android and iOS. 



Android already has a Garbage Collector (GC); Android Runtime (ART) GC for newer Androids and Dalvik GC for older versions of Android. In both cases it means that there are two GCs in Xamarin Android apps and that causes what we call ‘the double garbage collector problem”.

GC in Android can only collect objects that no longer has an active reference. The problem is that the two GCs operate in two different words and therefore do not have the same conception of the same memory consumption. For example a bitmap can take on multiple megabytes in Android while in Mono only sees a reference of a couple of bytes. 

A situation can therefore arise where Android GC has a need for releasing memory while everything looks perfect at the Mono side. Android GC is not capable of getting rid of the heavy bitmaps since Mono haven’t released the reference for them. It can finally lead to a collapse in the Android part because of lack of memory space, and the app crushes. 

This means that we as developers has to be careful about apps with to large of a memory need. Here it’s necessary to release memory with manual explicit call to objects — Dispose() method.

Besides that its important to separate certain area forms which is custom in Java. For example, eventhandlers are very used in C# and these are very important to explicitly get deregistered again since otherwise they will hold a reference to the object in real time and thereby lead to memory leaks. All of this is a time-consuming process that is not necessary in connection with native Android development. 



Native iOS uses Automatic Reference Counting (ARC) instead of garbage collection. The primary advantage of ARC is that it is very performance-effective. Xamarin introduced above mentioned Mono GC on top of ARC which results in a lack in the perfomance together with all of the normal problems GC introduces (which is better saved for another time). 

Like Android in many cases its necessary to call .Dispose() manually since ARC cannot release resources before Mono GC has approved it. All in all a huge stepback in comparison with native iOS since one of the biggest advantages of ARCs is precisely that you do not need to release resources manually. 



Advantages with Xamarin

  • C# has many good .NET libraries. 
  • Same language in iOS and Android
  • Code recycling of up to 40%. 
  • Coding in a simple development environment (Xamarin studio) 

Disadvantages with Xamarin

  • Hard to find third party libraries, components and help online. 
  • Take longer to deploy for devices. 
  • Multiple lines of code and more complicated code. 
  • Bigger binaries given the need for Mono libraries. 
  • A little more difficult to implement views (specially on iOS). 
  • Memory consumption & garbage collection can lead to significant problems and crashes. And adds as a minimum an extra level of complexity in code. 

The conclusion is that Xamarin can only be recommended for specific types of apps. The shared coding between Android and iOS has to be big and the app has to be in some way static in relation to UI and UX. If it is expected that there are going to be many changes to UI and UX then there’s no savings in comparison to a shared code. 

This means that in my option that all in all there can only be one answer - it is not useful to use Xamarin in most app projects. If there is any savings then its minimal and it’s therefore an unnecessary risk to take for using a third party system which you don’t even have control over yourself. 


By Andreas Juul Hirszhorn

Lead iOS developer at Touchlogic