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.
Have a look at some of the drawbacks of HTML5/CSS platforms. Two issues are of particular interest and they are slap-bang in the areas of user’s experience and security. Many facets of an app work together to give the user a great experience, including the design quality of graphics and the performance of backend systems, but since this conversation is about native versus HTML5 based apps, we will stick to issues relevant to this discussion. JavaScript, an essential element of HTML5/CSS apps, is an interpreted language whereas the code for native applications is compiled to machine level. This means that the HTML5 platform is immediately at a disadvantage in terms of performance, specifically noticeable on lower spec mobile devices. Not only that, but JavaScript/browser implementation is not multi-threaded.** Multi-threading, and offloading of processes onto background threads for asynchronous processing are essential components of creating a super responsive app. The user expects immediate feedback and control back to them once they clicked or touched a control. Imagine for a moment that you are using a music app that is streaming music to you. You may want to search for other tracks in your library while another track is playing. Without multithreading, the app will not allow you to do anything until the music is stopped. You can see how this would be a terrible user experience. In a similar way, when you touch controls of an app you expect to be able to continue with other functions: searching, scrolling, updating information and pictures without having to wait for each function to complete before the next commences. Lastly, when the app code wants to interact with the device itself (for example the camera or location based services), the calls have to go through additional layers of framework resulting in a performance loss.
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.
JavaScript is interpreted on the device. It is not obfuscated and is therefore relatively easy to decompile. Do you really want someone to decompile your mobile banking app code, potentially viewing your IP, security implementation and product rules? What happens to your product if the decompiled code of your app is published on a website by a hacker? If anything, this specific aspect of JavaScript should be of serious concern to anyone who are not prepared to publish their source code in the open domain for security and IP reasons.
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.