I'm not sure if this story is even news worthy but here is my take. Personally, I never really understood why most people flocked to the app store rather than using the already existing www mobile sites? Gmail is a good example -- why would I download the app when I can just go to the mobile site? This is especially true if you're running a pay wall and have to fork over 30% ;) The app needs to be updated constantly but the mobile site doesn't. Am I missing something? I guess you miss out on people searching for your app on the app store.
Native Apps are faster. Frankly, there isn't even a debate to be had. Native low level code will execute faster and be more efficient than web apps rendered in the browser using high level languages like JS. This is of course assuming the app is more than just a UIWebView, though.
Obviously it depends on the site and the quality of each app, but as a rule of thumb a half decent native app will beat out even the best web apps or mobile sites, which I might add are far and few between. Most web apps and mobile sites offer an awful experience.
A great example is Google Music. Why do I prefer the native 3rd party gMusic for iOS over Google's web app? Where do I even begin. How about, every single thing about the native app is better, faster, more responsive and less buggy without one exception, period. That covers it pretty well.
Even if we are talking about something simple like news, there are still huge advantages to native apps. For example, lets say I'm on the subway. I have two iOS devices. I launch the NYT app on one and go to newyorktimes.com in MobileSafari on the other. Which will actually have news on it?
Likewise, the subway goes above ground temporarily and I get a quick 3G spot. I do the same thing. Which will end up with more content, the mobile-fied homepage of NYT, or the much more efficient data pulled down by the app? Native apps still offer advantages that the web can't begin to duplicate. If they didn't, we would all be using Chrome OS right now.
Yes: something like Google Music is currently much better implemented as a native application; the browser support for audio interfaces, particularly in mobile browsers, is very poor. Meanwhile, the UI you want is often very custom for a music player: small, dense, and omnipresent.
However, the NYT example is really poor: the quality difference between an HTML5 offline application and a native application, for that specific use case, is going to be very small, if not downright negligible. The specific issues you brought up involving network connectivity aren't even true.
With the HTML5 offline application cache, all of the HTML, CSS, and JavaScript, will be cached locally, atomically stored and updated in MobileSafari's WebApp cache; you can therefore go to the website, even without any Internet access, and still get the site. If it is implemented well, you will also be able to browse previously downloaded news, which could be stored in HTML5 localStorage or Web SQL.
Finally, due to proxy server limitations, it isn't like the native alternative will be doing anything different than the web application with respect to "pull[ing] down" "more efficient data": both are going to be using HTTP requests, which will have identical overhead, and both could download the same data format.
So, no: I think you are drastically over-generalizing, and should spend some time looking into the more advanced mechanisms that are now available for developing HTML5-based applications on these devices. You may think you have had bad experiences with web applications, but frankly you probably have only ever used one or two (maybe even zero) HTML5 offline applications (they are fairly rare).
> With the HTML5 offline application cache, all of the HTML, CSS, and JavaScript, will be cached locally, atomically stored and updated in MobileSafari's WebApp cache; you can therefore go to the website, even without any Internet access, and still get the site. If it is implemented well, you will also be able to browse previously downloaded news, which could be stored in HTML5 localStorage or Web SQL.
Something nobody has yet to actually do. Sure, it CAN be done. But it's significantly easier to deliver those features with a native app over a web app. Web app developers refuse to ever admit or acknowledge this, but it's 100% true. Web apps just aren't there yet, and won't be any time soon.
> So, no: I think you are drastically over-generalizing
I don't think I am at all. I'm certainly generalizing, but not over or drastically so. You couldn't even provide a single example of a quality web app that fits your previous description. That pretty much says it all.
> You may think you have had bad experiences with web applications, but frankly you probably have only ever used one or two (maybe even zero) HTML5 offline applications (they are fairly rare.
Of course. I don't know what I'm talking about, I'm wrong, and my experiences are invalid for x reason. Responses like this drive me crazy. It's borderline "no true scotsman" IMO. Oh sure, those high profile web apps suck, but those aren't REAL web apps.
The bottom line is even the best web apps still have to utilize the newest technology and options to deliver basic, basic stuff that even crappy native apps have had forever, and they still can't reach the quality of a native app. I'm also completely unconvinced that your browser's rendering engine speed will be able to provide as good an experience as a native app.
The ONLY real advantages to web apps frankly are for the developer. It makes cross platform development & deployment much easier, and they don't have to pay Apple the 30%. It's worse for the user/consumer in almost every way.
I took each of your points, and either ceded them (audio applications) or provided a specific technology that could cover them nicely (HTML5 offline storage, Web SQL, and cache manifests), all of which are easily found in the specifications using Google, if you don't believe they exist.
Your response, which actively ignores all of that (and in fact snips it out of the reply text), is pretty much "I haven't seen it used, so it isn't true"; the only (unrelated) argument you added was "rendering speed" (as if a news reader was limited by that? citation?).
In juxtaposition, I must say you have a convincing argument: it had not even occurred to me that these technologies I and my coworkers use everyday might not actually do these things that they seem to do; certainly not the things the code for them (which is open source) seems to look like it does.
So yeah: I'm sorry. In the future, I will avoid making arguments that respond to points, and instead I'll just say "worked for me: you're not a true scotsman", as apparently that's all that you are capable of seeing in my text anyway.
It can be much easier to separate people from their money using the App Store model.
As soon as you throw up a long-ass payment screen, where I have to fill in name, billing address, CC info, etc, a lot of people will bail, both out of distrust for you and sheer inconvenience (doubly true for platforms with meh text input like phones and tablets).
Compare with integrating with a payment service that is almost guaranteed to already be set up correctly and is a single password away from transaction.
One can hardly emphasize this point enough. iOS users buy shit. The process of buying stuff on iOS is easy, easy, easy. It's unusual for it to be more than just the password prompt and the tiny pause for verification. When buying things is that easy, people buy more, and developers genuinely do make it up on volume. That's why the iOS App Store does so well - it has a solid track record of making money for developers. That's why developers in the iOS App Store put up with the restrictions it imposes - because you can make good money there.
You have to put yourself in the shoes of a normal iPhone user. Many users don't even know how to download apps and therefore never do.
The people who do know to download apps never imagine an "app" can be a "website". Therefore, they look to the "App store" as their first choice whenever they're searching for a solution to their problem (e.g. "oh, I need to know the latest news, let me search on the app store" or "oh, I want pictures of cute kittens, I wonder if they have those in the app store").
Which if you only have a web presence, you're never going to get discovered. That's why many app developers make native app wrappers over their HTML5 webapps - just to solve the discoverability problem.
Is this true? I thought web browsing was one of the primary features of smart phones. I thought it was taken for granted that the phones could browse the web.
Although your explanation does explain the huge number of companies creating stupid apps...
They want space on Apple's valuable digital shelves. It's really no different than selling a product at a retail store in that sense. Some products can do very well being sold directly with no retail partnerships but others depend on being at the end cap of a highly trafficked isle in popular retail stores. Being featured on Apple's top lists, featured, what's hot, or even in some instances an Apple television commercial is huge.
Native apps have push notifications. This is why Google released a Gmail app that is a just a UIWebView. Because there’s no way (yet) to have push notifications on a mobile website.
Agreed. The other thing app developers don't think about is discoverability. You would think you get found easier as a web app, but I would venture to think users still use google to find what they are looking for. If you optimize your web app for mobile users, in the long run, you could be getting more users. Not every app is going to get the Instagram following by just putting themselves on the app store. As patio11 puts it, I believe, Google is the navigation bar for the internet. The appstore isn't.
EDIT: I am a bit biased. Maybe if I was an app developer I wouldn't think this way.
Anyone who subscribes to the FT can attest to just how great their ipad site is. I honestly can't think of a native app that does what they do better, the entire interface is lovely.
They've only been marketing it "for iPad and iPhone", and they use strict user-agent checking against PCs and my blackberry. I could of course be wrong, maybe their marketing doesn't line up with the devices they actually support.
Eh, I doubt it. 1M is pretty impressive for FT's "niche." Unlike the WSJ, it's not dumbed-down for the general public, so it's audience is going to be significantly smaller than a mainstream newspaper.
Shit, now that you've made that good point about their niche I'm starting to rink my first reaction to this. Maybe a million is pretty impressive after all.
News sites are really starting to get their act together and present content in mobile-friendly manners. The Toronto Star just launched an iPad optimized site at read.thestar.com - and it's awesome. They're using Pressly (no affiliation). Highly recommend taking a peek if you're into mobile news design.
A whole million huh? Sorry, I'm really not impressed. Why is this becoming about native versus html5. The article has kind of an anti-Apple subtext to it too. I don't know. There was just something off about the whole post.
Native and web both have pros and cons. Some site used html5 despite the app store trend. Big whoop. I hope people use both in the future and I hope web apps get faster and the app store reduces fees. It's kind of a non story like filler to keep a page on TC filled for a bit.
I thought the whole "Web-apps makers are outsmarting Apple" angle was done by now. One of the reasons these kinds of sites work well is because Apple does a pretty nice job of allowing you to "appify" them. That kind of support makes it really nice, and shows that Apple is not trying to force people into the App Store. You might argue they overcharge you for using the App Store, but mobile web apps, when done well, are serious contenders for certain use cases. So there's really no reason to focus on this kind of drama.
