Tips and Considerations for Creating HTML5 Apps

Here are a few tips and considerations before jumping into your first HTML5 app.

Packaged or Hosted?

App stores like the Firefox Marketplace provide two types of apps: packaged and hosted. Packaged apps are simple: zip up your HTML, CSS, and JavaScript, and upload the final app to the store. Hosted apps are essentially a web view or browser that display your app from a remote site. Each app type has its advantages. Hosted apps are best for:

  • subscription-based services
  • apps which will frequently change (avoids daily app upgrades)
  • apps which are essentially mobile-wrapped versions of websites

Packaged apps, on the other hand, are best for:

  • standalone games
  • apps which require no internet connection
  • apps which require special device privileges

Ultimately there are no steadfast rules for when to chose either, but weigh your goals with the technology to decide which is best for your app and, more importantly, your users.

Target Device Support

There are a number of devices with different screen sizes to consider these days, and even more, will be thrown at us in the future. When you go to submit your app to the Firefox Marketplace, you’ll be asked if the app will support mobile phone, tablet, and/or desktop. Remember that apps aren’t just for tablets and phones — your traditional desktop can install them as basic apps.

When you consider device support and code to accommodate for multiple platforms, remember that you must consider:

  • Responsive and fluid design: you don’t know the screen size!
  • Avoid explicit pixel dimensions to maintain fluidity
  • Feature detection: always a must!
  • Orientations may change: be prepared to detect a change in orientation!

The more devices you support, the better, as long as you take the time to flexibly design and develop properly.

Be Kind: Please Offline

A classic mistake by app developers, even developers of iOS and Android apps, is assuming that the user always has an internet connection. Packaged apps generally don’t need to worry about these problems, but without an offline strategy, hosted apps become useless.

HTML5 apps can take advantage of the Application Cache (AppCache) API. This API has long made developers groan, but it’s the best option for making HTML5 apps work offline. While the AppCache API may not adequately accommodate for expansive hosted apps, apps with basic to medium architecture will be a good fit.

The Storage APIs are also essential when working with hosted apps offline. Saving data to localStorage and then sending that data to the hosted site when an internet connection becomes available is a common practice, and makes your app appear more fluid and valuable to the user.

Size and Speed Matter

Developers always strive to make their sites as compact and efficient as possible, but this becomes even more important when constructing HTML5 apps. There are a number of reasons for this:

  • Most countries outside of the United States don’t provide unlimited data plans, and customers are charged based on the amount of data used
  • Mobile devices don’t have nearly the amount of storage as desktops
  • More requests can slow down an app immensely over a mobile connection
  • You want good performance with and without a local wifi connection

Don’t become complacent when creating your packaged or hosted HTML5 app. Minify, gzip, concatenate, and do everything you can to ease the monetary and data cost to your app users.

Fill the (phone)Gap

If you’re looking to push your app to Android, iOS, Blackberry, and Windows phone, you’ll need the help of a utility like PhoneGap. Supporting multiple platforms is a major consideration when creating an HTML5 app, especially if you plan on using Mozilla’s new Web APIs, which doesn’t yet have a PhoneGap port.

In this case, it’s incredibly important that you create checks (via feature detection) for which environment you’re in, and either use the Web API of choice or the PhoneGap equivalent. This means creating callback functions and passing them to either the native or PhoneGap methods.

L10N

In the case of Firefox OS and other HTML5-based mobile OS’, they will most likely debut and be possessed mostly by users who do not speak English. Localization of your app is paramount to early adoption and usability. Packaged apps allow for different locale files which will be loaded as specified by the OS settings, and hosted apps should detect user locale and serve content accordingly.

HTML5 apps are easy to make, but good HTML5 apps take planning, testing, and brilliant execution. Sure, it’s possible to just only create a webapp.manifest file and submit your app to a marketplace, but take the time to consider all the user, device, language, and cost possibilities that factor into an app. It could be the difference between the next big app and one user remove five minutes after installing!

