xamarinDifferent Options

When developing software, whether it's for a fun project or a formal business project, a requirement can be met by many different options and technologies. After a while of looking at many, it is natural to think which is the best option for the requirement.

Let us consider the options for building a mobile application.

Sometimes the best option is determined by the compatibility of the implications of the option and the technical strengths of the development team. (I’ll cover implications a little later)  The first option to consider when building a mobile application are native applications, but it immediately raises a warning – when the code for a platform is done, the code will need to be transcribed to another platform.  Second, every native technology has its own implications. So to have a successful mobile experience in all native platforms, a developer for each platform is needed. Even if there was a developer for each platform, is it worthwhile to develop a native mobile application for each platform instead of modifying a web page so it can be viewed in any device?  This is an important question to consider so here is a comparison chart for key characteristics. [av_table purpose='tabular' pricing_table_design='avia_pricing_default' pricing_hidden_cells='' caption='' responsive_styling='avia_responsive_table'] [av_row row_style='avia-heading-row'][av_cell col_style='']Characteristic[/av_cell][av_cell col_style='']Native Application[/av_cell][av_cell col_style='']Web Page[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Internet[/av_cell][av_cell col_style='']After downloading the app, it can work in offline or online mode[/av_cell][av_cell col_style='']Only works with internet connectivity[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Performance[/av_cell][av_cell col_style='']Native components are lightweight and fast[/av_cell][av_cell col_style='']Pages tend to be heavy and work somewhat slower[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Push Notifications[/av_cell][av_cell col_style='']Can send push notifications[/av_cell][av_cell col_style='']Can't send push notifications[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Hardware Access[/av_cell][av_cell col_style='']Access to camera, speaker, flash, etc.[/av_cell][av_cell col_style='']Does not have access to hardware[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Accessibility[/av_cell][av_cell col_style='']Opening the app with a click[/av_cell][av_cell col_style='']Opening browse and typing URL[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']User Experience[/av_cell][av_cell col_style='']Natural feels and smooth[/av_cell][av_cell col_style='']Unnatural and, in some cases, slow [/av_cell][/av_row] [/av_table] Based on this comparison, it appears that a native application offers a wider range for creativity and service options. If the development team handles all the implications for every platform then it might be a good idea to develop a mobile app natively for each platform, considering that native applications have the best performance and assuming the business is willing to pay a higher cost.

Let’s talk more about those “implications”.


When dealing with software frameworks and APIs, each framework works naturally with the programmer at least interacting with (in others mastering) certain technologies or programming languages. This comes naturally if the framework is an extension for another technology. For example, consider Node.js, a JavaScript runtime. When using Node.js, being a JavaScript runtime, the code will naturally be programmed in JavaScript language. Therefore, working with Node.js framework implies the programmer knows, or can at least interact with, JavaScript language. We’ll call these framework dependency implications.

Following are some implications for some mobile application frameworks.

[av_table purpose='tabular' pricing_table_design='avia_pricing_default' pricing_hidden_cells='' caption='' responsive_styling='avia_responsive_table'] [av_row row_style='avia-heading-row'][av_cell col_style='']Mobile Application Technology[/av_cell][av_cell col_style='']Implications[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Native Android Mobile App[/av_cell][av_cell col_style='']• Java[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Native iOS Mobile App[/av_cell][av_cell col_style='']• Objective-C or Swift programming language[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Xamarin[/av_cell][av_cell col_style='']• .Net (C# programming language) • Extensible Application Markup Language (XAML)[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Appcelerator[/av_cell][av_cell col_style='']• JavaScript • Titanium SDK[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Phonegap[/av_cell][av_cell col_style='']• Hypertext Markup Language (HTML) • JavaScript Language • Cascading Style Sheets (CSS) Language[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Ionic[/av_cell][av_cell col_style='']• Hypertext Markup Language (HTML) • JavaScript Language • Cascading Style Sheets (CSS) Language • AngularJS[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']React Native[/av_cell][av_cell col_style='']• Hypertext Markup Language (HTML) • JavaScript Language (ES6 Syntax) • JavaScript XML (JSX) • Document Object Model (DOM)[/av_cell][/av_row] [av_row row_style=''][av_cell col_style='']Sencha Touch[/av_cell][av_cell col_style='']• Hypertext Markup Language (HTML) • JavaScript Language • Cascading Style Sheets (CSS) Language • Sencha SDK • MVC Architecture[/av_cell][/av_row] [av_row row_style=''][av_cell col_style=''][/av_cell][av_cell col_style=''][/av_cell][/av_row] [/av_table] There is another cost that is not visible at first glance.  Even though the different platform projects have the same core and logic, ultimately they are individual projects. Each project has a different language and application lifecycle and SDKs, so each project will also need its specialized maintenance. This can all add up.  If creating the application natively appears to be too expensive or the development team does not handle all the implications, another strategy can be used. Using a cross-platform technology has become very popular as a hybrid solution for mobile development, so you can write one set of code that can be used on multiple platforms and can give the user a native experience. There are many cross-platform mobile app technologies, each with it’s own implications. The strategy is to pick technology that has an implication that the development team masters, plus another consideration. Since this is cross-platform, it is important to choose a solution that has a large percentage of transcribing code; the code that can be written once and run natively across the platforms.

xamarin developerMy Experience

When I decided I wanted to develop mobile apps, my first thought was “What native technologies do I know?”

I had used Objective-C for an iOS application.  If I wanted to make a native android or windows phone application, I’d have to learn about project structure and app lifecycle and hope I could program in the language they used. Since I only knew one native technology (iOS) I decided it was better to invest time learning a cross platform technology. I then thought “Now if I’m going to use a cross platform technology, what implications can I handle the best?”.  Xamarin was a natural choice for me, thanks to the language and application structure.  C# is one of the languages I handle the best, plus the structure was intuitive. An .xml page with its back end code, the application lifecycle was also C-like. I managed to learn XAML and the app structure and lifecycle quickly. Later, I discovered that Xamarin generated native apps that shared 95% of the common code. I also got to an acceptable level of understanding in android and iOS native applications. Then I decided to test Xamarin’s generated native projects. It seemed that the native applications were greatly structured and coded. I thought “Wow. In theory, it is possible for someone to develop a full native Android app without knowing Java or the android app structure or even having the Android Studio”. Another plus for cross-platform technologies comes from the abstraction layer.  When using Xamarin, the code handles mobile events (like Swipe) in Xamarin’s way.

I can code once and use these events without even knowing how to do it the native way.

I decided it was a good idea to take full advantage of these generated projects and tried making everything in Xamarin, because some things are not implemented on the framework. For example, Xamarin has no radio button tag for iOS applications. Instead of modifying the generated iOS application and using Apple’s radio button, I decided to implement my own radio button in Xamarin, which rendered natively in iOS. This seemed like a good choice that would become an advantage, but I also found a disadvantage, when making a minimum change on a Xamarin project, it must be recompiled to see the changes on the device. This can be time consuming if one wants to test various changes.


I decided to use Xamarin to build mobile apps because it was cross-platform. So most code would only have to be written once. And the projects generated by Xamarin were native. This is not the case on every cross-platform technology. The fact that the final projects are native is an advantage since mobile characteristics can be used. Still, I studied native projects for Android and iOS to be able to modify the generated projects if something can’t really be done on Xamarin (I realized Xamarin does not support everything for every platform). Again, this can be done because Xamarin generates native projects. In other words, I take advantage of Xamarin to reutilize code and generate fully native platforms to the extent it permits me, but I also know how to do it without Xamarin in case I really need to modify a native project. Xamarin’s implications are my strengths in programming. This is how I determined Xamarin was the best option for me when it comes to developing mobile applications. It is important to note that the best option is a balance between the technical strengths of the development team and the implications of the technology. Xamarin with native platforms background was the best option for me, but I have a C# background.  Another developer could have worked faster with Ionic if, say, the developer is a master in AngularJS.

Share this entry

We’d Love To Schedule A Time To Talk.

Provide your information to talk with a number8 Relationship Manager about your development needs today and feel what it’s like to be listened to before being sold a solution.

  • This field is for validation purposes and should be left unchanged.

We’re Everywhere

number8’s onshore office is located in Louisville, Kentucky where our Account and Relationship Managers work hard to provide all of our clients with exceptional customer service. We also have consultant offices located in Escazú, Costa Rica and San Pedro Sula, Honduras that give us a strong local presence allowing for top-level recruitment, technical training and low employee turnover.

Our Locations