It goes without saying that most of us find it hard to imagine life without smartphones and mobile apps. There are apps for just about everything from getting you up in the morning, working productively during the day, socialising in the evening, right through to helping you to get a better night’s sleep.
When it comes to developing mobile apps, there are three main approaches: native applications, mobile web apps, or a hybrid approach. There are different benefits to each approach so it’s important to choose wisely and decide upon the most suitable approach for your situation.
The app marketplace is fiercely competitive and one of the key differentiating factors between apps is user experience (UX) so this should be at the forefront of your mind when making development decisions. In this article, we will look at some of the pros and cons of each option and the factors to take into account.
Native apps are generally faster, more reliable and more responsive than the alternatives because there are fewer layers in between the app code and the device hardware. This also means that they have access to the full range of device capabilities (e.g. camera, microphone, GPS, accelerometer, battery level, and other onboard sensors) and OS-level apps and features (e.g. contacts, calendar, tasks/reminders and health data etc.).
If your app needs to alert users to external events (such as when a friend adds you to their social network), the tightly-integrated nature of native apps allows them to use push notifications to get the message across. These use a dedicated online service that interfaces directly with the device’s operating system. Native apps also have access to device-level data storage, meaning that they can save and retrieve information, even when the device is offline. It’s this level of integration, responsiveness and polish that makes native apps more attractive to end users. As a result, people spend over 3 times as long using native apps than they do browsing the web or using the web.
Native apps have to be designed and coded for their specific platform (e.g. iOS, Android, Windows Phone etc.), taking into account the differing needs of the appropriate range of devices. This requires more effort because each platform has its own software language, development tools, user interface elements and Software Development Kits (SDKs). A native app written for one OS won’t run on any of the others, so if you’re looking to release your app for iOS, Android and Windows Phone, you’ll need to write three separate apps. Each platform also has different approaches, conventions and requirements. For instance, Android devices have physical or “back” buttons, so Android apps don’t need to include a separate UI element for this. iOS devices, such as iPhones and iPads, don’t have this feature, so their apps need to implement “back” buttons as part of the screen design (although, Apple makes this straightforward as part of their standard UI framework).
Another significant factor relating to native apps, particularly those for iOS, is that they are released and distributed via an app store. This makes it easier for users to find and install them, but each platform has its own publication process. This can take anything from a couple of hours (for the Google Play store for Android apps) up to 2-3 days for Apple’s more stringent quality review process for the iOS App Store. While Apple’s thorough checks mean users can be more confident of finding good quality apps, it can be frustrating for developers when they want to release a quick bug fix. For all app stores, updates are also dependent upon users either installing them manually or having their devices set to auto-update apps when new versions become available.
- Most responsive user experience
- Access to all device-level features and push notifications
- More stable and reliable
- Can be developed to work offline
- Can be marketed to show in app store search results
- No cross-platform support
- Increased development and maintenance time when developing for multiple platforms
- Approval required for Apple App store
Mobile Web Apps
There’s no need to submit web apps to an app store. Users can access them directly via their URL, just like any other website. To “install” them, the user can add them as a shortcut to their home screen. If you want to release an update or add a new feature, you can simply publish the changes online and all users will instantly have access to the new version. No need to wait 2-3 days for Apple to complete their review (or worse, reject your submission and require you to make corrective changes).
Whilst it’s possible to access some device-level features from a mobile web app, this is generally more limited. Some device properties (such as orientation and accelerometer information) can be used in a similar way to a native app. Other features are more limited. For instance, not all touch gestures are supported, and those that often take a fraction of a second longer to trigger. This doesn’t sound like much, but it’s long enough for users to notice the “lag”. Mobile browsers and web standards are adding more support for device-level API’s all the time, but there are still some features (such as push notifications and full online/offline sync support) that still can’t be accessed from within a web app.
- Easier to maintain: a single codebase can work across all platforms
- Updates and new features can be released instantly
- Interactions are not as snappy and responsive as for native apps
- User Interface design elements can feel inconsistent compared to native apps
- No support for some device-level features such as push notifications
- No app store means less exposure to potential users
As the name suggests, hybrid apps are developed using a combination of native app code and web technologies. At their simplest, they are effectively web apps “wrapped” within a native app “shell” and published via the relevant native app store(s). Apple currently rejects apps that simply re-create the experience of an existing web app, as they claim it adds no value to the end user. So, if you’re thinking of making your website into an app then you’ll need to consider how you can make more of the mobile platform. Some hybrid apps use a “half-and-half” approach by implementing most of the app’s features in native code but using part of the organisation’s mobile website for other parts of the user journey, for example, the shopping cart/checkout flow.
Some developers choose to deliver their web apps as hybrid apps in order to more easily integrate with device-level features such as GPS, the device’s camera or push notifications. Others want the benefit of being listed on the App Store, Google Play or the Windows Store so that users can find their apps in search results. Still, others want the convenience of writing their app with a single, web technology codebase in a way that can be deployed onto multiple platforms.
Whilst a hybrid app delivery model can mitigate some of the downsides of web apps, other aspects will always be an issue unless you fully embrace native app development. If you want a hybrid app to be consistent with the user interface conventions of each of your supported platforms, then you’ll need to write different versions for each one (partly negating the multi-platform benefit of web technologies). Even then, the apps still won’t feel quite as slick and responsive as their native equivalents.
- Single codebase with cross-platform support
- Faster and cheaper to develop using standard web technologies
- Apps can be found in the relevant app stores
- Less responsive than a native app
- Platform-consistent UX requires multiple versions to be created and maintained
- Requires submission (and approval for iOS) to relevant App Store(s)
The most appropriate development approach for your app ultimately depends on your priorities. If your budget is tight and you’re just dipping your toe in the mobile app marketplace, a web or hybrid app might be a good option to test the waters. Web development skills tend to be widely available and less expensive than native app skills. You will be able to reach a broad section of the market with a single codebase and, in the case of web apps, you will be able to respond quickly with updates and fixes without needing to re-submit your app for review and/or publication to an app store (where your users may or may not decide to update their app).
However, if your brand experience is key and you are confident that the additional investment will be rewarded, then you should seriously consider developing your app using native technologies. The speed and responsiveness will be superior and you’ll be able to deliver features that web and hybrid apps just can’t match.