The Apple Core

Jason D. O'Grady & David Morgenstern

The benefits of native versus Web apps

By | July 9, 2010, 10:08am PDT

Summary: YouTube’s new mobile site brings up an interesting debate about the benefits of native versus Web apps.

My post yesterday about Google’s launch of an overhauled YouTube mobile site (m.youtube.com) — with features that rival the native YouTube app bundled with iOS — generated an interesting discourse in the TalkBack on the respective benefits of native apps (i.e. from the App Store) versus Web apps.

While I still strongly believe that Google’s gravitation toward Web apps is no coincidence, and that it’s directly related to the smack that Apple’s been talking lately, many of you accused me of wearing my tin foil hat and for starting conspiracy theories. As with any opinion, there will always be two sides. But the TalkBack got me to thinking more about the benefits of native versus Web apps.

Each has its benefits, here’s what I came up with:

Native apps have:

  • Access to more APIs (like the accelerometer and gyroscope) than Web apps (which just got GPS access recently). Although that will change as Apple makes more mobile API’s available.
  • Persistence - allows data to be saved and reoloaded when application launched
  • Multitaking - in iOS 4
  • Integration - with other native apps
  • Marketing - via the App Store
  • Hosting/reporting – via Apple’s iTunes Connect portal

Web apps:

  • Multi-platform - develop once for every mobile browser
  • Instant iteration - no delays
  • No approval process - no limitations placed on content or subject matter
  • No third-party fees - the App Store commands 30% of revenue

One of the more salient points made in the TalkBack was that an app like Star Walk ($2.99, App Store) — that makes use of the many sensors in the iPhone (i.e. GPS, accelerometer) — simply isn’t as good as a Web app, yet. While Apple is certain to slowly expose more and more APIs over time, native apps simply have more options today. An even better example might be one of my new favorite games Eliminate:GunRange ($0.99, App Store) which is now hyper-accurate thanks to its use of the gyroscope hardware in the i4.

Many people don’t like Web apps regardless of how much devs try to make them look like native apps. Google Voice and YouTube do a respectable job, but they still have the iPhone status, URL and search bars at the top and the forward and back arrows, bookmark and page buttons at the bottom. They just look “webby” at the end of the day.

I definitely prefer native apps, which is why I continue to carry an iPhone, but both have their pros and cons.

So I ask you fair reader, which do you prefer? Native or Web apps? More importantly, why?

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Jason O'Grady is a journalist and author specializing in mobile technology. He has published six books on Apple and mobile gadgets and his PowerPage blog has been publishing for over 15 years.

Disclosure

Jason D. O'Grady

Jason D. O'Grady is the creator and editor of O'Grady's PowerPage, which has been publishing mobile technology news since 1995. He maintains an advertising relationship with the following legacy advertisers on the PowerPage:

  • Amazon Associates
  • Google Adsense
  • Tekserve
  • Advertising on the PowerPage is brokered by a third-party agency (BackBeat Media) and he recuses himself from these negotiations.

Biography

Jason D. O'Grady

Jason D. O'Grady developed an affinity for Apple computers after using the original Lisa, and this affinity turned into a bona-fide obsession when he got the original 128 KB Macintosh in 1984.

He started writing one of the first Web sites about Apple (O'Grady's PowerPage) in 1995 and is considered to be one of the fathers of blogging. He has been a frequent speaker at the Macworld Expo conference and a member of the conference faculty. He also co-founded the first dedicated PowerBook User Group (PPUG) in the United States.

After winning a major legal battle with Apple in 2006, he set the precedent that independent journalists are entitled to the same protections under the First Amendment as members of the mainstream media.

O'Grady is the author of The Nexus One Pocket Guide, The Droid Pocket Guide, The Google Phone Pocket Guide, and The Garmin nuvi Pocket Guide (Peachpit Press), the author of Corporations That Changed the World: Apple Inc. (Greenwood Press), and a contributor to The Mac Bible (Peachpit Press). In addition, he has contributed to numerous Mac publications over the years, including MacWEEK, Macworld, and MacPower (Japan).

When he's not writing about Apple for ZDNet at The Apple Core, he enjoys spending time with his family in New Jersey.

35
Comments

Join the conversation!

Just In

