Affiliate links on Android Authority may earn us a commission. Learn more.
HTML5 vs Native Android App
A common question asked by mobile app developers is this, ‘Should I build my app with HTML 5, or build native?’. There are a wide range of reasons why you would choose either of these, and the proponents of both have very valid and compelling arguments. With this article, we will explore the various types of app categories, and discuss the pros and cons of both methods.
Definitions
Before we begin, we ought to define the terms, HTML5 app and Native app, to prevent ambiguities, and needless arguments in the comments.
If you intend to develop a graphic intensive game, you almost certainly want to build a native app.
A HTML5 app, on the other hand, refers to a mobile app built completely using HTML, CSS and Javascript only. HTML5 apps are web apps and they must be run using the underlying OS browser. Note that HTML5 supports offline data as well as rich media, such as audio and video. A well written HTML5 app can be used even when the device is offline, or at the very least, show an error message.
Comparison of HTML5 and Native Apps
Portability
HTML5 apps are portable across different OSes and device types. A HTML5 app written with responsive design methods would also scale appropriately depending on the size of the device it’s currently viewed on. When an update is required, the single app is updated and tested, and is available for all devices immediately.
Native apps, by definition, are unique to each OS, and so, to support multiple mobile OSes, a separate app must be written for each OS. When an update is required, each app must be updated independently, and tested independently. Android apps do not modify the layout to match the size of the device automatically, however, during development, different layouts can be specified for different device/screen sizes and orientations. This usually results in layouts that are more aesthetically pleasing compared to automatic responsive design HTML5 apps, albeit with more effort and planning required.
Winner: HTML5
Cost to develop
HTML5 apps are generally cheaper to develop and maintain than native apps, since just the single app is required for multiple OS support. This single app can be developed by a single web developer. However, native apps for all major mobile OSes would typically require a specialized developer for each OS (Java for Android, Objective C/Swift for iOS, C# for Windows), which would be significantly more expensive than a single web developer.
Winner: HTML5
Speed and Efficiency
Native apps are almost always more efficient, and faster than HTML5 apps. Despite the strides made in increasing the speed of Javascript interpreters, a HTML5 app cannot execute at the same speed as a native app of similar functionality. Apple’s App Store can reject apps for being too slow or not feeling native enough, which is more likely to occur with a HTML5 app than a fully native app.
Winner: Native
Use of Hardware
Native apps can interact with a wide range of the hardware available on a device, including location, camera, accelerometer, speakers, screen and more. HTML5 apps do not have the same ability to interact with the hardware, which can be a major deal breaker, depending on the desired functionality of the app.
Winner: Native
If you need to deliver an app for the lowest cost at the quickest speed on multiple mobile OS types, a HTML5 app is almost always the preferred way to go. However, if your app needs to make use of device specific hardware, or needs to run very fast, you will do better with a native solution.
Hybrid Apps
Hybrid apps are not all roses though. There are both pros and cons:
Pros
- Hybrid apps are as portable as HTML5 apps. They allow code reuse across platform, with the framework handling all platform specific differences.
- A hybrid app can be built at virtually the same speed at which a HTML5 app can be built. The underlying technology is the same.
- A hybrid app can be built at almost the same cost as a HTML5 app. However, most frameworks require a license, which adds an extra development cost
- Hybrid apps can be made available and distributed via the relevant app store, just like native apps
- Hybrid apps have greater access to the native hardware resources than plain HTML5 apps, usually through the corresponding framework’s own APIs.
Cons
- Not all native hardware resources are available to hybrid apps. The available functionality depends on the framework used.
- Hybrid apps appear to the end user as native apps, but run significantly slower than native apps. The same restriction on HTML5 apps being rejected for being too slow on Apple’s App Store also apply to hybrid apps. Rendering complex CSS layouts will take longer than rendering a corresponding native layout
- Each framework has it’s own unique idiosyncrasies and ways of doing things that are not necessarily useful outside of the given framework.
While the HTML5 vs native app debate still rages on, it is worth mentioning that there are literally dozens of valid reasons to develop a HTML5, native or hybrid app. However, the most critical question shouldn’t be “What technology should we use to develop?”, but rather “What does the app do?”. The functions the app is intended to perform, when spelled out adequately would often answer what technology is appropriate.
If you intend to develop a graphic intensive game, you almost certainly want to build a native app, in order to give users the fastest and most responsive game play possible.
If you are writing an app for a business that enables executives on the go access company information, you can decide between a hybrid or HTML5 app, especially if your app has no need to use device hardware, and should be available to use on the user’s preferred device.
If you are developing an app that is the core of your business, like Instagram, you might want to build a native app, to provide the best experience for your users, or go hybrid, so that it will be be available to as many users, on as many devices, as possible.
Did we leave anything out? Hit the comments and let us know.