What are Native Apps

When we talk about apps, we’re really talking about native apps. Your Facebook app, your Twitter app, your Spotify app: all these apps are native. It means they are written using the native language of whatever operating system they’re made for. On iOS, this means Swift or Objective-C; on Android – Java; on Windows Phone – C#.

It also means you can download them in the app stores and the logo appears in the home screen of your mobile phone.

A native app is an app for a certain mobile device (smartphone, tablet, etc.) They’re installed directly onto the device. Users typically acquire these apps through an online store or marketplace such as The App Store or Android Apps on Google Play.

The upside is that native apps (and the reason native apps are the only way to go) offer the best user experience. They’re made for a specific device, so the navigation is much more intuitive.

Native apps can make full use of the users device and thanks to that is has extra features, like push messages, gps, access to images etc. That’s why native apps are the best performing channel within m-commerce.

In the past, building native apps for iOS and Android would run you at least $50,000 (25.000 per operating system.

Nowadays you can use an easy and code-free App Building Platform like JMango360 to design and manage your native iOS & Android app for as little as a few hundred dollars. To find out how, check out our article on no-code app builders here.

What is a Web App?

A web app is the “next step up” from mobile web-sites and can be useful to even replace your mobile website in the future. It’s an app that can be accessed from mobile browsers, which gives it a unique advantage.

For starters, web apps can be accessed from any operating system. This means you only have to write code and publish the app once, which saves time and money.

Then there’s the fact that web apps don’t require users to download them. Anyone can open a web app – like this version of Facebook – and start using it instantly.

If you’re a stickler for detail, you might say that web apps are more websitethan app. From a user’s point of view, they’re accessed using the exact same software as a mobile website. Moreover, web apps lack all the features that truly define (native) apps – for example:

  • Push notifications
  • Working in offline mode
  • Limited advanced features (e.g. no haptic feedback on iOS devices)

There’s also a different kind of web app: the progressive app. These are web-based apps that have a lot more functionality. Specifically, progressive web apps (PWAs) can:

  • Send push messages
  • Use touch gestures and your phone’s accelerometer
  • Use your phone’s camera, microphone and haptic/vibration hardware

But, before you get excited…. there is a huge disadvantage using progressive apps: they can only be used for Chrome. This means only Android users are able to use progressive apps. And iOS users being the biggest buyers, it’s not the best option if you want all your users to get a good experience and improve your conversion rate and revenue at the same time.

What is a Hybrid App?

This solution is a blend, hence the name hybrid, of both native and web solutions. Where the core of the application is written using web technologies (HTML, CSS, and JavaScript), which are then encapsulated within a native application. Through the use of plugins, these applications can have full access to the mobile device’s features. To better understand this approach, let’s break down how it all fits together.

The heart of a hybrid-mobile application is still just an application that is written with HTML, CSS, and JavaScript. However, instead of the app being shown within the user’s browser, it is run from within a native application and its own embedded browser, which is essentially invisible to the user. For example, an iOS application would use the WKWebView to display our application, while on Android it would use the WebView element to do the same function.

This code is then embedded into a native application wrapper using a solution like Apache Cordova (also known as PhoneGap) or Ionic’s Capacitor. These solutions create a native shell application that is just the platform’s webview component in which it will load your web application. This gives you the ability to create and publish true native applications that can be submitted to each of the platform’s app stores for sale.

Additionally, both Cordova and Capacitor have a plugin system that allows you to extend beyond the limitations of the ‘browser’ and access the full suite of capabilities of a user’s mobile device. So, if you wanted to use TouchID on an iOS device as a login option, or wanted to connect to a Bluetooth device, this can be easily done by installing a plugin. These plugins are created by a wide range of developers and many are actively supported. Ionic even offers a complete ecosystem of supported plugins as part of its Enterprise Engine solution. So, the limitations of a web-only application are easily overcome, allowing your application to have parity with native applications in their features.

However, there are some drawbacks with this option. Similarly to the web-only application solution, the UI library has to be recreated. Here is where solutions like Ionic, NativeScript, Xamarin, React Native, and others step in. These options all provide robust UI components that look and feel like their native counterparts, giving you a full suite of building blocks for your application.

The only other consideration to take into account is if your application is still running within the device’s native browser. If so, you may encounter performance issues or other quirks specific to each platform or operating version.

A hybrid app is a compromise between native and web apps. It consists of 2 parts:

  1. Back-end code built using web app-friendly languages like HTML, CSS and Javascript.
  2. A native, downloadable “shell” that loads the code up using Webview (a simple browser).

So essentially, a hybrid app is really a web app loaded inside of a native app. It can improve user experiences a little, and even create the illusion of a native app (in some cases).

In the end, though, hybrid apps are really web apps. The bulk of the code is the same for all devices; advanced functionality is still limited; the checkout is still complex and therefore the cart abandonment rate is high; you still need to be online to do anything.

The big difference is that hybrid apps are downloadable. This means they’re a fairly accurate facsimile of native apps, which makes them handy for pilot projects and minimum viable projects.

Outside of that, there’s no reason to get a hybrid app. If you’re going to shell out money anyway, you may as well pay a little extra and go native.

Now that you know about all 3 app types, let’s finish with an important question: when should you use each kind of app?

  • Well, native apps offer the best user experiences, simplified checkout, more features and the highest conversion and retention rates. They should always be your primary choice if you want improve your mobile experience and results.
  • Web apps are less than ideal – but they’re still better than mobile websites. Since some users will inevitably go to your URL from their mobile devices, a web app is a good auxiliary channel to have in addition to a native app. Progressive web apps can only be opened in Chrome, which means only Android users have access to these type of apps. Knowing that iOS users are the biggest spenders, it’s not an ideal solution if you want to improve your mobile commerce results.
  • Hybrid apps are useful when you need to test out a new idea, so it’s more suitable for other businesses (like Games) than eCommerce. Other than that, we advise against them.