Choose the right technology for your mobile app

Tags: Blog Published:

There are a number of ways to build an app. At one end of the spectrum, there’s a website that feels like an app. At the other, there’s a true ‘native’ app - the ‘native’ bit means it’s joined at the hip to the device, so the user interface (UI) of both the app and device’s operating system (OS) feel identical, and the hardware capability of the device can be fully utilised. Following on from "you need a mobile app, now what?" - this second article on mobile explores the options available.

The most popular approaches are:

Web app

1. Web App 

A mobile-first, responsive ‘website’, accessed via a URL, that performs the functions of an application, and ‘feels’ like an app, but runs in your device’s browser.

Example: Facebook or LinkedIn using your smartphone’s web browser.

Limitations: Some ‘native’ features (such as push notifications) will not work on any device. Will not be as fast or responsive. No offline support; users must be connected to load the app. Won’t be ‘discovered’ in the respective app stores.

Benefits: Greatly reduced development costs. A single code base. No app store (waiting for Apple to approve releases, logins/barriers to downloading). Users can save a shortcut icon to the home screen, prompted by a popup. Can be accessed from any web-enabled device. Supported by modern smartphones/tablets, including photo upload, GPS location, etc.

2. Progressive Web App (PWA)

A web app that progressively enhances the user experience and featureset, increasing with each device’s capability, right up to a native featureset (such as offline storage, push notifications, etc). Accessed via a URL, the device downloads an ‘app shell’ (and home screen icon), reducing data transfer and increasing performance. Browser controls disappear and the user is left with a ‘native-like’ experience, and greatly reduced friction compared to native.

Example: Financial Times ( / Twitter (best on Android/Windows, still good on iOS)

Limitations: Apple is currently developing ‘native’ support for service workers on iOS, so that user experience is not yet as good compared to Windows/Android. Won’t be ‘discovered’ in the respective app stores.

Benefits: As per #1, improved user experience and native support, with offline functionality. Good native support on Windows and Android.

Progressive web app
Hybrid app

3. Hybrid 

A web app that is ‘wrapped’ or ‘ported’ so that it can mimic a ‘native’ app and be published to the relevant app store.

Example: Many of the more niche/business/productivity apps that you might download.

Limitations: App store approvals process and delay when publishing changes. More friction in the user journey to first use. Mimicking the native UI can be labour-intensive.

Benefits: Single code base. Improved native featureset (push notifications, offline support, etc). Allows one code base to be maintained and published (separately) to the app stores. Exposure to users of the app stores.

4. Native 

An app specifically coded for each platform (iOS/Android/Windows/etc)

Example: Most mainstream native apps - eBay, Amazon, Facebook, Twitter, etc.

Limitations: Can be very costly, due to separate code bases and different programming knowledge for each OS version. Less popular OS versions (such as Windows) are often unlikely to have a user base large enough to justify the investment in a separate build. More friction in the user journey to first use.

Benefits: Improved performance, complete native support and compatibility with each device. Ideal where performance (such as gaming) or platform-specific nuances are important. Full native user interface, for a more intuitive experience. Exposure to users of the app stores.

Native app

So which type do I need (and when)?

The most prolific native apps have a web-app as a fallback - think of the ones you use most - logging in to the (Facebook/Twitter/YouTube/etc) websites using your smartphone’s browser still provides a reasonable experience.

If that fall-back is a PWA, then it will currently support important features, including some native functionality for Windows 10 and Android devices, with iOS expected in the near future.

This fall-back means that if (for example) an app isn’t available for Blackberry users, they’re not excluded, and more importantly, it provides an ‘access anywhere’ solution where users aren’t tied to using a device that has the app installed, (or being forced to temporarily download the app) just to quickly check something while borrowing someone else’s device.

So strategically, starting with a PWA before going native, makes a lot of sense as it allows you to:

  • Provide the widest support for your customer base, with forward/backward compatibility
  • Work out foibles before staking your reputation in the app stores
  • Understand user behaviour to justify investment in native features and/or versions
  • Reduce the effort and risk involved in meeting your original deadline
  • Remove much of the friction in the user journey to access your app
  • Provide an ‘access anywhere’ platform, instead of siloed apps¡
  • Target users of the PWA with adverts for the native version (if you build one)

Because of this, PWAs are receiving praise from leading brands, with many case studies reporting double-digit increases in conversion rates, a trend likely to grow with future iOS support.

2015 Statistics for the US show use of mobiles split between apps at 90% versus just 10% for web browsing (however extensive use of social media, entertainment and gaming skews this by 66%). There are also limitations to PWAs compared to true native apps, however the gap between them in terms of usability and capability is decreasing, and with it, the viability of native apps.

For some, ‘native’ may be an inevitability, although for most of you reading this, a PWA-first strategy will help you justify any business case for ‘native’, while putting users first from the outset.


Avoiding the pitfalls


  • Talk to developers - write a detailed brief, and ask if your budget and deadline are realistic
  • Talk to your stakeholders - use developer feedback to manage their expectations
  • Talk to your customers - survey them to find out what they want from the app
  • Test thoroughly - then soft-launch to a small group of actual users, and keep refining




  • Underestimate the ongoing investment required - instead keep your stakeholders properly informed
  • Overestimate the value of app store placement - instead consider the friction in this user journey
  • Let your deadline jeopardise success - instead use an MVP to build on what’s most important
  • Assume you will get everything right in version 1.0 - that’s why apps have a version!


Get in touch

See our previous article "you need an app. now what?".

At Hydrant we are always happy to discuss any project. Get in touch