It's sort of amusing to continually hear these arguments because they always miss the main point: It doesn't matter what you, as a dev, prefers or envisions. It's about what the user wants. Today they prefer native apps. They look and generally perform better. There may be a day when web apps catch up but it will be up to the user to decide which path is taken.
This is an important point, the users decide the experience of their computers to a great extent, whether they understand what they're doing or not. Which brings up another point, that for web apps to become more popular than native apps, internet connectivity is going to have to get much better everywhere. The average user doesn't like it much when a program they use doesn't work at full functionality because they don't have an internet connection, and they definitely wont like it if they cant access their apps at all.
> It doesn't matter what you, as a dev, prefers or envisions. It's about what the user wants.
That's a nice theory. Here's the reality:
1) Client wants to build 4 native apps for Android, iPhone, iPad, Blackberry, WinMo7.
2) Client is in sticker shock that it will cost $100k+ to roll out
3) Client does a bit of googling, drawn like a deer in headlights to the Titanium showcase page
4) Client ditches native apps, goes the Titanium route because it's cheaper, doesn't realize that most of those are funded directly or indirectly by Titanium
5) Client fails to monetize application because users think it sucks.
6) Chalks it up to "the market isn't ready", repeat from step 1.
This story is roughly 75% of the mobile contracting market by volume, although for obvious reasons <1% in terms of app sales. It comes up a lot in enterprise mobile dev as well.
The moral of the story is that it's much easier to focus on the upfront development cost and ignore the unquantifiable murky cost of ending up with a bad product. It's the same thought process behind e.g. credit card debt--present pleasure for future pain is easy to rationalize.
>5) Client fails to monetize application because users think it sucks.
Cute theory, but lots of good apps failed to get monetized as well, even when users like them (say 4.5 stars, and lots of great reviews?).
The failure can be in the promotion or marketing of apps at this point. There are too many apps out there for good apps to be discoverable without promotion.
Also, good and bad UI can be written in native and HTML/JavaScript. Some apps really don't need native to be good. It really depends on the app; the content and the UI design really trump fancy native-only effects.
I infer from your list that you're talking about small businesses. They are your customer and I believe that the customer is always right. The employee may be the tail that wags the dog but they do not pay you. They should be aware of the pitfalls of web apps:
1. They're generally not as fast as native web apps. At the very least they don't appear to be so.
2. A user/employee is more familiar with apps that are native and they will understand them better than a web app.
It is up to your customer to know what they're willing to sacrifice, immediate cash or the quality and recognition of their product in the long run.
Your analysis on Titanium development being cheaper and "sucks" is false. It's the archer not the arrow. My company builds full stack solutions for clients with projects of $50k - $100k. We work in obj-c, java, javascript and c, with the bulk of development dedicated to Titanium.
You are patently wrong in your assessment and seem to miss some major aspects of the Titanium architecture.
The problem with webapps right now is that they look and perform badly.
I just tried to make a multi-touch piano keyboard work in-browser using html5. The only thing that worked was the graphics, since that was a single image! The chances of playing a sound when the user presses a key in any kind of cross-browser way seems shot.
Html has been around for decades and its still not fit for purpose.
HTML is perfectly fit for the purpose for which it was designed - presenting content in a way that different pages of content can link to each other. It's only recently that people have begun to use it as a platform for applications.
The biggest draw for me with native apps is the revenue model. Most users are conditioned to think if it opens in a browser, then it should be free. It really doesn't matter to me if i'm programming in Java, Objective C, or some HTML/Javascript framework... but can I justify spending time without a simple way to charge for my product?
Solve the monetization problem and I guarantee developers will look at web apps more seriously.
This is a really good point and often overlooked. A native app gives you a sense of ownership--a subtle yet powerful concept that attaches value to the application. I'd like to think I'm above such psychological games, but I know I've paid real money for apps that I wouldn't have paid for things delivered through a URL. Also, the common way to bill for a webapp is with recurring fees. But not everything fits that mental model of a monthly service very well. For example, it feels better to me to pay a one-time fee for a todo list app than to pay $5/mo--even if it worked out to where I was spending the same amount annually.
I've done usability studies with users who use native apps and PhoneGap-based apps and users are clearly perplexed by PhoneGap apps because of numerous usability problems like 1) they're choppy, 2) they look/feel slightly different, 3) they don't behave like user's think they should. Users can tell the difference between a fully-native app and an HTML interface wrapped in an Objective-C downloadable.
It's like the uncanny valley where humanoid things get so close to being fully realistic that the small difference in their behavior or look & feel causes people to be totally turned off. If it looks like a native app but doesn't quite behave like one, it's noticeable and (at least the people I've talked with) do not like it.
hmmm...there's part of me that's just offended by the idea of having to write an application twice.
Maybe the HTML5 experience isn't good enough, but it truly sucks to have to write the app once for each platform.
I'd love to see the specific examples you're talking about; details like whether the apps were made by people with equivalent skills, and whether you're REALLY talking about the same app being judged better or worse.
Because it's so easy to write HTML5 and JavaScript, well, lots of idiots do it. If the study compares an app written by a median HTML5/JavaScript app developer with an app written by a median ObjectiveC developer, then it's not the environment you're actually comparing.
It's the norm to have to write applications for the platform you want to run them on. Nintendo 3DS, Playstation 3, Wii, Steam, Android, iOS, Windows... these are all different platforms. Write-once-run-anywhere is a myth and it seems that web developers deploying to one platform (the browser) still can't grok the idea of multi-platform development that desktop, mobile and game developers have understood for years.
You can't get the best experience for each platform if the tools and frameworks you use are dumbed down to accommodate the lowest common shared experience across everything.
I actually do my development in cross-platform native code. My currently library can target iOS, Android, and Windows, and I'd be able to add most other major platforms pretty trivially.
I agree that some UI changes are necessary between platforms as different as the PC, the Wii, and a touch-screen-based phone. But I very much disagree that you can't take advantage of solid cross-platform tools. I've written such tools, in fact.
Some native code to interface to native UI is necessary, but none of the native UI is really rocket science, and something offered natively on one phone can typically be done manually on another. Then it becomes an abstraction in the cross-platform library, and your code doesn't need to know how it's implemented.
But then again I'm a game developer, so I guess you've admitted that I could potentially already understand cross-platform development. ;)
Have you used Sencha Touch or the other mobile app frameworks? They're good but not great. There's still a real difference in the user experience between them and building a real, native app. It's fairly obvious due to clunky scrolling and choppier animations throughout the app.
No, thought I've read about Sencha Touch and several others.
I am planning on having a Web-app component to my next product, actually, and have been reading about them all; Dojo and jQuery Mobile are the two finalists I'm considering.
But the primary app is a game, and the production values for games make doing them entirely as web apps not an option.
Clunky scrolling would be a problem, sure, as well as choppy animations. I'll have to see what can be done when I actually dive in to writing the HTML5/CSS components.
The thing is, it's certainly POSSIBLE for web apps to animate better than they do. It may not be time for web apps to take over on phones, but it's only a matter of time. Processors in phones are getting more powerful, and the WebKit-based browsers are being optimized; scrolling animations really shouldn't be significantly slower done in JavaScript than they are in, e.g., Java on Android.
Here is my thought process when it comes to the issue.
1. What problem am I trying to solve?
2. Which technology choice provides the best solution to the problem and the best UX? Which one does the user prefer?
3. Implement it.
That said, the author of this post is absolutely right in regards to the browser being a limited cross-platform solution available everywhere vs native apps being specialized solutions for a given platform.
Even developing the client side of a web app in HTML5, CSS3, JavaScript so that it's fast and it works in most browsers is still more complicated and tedious than anything you experience when building native applications.
There are two main advantages to web applications, though:
* A potentially larger audience (addressed in the post).
* The ease with which users accept to pay a recurring monthly fee. It can be emulated via in-app subscriptions, but let's face it, it's less common and/or accepted by users.
I wonder if this is one reason why World of Warcraft does all transfers of real money through your account on the website instead of offering an in-game store. On the other hand, I have played other MMOs, online FPSes, and so forth that have in-game stores.
Come to think of it, the only correlation I can think of is that web applications are more prolific for online sales than desktop apps, which typically relied on a model of "buy me, install me, and you own me". My experience in the gaming world suggests that people are happy to pay for things within the desktop game interfaces, too. I have also read that iPhone apps with in-app sales (particularly for free apps) are greater than the initial app sales, and it is obvious that users have no problems making payments for things through their phone apps.
I assumed that "web app" refers to things that must be run through a web browser, as opposed to "app that can connect to the Internet", which will cover recurring subscriptions like Norton's latest virus updates and so forth.
"Apple did not want to allow native apps on the iPhone, and was pushed into it by the overwhelming strength of the jailbreak community. People wanted the better user experience provided by native apps, and if Apple wouldn't allow it, they would do it themselves."
Maybe I'm ignorant.. but how is this true? Apple could have NOT release the API for creating iPhone apps, and there wouldn't be any iPhone apps. You can crack, jailbreak, hack, and hax0r all you want. No API, no native app.
There is always an internal API or even kernel level functions that can be used. Of course, they may break in the next update but you can use the same way of reading input, displaying graphics, getting device location as, say the mail client and Maps.
Remember the iPhone is, inside, a Darwin system. Put a terminal, and the sky is the limit. Plus, there is always an API. The API, in the first days, wasn't public, but it was there. The base apps included (calendar, browser, etc) needed it.
And there was an app store (well, a fully free store) before Apple even released their APIs. I don't know how people discovered the APIs (reverse-engineering ? Leaks from Apple ?), but they had them.
There was several native apss written before thte SDK was released. The game Trism was one of them.
I still don't believe Apple "was pushed into it by the overwhelming strength of the jailbreak community". Apple must have had it planned, even before the SDK and the Appstore infrastructure was ready. The web app-only strategy was retarded; no one wanted that, and Apple knew it. Still, consumers would never accept the walled garden model if it was enforced after native apps were allowed. Web apps were only a surrogate until the Appstore was ready, but they couldn't market it like that, could they?
While i find this discussion interesting to some extent, I find it odd that no one mention that the native and web applications use cases do not overlap completely.
We have text editors IDEs, command line utilities, etc. not every application needs to interact with a network. More importantly, not every web aplication is some kind of fancy CRUD interface, we do a lot more with computers than managing our online presence.
Native vs Web isn't what you should think about. At a higher level, what matters is whether the software you're using or writing is centralized or distributed.
Anything that does not specifically require decentralization probably should be written as a web service.
If Apple doesn't want your app published, good luck providing that "better experience".
The smart money is in making a web app for everyone first, perhaps not with all the bells and whistles, but sufficiently functional, and then making platform-specific apps.
Regarding "offering the same lowest common-denominator user experience on all devices"—know your audience. You don't have to make your app pixel-perfect for IE 6 if iOS users are all you're targetting. Web browsers "degrade" gracefully.
One of the features of web apps is that they can be anything—"the web is open". Mobile native apps are (often solely) available through app stores which are dictatorships, controlling when—and if—your app and its updates are released.
But that's a fallacy - web apps can't be "anything". For example, right now they can't pulse phone's vibrate function, or turn on camera flash LED if your stock hits a certain price. Yes, maybe some day they will, through a "camera flash control XHTML extension", but by then we'll want those same apps to also toggle the built-in hologram projector.
That's true—I wasn't thinking about the more hardware-focused apps at the time (rather the Apple-won't-allow-that kind).
Regarding "camera flash control XHTML extensions", Mozilla's WebAPI[1] is trying to provide a standard API to interact with (namely) phones' software and hardware.
It depends on which app your creating, doesn't it? Google's Marketplace for Android is completely open but they don't have the users purchasing apps as they should.
Many web apps haven't proven to be financially profitable except a well-publicized few,
Let's face it: The "dictatorship" metaphor was fun (Remember the cartoons with the X-wing fighter torpedoing the AT&T Death Star logo? Good times.) but it was probably overwrought even back in the old days when DOS software and Mac software and each of the 23 different Unices were binary incompatible and emulation was dog slow and virtualization was like science fiction and choosing a platform felt like proposing marriage. But now? It might even be a dangerous line of thinking. You need to learn to think like your customer, and they don't see this oh-so-crucial distinction between "native apps" and "web apps". Except to the extent that web apps are a trifle more difficult to find: Instead of finding the pretty icon and touching it, you have to touch Safari and then type the name of your desired app into the Googles.
(No, of course the average customer doesn't know how to bookmark a URL. They don't know what a URL is.)
A defining characteristic of the metaphorical "dictatorship" is that people can't vote. In particular: They can't vote with their feet, because the wall is too high or the ocean too wide or the border guards (on whichever side of the border) are too expensive to bribe. But there are only two kinds of native-app platforms today:
A) The platforms in which a full-featured HTML5-compliant browser is at most two clicks away at any time;
B) The platforms that are being crushed to death by iOS, Android, and the other platforms in Category A.
Where's the big barrier here? Half of my native apps embed entire HTML5 web pages. Or they link out to HTML5 web pages. Meanwhile, an increasing quantity of web pages prompt me to install native apps. The answer to "web apps or native apps" is "both", to the degree that they interpenetrate and are inseparable, and what reason is there to believe that this won't continue?
Developers obviously care about their release schedules and their profit share and the backend technology underlying each and every screen on the phone, but customers don't know and they don't much care.
More than anything I meant the allusion to a dictatorship as to the fact that Apple can decide whether they want your app or not, and can decline it for any reason. (And I agee, it's a worn metaphor but I couldn't come up with a more succinct description.)
> Web apps are a trifle more difficult to find
That's pretty much my point—Apple want to control what you put on their devices. Remember when they were touting web apps[1]? Look at the page now. Most recent: 12/03/2010. iPhone 3Gs. They dropped that as soon as they realised they were harming their profits with the App Store.
Does Apple make money from the App Store? Last I heard it covered its costs and Apple made from from selling extremely high margin devices.
Also, how do you reconcile the idea of an Apple who wants to maximise profits from the App Store with an Apple who limits what apps can be sold through that store? They're literally turning down paying customers in the App Store because they think it'll hurt their real business, selling devices.
Looking at it only from a technology viewpoint is parochial. The non-tech view is that the whole app experience is fragmented. Apps that hardly talk to each other. Apps that need to be updated every few weeks if not more often if I want fixed bugs or newer available features. Apps that behave differently if I move to a device running on a different platform.
But then, that is only half the story. Apps that can use the power of deep access on front end, on top of a strong thing on the back end - those are the apps which are really making use of native story to build a more useful product than otherwise would have been possible.
Im a web developer and I agree with the speaker. Native apps are cool and have shown what people really want from their interface but are only a stepping stone. Web apps/browsers will catch up to native apps in capability and surpass them value. see WebAPI http://hacks.mozilla.org/2011/08/introducing-webapi/
Web development seems to be trending towards full client-side MVC application frameworks, not unlike those used by native developers. It leaves me wondering what the browser really brings to the table?
As we are reaching the point where the browser is a poor mans virtual machine and nothing more, why not just provide a virtual machine and let HTML be just another application on the virtual machine?
Couldn't agree more. As HTML APIs further develop they'll allow access to those parts of a device that only lower level/native languages have had access to so far. Question is When not If.
Hmm. In my experience this is not true. Everyone in northern europe is having apps made because it's something you need to do, but they are gambling on web apps. Repackaging via Phonegap works there if written correctly, but I don't see any native app feelings.
Native Apps are here to stay because it is impossible to build a certain class of Apps in the web browser.
There is no way to upload files on Mobile Safari. I'm told this has finally been implemented in Android 2.2. It's 20-frackin-11 and an App like Instagram is not even possible as a Web App.
App developers use Push Notifications to increase engagement with their App and notify users when something interesting happens. Ditto, for Local Notifications and Background Location. That's not even possible with Web Apps.
The new hotness in 2012 will probably be NFC. Web Apps probably won't have access to hardware data exchange for years.
And the list will keep going on. There will be new functionality in mobile phones released each year. Native Apps will get access to this functionality right away. Web Apps will have to wait for years to get access to this functionality.
> Native Apps are here to stay because it is impossible to build a certain class of Apps in the web browser.
Even current usages have issues. A few hours ago I decided I wanted to move a bunch of RSS feeds into Google Reader so I could prototype a new tool I'm working on.
So easy enough, create new Google Apps account, populate RSS feeds.
I'm not sure what was going on but my Google Apps admin console kept timing out. No idea what the problem was, my wifi, my ISP, international cable, some erroneous proxy, Google apps itself I dunno... maybe the bad/stormy weather outside... But it took me over 5 minutes to create a new user account.
Everything else seemed to be running fine so I thought it would correct itself. However after about 10-15 minutes of no improvement and very slow progress. I gave up trying to add RSS feeds (and put them into folders) via the web.
Annoyed at this point I downloaded an RSS client, added all the feeds I wanted, exported the OPML and uploaded it to google in around 10 minutes.
To do a simple chore I had to revert to a native client, and that is the reason why native apps are here to stay for me.
They are reliable and fast, ignoring other benefits. Web apps in a lot of use cases just aren't upto task.
This is unreadable and unconvincing. Why is it rated up? You could make a reasonable argument supporting the headline, but he doesn't. There's no logical weight behind his conclusions and no evidence that he's actually thinking about any evidence, and the cherry on the top is that he uses inflammatory phrases like 'unquestionably flawed', and then making random arguments about presentation vs data. Plus, web applications are 'by their very nature unoptimized'.
The only conclusion I could draw is that this guy is an iOS developer who likes developing native apps. Fine with me, but he doesn't go anywhere from there.
There is the third option of hybrid native/web applications, which I haven't seen considered here.
One example is the Adobe Integrated Runtime, or AIR, which "... intends to provide a versatile runtime-environment that allows existing Flash, ActionScript, or HTML and JavaScript code to be used to construct Internet-based applications that have many of the characteristics of more traditional desktop-like programs." - http://en.wikipedia.org/wiki/Adobe_AIR
Another example of a hybrid option, one which is much simpler than AIR, and which I haven't seen anyone really trying, is where the application is sold without a GUI of its own. You interact with it through your browser, and it acts as your proxy to the Internet. This allows for increased computation, better display, and optimized communication, such that the experience is somewhere between pure web app and pure native app. The customer gets the good feeling of "owning" the thing for which they paid, and the developer's work is simplified by using the browser as a cross-platform GUI.
HTML is capable of anything, given the makers of browsers will it to be so. There's nothing inherently special about "native" technlogies, other than OS makers tend to give new features to the platforms they own first. It doesn't have to be this way, but will probably remain so, because the leading OS makers (once Microsoft, now Apple) have the discretion to throttle the flow of new goodies into their web browsers, and it would seem they often do. Really, how else can you explain the fact that Safari in iOS 5 still lacks the ability to utilize the camera?
I used to say native applications were the only way to do a lot of things like photo editing. Since then I have been proven wrong in finding photo editing and even audio production tools running in web browsers. Not the highest end stuff, but useful enough. Javascript has come a long way and Canvas really reorganizes the playing field.
The thing I am realizing is both Apple and Microsoft have extremely unstable APIs that are driven by political or maybe stupidity purposes (some non-engineering reason), where perfectly good software just stops working because some bureaucrat at the Duopoly decided to nix something for arbitrary or foolish reasons.
But you can't do this with HTML apps, since it's not a monopoly, duopoly, or oligarchy, it's an actual competitive market for browsers. If your browser decides to stop supporting HTML4, it's broken and no one will use it.
This means you can write once for web apps and be confident it will continue to work forever.
That's a huge advantage and has changed the way I think about things. Now I am of the opinion that if there is any possible way to make something run in the browser, that is the preferred and superior choice. It's also instantly Mac/PC and Linux cross compatible too.
51 comments
[ 3.0 ms ] story [ 95.8 ms ] thread[1] http://diveintohtml5.org/offline.html
That's a nice theory. Here's the reality:
1) Client wants to build 4 native apps for Android, iPhone, iPad, Blackberry, WinMo7.
2) Client is in sticker shock that it will cost $100k+ to roll out
3) Client does a bit of googling, drawn like a deer in headlights to the Titanium showcase page
4) Client ditches native apps, goes the Titanium route because it's cheaper, doesn't realize that most of those are funded directly or indirectly by Titanium
5) Client fails to monetize application because users think it sucks.
6) Chalks it up to "the market isn't ready", repeat from step 1.
This story is roughly 75% of the mobile contracting market by volume, although for obvious reasons <1% in terms of app sales. It comes up a lot in enterprise mobile dev as well.
The moral of the story is that it's much easier to focus on the upfront development cost and ignore the unquantifiable murky cost of ending up with a bad product. It's the same thought process behind e.g. credit card debt--present pleasure for future pain is easy to rationalize.
Cute theory, but lots of good apps failed to get monetized as well, even when users like them (say 4.5 stars, and lots of great reviews?).
The failure can be in the promotion or marketing of apps at this point. There are too many apps out there for good apps to be discoverable without promotion.
Also, good and bad UI can be written in native and HTML/JavaScript. Some apps really don't need native to be good. It really depends on the app; the content and the UI design really trump fancy native-only effects.
1. They're generally not as fast as native web apps. At the very least they don't appear to be so.
2. A user/employee is more familiar with apps that are native and they will understand them better than a web app.
It is up to your customer to know what they're willing to sacrifice, immediate cash or the quality and recognition of their product in the long run.
You are patently wrong in your assessment and seem to miss some major aspects of the Titanium architecture.
Read this documentation: http://developer.appcelerator.com/apidoc/mobile/1.4/Titanium... and tell me how I should use custom fonts. I reported this issue in early July.
I just tried to make a multi-touch piano keyboard work in-browser using html5. The only thing that worked was the graphics, since that was a single image! The chances of playing a sound when the user presses a key in any kind of cross-browser way seems shot.
Html has been around for decades and its still not fit for purpose.
Unless of course he's totally supportive of using a hyperTEXT markup language to write applications, I don't know.
Solve the monetization problem and I guarantee developers will look at web apps more seriously.
It's like the uncanny valley where humanoid things get so close to being fully realistic that the small difference in their behavior or look & feel causes people to be totally turned off. If it looks like a native app but doesn't quite behave like one, it's noticeable and (at least the people I've talked with) do not like it.
Maybe the HTML5 experience isn't good enough, but it truly sucks to have to write the app once for each platform.
I'd love to see the specific examples you're talking about; details like whether the apps were made by people with equivalent skills, and whether you're REALLY talking about the same app being judged better or worse.
Because it's so easy to write HTML5 and JavaScript, well, lots of idiots do it. If the study compares an app written by a median HTML5/JavaScript app developer with an app written by a median ObjectiveC developer, then it's not the environment you're actually comparing.
You can't get the best experience for each platform if the tools and frameworks you use are dumbed down to accommodate the lowest common shared experience across everything.
I agree that some UI changes are necessary between platforms as different as the PC, the Wii, and a touch-screen-based phone. But I very much disagree that you can't take advantage of solid cross-platform tools. I've written such tools, in fact.
Some native code to interface to native UI is necessary, but none of the native UI is really rocket science, and something offered natively on one phone can typically be done manually on another. Then it becomes an abstraction in the cross-platform library, and your code doesn't need to know how it's implemented.
But then again I'm a game developer, so I guess you've admitted that I could potentially already understand cross-platform development. ;)
I am planning on having a Web-app component to my next product, actually, and have been reading about them all; Dojo and jQuery Mobile are the two finalists I'm considering.
But the primary app is a game, and the production values for games make doing them entirely as web apps not an option.
Clunky scrolling would be a problem, sure, as well as choppy animations. I'll have to see what can be done when I actually dive in to writing the HTML5/CSS components.
The thing is, it's certainly POSSIBLE for web apps to animate better than they do. It may not be time for web apps to take over on phones, but it's only a matter of time. Processors in phones are getting more powerful, and the WebKit-based browsers are being optimized; scrolling animations really shouldn't be significantly slower done in JavaScript than they are in, e.g., Java on Android.
1. What problem am I trying to solve?
2. Which technology choice provides the best solution to the problem and the best UX? Which one does the user prefer?
3. Implement it.
That said, the author of this post is absolutely right in regards to the browser being a limited cross-platform solution available everywhere vs native apps being specialized solutions for a given platform.
Even developing the client side of a web app in HTML5, CSS3, JavaScript so that it's fast and it works in most browsers is still more complicated and tedious than anything you experience when building native applications.
There are two main advantages to web applications, though:
* A potentially larger audience (addressed in the post).
* The ease with which users accept to pay a recurring monthly fee. It can be emulated via in-app subscriptions, but let's face it, it's less common and/or accepted by users.
Come to think of it, the only correlation I can think of is that web applications are more prolific for online sales than desktop apps, which typically relied on a model of "buy me, install me, and you own me". My experience in the gaming world suggests that people are happy to pay for things within the desktop game interfaces, too. I have also read that iPhone apps with in-app sales (particularly for free apps) are greater than the initial app sales, and it is obvious that users have no problems making payments for things through their phone apps.
I assumed that "web app" refers to things that must be run through a web browser, as opposed to "app that can connect to the Internet", which will cover recurring subscriptions like Norton's latest virus updates and so forth.
"if you follow my TOS"
Maybe I'm ignorant.. but how is this true? Apple could have NOT release the API for creating iPhone apps, and there wouldn't be any iPhone apps. You can crack, jailbreak, hack, and hax0r all you want. No API, no native app.
And there was an app store (well, a fully free store) before Apple even released their APIs. I don't know how people discovered the APIs (reverse-engineering ? Leaks from Apple ?), but they had them.
I still don't believe Apple "was pushed into it by the overwhelming strength of the jailbreak community". Apple must have had it planned, even before the SDK and the Appstore infrastructure was ready. The web app-only strategy was retarded; no one wanted that, and Apple knew it. Still, consumers would never accept the walled garden model if it was enforced after native apps were allowed. Web apps were only a surrogate until the Appstore was ready, but they couldn't market it like that, could they?
We have text editors IDEs, command line utilities, etc. not every application needs to interact with a network. More importantly, not every web aplication is some kind of fancy CRUD interface, we do a lot more with computers than managing our online presence.
Anything that does not specifically require decentralization probably should be written as a web service.
The smart money is in making a web app for everyone first, perhaps not with all the bells and whistles, but sufficiently functional, and then making platform-specific apps.
Regarding "offering the same lowest common-denominator user experience on all devices"—know your audience. You don't have to make your app pixel-perfect for IE 6 if iOS users are all you're targetting. Web browsers "degrade" gracefully.
One of the features of web apps is that they can be anything—"the web is open". Mobile native apps are (often solely) available through app stores which are dictatorships, controlling when—and if—your app and its updates are released.
Regarding "camera flash control XHTML extensions", Mozilla's WebAPI[1] is trying to provide a standard API to interact with (namely) phones' software and hardware.
[1] http://hacks.mozilla.org/2011/08/introducing-webapi/
Many web apps haven't proven to be financially profitable except a well-publicized few,
The 1990s called. They want their metaphor back.
Let's face it: The "dictatorship" metaphor was fun (Remember the cartoons with the X-wing fighter torpedoing the AT&T Death Star logo? Good times.) but it was probably overwrought even back in the old days when DOS software and Mac software and each of the 23 different Unices were binary incompatible and emulation was dog slow and virtualization was like science fiction and choosing a platform felt like proposing marriage. But now? It might even be a dangerous line of thinking. You need to learn to think like your customer, and they don't see this oh-so-crucial distinction between "native apps" and "web apps". Except to the extent that web apps are a trifle more difficult to find: Instead of finding the pretty icon and touching it, you have to touch Safari and then type the name of your desired app into the Googles.
(No, of course the average customer doesn't know how to bookmark a URL. They don't know what a URL is.)
A defining characteristic of the metaphorical "dictatorship" is that people can't vote. In particular: They can't vote with their feet, because the wall is too high or the ocean too wide or the border guards (on whichever side of the border) are too expensive to bribe. But there are only two kinds of native-app platforms today:
A) The platforms in which a full-featured HTML5-compliant browser is at most two clicks away at any time;
B) The platforms that are being crushed to death by iOS, Android, and the other platforms in Category A.
Where's the big barrier here? Half of my native apps embed entire HTML5 web pages. Or they link out to HTML5 web pages. Meanwhile, an increasing quantity of web pages prompt me to install native apps. The answer to "web apps or native apps" is "both", to the degree that they interpenetrate and are inseparable, and what reason is there to believe that this won't continue?
Developers obviously care about their release schedules and their profit share and the backend technology underlying each and every screen on the phone, but customers don't know and they don't much care.
> Web apps are a trifle more difficult to find
That's pretty much my point—Apple want to control what you put on their devices. Remember when they were touting web apps[1]? Look at the page now. Most recent: 12/03/2010. iPhone 3Gs. They dropped that as soon as they realised they were harming their profits with the App Store.
[1] http://apple.com/webapps
Also, how do you reconcile the idea of an Apple who wants to maximise profits from the App Store with an Apple who limits what apps can be sold through that store? They're literally turning down paying customers in the App Store because they think it'll hurt their real business, selling devices.
But then, that is only half the story. Apps that can use the power of deep access on front end, on top of a strong thing on the back end - those are the apps which are really making use of native story to build a more useful product than otherwise would have been possible.
As we are reaching the point where the browser is a poor mans virtual machine and nothing more, why not just provide a virtual machine and let HTML be just another application on the virtual machine?
We've tried making them work, but mobile browsers just aren't good enough yet to process the JS at a reasonable speed.
There is no way to upload files on Mobile Safari. I'm told this has finally been implemented in Android 2.2. It's 20-frackin-11 and an App like Instagram is not even possible as a Web App.
App developers use Push Notifications to increase engagement with their App and notify users when something interesting happens. Ditto, for Local Notifications and Background Location. That's not even possible with Web Apps.
The new hotness in 2012 will probably be NFC. Web Apps probably won't have access to hardware data exchange for years.
And the list will keep going on. There will be new functionality in mobile phones released each year. Native Apps will get access to this functionality right away. Web Apps will have to wait for years to get access to this functionality.
Even current usages have issues. A few hours ago I decided I wanted to move a bunch of RSS feeds into Google Reader so I could prototype a new tool I'm working on.
So easy enough, create new Google Apps account, populate RSS feeds.
I'm not sure what was going on but my Google Apps admin console kept timing out. No idea what the problem was, my wifi, my ISP, international cable, some erroneous proxy, Google apps itself I dunno... maybe the bad/stormy weather outside... But it took me over 5 minutes to create a new user account.
Everything else seemed to be running fine so I thought it would correct itself. However after about 10-15 minutes of no improvement and very slow progress. I gave up trying to add RSS feeds (and put them into folders) via the web.
Annoyed at this point I downloaded an RSS client, added all the feeds I wanted, exported the OPML and uploaded it to google in around 10 minutes.
To do a simple chore I had to revert to a native client, and that is the reason why native apps are here to stay for me.
They are reliable and fast, ignoring other benefits. Web apps in a lot of use cases just aren't upto task.
The only conclusion I could draw is that this guy is an iOS developer who likes developing native apps. Fine with me, but he doesn't go anywhere from there.
One example is the Adobe Integrated Runtime, or AIR, which "... intends to provide a versatile runtime-environment that allows existing Flash, ActionScript, or HTML and JavaScript code to be used to construct Internet-based applications that have many of the characteristics of more traditional desktop-like programs." - http://en.wikipedia.org/wiki/Adobe_AIR
Another example of a hybrid option, one which is much simpler than AIR, and which I haven't seen anyone really trying, is where the application is sold without a GUI of its own. You interact with it through your browser, and it acts as your proxy to the Internet. This allows for increased computation, better display, and optimized communication, such that the experience is somewhere between pure web app and pure native app. The customer gets the good feeling of "owning" the thing for which they paid, and the developer's work is simplified by using the browser as a cross-platform GUI.
The thing I am realizing is both Apple and Microsoft have extremely unstable APIs that are driven by political or maybe stupidity purposes (some non-engineering reason), where perfectly good software just stops working because some bureaucrat at the Duopoly decided to nix something for arbitrary or foolish reasons.
But you can't do this with HTML apps, since it's not a monopoly, duopoly, or oligarchy, it's an actual competitive market for browsers. If your browser decides to stop supporting HTML4, it's broken and no one will use it.
This means you can write once for web apps and be confident it will continue to work forever.
That's a huge advantage and has changed the way I think about things. Now I am of the opinion that if there is any possible way to make something run in the browser, that is the preferred and superior choice. It's also instantly Mac/PC and Linux cross compatible too.