Choose the right technology for your mobile app
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:
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 (ft.com) / 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.
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.
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.
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!