Mobile Computing | Feature
Will HTML5 Kill the Native App?
As schools calculate the best way to serve students via mobile apps, cost and performance are part of the equation. Does HTML5 offer a solution or is it just another variable?
Illustration by Nigel Buchanan |
For colleges and universities today, the question is no longer whether to develop a campus app or not. That horse left the barn in 2012, and BYOD is now galloping freely. Instead, the debate has shifted to the best--and most cost-efficient--way to make campus applications accessible to the myriad devices and operating systems out there. Schools have a few options: They can develop multiple native app versions; they can develop an HTML5 solution that will run on the device browser; or they can plump for a hybrid of the two. Predictably, the solution is rarely simple.
HTML5 is the dark horse. Its promise has been quietly whispered for years, but there is yet to be a trumpet blast heralding its triumphant arrival. Put simply, HTML5 is the fifth iteration of the HTML (hypertext markup language) standard that underlies web pages. Though HTML5 standards are still in development, web browsers already support HTML5, which includes new elements that handle multimedia and graphical content without relying on plug-ins such as Adobe Flash Player. This is especially critical for Apple devices, which don't support Flash.
Whether this souped-up version of HTML will have enough bells and whistles to supplant native apps is the big question, but schools will probably base their decisions on three factors: performance goals, development costs, and maintenance expenses.
The Costs
Developing applications for multiple platforms is expensive, primarily because it takes developers a lot of time to create two or three versions of a single app. Not only does the coding itself take time, but the developers also have to learn multiple authoring systems: Xcode for Apple apps, Visual Studio for Windows apps, and the Android SDK development tools and platform for Android apps. And when updates are needed, which is inevitable, changes must be replicated across the various operating systems. Costs escalate even further when you account for the extra time needed to develop for different-sized devices. Ryan Matzner, writing in Mashable Tech, estimates that adding iPad compatibility to an iPhone app can increase development costs by 50 percent.
Another drawback associated with native apps is that companies such as Apple act as gatekeepers: Users have to visit their app stores to download the app or update it, and these same companies must approve the app before it goes public--a process that can take weeks. It's a lopsided arrangement with which not everyone is comfortable. "There are real concerns with [these] companies deciding who can and who can't publish what on their stores," explains John Kennedy, developer of Pocket Universe, a successful iOS app.
The Good
These costs and hosting concerns don't apply to HTML5 solutions, which generally incorporate CSS (cascading style sheets) and JavaScript, the code language often used to augment HTML apps. All three are considered among the easiest codes to write, and can be written in Notepad or any number of free editors. Plus, you don't need a development environment to compile them, just a browser for rendering.
An additional advantage of HTML5 involves updating. In truth, people are terrible about updating their apps when new versions come out. Browser-based apps draw their features and content in the form of data hosted on the web. If there's an update, it's incorporated in that data. The user doesn't have to download it from an app store. The user might not even know about it.
Another benefit is flexibility, allowing a user to access the same piece of content from multiple devices, something that's especially critical in higher education. Harvey Singh, CEO and founder of Instancy, a company specializing in web and mobile learning solutions, says it's increasingly important for users to be able to "open a course on a desktop, then go on the road and access it using a mobile device and continue where they left off."
The Bad
So why aren't we hearing the death knell for native apps? Well, HTML5 also has real limitations. With native apps, for example, course content can be downloaded to users' devices, so they don't need constant access to the internet to work on a course. With a native app, furthermore, when network access is restored, files are automatically synchronized on the network.
Communication via native apps is easier, too. With native apps, if an instructor gives a new assignment or has a message for the class, users receive a notification on their mobile devices without having to open the app. Web-based apps, on the other hand, can deliver notifications only when users open the app in their browser.
Along the same lines, HTML5 apps can't take advantage of a device's inherent features. "If you want different visual multimedia effects based on a game-type interaction, or you want to take advantage of certain graphics on the device, or use features like geolocation or the camera which are very device specific, then native app becomes the way to go," explains Singh.
And the Ugly
"I would definitely not consider HTML5 for app development," says Kennedy. "Anything that requires hosting in a web browser will always, always be secondary in user experience (and features) to a native application." He adds that tools such as Corona SDK and Unity, a game-development ecosystem, enable much better cross-platform, multi-device apps than those that can be developed with HTML5.
"HTML5 apps are cross-platform, sure, but that's mostly because they're relatively simple," notes Kennedy. "The fact that all the controls are non-native, standard controls will annoy the user (and the developer). What you're building depends on something out of your control--the browser--and that is like building on sand."
Another issue is speed. This summer, Facebook moved from an HTML5-based iPhone app to one created primarily with Objective-C, the iOS app language, due to overwhelmingly low approval ratings for the app. The problem: The app was slow--crushingly slow. HTML5 apps pull content and images from the web, essentially building the app upon the launch of the browser. A native app, built with Objective-C, embeds most of the functionality directly into the app, so there's no lag time.
The Compromise
The best solution may lie in a compromise. That's the approach taken by the University of South Florida when it needed a cross-platform, cross-device app. Kathleen Long, director of web services at USF, worked with Verivo Software to deliver iUSF, a mobile app that gives students access to course schedules, university directories, news, events listings, and meal-card balances.
The app takes advantage of the native functionality of users' devices, including GPS for campus maps, as well as offline access to the campus web portal, MyUSF. But, to really meet student needs, the app needed to pull in information about Bull Runner, the campus bus service, so it would all be available in one place.
"USF now uses Verivo's new browser control to access the Bull Runner page, taking our existing HTML5 content and incorporating it within our cross-platform native mobile app," explains Long. The iUSF app is available from Apple, Android, and BlackBerry stores.
Instancy also recommends a hybrid approach as the best solution for delivering courses. According to Singh, a solution where the delivery environment is native but pulls in HTML5-based course content provides the maximum portability across multiple devices, especially because the course content is most subject to change and building it requires the most investment.
Even Kennedy finds opportunities for using HTML5 content in his apps. For an education e-book project for the iPad, Kennedy says that a small module--an animation of a set of scales--just makes sense in HTML5.
