The Mobile Publisher Conundrum: Native Apps Or Browser-Based?

Now Serving MobileNow Serving Mobile" is a column focused on the audience-buying opportunity in mobile advertising.

Eric Brown is co-founder of mobile display advertising company Media Armor.

Almost a year ago as part of a survey on the mobile industry, Michael Nevins outlined the display advertising channel. The fuss in mobile most recently has had a particular emphasis on the future of apps and consumer experience: what will the future be, native apps or browser-based ones? 

My opinion of the future, per se, is derived with respect to the technology and how we want it to inform consumer engagement.  Ultimately, it is about the consumer.  And so, when an Advertiser or Publisher is told that they need an app, the decision of if and what to build should come from the end goal of experience.

Defining It

To understand what the future may hold, it's first helpful to define what an application is.  In general terms an application is computer software that allows its user to interact with it.  Simple enough.  The first desktop computers had applications installed on them (e.g. text editors, spreadsheet software).  As technology improved, these stand-alone entities became integrated with the Internet, and the focus and definition of what an app was shifted.  Internet real estate diverged into two categories: content sites and web applications.  Content sites (e.g. a news site) were passive with respect to consumer interaction.  Web applications were more complex, often enabling new interactions like ecommerce and porting traditional desktop applications to hosted solutions online (e.g. Google Docs).

Three things happened in parallel that were pivotal to this metamorphosis:

  1. Devices and their capabilities improved
  2. Web technologies were enhanced
  3. And, data connections became faster.

Sound familiar?  It should, because that is precisely what’s happening right now within mobile.

And just as their desktop brethren, mobile applications can be broken down into both native app and browser-based:

  • Native App:  These are specific to a platform like iOS, Blackberry, Android, Windows, and the late WebOS. They are akin to using Word or Excel on your desktop, and run locally on the device.  They must also be installed before they can be used, and are developed using platform-specific code, leverage the device hardware, and the operating system’s unique capabilities.
  • Mobile Web:  This is the equivalent of an online web site.  The code and content are hosted remotely on servers.  Each time the site is accessed through a browser, a page is rendered. Any changes to the code are present when the site is rendered. Examples of these are content sites like CNN or The New York Times, or e-commerce sites such as Gap.com or Zappos.com.  Any device with a web browser and an Internet connection can access them, and just as online, sites can be broken down into two groups, content and application.

Today, the press loves commenting on the mobile evolution and how everything being developed is a Native App.  Companies like Facebook, Tech Crunch, Twitter, and EBay all currently have them.  This may seem confusing, particularly given the disparity between content publishers and web applications, and yet the reasons for having a native app, hype aside, follow the path of the desktop.  Today, applications sometimes leverage device capabilities, and that requires a native app (e.g. phone camera or contact list).  They are often a bit faster and the functionality they required at the time of creation simply was not available through a web application.

This brings us back to where we began.  Everyone is talking about apps, native or browser-based.  Likewise, everyone is talking about HTML5.

HTML5 is simply the fifth iteration of HTML, the syntax behind the web. Its true promise is that it is a simple, extensible framework that solves for the fact that standards haven’t been updated as part of a major release in 14 years.  Or as analogy, HTML5 represents an enhancement to the ‘grammar’ upon which the web was developed.

Fight Through The Hype

Are native apps necessary, and do you need one?  In short, simply look at the past in order to understand the future.  When considering whether or not to build a platform-specific app, most would benefit from the HTML5 approach as technology evolves.  The reason being is that not only does HTML5 offer consumers a web-based experience that is almost indistinguishable from that of a native app, but it ensures that Publishers and Advertisers only have to support one development process.  For sure HTML5 is new, with standards and technologies still being worked out.  As it matures, however, application owners will no longer be beholden to the app store approval processes, and Advertisers will have a simpler time unifying their various avenues of application-based consumer engagement into once place.  More globally, as mobile devices improve, connection speeds get faster, and HTML5 becomes a proven technology framework, the number of native apps currently maintained will decrease as functionality can be replicated on the web and for the most part native applications developed across different platforms won’t be necessary.

I can’t tell anyone whether or not they need an app, although one thing is for sure: the technology debate should be put to rest.  In the end, it all depends on what is appropriate for you and the experience within which you wish to engage consumers.  For some, like ESPN and The Financial Times, releases of HTML5 apps achieve their engagement goals and are paving the way for increased web browser-specific adoption down the road.  For others, native applications will continue to exist in mobile, as they make more sense for their individual company goals.

And as for me, I’m siding with Fred Wilson:

“HTML5 mobile web apps are taking us back to the web on mobile, where you can follow a link, go from service to service, don't need to download anything, and get shit done. That's a world I want to live in.”

Follow Media Armor (@mediaarmor) and AdExchanger.com (@adexchanger) on Twitter.

1 Comment

  1. Brian Foster

    Very interesting. I find Apple's recent stance with me as quite peculiar and offensive. I have valuable content in the form of images which are copyrighted to my business. I am currently building a Native App for the IPhone and Android markets. It will be free but additional content can be purchased... standard business format for this market. I realised that a great way to increase distribution would be to “white label” this content for third party companies where they would provide additional content unique to their business. These Apps would be uploaded under my developer licence. I thought I would approach Apple to see if this would cause a problem ie. replication of content. I was shocked when they said that it fell foul of 2.20 of the App Store Review Guidelines which refers to “spamming” of the App Store!! I asked for absolute clarification of this as I thought they may have misunderstood my request, their answer stated; “Apps that replicate functionality with different content create clutter in the App Store, hindering users' ability to find apps” and so whilst I completely and utterly disagree I feel it is not worthwhile arguing the point as I could be a marked man! However the point I wish to make is that after reading your article I am now convinced that the third party Apps should be constructed as Web Apps where there would be absolutely no problem with vetting. I really do not think this is a healthy situation but fully understand that they have every right to do this. I found your article extremely useful and has helped me make the decision on how best to achieve my commercial objectives without feeling like a pariah for submitting unsolicited data to the App Store!!

    Reply

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>