RE: The benefits of native versus Web apps
jackson1984-24316069205748857739440257893812 11th Oct
I surfed due to your internet site when I used to be to the lookout for any targeted points. Acquired superior ideas suitable right here! I really hope you dont thoughts if I nfl jerseys 2012 quote you in my especially unique weblog for the duration of the long run
0 Votes
+ -
Pretty amazing.
MSFTWorshipper 9th Jul 2010
I remember a few years ago people were saying that web apps were gonna rule the universe and native apps were on the way out. Web 2.0 and all that nonsense.
So you can write off the second and the third items in your list of native benefits.

And any web page can easily do Hosting/reporting, Apple's iTunes Connect portal could easily be accessed via a web page if Apple allows that to happen so that so-called benefit is artificial and could easily be removed.

And don't forget that marketing via the app store comes with a 30% cut in your income so that's hardly a benefit. Also, if your app gets thrown to the end of the list (a very common occurrence irrespective of merit, it is the timing that counts most) then marketing via the app store is working against you. And don't forget how that Nguyen fellow and his meritless mycompany managed to grab several (50 or so) app store top positions and throw honest developers to the bottom of the list.

To sum things up: of the benefits you propose only 2 survive the test (the first and the fourth) but you forgot an important one, which is speed. Native apps are usually faster. But not necessarily though, as proved by google chrome which will allow native code to run inside the browser.
0 Votes
+ -
@OS Reload

"as proved by google chrome which will allow native code to run inside the browser."

Umm, last I checked, it does do JIT, but that's not the same as running native code directly.

And look at the security nightmare ActiveX bought to IE, do I really want that in Chrome??

" HTML5 has multitasking (web workers) and persistence (local storage)"

If it's anything like Google Gears, which never really worked all that well, I don't want it.

. . . and of course you need a browser that supports it.

. . . and of course the people who design web apps have to start using it.
@CobraA1

Chrome running X86 or Arm binaries. Those binaries are only processor dependent not gadget or OS dependent.

With web Workers and local storage planed to be a part of the HTML5 standard all HTML5 compliant browsers will support Web workers and local storage.

ActiveX belongs to a different era and it is completely irrelevant here. Unlike the modern form to be employed by chrome ActiveX was OS specific, more, it relied heavily on the OS.

People learned a lot with the ActiveX fiasco, we've come a long way since then. Google and everyone must thank Microsoft for showing how NOT to do it.
0 Votes
+ -
@OS Reload

"Those binaries are only processor dependent not gadget or OS dependent."

What is to prevent a native app from making OS-specific calls?

"all HTML5 compliant browsers will support Web workers and local storage."

It's a bit of a wait, though, considering HTML 5 isn't a finished spec yet.

"ActiveX belongs to a different era and it is completely irrelevant here."

Native code is native code. Comes with all of native code's benefits and drawbacks.

"People learned a lot with the ActiveX fiasco, we've come a long way since then."

We did - don't run native code. By its very nature, it has low level access you don't want it to have. That's what we learned.
0 Votes
+ -
they are subject to the same restrictions JavaScript code is. That code is native to the processor, it knows nothing about the OS, the browser is its OS, so it can do nothing that goes beyond the browser. Quite unlike ActiveX.

Those binaries run at the processor full speed and should be used instead of JavaScript only where speed is crucial.

And yes, it is a wait so you can keep working on your native apps, depending on what you need to do it can pay off for a while.
0 Votes
+ -
"Those binaries are not native apps"

Then it's not native code.

"they are subject to the same restrictions JavaScript code is."

Yes, JavaScript with its perfect security.

Oh, wait. Nevermind.

So - how does it manage to restrict native code? JavaScript can do it because the JIT compiler checks the code while it's compiling. But machine code is already compiled.

"That code is native to the processor, it does knows nothing about the OS"

What is to stop devs from writing code that knows about the OS? Magic?
0 Votes
+ -
No, there's no magic
OS Reload Updated - 9th Jul 2010
@CobraA1

Simply ban all operations that can pose a security risk that's all. That 'native' code is not supposed to provide new functionality it's only meant to boost speed. It should be able to do very little but do it very fast.

It's supposed to do fast computations, that's all. It's not to interface with the system or control its functions. There's nothing dangerous it can do that goes beyond hogging the cpu.
0 Votes
+ -
"Simply ban all operations that can pose a security risk that's all."

Including memory access?

Problem is, you can't write a program without accessing memory.

And there's nothing special about accessing the OS: It's just another memory location.
0 Votes
+ -
@OS Reload

