Written by Nick McKenzie, Feb 2016
Technology Choices in Mobile App Development
In software development it is usually a good idea to defer technical decisions until as late as possible. This gives you a great deal of flexibility and allows you to make a decision at a point when you have the best possible information available. In mobile development however there is a technical decision that you must make early on and, if you choose poorly, it can have dire consequences. The decision in question: the development platform.
Today they are many ways to build a mobile application: Mobile Web, Hybrid Web, Cross-platform Compilers and Native. Each of these approaches has its advantages and disadvantages. A good technology choice at this point can mean getting to market quickly. A poor choice might result in a total rebuild mid-way through the development process! So how do you navigate this minefield? It starts with looking at the advantages and disadvantages of each technology in the context of what you want to build.
First though, let’s get the nomenclature out of the way…
So which platform is best then? It depends. It depends on the requirements, the platforms you would like to target, the device capabilities you need to access, how fast you need to deliver and how fussy you are about visual fidelity. To select a platform, you need to overlay your answers to these questions on the relative strengths and weaknesses of each platform.
Mobile Web is the simplest, quickest means of targeting the broadest number of devices. If you have built your current web application using Responsive Design principles chances are that people can access your app via a mobile device already. There are some limitations though. Firstly your ability to access device capabilities like GPS and Camera is limited to what the device’s browser can provide. Secondly differences in how manufacturers have ‘interpreted’ various standards means that you app may not perform consistently on different devices which can increase testing and maintenance costs. Most often these issues show up in the visual fidelity of you app or performance. For example a CSS style that works brilliantly on one platform may perform poorly on others.
Hybrid differs from Mobile Web in that the application is deployed into a 'container' that runs directly on the mobile device. The container provides improved access to the device’s capabilities and allows the app to be distributed via the app store. It is extremely difficult to spot the difference between a properly implemented hybrid app and a native one. Unfortunately a poorly implemented hybrid app sticks out like a sore thumb – if you go this route you need to take the time to adhere to the conventions of the platform .
Whilst hybrid is a great approach for most applications there are a couple of provisos. The first is that hybrid suffers from the same stabilisation issues as mobile web: the app may not behave consistently across all devices. Secondly access to device capabilities, whilst superior to mobile web, is still limited to what the container provides. If the container does not do what you want you will either need to wait for support to be available or add it yourself.
Cross-platform systems come in many forms and use a variety of approaches. In general, though, they aim to give you native levels of control and performance whilst using the least amount of code. The risks are similar to the Hybrid approach: you are limited to what the manufacturer provides. If there is a missing feature or defect you are at the mercy of the manufacturer to fix it. Another issue is cost; many of these platforms require per-user or per-instance pricing that may completely offset the cost savings of developing off a single code base.
Native gives you full access to the device and its capabilities. If you need low-level access to the device and want to squeeze maximum performance and pixel-perfect control then this is the way to go. The challenge with this approach comes when you need to target multiple platforms. If you are building a public facing app you need to be thinking about at least 2, possibly 3, platforms. This means that you will be essentially building the same app at least twice. Yes, you can re-use most, but not all, of the User Experience and User Interface design but the rest needs to be done per platform. This means twice the development, twice the testing, twice the maintenance and twice the project overhead.
As you can see this is not a simple decision and there are many factors to evaluate. In my experience (which is based on getting this decision both spectacularly right and catastrophically wrong) I would err in favour of the approach that gets your app to market fastest. This lets you evaluate your design decisions and verify that your approach is correct with real users in the real world. If you start with a simple Mobile Web application for your core features, you can always add Hybrid or Native versions down the line based on real-world knowledge about what your users actually need. If you go the other way you may lock your self into an expensive development approach when all you really needed was a mobile web page.