Which mobile development technology should I select for my app?

What technology should I select for my mobile app?

Today, the OS landscape is simpler than ever but there are dozens or even hundreds of ways to reach the same goal; a working mobile app. This blog post aims to provide an overview of the available mobile development options and help with the decision-making process when starting a new project.


Native or hybrid mobile development?

There’s a great deal of confusion hovering around different types of mobile apps. One of the most persistent ones is what native really means. Some developers claim that native apps are the ones developed solely for the target platform in their native programming language (e.g. Java on Android, Swift or Objective on iOS and so on). However, the truth is not that black and white. Nowadays, there are multiple mobile development technologies that let developers use other languages which will then be compiled into native machine code at runtime or during the build process. Instead of compiling, some products also interpret code during runtime. We will go through each of the most prominent ones and compare them to other approaches.Mobile Development UX sketch

Fully native application

The best way to squeeze all the juice out of the target platform is to develop an app with native development tools and programming languages. Back in the day, this was the only viable option for serious apps making use of platform features such as push notifications, sensors and Bluetooth. The feasibility of this approach has diminished during the last few years because of the high requirements from both the developer and finance perspective.


  • Access to the underlying platform features (push notifications, sensors, Bluetooth etc.)
  • Distribution (purchases, downloads, in-app purchases) handled by app stores.
  • Native code runs the fastest. This is especially important for games and apps that rely on heavy processing, multi-threading or network communications.
  • All apps look and feel the way they’re intended to.


  • Generally, separate mobile development teams build the same app for each target platform.
  • No code reuse between platforms due to different programming languages and SDKs.
  • Requires more time and money to deliver on multiple platforms.
  • App stores can force the apps to use their own payment mechanisms and usually take a cut on each sale. This can be disruptive to existing business models.
  • App stores fully control the apps and might remove them because of slightest of infringements.


Other types of native mobile applications

Apart from the fully native applications, there are a couple of mobile development technologies that enable developers to create native applications by other means. While the end result is basically indistinguishable, the tools vary a lot.


Xamarin mobile develpment platform

Xamarin enables developers to build native apps using the C# programming language. Even though C# can’t run natively on Android or iOS, it compiles to the native machine code during build time (iOS) or runtime (Android). The language itself brings support for easy asynchronous programming, generics, lambdas, type inference and the full .NET Base Class Library etc. Xamarin makes use of Mono runtime that communicates with the native runtime on each platform.

Mobile development with Xamarin is generally done in one of two ways. The more laborious approach involves using Xamarin.Android and Xamarin.iOS, which means that the UI and platform specific functionality is written separately for each target. Another choice is to use Xamarin.Forms where almost everything, including the UI, can be shared between platforms.

Customer success story

Do you want to see what Atos Consulting has developed using Xamarin? Check out our blog post about the Zürich airport application

  • Rich ecosystem of additional tools and services (Xamarin Profiler, Xamarin Test Cloud, HockeyApp, Visual Studio Mobile Center, NuGet etc).
  • Fits well into Microsoft’s DevOps offering.
  • Provides a dedicated educational platform, Xamarin University.
  • Fully integrated into Visual Studio on Windows and Mac OS.
  • Anything the developer can do in iOS using Objective-C or Swift and Android using Java can be done in C#.
  • Using Xamarin results in a 100% native mobile app in terms of UI and code-behind.
  • Support for wearable platforms like Apple Watch.
  • Same day support for new operating system versions.
  • Enterprise support available.
  • Produces big application packages by default. This can be remedied by using Xamarin linker that removes unused code using static analysis during build time.
  • If not using Xamarin.Forms, developers still need quite deep knowledge of the target platforms.


React Native

React Native mobile development

On a high level, React Native is quite similar to Xamarin. Instead of C# it uses JavaScript and lets developers compose a mobile UI from declarative components. Even though React Native is a relatively new player on the field, it’s gaining traction quickly. This is partly due to Facebook using it on multiple apps of their own, investing in the development and attracting a large number of external contributors.

Internally React Native is almost as native as Xamarin. On Android, it uses WebKit’s JavaScript engine JavaScriptCore to JIT compile the code to native machine code. However, on iOS Apple doesn’t allow dynamic code generation so the JavaScriptCore will simply interpret the code. The UI, on the other hand, is native on all platforms, resulting in near native performance with animations, transitions and other visual tasks.

  • Minimal feedback loop (Live and Hot reloading).
  • Flexbox translated to native mobile UI’s.
  • Developers can update apps without user interaction (for example CodePush by Microsoft).
  • A fully native app can have parts built with React Native.
  • Developing with React Native results in a 100% native mobile app in terms of UI and code-behind.
  • Relatively new, breaking changes are still likely to occur before hitting version 1.0.
  • Uncertain roadmap.
  • Unclear licensing (Facebook’s Additional Grant of Patent Rights).
  • JavaScript (lack of function signature, arrays, poor exception handling, slow evolution). This is partly fixed by Flow but the foundation is still weak.
  • No enterprise support, community supported.
  • Originally created for iOS so Android support is not at the same level and might cause extra work for the developer.


