mobile platform logos

Mobile apps have enjoyed staggering growth, but without a standards organization like the W3C, this growth has come with platform fragmentation. As iOS and Android continue to diverge with competitive, distinguishing features, product owners look to cut costs with hybrid or cross-platform alternatives.

Marketing terms for these cost-saving alternatives, like Hybrid, HTML5, and “real” native, can be confusing and misleading. And there are so many frameworks to choose from, such as PhoneGap, Telerik, Titanium (now part of Appcelerator Platform), Xamarin, Ionic, and React Native, that just add to the confusion.

To keep it simple, we can boil down mobile development to three primary approaches, which we’ll call:

  • Hybrid Web
  • Cross-Platform Native
  • Native

Here’s an overview of each of these approaches and their pros and cons.

Hybrid Web

Hybrid Web is based on an HTML5 website running inside a WebView. This means you can deploy a single code base to both iOS and Android.

Besides being reusable, it is web code, which means web developers can leverage existing skills. The popularity of Hybrid Web has led to a rich developer ecosystem of community solutions and 3rd party plugins. And every year, performance gets better as hardware improves.

PhoneGap (Adobe) is the best known example, handling the magic of turning what is essentially a website into a compiled mobile app. Cordova (Apache) is the open source counterpart to PhoneGap. Ionic is perhaps the strongest framework in this category. Ionic runs on top of Cordova, leverages the popular Angular.js framework, and comes with Bootstrap-like mobile UI elements.

There is a problem though. Hybrid Web, at its core, is an imitation. Within the confines of a WebView, there is no access to native objects. Custom web UI needs to be recreated to mimic their native counterparts. Touch events are buggy because all the tap, pan, long-press, and multi-touch gestures are crammed into a single WebView. The API footprint is tiny, so third party plugins are needed for even basic native software developer kit (SDK) features. With heavy module use comes managing updates, fixing regressions, and app instability. Much of the money saved when building the app is lost on the tail end in bug fixes.

Hybrid Web does not scale well. It is best suited for simple brochure apps with a minimal feature set. Circumventing the native SDK is not a good idea because it makes basic features like push notifications more difficult, and exciting features like Apple Watch integration downright impossible. But if you have to use this approach, the Ionic framework is a decent option.

Cross-Platform Native

Cross-Platform Native uses a custom API and unified language to access native UI elements such as Labels, Buttons, and Navigation Controllers. This gives you the benefit of a single code base while displaying real native UI elements on the screen. Cross-Platform Native apps are not confined to a WebView, but live in the Main Window. This approach scales much better than Hybrid Web, striking an ideal balance between cost savings and capability. It’s important to note that the UI objects are native, but the API is not.

levels of abstraction

Xamarin is well suited for .NET developers. Xamarin.Forms lets you build iOS and Android apps using a single language (C#) and an unified API. (As an exception, Xamarin Classic has a one-to-one mapping to native APIs so it’s more similar to Native. You do have to master both iOS and Android APIs, so re-use benefits are limited to language and some shared business logic).

Appcelerator Titanium is a natural fit for front-end JavaScript developers coming from Backbone or Angular. Titanium uses JavaScript along with an API layer that gives you access to both iOS and Android native objects. Facebook’s React Native uses an approach similar to Titanium, but might be easier to learn for those already familiar with the popular React web framework. However, React Native is still years behind Titanium and doesn’t even support Android yet.

Abstracting the API gives you code reuse, but you end up with a lowest common denominator app. Cross-Platform Native replaces the vast powerful native API with a custom API constrained by the partial overlap of diverging platforms. You end up avoiding UI that behaves differently between platforms. Forget about using checkboxes, segmented controls, snackbars and toasts, collection views, and other UI conventions users have come to expect.

Perhaps the greatest weakness of Cross-Platform Native is low traction. Existing web developers won’t bother learning a custom API if they can just use PhoneGap. A quick search on Dice should make a developer think twice about pursuing a career in one of these platforms. And with a smaller developer community comes fewer online solutions and modules. This introduces the risk of a project getting stuck on an obscure bug or the lack of a module for a 3rd party native SDK.

traction vs performance cost

Platform capability is proportional to the cost of development. Cross-Platform Native strikes an ideal balance, but suffers from lower market traction.

Cross-Platform mobile is best suited for captive audiences like internal enterprise business applications where platform reach is more important than user experience. It would be ideal to wait until this category matures before betting on a specific vendor. Keep an eye out for React Native to see whether Facebook can pull this off. But if you had to choose, Xamarin has slightly better traction, and Xamarin Classic still gives you full API access. Hanx writer is a good example of what you can do.


This is what people are most familiar with. Android uses Java. iPhone uses Objective-C or Swift. Native naturally has the best performance and capabilities, with full access to the vast native SDK. This allows you to take advantage of the latest features like watchOS2 for the Apple Watch, app extensions, and integrated automated UI testing.

Being native, there’s naturally a strong developer community behind each platform. Even Swift, which was announced in 2014, has already become one of the most loved developer languages. For traction, Native gets five stars.

And nothing beats native UX. By leveraging platform UX conventions, iOS users already know that the tabs are on the bottom and you can swipe to delete rows, whereas Android users expect the tabs on the top and the floating action button on the bottom right for creating a new post. Users have no tolerance for a steep learning curve. With so many apps to choose from, users will keep the one they enjoy using most and delete the rest.

Native almost becomes a pre-requisite for surviving in the App Store. Especially for consumer-based apps, poor discovery has created a hits-based ecosystem where the winner takes all. Like music, the majority of apps go unnoticed, while the same top apps dominate the charts week after week. An app really has to shine in order to get noticed. This often means building a Native app that embraces the competitive distinguishing features of each platform, and delighting the user with a great UX.

The Best Platform For You

As always, the best platform depends on your business needs.

Hybrid Web should be limited to simple brochure apps, and sometimes it’s necessary to educate product owners of PhoneGap’s limitations. Cross-Platform Native is a much better approach than Hybrid Web, and is a good fit for Enterprise applications. For everything else that has to compete in the App Store, Native is the way to go.

Like this post? Please share it with the buttons to the left! Then join our mailing list below and follow us on Twitter @thorntech for future updates.

[grwebform url=”″ css=”on” center=”off” center_margin=”200″/]