Native vs Non-Native Apps – What’s the Difference?

Working in mobile security over the last 5 years, I often get asked some variant the following questions:

1. What’s the difference between native apps and non-native apps?
2. What’s the difference between “cross-platform” mobile apps and “hybrid apps”?
3. How do cross-platform apps and hybrid apps relate to the ‘native vs non-native’ app question?
4. And finally what are Progressive Web Apps (PWA) and how do they fit into the mix?

Sooooo, if you’re not a mobile developer, this all may sound like alphabet soup to you. Well, don’t worry you’re not alone. As I said, I get these questions all the time. And tbh, it was confusing to me at first as well, (and I live and breathe mobile everyday!).

In this article, I’ll break down the differences between native, non-native, hybrid, cross-platform and progressive web apps — and explain a bit about why those differences exist.

Quick note: this is by no means intended to be a hard-core technical definitional document. Nor am I proclaiming that this is an ‘exhaustive’ list (ie: my goal is not to define all the ways that there are to make apps). Nor is this a proclamation of which is ‘better’. Quite frankly, the answer to that question is: you guessed it: it depends.

So read this blog if you want a quick and simple way to understand the basic differences between native and non-native apps.

Ok here goes!

Mobile App Development Categories — An Overview

Mobile apps can be broken into 2 top level categories (native and non-native apps). Then within the category of non-native apps, there are various sub-categories (hybrid-apps, cross-platform apps, and progressive web apps (PWAs).

First I’ll discuss the differences between native and non-native mobile apps. Then I’ll cover the various sub-categories of non-native apps, including some details on the frameworks used to build them.

What makes an app ‘native’ anyway?

Native mobile apps are built entirely in technologies that are specifically designed to leverage proprietary mobile OS and hardware functions of the 2 mobile operating system vendors — (Apple/iOS & Google/Android) — without requiring additional layers to bridge gaps. Specifically, the libraries used in native apps are designed to directly access all of the classes, objects, functions, methods, etc of the source code (and the programming languages underlying the code).

NATIVE Android apps written in either Java or Kotlin. The libraries used in these apps can access all of the bespoke functionality built into the Android operating system, as well as the various hardware/firmware variants and chip architectures of the Android ecosystem.

Similarly, NATIVE iOS apps are written in either the Swift or Objective C programming languages, and they contain libraries that can access and take advantage of the OS functions, controls, hardware etc built by Apple.

Non-native mobile apps are written in higher-level programming languages / frameworks (e.g. JavaScript, CSS, HTML5, Python, .net, etc) and cannot directly access all of the proprietary operating system functions and hardware components — they require an additional layer/framework in between in order to make use of all the bespoke OS controls specifically built and designed by Google and Apple for the Android and iOS ecosystems respectively.

Another major difference between native and non-native apps is the manner in which they are built and compiled:

Native apps are compiled to run directly on the application. When you compile native mobile apps, the source code (human-readable) is actually converted into binary code (machine-readable) and it executes from there.

With non-native apps, the source code is not compiled directly into binary code. Instead, the source code is saved inside the application itself. When the app initializes, it reads the code from the saved source code files, and runs the code from there. (side note: This means that all of the code is available to anyone with the application file in hand (it’s not encrypted or obfuscated by default). You can learn more about securing non-native apps without coding in a separate post.

Generally, what makes an app ‘native’ relates to the fact that all the languages, development tools, frameworks, etc were explicitly designed to work together; differently stated, all the components inside native apps can directly access the functionality that Apple and Google make available through their respective platforms by using the native programming languages to build applications (again Swift/Objective C for iOS and Kotlin/Java for Android. It’s also worth nothing that Android apps often include C and/or C++ code for native libraries).

Non-Native App Types — Hybrid, Cross-platform, Progressive Web Apps (PWA)

Now that we covered the differences between native and non-native apps, I’ll focus on non-native apps and break them down further into sub-categories.

What are the different types of non-native mobile apps?

Among non-native apps, there are several different variants: Hybrid, Cross-Platform, and Progressive Web Apps (PWAs). I’ll cover the differences between each non-native variant below:

Hybrid Apps (aka Hybrid Web Apps) 

Hybrid apps are developed using common web development technologies like JavaScript, CSS, and HTML5. Structurally, hybrid apps are built as web apps, and then packaged inside a native container or shell for distribution. Ionic and Apache Cordova are popular ‘hybrid’ app development frameworks. Hybrid apps are appealing because they use a shared code-base to reach multiple platforms. They are also easier to build because of the abundance of pre-packaged libraries and pre-assembled components that developers can assemble (rather than line-by-line hand coding). Hybrid apps also allow enterprises to tap into a larger pool of resources due to the larger number of developers conversant in web technologies than there are for the more specialized native frameworks.

Cross-platform apps

Cross-platform apps, such as apps built using Maui, Xamarin , React Native and Flutter are also written in a common programming language, and then compiled to run on both iOS and Android platforms, sharing the same code base. For example, Maui, Xamarin apps are written in C# (‘C Sharp’) programming language and leverage native Android and iOS user controls and OS functions which enable user experiences and performance characteristics closer to those of native iOS/Android apps (That’s the main thing that differentiates Maui, Xamarin apps from their hybrid app counterparts). And though some may argue that Maui, Xamarin apps are truly native, they are not, but it’s fair to state that they are ‘native-ish’.

What are Progressive Web Apps (PWAs)?

Progressive Web Apps (PWA) are the newest kid on the mobile development framework block. PWAs, like their hybrid-app ancestors, leverage common web technologies like HTML5, CSS and JavaScript and they can also run cross-platform (on both iOS and Android devices). PWAs generally offer a broader set of native OS controls and richer user experiences because they address several major functional gaps that were missing in traditional hybrid apps, such as push notifications, offline access and data synchronization. This enables richer mobile experiences and results in a user experience that is much more like true native apps. PWAs also have more packaging flexibility than native apps and don’t require centralized distribution through public app stores, which many organizations and developers find useful and flexible. And you can use a no-code platform like Appdome to build and secure a new PWA from scratch in a few minutes that will run on any Android or iOS device or cross-platform — all without writing any code.

That’s it for today. I hope you found this article useful. If you’d like to see more on this topic, please let me know in the comments or by sharing the article.

Cheers!

Alan