The ups and downs of hybrid mobile app development
Creating applications for mobile devices is a great way to capture a user’s attention and continued business. Once installed your app has a persistent presence on your user’s device placing your services literally at their fingertips.
It’s an invaluable piece of real estate that many organisations are looking to make the most of. Apps give better performance verses a mobile web site, mean your customer has to do less to access your services and provide an ever present icon in the application draw/home screen.
The first issue faced by many organisations when getting into the App game is that there are so many competing app ecosystems to develop for. Between iOS, Android, Windows Phone, Chrome, Blackberry, Windows 8 there’s a lot of work to do. Not only that but you need a version optimised for phone, tablet and before too long smart TV, smart watch and smart glasses as well.
In principal hybrid apps seem like a fantastic idea: pay to develop once and release for every major platform. Changes and updates can be rolled out by altering a single code base and you get a unified experience regardless of device. But before jumping in with both feet it’s worth considering some of the down sides:
- Performance – Nothing beats a properly coded native application. Different platforms have their own quirks and foibles; what works well on iOS isn’t always best practice on Android. A skilled developer who understands the platform they’re working with can improve performance, stability and usability by applying best practices to squeeze the maximum amount of processing power from the device for smooth performance and a frustration free experience.
- Features – Many platforms have unique features that cannot be utilised through hybrid apps. If a feature doesn't translate to all of the platforms it probably won’t make it to your hybrid development environment. This means you may be ignoring some of the best features of the platform you’re releasing for. Take for example the widgets on Android, Live Tiles on Windows Phone and the smooth built in animations on iOS.
- User Experience – Each of the major platforms have their own set of interface guidelines to help developers to create applications that fit with the look and feel of the platform. Google goes as far as to provide themes that specify colour, height, padding and font size for Android apps to help “promote greater cohesion between all apps on the platform”. Developing with one design language in mind can make the experience jarring on different platforms and can have a dramatic negative effect on usability. A prime example of this is that Android provides (either by hardware or software) a persistent back button which isn’t available on iOS. Apps specifically developed for each of these platforms are designed with this in mind but by designing for both simultaneously you’re going to alienate one or both sets of users.
- Debugging – Even the very best developers make the odd mistake, we are human afterall. Bugs happen and if it turns out to be in the code generated by the hybrid app platform you may find it difficult if not impossible to fix. With a natively coded application the developer has a complete understanding of how the application works and full control over the code. Native platform development tools also provide advanced debugging tools to enable the developer to identify and fix issues as fast as possible.
Hybrid apps certainly have their place; they’re a great way to get an app for every platform in a short space of time but they also have their pitfalls. Native applications are more costly to develop and maintain but provide users with a better, more cohesive experience as well as giving developers more control.
- » We can work it out: How the Lennon-McCartney partnership can translate to software development
- » Google is pulling open-source apps which feature donation buttons
- » Project Treble is making a big difference to the speed of Android updates
- » Apple removes 18 iOS apps for fraudulent advertising activity
- » Google Cardboard goes open-source as VR SDK development halts