Guide to enterprise mobile app development and SOA
A comprehensive collection of articles, videos and more, hand-picked by our editors
A debate has raged recently over whether mobile applications should be implemented using HTML5 or native (platform-specific) code. The controversy surfaced in the wake of Mark Zuckerberg's admission that the initial HTML5 implementation of the Facebook app on iOS "was the biggest strategic mistake we made." Simply put, the browser-based HTML5 version of the app suffered performance-wise.
Mobile users on the road -- with some justification -- don't have patience for sluggish software. The issue of execution speed and user expectations means that, for the foreseeable future, the enterprise mobile app should be delivered as native code. Let me delve into some of the reasons why native apps are often a better solution than HTML5 apps.
A native app's custom UI elements are stored as resources within the app itself, which eliminates the overhead of downloading them.
One of the major advantages of HTML5 apps is their flexibility. They consist of scripts and content that are downloaded and executed within a mobile device's browser. Code updates can be distributed quickly: Just revise the code on the website and you're done. However, this flexibility exacts a performance penalty. The browser first has to download and then interpret the HTML and scripts. Furthermore, UI elements must be rendered before the scripts themselves execute. This multi-step process adds considerable overhead to the app's execution, especially if the SOA task is a complex one.
By comparison, the native app can draw upon the mobile device's performance-tuned feature-rich frameworks to implement all of its functions. These frameworks provide for all of an app's needs, such as ready-made UI elements, a network stack, XML parser and database services. Any custom UI elements are stored as resources within the app itself, which eliminates the overhead of downloading them.
Third-party tools, such as Appcelerator's Titanium Studio, let you build hybrid apps that consist of HTML5 packaged within a wrapper of native libraries. While such apps promise code flexibility and offer some improved performance, this is a tacit admission that the mobile browser impairs the performance of a complete HTML5 app implementation. This is not a knock against hybrid apps: They can be valuable for re-using proven HTML code and for cross-platform distribution.
The dual-core and quad-core mobile devices appearing on the market can certainly improve the browser's execution speed. However, native apps also benefit and still come out further ahead in performance.
Bandwidth and connectivity
As mentioned, the mobile browser has to download an HTML5 app's code before it can execute. This transfer can require tens to hundreds of kilobytes of code before getting around to handling the data payload -- that is, the actual data used in the transaction. By comparison, a carefully written native app requires only the transaction data, as its UI and application logic is stored on the mobile device.
The other thing to keep in mind -- announcements of LTE coverage notwithstanding -- is that in an area with low-bandwidth coverage, large code downloads are going to take time. This makes the HTML5 app appear very sluggish at best. The native app, which consumes far less data, can launch and handle transactions faster, even on a marginal connection. In this era of data caps, less is more in terms of what gets downloaded to the device. Finally, if the user wanders into a "killing field" that lacks wireless coverage, the HTML5 app won't even load.
In terms of security, IT managers are painfully aware that a browser provides a large attack surface. It has to download scripts and execute them, and some of those scripts might contain malicious code inserted by a hacker. Native apps, while also using HTTP as a communications conduit, can implement a private protocol to conduct their transactions with the servers. Any data not corresponding to the session protocol is either discarded or triggers an alert. While it might be possible to snoop on such sessions, the native app should be using a secure authentication scheme when establishing an HTTP connection, and then encrypt its session data.
The downside to native apps is that you have to implement these authentication and encryption measures yourself. A browser provides such services out of the box, but this advantage is neutralized by that large attack surface. The Android and iOS frameworks provide APIs that can establish secure sessions, but you have to write the native code and test it for robustness. Still, the price of a programming team and testing to ensure an app's security will cost far less than a security breach that loses data, raises privacy concerns and places your company's reputation at risk.
Follow us on Twitter at @SearchSOA.
Tom Thompson asks:
Do you and/or your organization use a mix of HTML5 and native development?
3 ResponsesJoin the Discussion