By Martin Dippenaar, Global Kinetic
At Global Kinetic, we are often asked by clients whether they should be developing their mobile apps using a web-based application framework such as Apache Cordova and Appcelerator, or whether they should develop natively for iOS, Android and Windows Phone.* Let me start by saying that every technology has its’ place. Often, developers and other technologists are strongly biased towards or against a specific technology or a specific manufacturer. This is acceptable at university but not in the business world where these biases can have a detrimental effect on your technology stack and on your business. It is important to see past these biases and to use the technology that is appropriate for your business and your product.
When considering mobile development, there are compelling reasons for going the HTML5/CSS web-based application framework route and most of them revolve around that of perceived cost of development. These platforms promise cost saving by:
1. Re-using an existing skill base that is readily available and cheaper than native mobile developers,
2. Accelerating development timelines because the app is only developed once for all platforms.
But is it really cheaper? Consider for a moment that today’s user expects an app to work perfectly, consistently, beautifully and true to the platform it is on. If an app behaves slowly, even only for a fraction of a second, scrolls slightly jittery, shows an inelegant exception message only once or has objects that are slightly out of alignment, the user will subconsciously notice these and it will affect the users’ confidence in the app and the product as a whole. This is of particular importance in applications where the user invests a tremendous amount of trust in the app, such as banking and other financial or payment apps. The user may not consciously notice these issues, but these problems will affect the user’s confidence in your app and product, resulting in a higher rate of app abandonment.
Another potential issue is that designers and programmers tend to develop for the lowest common denominator platform when using “build once, compile everywhere” type technologies. This is because there are a plethora of screen sizes and formats and one implementation has to cover all of these permutations. In addition, the developers and designers have to take immense care to ensure that the app works perfectly on multiple platforms, and that it has the appropriate UI for that platform. This is specifically important because of the affinity users’ have for their chosen mobile platforms. Users expect all apps on their device to conform to the UI standards inherent to that platform. For example, an app that appears to be an Android app when running on an iOS platform will have the Apple user abandon the app pretty quickly. Similar is true for an app that looks like an Apple product on an Android device or on a Windows device. Getting this right for all the platforms takes a lot of effort.
Lastly, because the platform is normally provided by a party different to that of the operating system manufacturer, security vulnerabilities are more likely to present themselves than on native platforms, as are advances on new versions of operating systems and associated hardware which is not yet supported by the framework.
Even though a real cost saving during development is possible using web-based application frameworks for mobile, the cost of reduced take-on, app abandonment, security issues and users not having confidence and trust in the application is often not taken into consideration when decisions on development cost is made. The question that you need to ask is: can you afford not to develop native? If you have absolute control over your user base, for example for an in-house application used exclusively by employees, a web-based application framework is likely to reduce cost. However, if your app is intended to be available to the world at large, you may want to consider going native.
* This discussion does not include Xamarin.
** Not all web applications frameworks behave like this, but the most popular ones do. See https://en.wikipedia.org/wiki/Multiple_phone_web-based_application_framework for more information.