Xamarin VS Native Apps part 1/2

Xamarin VS Native Apps

Xamarin app development VS Android and iOS (iPhone and iPad) native app development. First part is about recycling of code, maintenance and the development process. 

When I’m talking with clients they often ask me if its possible to develop a single codebase that’s shared between Android and iOS (and some Windows Phone). It seems ineffective for many to have to write the ‘same code’ two or three times instead of just writing a single codebase that’s shared. 

This post is going to go through the advantages and disadvantages by developing in Xamarin compared to native development for Android and iOS. We are not going to be including Xamarin Forms since that topic is better saved for a post of its own. 

Also, analyzing apps implemented in for example PhoneGap, Cordova, Appcelerator or any other platform for JavaScript and HTML5 container apps are better saved for another blogpost. Flatforms/tools like that are in my opinion pretty much never recommendable. 

 

Reusing code

Xamarin announced on their website that there are proximally about 75% recycling of code between Android and iOS in an Xamarin app project. After having used Xamarin in practice for bigger projects it seem like an overstated percentage assessment from Xamarin. Our experience shows that it’s hard just to reuse 50% and that the maximum of recycled coding is not going to be more than 40%. 

It’s primarily a servicecall, intern data management, model class or similarly that can be reused, while alt UI generally is implemented singularly for every platform. For development of UI the following applications are used: 

Xcode Interface Builder or Xamarin iOS designer, with storyboard and .xib files for iOS.

Standard XML layout files for Android.

The root classes are also implemented separately in each platform because in connection with the programming of views and viewcontrollers there are so many dependent views for the respected platforms APIs that it’s hard to reuse especially much. 

The shared codebase is in reality therefore maximum the part of the project that is not related to the UI. But since most smart phones and tablet apps are pretty view heavy the shared part is going to be less than what is going to be implemented, especially for Android and iOS. 

Xamarin VS Native Apps

 

Recycling of code in Xamarin vs Native app development seen in comparison to developing the app for a platform. 10% recycled in Native is because there is always a little saved in platform nr two because of knowledge from the first platform. 

 

Maintenance

When you have an app that has been implemented then comes the question about maintenance and updating it. A specific question in comparison to Xamarin, is whether or not the 40% can be reused in connection to maintenance. 

It depends of cause on the specific app, but our overall experience is that most apps have the larges part of changes on the UI-part. It’s rare that an app replaces the entire backend, or introduces very large changes in the internal data management (specially if the app is well thought and build from the ground up). In some cases new services are introduced, but when the overall communication is established it seems trivial to add minor changes. 

On the UI and UX front there are much more often bigger updates. Sometimes with the introduction of new features. Sometimes with completely new UI or UX paradigms that are updating graphic and new transitions or navigations with it. 

When the shared code in Xamarin projects primarily is the static part of the app it means that the possible reuse of code in the maintenance is minimal. 

 

Development process

As developers we all use the same third party libraries and components to make our everyday work easier. Android and iOS both have a long line of good open source libraries that makes almost anything possible. With Xamarin it’s not always the same. The really big libraries do have sometimes a variant of Xamarin but in most cases you’ll be looking in vain. That puts a strain on implementing features that would have been easy to implement with native development.  

Another thing that can’t be neglected as a programmer is the help you get from Google, Stackoverflow or similarly. Xamarin has an active and engaging community but there are a lot more developers for Android and iOS, which also has existed longer. My experience is that it’s a lot easier to find an answer to an advanced problem on the two native platforms.

That, overall, leads to the conclusion that coding in Xamarin is much slower that Native. It’s however deficit to put a specific procenttage on the difference since it will vary depending on the project. But it definitely minimises the earlier percentage.    

In the next blog post ‘Xamarin VS Native Apps part 2/2 I will be going through the available development communities. And we will be diving into the more advanced problems like memory consumption and garbage collection in Xamarin. In the end there will be asummary and a conclusion on the Xamarin VS Native Apps mini serie. 

By Andreas Juul Hirszhorn

Lead iOS developer at Touchlogic