When to Go Native, Mobile Web or Cross-Platform/Hybrid

First – Why Mobile Should Be On Your Mind

Ever since Luke Wroblewkski coined the phase “mobile first” in 2011, the zeitgeist of software development (at least the vast portions of it that touch mobile devices in some way) has been building towards a critical mass of not only “mobile first”, but – as the CEO of Twitter said – “all-in on mobile.”

I know I don’t need to remind you of how quickly the world has changed. If you’ve been developing software for as little as 2 years, you’ve already witnessed unprecedented shifts in focus and innovation, much of it occurring in a language once considered an also-ran by many – JavaScript. The odds are very high that you – the reader – have access to electricity at home and at work, and you most likely interact with the internet through multiple devices – desktop, notebook, tablet and/or mobile phone. It’s easy, then, to not fully grasp the groundswell of change headed our way. That being the case, let’s step outside of our normal techno-cultural environment for a moment to see the change through the eyes of East Africa (and of course, if you’re reading this from Kenya, asante sana).

When I travelled to Africa in 1998, my luggage was stolen. I spent several hours in an airline office in Nairobi, Kenya – where it took thirty minutes just to get a landline connection to the airline’s office in Uganda. It was busy. Thirty minutes just to get a busy signal! I travelled again to the same areas in 2003 and then 2005 – and I noticed something: the use of mobile phones had exploded. It was fascinating to observe the region skip the period of wired infrastructure (which we’d had for numerous decades where I live) and jump straight to wireless.

Why is this important? In a great piece by Toby Shapshak, he notes some interesting facts about Africa:

  • More people have access to a mobile phone than electricity (i.e. – no home electrical power)
  • “Mobile money” – payment systems that allows you to transfer money to another phone user – is expected “to become a $617 billion industry by 2016”.
  • “80% of the world’s mobile money transactions are happening in East Africa…” (with half of Kenya’s GDP moving through mobile payment services!)
  • In 2012, Google reported that 25% of its weekday searches in South Africa occur on mobile devices – and that figure jumps to 65% on the weekends

Perhaps the most bellweather-like point from Tony’s article is that the Economist noted, in 2011, that “six of the 10 fastest growing economies in the last decade were in Africa”.

“Simply put, Africa is not just a mobile-first continent”, Tony concluded. “It is mobile-only.”

“Great – but I write line of business applications for my company in Europe. I’m not writing payment, radio or apps like Farmerline. How is this relevant?”

If you don’t want to be caught by surprise, or unprepared, it’s relevant. If you – like many developers in the world – desire to further your career and be a part of compelling projects, it’s relevant. The largest players in the development world (and myriads of smaller ones) are heavily investing in mobile innovation, with a particular common theme of open web standards throughout many of the advancements. Mozilla is working on the exciting FirefoxOS (an OS that will be capable of impressive features on even lower-quality phones). Microsoft debuted the ability to write Windows 8 desktop & tablet applications in HTML, JavaScript & CSS. Adobe purchased Nitobi – the company that created Cordova/PhoneGap (more on this in minute, don’t worry) – and are actively developing it. I probably don’t need to mention Apple and Google!

The mobile tsunami is already underway – the question is, what will you do when it reaches you? What are your options, when the time comes that your next project is a mobile application? What does this mean for your team? Will you need to hire new talent? Which mobile platforms should you focus on supporting?

Understanding Your Options

A little learning is a dangerous thing –– Alexander Pope

Knowing is half the battle –– GI Joe