"the app store comes with a 30% cut in your income so that's hardly a benefit."

Just how much do you think the overhead is to operate your OWN app store?

Assuming you set up the website, the database, the administration... what would that cost?

Actually, about 30% of the gross on small sales.
0 Votes
+ -
Although Google has done a good job with the web apps they have developed and they are getting better. Their YouTube web app is better because you get the better quality over 3G, so, IMHO, for video content delivery web apps are where it's at. Still native apps are faster, smoother and currently more robust. Some web apps do function offline as well and here I am thinking specifically about the Ibis Reader. It would be nice to have some for direct comparison, web app vs native, but all I have really compared is gmail to iPhones native email app so maybe that's not a true apples to apples comparison.

I am not sure about persistence though, getting back to the Ibis reader (and no I have no financial interest here) it does remember where you left off when you close it so there is some persistance. Likewise the gmail app is storing data locally so you can still look at email already loaded in "airplane mode". IMHO a lot of the native app advantage may become lessened as companies like Google push forward web app development.
0 Votes
+ -
Ibis Reader uses the HTML5 database API for persistence.
0 Votes
+ -
If the API's are open, web apps can get at 'em. Apple closes everything off. Why not talk about Android Native vs. web apps?
0 Votes
+ -
Native apps are much better
P. Douglas Updated - 9th Jul 2010
Many of the benefits we see in computers today, are a result of competition between OS / application platforms. If everyone moves away from OSs as development platforms, competition would end, and application platform development would stagnate. This problem becomes exacerbated by the fact that web specifications are defined by excruciatingly slow web committees. Case in point, note the following excerpts from this article :


" The Web Hypertext Application Technology Working Group (WHATWG) started work on the specification in June 2004 under the name Web Applications 1.0."


"The HTML5 specification was adopted as the starting point of the work of the new HTML working group of the World Wide Web Consortium (W3C) in 2007. This working group published the First Public Working Draft of the specification on January 22, 2008. The specification is an ongoing work, and is expected to remain so for many years, although parts of HTML5 are going to be finished and implemented in browsers before the whole specification reaches final Recommendation status .

According to the W3C timetable, it is estimated that HTML5 will reach W3C Recommendation by late 2010. However, the First Public Working Draft estimate was missed by 8 months, and Last Call and Candidate Recommendation were expected to be reached in 2008, but as of May 2010[update] HTML5 is still at Working Draft stage in the W3C. HTML5 has been at Last Call in the WHATWG since October 2009.

Ian Hickson, editor of the HTML5 specification, expects the specification to reach the Candidate Recommendation stage during 2012, and become a W3C Recommendation in the year 2022 or later. However, many parts of the specification are stable and may be implemented in products :"

So HTML 5 has been in development for 6 years; it has been delayed; and it is not expected to be fully completed until about 2022 - which is 12 years from now. Granted aspects of HTML 5 will be completed and implemented in most browsers within a year or two, but then it may take 3 or more years before 50% of browsers support significant aspects of the HTML 5 standard. In short, the development speed of HTML is a joke compared to the speed of OS platform development.

I personally believe the browser should be considered a publishing platform for primarily free content - e.g. personal blogs, academic resources, free publications by content owners done in large part to drive users to high value content made available in native applications - built on OS platforms that evolve and innovate very quickly. In the enterprise, I think companies like MS should dramatically simplify the deployment and management of native apps on PCs using all kinds of virtualization strategies - including deploying native apps on servers for anywhere access, in lieu of HTML applications. I think the iPad shows how native apps can trounce comparable web apps - resulting in much greater user engagement, and better monetization of content. I think the idea that the browser will one day supplant OSs like Windows and Mac OS is a joke. The fact of the matter is that OSs innovate much more quickly (widening the distance between them and HTML as development platforms over time), and OSs can use virtualization to eliminate just about all the advantages HTML have over native apps - including everywhere access.
0 Votes
+ -
Web apps are much better
OS Reload Updated - 9th Jul 2010
@P. Douglas

Web apps unify development efforts while native apps fragment those efforts.

With web apps you have an industry standard to work against while native development puts you at the mercy of platform vendors and their whims.

On the performance front there's nothing to stop web apps from achieving performance levels equal to native apps as google chrome is about to show.

The only benefit of native development is some form of first mover advantage because initially all new features will only be available natively.
0 Votes
+ -
No they are not
P. Douglas Updated - 9th Jul 2010
@OS Reload,

