January 30, 2012

Going Native: Deciding between HTML5 and Native Apps

Almost every publisher I speak with these days is in the midst of developing, implementing or revising their mobile and tablet strategy. With technology changes coming faster than most can keep up, the mobile strategy you developed six months ago (post iPad 2 but pre-Kindle Fire) is most likely out of date.

Yet when speaking to publishers, I find lots of confusion. And the one topic that seems to cause the most confusion is the decision on whether to build native apps. Despite the near-religious debates that often arise on the topic, the decision on whether to go native app or not is based on a handful of straightforward questions you can ask yourself.

So, here’s a starting point for your decision tree on whether to go native.

How many platforms do you plan to support? Are all of your customers (current and intended) on a single platform? How likely is that to change in 6-12 months? For which platforms do you think that you need to provide full support and for which might a simple mobile browser version work? For most publishers, the iPad has emerged as the key tablet platform, with no clear second choice. It’s possible that the Kindle Fire may become a clear number two, but that’s not happened yet. And while smartphones are ubiquitous, the question will be whether your customers view phones as a real way to access your content.

How important is it for you to have your app included in the App Store? If you expect users to discover your app via the App Store, then you’ll need to create a native app. Or, at least put a native app wrapper around your HTML5 app (more on this later). Of course some publishers are choosing to bypass the app store, noting that buried among all the games and social tools, it’s unlikely a user will find your app unless they are specifically searching for it. That said, it’s important to keep in mind that providing an app in the App Store also gives you a way to get screen real estate. In theory, a user can save a browser page to their Home Screen, but I’d wager that fewer than one in ten have figured out how to do this.

Will your app generate revenue? There are many reasons to launch a mobile presence. The obvious one is for revenue generation – either via subscription, in-app sales or advertising/sponsorship. But there are many other reasons to launch. Perhaps it’s a lightly-used mobile companion to a desktop app, or a promotional app for brand awareness. While the latter two may be very important, it will be easier to justify the development and ongoing maintenance for a native app when you can tie it back to revenues.

Do you need both an online and offline experience? This can be a hugely important factor for certain types of apps. For example, news apps like The Daily or the New York Times need to support an offline experience. Readers often download the latest issue before reading it on a subway or airplane. Of course, to keep downloads manageable, the offline versions usually exclude video (which is streamed when online) and other large media formats, but the bulk of the experience can occur offline. But it’s not just news apps – the London Tube app provides maps of the London Tube and is available offline. Surprisingly, some of its competitors only work when connected – hardly useful when you’re on the platform and hear a message that the Jubilee Line has been closed for service.

Do you need to access any special phone features? HTML5 is powerful but there are some things it cannot do. On the iPhone you cannot access the camera, the microphone or the light or gyro sensor with HTML5. That’s not a big constraint for most app developers, but it can be for some. Crowd Fusion client Tecca wanted to embed a bar code scanner in its app. That required a native app.

HTML5 is improving rapidly… but it’s still not the equivalent of an app experience. This is important to understand. If you’re reading this blog post, I assume that you own an iPad. If not, I really recommend that you get one immediately. It’s almost impossible to understand how the app world is changing things if you’re not spending a good portion of your day on the iPad.

As I mentioned above, HTML5 web apps are getting better. But they still seem clunky when compared to comparable apps. Let’s take a look at a few to start:

Electionismis a brand new tablet-only HTML5 based news publication from the Economist. In fact, Economist parent, the FT recently acquired Pressly, the development team that built the Electionism site. I’d like to give kudos to the Pressly team. Electionism is one of the best HTML5 web apps that I’ve seen. Yet it still doesn’t feel quite like a native app.

Music discovery engineWe Are Hunted is another compelling HTML5 web app. It works very smoothly for browsing artists and listening to music, but it’s a fairly limited app. If you want to buy music, the app simply launches out to iTunes for the transaction, then you have to manually return to the browser.

The good news is that HTML5 is improving rapidly. It’s sort of like the early days of AJAX development on the web. AJAX was really cool – you could potentially do things on a website that could previously only be done in a standalone application. But the early AJAX apps were clunky and felt like they were pushing the limits of browsers. That’s sort of where HTML5 stands today. But it’s already a huge improvement over the world of HTML and Flash and will continue to improve dramatically in the coming months.

It’s not an all-or-nothing choice. There are numerous hybrid apps on the market, using HTML5 for all that it can do, but wrapped in a native app wrapper either to provide special functionality or to get into the App Store (though simply putting a wrapper around a pure HTML5 app may not gain approval in the App Store). For Tecca, whom I mention above, while the bulk of the app is serving up content via HTML5, they needed an app wrapper and scanner as part of their offering, so wrapped it all into a native app.

So how do you make your decision? Think about your responses to the questions above. Hopefully, by now, you understand that the native app - HTML5 decision is not based on a set of preconceptions, but rather by the specific needs of your business. And, of course, your strategy can vary by device platform. There's nothing wrong with having an iOS app for the iPad and a compelling HTML5 web app for other mobile platforms, if you believe your most active users will be using the iPad. It's harder to remove an app than to add one - so if you're unsure about a platform, use an HTML5 web app to support that platform until you learn enough to make the decision to invest. And no matter what decision you make today, you'll need to reassess that decision every 3-6 months going forward. Welcome to the exciting world of mobile apps.