Would it surprise you to learn that there’s more than one way to write an application for an iOS or Android device (not to mention other mobile platforms)? To create an application for a mobile device, you generally have three choices:

  • Write the app in the native platform/language for the device. For iOS, this means writing it in Objective C using a Mac + XCode, etc. For Android, this means writing it in Java using Eclipse/Or-Insert-favorite-IDE + the Android SDK on Windows/Mac/Linux/BeOS (just kidding about BeOS). For Windows Phone 8, this means writing it in C#/XAML on a Windows 8 machine + Visual Studio 2012, etc.
  • Write a mobile web site. Your application is a web app – hosted on the web and accessed by the device’s browser.
  • Use a “Cross-Platform Tool (CPT).” To quote VisionMobile, “CPTs can be used to develop native, hybrid and web apps and come in several technology flavours: JavaScript frameworks, App factories, Web-to-native wrappers, Runtimes and Source code translators.” One of the most common approaches along these lines is the hybrid mobile app. In this case, your application is effectively a web app, but hosted inside a native-to-the-device application container. It’s installed, launched and used like any native app, and can access device APIs (with some exceptions/hurdles) – but it’s written in HTML, JavaScript and CSS. The most popular approach is to use Apache Cordova – often referred to as PhoneGap, though that is the Adobe-branded re-distribution of Cordova. Both Telerik and Adobe have Cordova-based options for hybrid mobile applications, for example. Other popular CPT approaches exist as well, including Appcelerator’s Titanium and Xamarin.

As you might already suspect, there are a host of trade-offs you will confront in choosing any one of the above options. These trade-offs are critical for the decision makers in your organization to understand. My goal in this article is to help jumpstart the discussion around these trade-offs, and help you begin to form the rails on which to guide and direct your energies as you assess which approach makes sense for you and your team. We can’t possibly cover every aspect of how these options compare, nor can we anticipate the widely-varying needs of each team, application, company, etc. – all very important drivers in a decision. But I can tell you now that – no matter what the “native-only-or-you’re-doing-it-wrong” or the “hybrid-is-just-as-good-as-mobile-all-the-time” pundits say – there is no single right answer in this debate.

Comparing Trade-Offs

Let’s start with a high-level view of pros and cons:

Approach Pros Cons
Native
  • Full Access to Device/Platform/APIs
  • Best Performance (esp. with UI concerns)
  • App Store Discoverability
  • Different skills/languages/tools for each target platform
  • Tend to be most expensive-to-develop, with thin margin
  • Client code not re-usable between platforms (of course)
Mobile Web
  • Arguably the broadest reach
  • Can re-use existing, responsively designed sites
  • Code base is re-usable between platforms
  • Finding necessary skills isn’t difficult
  • Extremely limited access to device APIs
  • Limited discoverability (no app store presence)
  • Tend to be more difficult to monetize
Hybrid (CPT)
  • Natively-installed & run, but built with JavaScript, HTML & CSS
  • Code base is re-usable between supported platforms
  • App Store Discoverability
  • Access to many device APIs (& extendable via plugins)
  • UI Performance affected by native webview implementation & (potentially) poorly written JavaScript/HTML
  • Differing webview implementations per platform
Cross-Compiled (CPT)
  • Can re-use existing skills if source language matches team skills
  • Code base is re-usable between supported platforms
  • Access to many (if not all) device APIs
  • App Store Discoverability
  • May not support all target platforms
  • Can be d

Why Not Just Go Native?

Let’s be honest – as I oversimplify for a moment – if money isn’t an issue and your company can afford to venture into multiple native platforms (i.e. – hiring talent experienced in each platform, etc.) and you need app-store discoverability, then native might be the ideal option for you. Developing a native application means you will not be constrained by any “lowest common denominator” forced on you by a hybrid/cross-compiled approach. It also means that you won’t be sacrificing performance and you’ll have access to device-differentiating features that may not be readily accessible to hybrid containers.

Then why do the other options exist? It turns out the developing native applications comes at a price. Literally.

Native App Means Native Cost

This is just a peek into the economic factors of writing mobile applications, but it already paints a clear picture: the margins are razor-thin, a large portion of companies don’t break even, and your chances improve if you can target mutliple platforms. That is why the other options exist, and why their siren call – the reach of multiple platforms without the expense of multiple teams – appeals to many. The question of “when should I go native?” is often best answered with “When you can afford to support each target platform – including hiring developers, designers, QA & analysts as well as purchasing/maintaining any infrastructure required to build for the native target”.