As I've said before, you need competition among application platforms to drive application innovation. You simply will not get it on a single, standards based application platform - especially one as slow developing as the web.

Are we to be impressed by the web achieving application milestones native apps achieved decades ago? If Apple and MS play their cards right, I don't see why application development won't continue to trend back to the desktop and stay there - as we are now seeing with the iPad.
0 Votes
+ -
"Are we to be impressed by the web achieving application milestones native apps achieved decades ago?"

We could paraphrase that remark of yours to include green tech only the time scale would be larger.

So let me ask you: Are we to be impressed by CFLs achieving what the incandescence light bulb achieved many decades ago?

I, for one, am impressed by the progress in CFLs though I suspect you might want to disagree.
0 Votes
+ -
RE: The benefits of native versus Web apps
Eleutherios 12th Jul 2010
@P. Douglas
You make a couple of good points. One point, however, that you don't mention is that you need to learn specific technologies when you develop native apps (for example Objective-C and Cocoa APIs for the Apple environment), whereas web apps only require general knowledge (HTML, CSS, Javascript, and maybe Ajax).
0 Votes
+ -
"While I still strongly believe that Google?s gravitation toward Web apps is no coincidence"

They are a web company. Therefore, everything is about the web.

Apple is a hardware company. Therefore, everything is about the hardware.

Microsoft is a software company. Therefore, everything is about the software.

It's only natural.

Personally?

I think the future lies in hybrid apps that cover the benefits of both web and native apps.

But maybe I'm just crazy.
@CobraA1

The chrome browser will be able to run native code.
0 Votes
+ -
@OS Reload Goodbye, security. PROVE to me it's not gonna bite them back.
0 Votes
+ -
@CobraA1: It's as secure as JavaScript is
OS Reload Updated - 9th Jul 2010
No more and no less, it is subjected to the same restrictions JavaScript is. It can do nothing JavaScript can't, i's only useful to speed things up, that's all.
0 Votes
+ -
Apple itunes Cut is 30% of a real market, there is no market for web apps! So 70% of the native iPhone app market is infinitely better than 100% of the non existent web app market.
Web apps have their place and can be good or even better than native apps for certain applications - goggles' new youtube web app is a great example.
But you will never be able to leverage the full benefits of a platform with a web app. And web apps will not replace native apps in the next 10 years.

Looking at your list of Web apps benefits:

"Multi-platform - develop once for every mobile browser"
Means lowest common denominator app or lots of conditional cod for different browsers and different os/platform web api's. Not really a benefit?

Instant iteration - no delays - can be done with native apps - the App store process does delay things but that will get better over time.

No approval process - no limitations placed on content or subject matter - true but if you are developer there is no market for non native apps so it is irrelevant

No third-party fees - the App Store commands 30% of revenue as above this is a bug not a feature!
0 Votes
+ -
Things come and go
OS Reload 9th Jul 2010
@kpbpsw

Twenty years ago music cassette sales were good business and look where they went.

iTunes can have the same fate.
0 Votes
+ -
Wake up call: This is not the 1990s
OS Reload Updated - 9th Jul 2010
@kpbpsw

"...lots of conditional code..."

Well into the 21 st no one uses conditional code anymore.

Haven't you heard about standard compliance? (even Microsoft is doing it now.) Or jQuery as an enabler for fallback mechanisms where browser compliance fails?

And all relevant mobile browsers use webkit so there should be no need for conditional code.
0 Votes
+ -
Every browser has is pros and cons. What looks good on Firefox, may not look nice or the same in Chrome, or Opera or IE.

The fact that you don't know that, shows how clueless you are about the topic.
0 Votes
+ -
And one more thing! Right now the company making the best web app interfaces is Apple, Check out the new mobileMe web apps and then look at Google or Microsoft's equivalent web apps! Google still does not get the whole UI thing!
0 Votes
+ -
Web Apps
rmbiggs 9th Jul 2010
For browsers that support html5 there is persistence through session storage, local storage and the SQLite client-side database API. Using the following meta tag: <meta name="apple-mobile-web-app-capable" content="yes"> forces mobile Webkit to hide the browser address bar. Using CSS3 transitions and transforms, you can create seamless and smooth transitions from section to section of your Web app, just like native apps. And you can submit your Web apps to Apple for inclusion in their online Web app list: www.apple.com/webapps
0 Votes
+ -
"but they still have the iPhone status, URL and search bars at the top and the forward and back arrows, bookmark and page buttons at the bottom"