Comments

Going Native: Deciding between HTML5 and Native Apps

Almost every publisher I speak with these days is in the midst of developing, implementing or revising their mobile and tablet strategy. With technology changes coming faster than most can keep up, the mobile strategy you developed six months ago (post iPad 2 but pre-Kindle Fire) is most likely out of date.

Yet when speaking to publishers, I find lots of confusion. And the one topic that seems to cause the most confusion is the decision on whether to build native apps. Despite the near-religious debates that often arise on the topic, the decision on whether to go native app or not is based on a handful of straightforward questions you can ask yourself.

So, here’s a starting point for your decision tree on whether to go native.

How many platforms do you plan to support? Are all of your customers (current and intended) on a single platform? How likely is that to change in 6-12 months? For which platforms do you think that you need to provide full support and for which might a simple mobile browser version work? For most publishers, the iPad has emerged as the key tablet platform, with no clear second choice. It’s possible that the Kindle Fire may become a clear number two, but that’s not happened yet. And while smartphones are ubiquitous, the question will be whether your customers view phones as a real way to access your content.

How important is it for you to have your app included in the App Store? If you expect users to discover your app via the App Store, then you’ll need to create a native app. Or, at least put a native app wrapper around your HTML5 app (more on this later). Of course some publishers are choosing to bypass the app store, noting that buried among all the games and social tools, it’s unlikely a user will find your app unless they are specifically searching for it. That said, it’s important to keep in mind that providing an app in the App Store also gives you a way to get screen real estate. In theory, a user can save a browser page to their Home Screen, but I’d wager that fewer than one in ten have figured out how to do this.

Will your app generate revenue? There are many reasons to launch a mobile presence. The obvious one is for revenue generation – either via subscription, in-app sales or advertising/sponsorship. But there are many other reasons to launch. Perhaps it’s a lightly-used mobile companion to a desktop app, or a promotional app for brand awareness. While the latter two may be very important, it will be easier to justify the development and ongoing maintenance for a native app when you can tie it back to revenues.

Do you need both an online and offline experience? This can be a hugely important factor for certain types of apps. For example, news apps like The Daily or the New York Times need to support an offline experience. Readers often download the latest issue before reading it on a subway or airplane. Of course, to keep downloads manageable, the offline versions usually exclude video (which is streamed when online) and other large media formats, but the bulk of the experience can occur offline. But it’s not just news apps – the London Tube app provides maps of the London Tube and is available offline. Surprisingly, some of its competitors only work when connected – hardly useful when you’re on the platform and hear a message that the Jubilee Line has been closed for service.

Do you need to access any special phone features? HTML5 is powerful but there are some things it cannot do. On the iPhone you cannot access the camera, the microphone or the light or gyro sensor with HTML5. That’s not a big constraint for most app developers, but it can be for some. Crowd Fusion client Tecca wanted to embed a bar code scanner in its app. That required a native app.

HTML5 is improving rapidly… but it’s still not the equivalent of an app experience. This is important to understand. If you’re reading this blog post, I assume that you own an iPad. If not, I really recommend that you get one immediately. It’s almost impossible to understand how the app world is changing things if you’re not spending a good portion of your day on the iPad.

As I mentioned above, HTML5 web apps are getting better. But they still seem clunky when compared to comparable apps. Let’s take a look at a few to start:

Electionismis a brand new tablet-only HTML5 based news publication from the Economist. In fact, Economist parent, the FT recently acquired Pressly, the development team that built the Electionism site. I’d like to give kudos to the Pressly team. Electionism is one of the best HTML5 web apps that I’ve seen. Yet it still doesn’t feel quite like a native app.

Music discovery engineWe Are Hunted is another compelling HTML5 web app. It works very smoothly for browsing artists and listening to music, but it’s a fairly limited app. If you want to buy music, the app simply launches out to iTunes for the transaction, then you have to manually return to the browser.

The good news is that HTML5 is improving rapidly. It’s sort of like the early days of AJAX development on the web. AJAX was really cool – you could potentially do things on a website that could previously only be done in a standalone application. But the early AJAX apps were clunky and felt like they were pushing the limits of browsers. That’s sort of where HTML5 stands today. But it’s already a huge improvement over the world of HTML and Flash and will continue to improve dramatically in the coming months.

It’s not an all-or-nothing choice. There are numerous hybrid apps on the market, using HTML5 for all that it can do, but wrapped in a native app wrapper either to provide special functionality or to get into the App Store (though simply putting a wrapper around a pure HTML5 app may not gain approval in the App Store). For Tecca, whom I mention above, while the bulk of the app is serving up content via HTML5, they needed an app wrapper and scanner as part of their offering, so wrapped it all into a native app.

So how do you make your decision? Think about your responses to the questions above. Hopefully, by now, you understand that the native app - HTML5 decision is not based on a set of preconceptions, but rather by the specific needs of your business. And, of course, your strategy can vary by device platform. There's nothing wrong with having an iOS app for the iPad and a compelling HTML5 web app for other mobile platforms, if you believe your most active users will be using the iPad. It's harder to remove an app than to add one - so if you're unsure about a platform, use an HTML5 web app to support that platform until you learn enough to make the decision to invest. And no matter what decision you make today, you'll need to reassess that decision every 3-6 months going forward. Welcome to the exciting world of mobile apps.