When Native Isn’t an Option

How will I know when it’s love? –– Van Halen

Now what?! –– Bloat, Finding Nemo

If going native is off the table as an option, how do you know which alternative to choose?There’s no silver bullet, but there are questions you can ask that will help determine your options:

  • Do you need to have an app store presence? If yes, then mobile web is out. If “no” or “not necessarily”, then mobile web is an option.
  • Are you OK with no app store presence, you need the ability to frequently update the application and you’re not nessarily concerned with heavy monetization of the app? (Believe it or not, this happens – particularly when an established company is expanding its reach to mobile to establish presence before other mobile initiatives.) If yes to all 3, then mobile web could be your answer (assuming you don’t need heavy device API availability).
  • Do you need to be able to access device APIs (accelerometer, camera, GPS, key chain, use push notifications, etc.)? Then mobile-web is out.

What’s the fuss about app store presence? Many companies may not already have existing customer accounts. Being in an app store provides the ability to reach & bill customers, as well as a means of distribution and discoverability for lesser-known companies/apps. If monetizing your app is critical, and you don’t already have solid channels via which you can reach your customers, then having an app store presence is something you shouldn’t ignore!

From the above questions, you can begin to see the logic behind answering “When should I go mobile web?”. In many cases, this is best answered with: “When you don’t need an app store presence, aren’t really using device APIs, aren’t as concerned about app monetization, and want to potentially take advantage of re-using a responsively-designed desktop site”. Don’t underestimate what’s possible here. Both Time.com and darksky.net are good examples of what’s possible with this approach. (It’s worth noting that some device-level APIs are available to mobile web applications – good examples being geolocation, media capture, contacts and others.)

Cross Platform Tools – Democratizing Mobile Development

Since hybrid mobile applications utilize many of the exact same skills necessary to create a mobile web site, this can be an attractive option – especially given the likelihood that you may already have a web development team and can leverage those skills immediately. Developers that had previously been kept out of a platform due to the walled-garden nature of developing for it can now create applications that usually look and feel like native apps. However, it’s not as simple as writing your web application and hosting it inside the native container app provided by, for example, Apache Cordova. You can (and probably will) run into road blocks – and it’s important to be aware of where that might happen.

Apache Cordova/PhoneGap

Cordova-based options are among the most popular hybrid mobile approaches (you will often hear “PhoneGap” used interchangably with “Cordova” – see this for more explanation). The native ‘webview’ of the device is used to run the application you create in HTML/JavaScript/CSS – effectively within a full-screen, chrome-less browser window. As a baseline, it’s relatively safe these days to assume that most, if not all, of these APIs will be available to you:

Accelerometer Camera Compass Contacts
File Geolocation Media Network
Notification – Alert Notification – Sound Notification -Vibration Storage

As far as devices, Apache Cordova/PhoneGap supports, to some degree or another, the following platforms:

Android Bada Blackberry iOS
Symbian Tizen webOS Windows Phone 7
Windows Phone 8 Windows 8

Not bad for platform coverage. But what do you do when access to a native API doesn’t exist? You can write a Cordova Plugin to open up a native API to your JavaScript. This is both a strength and weakness of this type of hybrid approach. Many Cordova plugins already exist (with generous open source licenses), which is a positive. However, if you need the functionality on (for example) iOS, Android and Blackberry – this entails writing a version for each platform. So now we’re back to needing other skills like Java and Objective C. The silver lining, though, is that the need for these skills is focused on the plugin only – and it’s reasonable to outsource the creation of these plugins to experienced contractors if you don’t have the skills in-house.

If you decide to go the Cordova/PhoneGap route, three of the biggest challeneges you need to prepare for are:

1.) UI Performance

