With the rise in popularity of frameworks like React Native this year, things got a little more complicated in the mobile development space. The terms ‘native’ and ‘hybrid’ no longer adequately distinguish the options available to mobile developers, which can be confusing for non-technical folk.

Back in 2010, working in an iOS and Android development team, I experimented with building hybrid frameworks using JQTouch and Sencha Touch at their core. The apps produced with these frameworks/themes showed significant performance and quality issues when compared to natively developed apps of the same era. Back then there was a plain and obvious dividing line between native and hybrid solutions.

  • Native = Objective C (language) + XCode (tool)
  • Hybrid = Web/HTML5 app ‘wrapped’ in a native shell.

There was also an obvious reason for choosing one over the other – if you wanted quality and had both the time and money, go native. If you didn’t have the time and/or money, but still wanted an app in the store, a hybrid solution would get you there. The promise of ‘crossplatform-ness’ from the hybrid platforms at the time didn’t really pan out, with the solutions feeling like an impostor on both platforms. Possibly the most damning indictment of hybrid is in the following quote…

“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native… It just wasn’t ready.” – Mark Zuckerberg at TechCrunch Disrupt in 2012.

Now years later, the landscape is shifting somewhat and there is a wider gamut of tools available to build app store ready apps. These different approaches to development can be categorised as…

  • Native
  • Hybrid frameworks
  • “Javascript” Native frameworks
  • “Compiles to Native” frameworks

Let’s take a closer look at the differences, pro, cons and best use cases for these frameworks.

I’ve specifically made the distinction between what I call ‘UI-land’, and ‘Code-land’…


  • What matters most to the consumer or user,
  • what does it look like, and
  • how does it perform.


  • What do developers need to think about, and
  • how project plans are impacted.


This is what we would consider to be standard mobile development – or ‘vanilla’ development – using Swift or Objective C on iOS, and Java on Android.

Skills Required:

  • Swift or Objective-C on iOS.
  • Java on Android (although Kotlin is becoming popular).
  • The native dev tools – XCode for iOS and Android Studio for Android.


  • Potential to achieve the highest standard of app quality.
  • 0-day access to new features.
  • Both iOS and Android have vibrant communities of 3rd-party library development.
  • Support from the official platform owners – Apple and Google.


  • Cost.
  • Expertise is in shorter supply.
  • Skills required differ greatly between iOS and Android.

When to use:

  • You have a well-defined product.
  • You want to deliver premium “AAA” apps.
  • If you’re targeting a single platform.

Hybrid frameworks

The ‘web’ hybrid model hasn’t changed drastically over the years. The app consists of a trivial native wrapper, typically shipped as an example with the framework of choice.

Some of the main benefits in using a hybrid framework over just building a web page is that the app can be uploaded to the app store, and the HTML5 app can gain access to native-only functionality and hardware: camera, contacts, calendar, push notifications, etc.

In this configuration, the native platform is bypassed almost entirely when rendering the UI. While most hybrid platforms attempt to ‘fool’ the user into thinking the app is native, only the least discerning consumers would confuse a hybrid app with a native one.

Example Frameworks:

(Not exactly comparing like for like here, as one would typically search for Cordova which also happens to be the English translation for a large Argentinian city.)

Skills Required

  • Web dev skills.
  • Knowledge of one of the Hybrid frameworks.
  • Some iOS and Android developer tool knowledge is useful for shipping apps, and debugging when things go wrong.


  • Leverage an existing responsive mobile site.
  • Javascript developers can build these apps with little help.


  • ‘Uncanny valley’ style experience for users. The app doesn’t ‘feel’ right. Ionic for example “… emulates native app UI guidelines”.
  • Limited by the speed and capabilities of the in app web-browser.

When to use:

  • Project has a tight budget.
  • Quality and polish are not major factors.
  • Lack of competition, ie. limited or no alternative apps. You see this happens a lot with government agency apps, music festival apps etc.

Javascript Native

Perhaps the ‘hottest’ of the bunch at the moment is Javascript Native, championed by Facebook’s popular ‘React Native’ framework.