They don't have to. You can create "web apps" using services on your Mac (an example) that can be saved to the "home screen" then used with no chrome. Pretty nice.

http://padilicious.com/photoapp/viewing.html
0 Votes
+ -
The advantage of a native app
wackoae 9th Jul 2010
The top advantage: Fully native apps can run when the network is down. On the other hand, a web based app is down 100% of the time the web connection is down .... for example, while in-flight.
0 Votes
+ -
Wrong
OS Reload Updated - 10th Jul 2010
@wackoae

HTML5 will be able to work when the network is down.

Local storage, does that ring a bell with you? (warning: that question is rhetorical, please don't try to answer.)
0 Votes
+ -
Practical experience
tonymcs@... 11th Jul 2010
I have a 20 year old authoring system for eLearning that was Windows specific. It incorporates a development system and a player. Over the years we've seen most of the problems with developing for a variety of OS versions. From DLL hell in the old days, to the occasional ActiveX that breaks everything.

We'd already virtualised the eLearning player to make it easier to run in a variety of environments, especially the locked down ones, but we still wanted to make it easier to use and even look at the minority markets like Apple.

Our decision was to make the player a web app, but leave the development system as native/desktop. This meant the development could proceed with powerful sophisticated software, while the actual eLearning would be played by a Web player.

The development of a Web player took some time as we had to provide the same features as our native code player without the benefits of an IDE (well I suppose some of the environments almost qualify) and only the help of Javascript/CSS/HTML and something to play the media like WMP/Flash/HTML 5.

It was also difficult in that our eLearning all contains synchronised voice-over, sequential text/graphics/video display and a fixed screen size.

Playing media is a necessity for us and it provided the most difficulty. While people may talk about HTML 5 like it exists, it's only implemented in Safari and the implementation in FF lacks the most basic requirements - such as MP3 playing. Currently we use WMP/Flash and are testing a HTML5 fallback on Safari. Ideally I want MP3 audio and a single format for video. Currently I can use WMP (with the add-in for FF/Chrome etc and Flip4Mac for Apple) or Flash. If I use Flash it won't be playing on the iPad. In the near future, we will probably support just H.264 video and have the Web player choose the most convenient method.

We found IE the easiest to write for, followed by FF and then the pain of Chrome and Safari. The ACID test may be fine, but the real problem is when one of the browser implements one of the crucial things you need slightly differently. There is also a wealth of information available on IE and relatively little for developers on the other browsers.

So we chose a web app for easy distribution and running on multiple platforms. We stayed with desktop for development, as web-based development is slow and clumsy at best. In the end it comes down to different horses for different courses.
0 Votes
+ -
This is a great discussion thread concerning native vs web apps for mobile computing. Regardless of your viewpoint, I think we all agree that business and technical requirements are most important in setting a native vs web app strategy.

I created a dynamic spreadsheet to help marketing and technical teams consider the options in the context of a given project - http://ipadcto.com/mobile-apps-native-or-web/

Cheers! --bf
0 Votes
+ -
RE: The benefits of native versus Web apps
Eleutherios 12th Jul 2010
Jason, I see more benefits / drawbacks to both:
Native apps:
- You need to learn a new language / environment (Objective-C and Cocoa APIs for Apple)
- You're beholden to a company for acceptance of your app (Apple's app store's approval process and bug fix process)
- You need to pay your dues (Dev "tax" in Apple's case)
- You need to develop on a proprietary platform (Mac / OS X in Apple's case)
Web apps:
- You can choose your dev tools and dev platform (but you do need to have a local web server on your WiFi network for testing)
- You just need to be familiar with standards used on all platforms (HTML, CSS, Javascript/Ajax)
- Problem is that you need to have your own "app store" to monetize your apps.
- In some cases, you can automatically "translate" your web apps into proprietary platforms (e.g., PhoneGap)
0 Votes
+ -
RE: The benefits of native versus Web apps
jackson1984-24316069205748857739440257893812 11th Oct
I surfed due to your internet site when I used to be to the lookout for any targeted points. Acquired superior ideas suitable right here! I really hope you dont thoughts if I nfl jerseys 2012 quote you in my especially unique weblog for the duration of the long run

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources
ie8 fix
ie8 fix