3 ms·

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

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.

deleted 15y ago
[deleted]
saurik 15y ago
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).
- shinratdr 15y ago
  > 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.
  - saurik 15y ago
    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.

deleted 15y ago

[deleted]

saurik 15y ago

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

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