Decision No.2 What kind of app to build?
This is one of a number of posts helping businesses establish a mobile strategy. We can’t attempt to give you a strategy in a single article, or even a series, as there are too many variables to think about. The articles will however help you understand what things you need to take into consideration when developing your own strategy.
In another post we looked at the different types of mobile presence you can build. Many businesses arrive at the decision that they need both a website for discovery and short, casual interactions with the customer, and an app for deeper, more engaged and frequent relationships. In this post, we’ll look at the specific types of app you can consider.
Let’s start with what an app is. An ‘app’ is an application which runs on a device, like a smartphone, tablet or even a desktop computer (your email or spreadsheets programmes are technically apps but few people think of them as such). Without getting too complex, in the world of marketing apps, the kind of which We Are Apps builds most, apps fall into two categories: web apps and native apps, if we use native to mean a downloadable app.*
Broadly, the two key differences are that web apps are accessed through a browser and don’t need to be downloaded from an app store and native apps are downloaded and can be run straight from the device.
As we’ll see, ‘native’ is going to cover a number of different types of app coding technique, from pure native to cross-platform, which we’ll go on to explain. But let’s start with the far-simpler web app.
Mobile strategy: Web apps
Web-apps are often confused with websites, but the simplest distinction is that websites are pretty much read-only and web apps have functionality. Although they are both viewed via browsers, a web app can also download a separate ‘native-like’ navigation layer and save it onto the device. This makes the content quicker and arguably easier to navigate than a website which, while optimised for mobile users (a ‘responsive’ site), may also be accommodating navigation that’s also needed for larger desktop screen users. There are a few other things web apps can do but we are trying to keep this post simple.
You would consider a web-app when you:
- Want to provide enhanced navigation over a website or .mobi site
- Don’t want to support multiple device operating systems
- Have quick, easily digestible content
- Have few navigational layers
- Do not need access to device functionality, such as the camera and sensors
- Have no need to send push notifications to users when the app isn’t in use
- Don’t need to securely store data on the device (like account data)
- Don’t need to support Bluetooth or BLE Beacons
- Want to keep the budget as low as possible
- Want to build quickly
The list could have gone on but in short, web apps are simple to build and use, but don’t offer the greatest user experience and have very, very limited functionality. And of course they need a really good internet connect every time they are used. But they are cheaper to produce than native apps, and often you can use assets that you have already built for your website.
Mobile strategy: Native and hybrid apps
‘Native’ is an abused term. It can mean apps that are native to the device (as in a downloaded app), apps that can run entirely on the device (without an internet connection) and apps that are compiled in native code, meaning they use a language the device doesn’t have to bridge between its own code and machine-code (meaning the device can be more efficient and quick at running the app).
Unfortunately, we can’t produce a simple list like the one for web apps above, as there are multiple benefits to producing a native app, from access to multiple device functions to offline use. But to simplify things as much as we can, if you are looking to produce an app that your users can download and keep on their mobile device, you have these options:
- A ‘pure native’ app complied in each operating systems native code
- An ‘as native’ app using native UI, but with logic written in cross-platform (reusable) code recognised by multiple operating systems
- Cross-platform apps, designed to run a single user interface across all operating systems
The pure native app
This is compiled in the operating system’s native language, Objective-C for iOS, Java for Android and so on. The app will feature ‘gestures’ and features that the device users are familiar with, such as swiping left to delete something on an iPhone app or using the back button on an Android device (iPhones don’t have the separate back button).
These ‘pure’ native apps are the most robust and efficient apps that can be built. The operating system’s developers, such as Apple in the case of iOS, provide a lot of tools and support for developers to make the apps as easy and elegant as possible to both build and use. Pure native apps have access to all of the device functions and as soon as an operating system is updated with a new release, developers can access any new functions and features without any delays. Plus, native apps are the most popular with users themselves.
The downsides of pure native are that you need to write and support an app for each operating system (or platform, if you will), which can be expensive. Also, Apple and Google (the people behind Android) are in competition with each other, releasing features and updates that mean your iOS and Android app could have different features and be out of sync with each other.
Such is the quality difference between purely native apps and the other options (although React Native, below, can come pretty close in many situations), is that many project managers/businesses decided to go with one platform first, normally iOS, and then develop an app for the other platforms later, learning from their users before they commit to the other apps. This is to avoid compromising the quality of the apps they release.
From a mobile strategy perspective, if you can afford to do pure native apps, for each platform, you’ll deliver the best app experience for your users.
The ‘as native’ app
Obviously building and maintaining two or three different native app platforms is both expensive and time consuming so developers and their clients are very interested in cross-platform technologies that ape the native app as much as possible. The idea is that, while still needing individual apps to be created for each app store, as native apps share as much code as possible from a single code base.
Facebook’s React Native framework for example or Xamarin for another allows us ‘learn once, write anywhere’ and build apps that share much core logic (for accessing the app’s database being one example) but have dedicated UI (the User Interface) for each operating system. This means iOS users can have a ‘back’ symbol where they usually expect to see one and Android users see no symbol at all as they are used to using the back button built into their device.
The downside to ‘as native’ is that device features and functions aren’t as well supported as pure native apps – it can take even Facebook some time to update React Native when Apple or Google update their OS’s, although they should normally have updated before those OS’s are released to users. But, in many situations, the apps can run nearly as efficiently as native apps, have native UI and, the most powerful argument of all, can be more cost-effective to produce and support.
Looking at your mobile strategy, using a platform like React Native will give you most of the benefits of having pure native apps, but with less initial cost and reduced ongoing maintenance.
Cross platform and hybrid apps
Where does ‘native’ come into the cross-platform apps? Well, if you build an app using HTML5 so it works on all devices, you still need to embed it in a native ‘wrapper’ so that it can be distributed from individual app stores and installed on the different types of devices. Hence the term hybrid.
Given that budgets aren’t exhaustive, if the quality of the user’s experience isn’t the priority, it makes sense to try and build one app that will work on all devices and a number of platforms have sprung up to offer this, like Sencha Touch or PhoneGap to name a but two.
Generally speaking, it’s quicker and therefore cheaper to build an app this way. However, there are hidden costs in testing and de-bugging cross-platform apps that you must also consider.
The theory of writing a single code base that will work on all operating systems is fine, but in practice the output never, ever matches that of the native app options above. This is because whatever language the app has been written in, that is common to all the operating systems you want to cover, it still needs to be translated by the device to be machine-readable. Also, you don’t have access to all of the phone functions, which can impact in many ways, such as the ability to manage the devices memory as efficiently as possible (a common cause of app crashes). Put simply, when you build using cross-platform methods, there is always a compromise you are forcing on your users.
However, they can be very cost effective if you need to produce apps for more then one mobile operating system. Again though, just like native apps, if just one operating system is updated you may need to affect changes in your app and it could affect how the app works on the other operating systems – you’ll still have to test for that. So while in theory it may be marginally cheaper to initially develop an app that works on all devices, there may not be so many savings ongoing. The costs come in supporting multiple systems, regardless of your actual app build type.
The biggest disadvantage is that ‘build once, run multiple ways’ leads to many compromises on the user’s experience. We’ve watched as new app users have tried to perform a regular iOS-type and Android-specific gesture on an app built using cross platform technology and had to tell them, ‘it doesn’t do that.’
Start with your users, not your budget
As we’ve pointed out in other posts, the starting point is for your mobile strategy is to first consider your users, what they expect from you and how best you can deliver that for them. And as we’ve mentioned in this post already, one strategy is to release for specific platforms that match you users.
If you are a high-end luxury hotel brand, it’s quite possible that up to 95% of your clientele are iPhone users. So why go to the bother and expense of building and supporting an Android app? Conversely, don’t discount seemingly ‘out of favour’ devices like Blackberries and Windows Phones when these may be very popular with your users – Windows Phones has very high penetration in Italy, for example.
By starting with the users you want to build for and the experience you want to give them, you can determine what you want to budget based on how much you do or don’t want to compromise.
For a mobile strategy for apps, it’s probably the best method to ensure what you build can be built upon.