It’s not rocket science – running an app inside a container can have performance concerns. Cordova/PhoneGap has gotten a bad rap in some cases due to slow webview implementations (looking at you, Android 2.x), as well as popular (ahem) UI frameworks that excel at causing reflow due to how they manage the DOM. Desktop browsers often cover up inefficient DOM and JavaScript due to the sheer brute force processing power available. You can’t assume the same level of power will be available on mobile devices. This means that even your experienced web team needs to pay close attention to things that can help or harm performance. I recommend starting with this post by Andrew Trice. The performance of webview implementations has improved to the point to where hybrid approaches work well for line-of-business style applications that don’t need game-intensive UI performance.

2.) Debugging

Not all mobile devices support remote debugging like iOS 6 (for shame). Weinre is the next best option (currently) for remote debugging, but it can be a painful, buggy experience. You will find that running your hybrid app in a dekstop browser simulator (Telerik’s Icenium and Apache Ripple both provide simulators like this) will help a great deal – given the maturity of debugging tools in browsers like Chrome. Of course, if you write Cordova plugins, you will need to become familiar with each platform/SDK’s debugging toolsets as well.

3.) Platform Requirements & Maturity

In 2012, Vision Mobile’s Cross Platform Developer Tools report indicated that while PhoneGap had a high adoption rate, 27% were abandoning it – likely due to frustrations with the development & debugging experience, coupled with lack of desired native APIs. (Appcelerator Titanium had a slightly higher abandonment rate of 33%.) As predicted, vendors have improved their tooling quite a bit in the last year, though it still has a long way to go. Both Adobe and Telerik are making headway in this area by providing cloud-based build tools alonside other differentiating features. Removing the burden of locally-installed SDKs, improving the debugging experience and reducing the pain of including custom Cordova plugins will likely go a long way towards retaining developers.

There Can’t Be Only One

I would be foolish to not at least mention two of the alternatives to Cordova: Appcelerator Titanium and Xamarin. Titanium provides a cross-platform JavaScript API (giving you some code re-use), while it also focuses on leveraging performant native UI widgets. Xamarin allows you to develop iOS, Android & Mac applications in C# – and even provides the “Xamarin Component Store” which includes UI controls, themes, services, graphs and more. Vision Mobile’s Cross Platform Developer Tools 2012 report indicated that both PhoneGap/Cordova and Titanium could substantially improve retention if they address debugging and development features, and that Xamarin appeared to be climbing in popularity as well.

So – this begs the question: “When do I go with a cross-platform tool?”

  • Do you need to support multiple platforms but don’t have the skills or budget in-house to go native?
  • Is an app store presence a must-have?
  • Do you have existing web skills (or C#, in the case of CPTs like Xamarin) that you want/need to leverage for your mobile application?
  • Is maintaining one code base (and thus synchronizing releases across platforms) a goal?

Answering yes to the questions above (especially the first one) is a good indicator that using a CPT might be your best bet. As to the question of which CPT to use, it depends so heavily on details unique to your circumstance that it’s not easily predictable. Obviously, a heavy .NET shop might favor Xamarin. Companies with available web talent may favor Cordova. The tools provided by vendors can drive things as well. If you target iOS and Android primarily and want to sidestep SDK requirements, easier testing & simulation and a simpler publishing-to-app-store experience, using Icenium is a good option. If you have a custom build tool chain, need to support multiple platforms, want to use Cordova and graft it into your build setup, then PhoneGap Build might be an option. The different alternatives exist because the needs of different apps and companies can vary widely!

Where To Go From Here

In 2011, Marc Andreessen said that “software is eating the world”. It’s clear from current trends that a vast portion of the software to which he refers will be on mobile devices. If you are evaluating alteratives currently, I recommend a small pilot project in 2 or 3 of your top choices to get in-the-trenches experience with them. Once you set a course, find and follow the top voices for that platform or CPT – and become a voice as well.