Telerik NativeScript

Telerik NativeScript Development

Just like React Native, Telerik’s NativeScript solves the same problems as Xamarin but from a web developer’s perspective. As Telerik’s employee put it on StackOverflow: For NativeScript, we’re focused heavily on the web developer skill set. We want anyone that is comfortable today writing HTML/CSS/JavaScript to feel instantly at home creating native apps using NativeScript”.

NativeScript is quite similar to Xamarin in terms of how it handles code on the device. It provides a JavaScript runtime that handles all the type conversions and communication between the native runtime and the NativeScript application. On Android, the code is actually compiled to machine code during runtime. Just as with other technologies above, the UI components are native so the app looks and feels right at home on each target platform.

To sum it up, NativeScript is a mature and stable mobile development product but it hasn’t attracted as wide developer audience as Xamarin or React Native. This shows in the amount of documentation and other material available online.

  • Two-way data binding between JavaScript objects and native UI components.
  • Developers can style native controls using a subset of CSS, use Angular, TypeScript or modern JavaScript and reuse packages from NPM, CocoaPods and Gradle.
  • Mature, stable product
  • Enterprise support available.
  • Hot-reloading speeds up testing considerably.
  • NativeScript supports invoking new “unsupported” APIs with reflection.
  • A lot smaller developer community than the other products in this post.
  • Large app size and slow startup time due to JavaScript overhead.
  • There’s no HTML and DOM in NativeScript so the developers need to learn product specific controls.


Hybrid apps

Apache Cordova Logo

Hybrid applications are basically web applications wrapped inside a native binary. They run inside a WebView and communicate with the target platform’s APIs through a mediator. Apache Cordova (Adobe PhoneGap) is usually the technology of choice and is sometimes confused with other products. For example, Ionic and Framework7 are products that build on top of Cordova. They usually provide frontend SDK’s, additional services and tools.

  • Developers can update apps on the fly (for example using CodePush).
  • App containers are still native so the end users can install them on the phone and access native features like push notifications, home screen etc.
  • Junior app developers can get started with HTML5, JavaScript and CSS to create apps.
  • Almost 100% code reuse between the target platforms.
  • Hybrid mobile development frameworks usually provide a wider OS support than native frameworks. For example, Cordova supports Blackberry 10, Ubuntu, FireOS and LG webOS on top of Android, iOS and Windows platforms.
  • The apps rely on system’s web browser to work.
  • The UI is same for each platform so the apps never feel familiar to the users. Some libraries try to remedy this by rendering different controls on each platform. The problem with this is that the controls still aren’t native and we enter The Uncanny Valley where the apps look similar to the real ones but something’s is still noticeably “off”.
  • The performance is not up to par with native frameworks. Complex UI animations can be laggy due to web browser sandboxing and processing power.
  • Y Media Labs famously said: “Your customers don’t know what a hybrid mobile app is, but they don’t like it.” Even Facebook backtracked from HTML5 hybrid web app and as a result developed React Native.

While hybrid technologies have their use cases, they still generally result in a degraded user experience requiring considerable extra time spent on polishing and optimizing the app.



Mobile technology key takeaways

It’s quite clear that the native development is making a comeback and with the increased availability of mobile development technologies like Xamarin, React Native and NativeScript, the need for hybrid apps is declining.

Stay tuned for our free, definitive PDF guide on mobile development technologies. Don’t risk missing the article and subscribe to our monthly digest newsletter!

If you still have trouble deciding on which technology to use, here’s a helpful PDF flowchart that covers all the main technologies.

Which mobile development technology should I select for my app?
Article Name
Which mobile development technology should I select for my app?
Xamarin, React Native, NativeScript and the list goes on... Developing a mobile app starts with choosing the right tools, find out which technology fits your needs best.
Publisher Name
Atos Consulting CH
Publisher Logo

One thought on “Which mobile development technology should I select for my app?

  1. Pingback: Android O Developer Preview 2 - Atos Consulting CH

Leave a Reply

Your email address will not be published. Required fields are marked *