It’s easy to fall into the trap of confusing React Native as a Hybrid solution, but as you can see in the above image, in UI-land users are treated to a native look and feel. Unlike Hybrid solutions, there is no browser in sight. Instead, the logic of the app is executed in the Native platform’s ‘Javascript Engine’, which hooks into the native UI via a ‘bridge’. It’s interesting to note that the owners of these frameworks would vehemently deny that they use a Hybrid approach. This may be because of the perceived lack in quality and performance associated with Hybrid.

Example Frameworks:

Skills Required:

  • Javascript.
  • Knowledge of iOS and Android platforms is really beneficial (required in some cases) – more so than the with the Hybrid.


  • It’s Javascript, yay! 🙂
  • Leverage existing Javascript talent.
  • You can still choose to use standard Native when you need it.
  • This interoperability makes it easy to introduce into an existing project.
  • Potential to re-use up to 70% of app logic between iOS and Android.


  • It’s Javascript, nay! 🙁 (You either love it or hate it).
  • While it is Javascript, there’s a bit of a context switch from the traditional web stack.
  • It is possible to run into performance bottlenecks because of the bandwidth of the ‘bridge’, causing a degradation in UI-land.
  • Some performance bottlenecks are only solvable by using native code.
  • Yet another 3rd-party dependency.
  • Smaller community of developers with open-source contributor libraries to pull into your apps.

When to use:

  • Existing in-house Javascript expertise.
  • Re-use across apps is important to you.

“Compiles to native” frameworks

The cross-platform Native ecosystem could really be considered a community of 1… Xamarin. Although Rubymotion provided some early competition, it has nowhere near the level usage or support as Xamarin.

Things are largely the same in UI-land, with users still experiencing a native look and feel. In code-land, our setup is again different to any that we’ve seen before. In this case, the foreign code (C# in the case of Xamarin) is actually ‘statically compiled’ into a binary that is Native. The platform has Native bindings, that give developers access to all of the same libraries and functions available to vanilla Native developers.

Example Frameworks:

Skills Required:

  • C# for Xamarin, Ruby for Rubymotion.
  • Knowledge of the iOS and Android platforms is really beneficial (and required in some cases) – more so than the with Hybrid solutions.


  • Xamarin essentially achieves Native performance.
  • Leverage existing C# talent if you have it.
  • Potential to re-use up to 70% of app logic between iOS and Android.


  • Rubymotion has some well advertised performance issues.
  • Technology lag. There were months between when tvOS was released to iOS developers via ‘vanilla’ channels, and when support was provided for Xamarin devs.
  • Yet another 3rd-party dependency. (Although with the sheer number of apps released, and Microsoft firmly supporting Xamarin, it’s unlikely to die anytime soon.)
  • Either the UI is created programmatically (ie. in code) or you will need to ‘tool hop’ between the native IDEs.
  • Smaller community of developers of open source contributors libraries to pull into your apps.

When to use:

  • Existing in-house C# expertise.
  • Re-use across apps is important to you.

How do the top frameworks from each category rank in Google trends?

With Phonegap (Hybrid) losing ground in recent years, Xamarin seems to have become the framework of choice for non-vanilla development. React Native has a lot of buzz at the moment and is gaining ground rapidly.

It’s worthwhile looking at these numbers in the context of the broader mobile development ecosystem. Our advice for building best of breed apps on mobile has always been to use standard Native – and the market also suggests as much. In the USA the demand for standard Native developers is still incredibly high. LinkedIn jobs suggests 9,000 open iOS positions, 9,000 open Android positions but only 400 open Xamarin positions – the ‘most’ popular of the non-vanilla frameworks.

But we’re definitely going to be checking in on these alternate development methods again in 2017.

Eoin McCarthy
App development, Frameworks, Hybrid app development, Java Script, Native app development, UX
Share to LinkedIn
© 2020 Hydric Pty Ltd
Icon/Hydric is a subsidiary of
Follow Us