8 ms·

Why native apps are here to stay

63 points by DeusExMachina 15y ago

technoslut 15y ago
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.
- rnemo 15y ago
  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.
  - beaumartinez 15y ago
    HTML5 has a bunch of features[1] just for that—providing the same experience whether you're on or offline. [1] http://diveintohtml5.org/offline.html http://diveintohtml5.org/offline.html
- drewcrawford 15y ago
  > 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.
  - SomeCallMeTim 15y ago
    >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.
  - technoslut 15y ago
    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.
  - tzm 15y ago
    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.
    - drewcrawford 15y ago
      Let me give you just one data point backing my "patently wrong" assessment: Read this documentation: http://developer.appcelerator.com/apidoc/mobile/1.4/Titanium.UI.iPad-module 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.
willvarfar 15y ago
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.
- LeafStorm 15y ago
  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.
  - jff 15y ago
    Yeah, if Tim Berners-Lee was dead, he'd be rolling over in his grave. As it is, he's probably rolling over in his bed at night... Unless of course he's totally supportive of using a hyperTEXT markup language to write applications, I don't know.
mmcdan 15y ago
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.
- toddmorey 15y ago
  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.
  - SomeCallMeTim 15y ago
    With PhoneGap you can have what looks like a "native app" to end users that's written entirely in HTML5/JavaScript.
    - flyosity 15y ago
      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.
acangiano 15y ago
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.
- Xurinos 15y ago
  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. "if you follow my TOS"
Hisoka 15y ago
"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.
- recoiledsnake 15y ago
  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.
- Wilya 15y ago
  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.
- geon 15y ago
  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?
skeptical 15y ago
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.
wavephorm 15y ago
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.
wnoise 15y ago
Unreadable without javascript.
- slug 15y ago
  I agree with you, it's ridiculous the need to activate javascript to read a freaking webpage.
beaumartinez 15y ago
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.
- slaven 15y ago
  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.
  - beaumartinez 15y ago
    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. [1] http://hacks.mozilla.org/2011/08/introducing-webapi/ http://hacks.mozilla.org/2011/08/introducing-webapi/
- technoslut 15y ago
  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,
- mechanical_fish 15y ago
  app stores which are dictatorships 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.
kalkat 15y ago
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.
joshontheweb 15y ago
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/ http://hacks.mozilla.org/2011/08/introducing-webapi/
- gaius 15y ago
  Native isn't standing still. By definition, no web app can ever do anything a native app can't - since the browser is a native app!
- randomdata 15y ago
  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?
- kbm 15y ago
  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.
n9com 15y ago
Web apps just don't have the same fast and slick feel as native apps. We've tried making them work, but mobile browsers just aren't good enough yet to process the JS at a reasonable speed.
tluyben2 15y ago
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.
pkaler 15y ago
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.
- rjd 15y ago
  > 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.
tmcw 15y ago
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.
ThaddeusQuay2 15y ago
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 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.
joehewitt 15y ago
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?
protomyth 15y ago
At some point, someone is going to get a client that is meant to run apps and we are going to move beyond HTML / JavaScript / CSS.
bugsy 15y ago
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.

63 points by DeusExMachina 15y ago

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.

rnemo 15y ago
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.
- beaumartinez 15y ago
  HTML5 has a bunch of features[1] just for that—providing the same experience whether you're on or offline. [1] http://diveintohtml5.org/offline.html http://diveintohtml5.org/offline.html
drewcrawford 15y ago
> 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.
- SomeCallMeTim 15y ago
  >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.
- technoslut 15y ago
  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.
- tzm 15y ago
  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.
  - drewcrawford 15y ago
    Let me give you just one data point backing my "patently wrong" assessment: Read this documentation: http://developer.appcelerator.com/apidoc/mobile/1.4/Titanium.UI.iPad-module 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.

willvarfar 15y ago

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.

LeafStorm 15y ago
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.
- jff 15y ago
  Yeah, if Tim Berners-Lee was dead, he'd be rolling over in his grave. As it is, he's probably rolling over in his bed at night... Unless of course he's totally supportive of using a hyperTEXT markup language to write applications, I don't know.

mmcdan 15y ago

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.

toddmorey 15y ago
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.
- SomeCallMeTim 15y ago
  With PhoneGap you can have what looks like a "native app" to end users that's written entirely in HTML5/JavaScript.
  - flyosity 15y ago
    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.

acangiano 15y ago

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.

Xurinos 15y ago
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. "if you follow my TOS"

Hisoka 15y ago

"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.

recoiledsnake 15y ago
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.
Wilya 15y ago
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.
geon 15y ago
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?

skeptical 15y ago

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.

wavephorm 15y ago

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.

wnoise 15y ago

Unreadable without javascript.

slug 15y ago
I agree with you, it's ridiculous the need to activate javascript to read a freaking webpage.

beaumartinez 15y ago

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.

slaven 15y ago
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.
- beaumartinez 15y ago
  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. [1] http://hacks.mozilla.org/2011/08/introducing-webapi/ http://hacks.mozilla.org/2011/08/introducing-webapi/
technoslut 15y ago
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,
mechanical_fish 15y ago
app stores which are dictatorships 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.

kalkat 15y ago

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.

joshontheweb 15y ago

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/ http://hacks.mozilla.org/2011/08/introducing-webapi/

gaius 15y ago
Native isn't standing still. By definition, no web app can ever do anything a native app can't - since the browser is a native app!
randomdata 15y ago
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?
kbm 15y ago
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.

n9com 15y ago

Web apps just don't have the same fast and slick feel as native apps. We've tried making them work, but mobile browsers just aren't good enough yet to process the JS at a reasonable speed.

tluyben2 15y ago

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.

pkaler 15y ago

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.

rjd 15y ago
> 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.

tmcw 15y ago

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.

ThaddeusQuay2 15y ago

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 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.

joehewitt 15y ago

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?

protomyth 15y ago

At some point, someone is going to get a client that is meant to run apps and we are going to move beyond HTML / JavaScript / CSS.

bugsy 15y ago

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.