4 ms·

Apple was pushing for "apps" to be web apps when they first released the iPhone as well [1], with Steve Jobs going as far as to say that native apps would poten

Apple was pushing for "apps" to be web apps when they first released the iPhone as well [1], with Steve Jobs going as far as to say that native apps would potentially "damage the phone system". It wasn't until after the iphone was jailbroken, and people kept insisting on more powerful development choices that they started on their app store. People have been saying that webapps are the future for a decade now. At this point, I have to say it's never going to happen. [1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-Third-Party-Web-2-0-Applications.html http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...

Spooky23 11y ago
Don't forget Facebook's HTML5 focus.
benlower 11y ago
Fair points. I think it's more nuanced. Native apps are great and necessary for many scenarios. However, there are a ton of native apps that could be just as functional as a responsive web site. Sure there were issues with discoverability which the app stores helped with in the beginning (now I think it's just as hard to get noticed in the store as it is on the open web). I don't think "web apps are the future of mobile". But I do think there is a better separation of native apps and mobile/responsive web apps.
- wwweston 11y ago
  What's more -- a significant number of apps ARE a wrapper around a UIWebView or something like it.
  - adamdoupe 11y ago
    We've studied this and found that ~85% of the free apps on the Google Play store use a WebView (I like the term "mobile web app"): http://adamdoupe.com/publications/large-scale-study-of-mobile-web-app-security-most2015.pdf http://adamdoupe.com/publications/large-scale-study-of-mobil...
    - nodamage 11y ago
      There's a big difference between an app that 'uses a WebView' to render specific pieces of content or clicked links, and an app that is basically a thin wrapper around a WebView. Can you clarify whether your ~85% number is referring to the former or the latter?
      - adamdoupe 11y ago
        Sure! The short version is that I don't know. We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps). However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage. We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView. Of those 998,286 apps: - 97% enable JavaScript (which is off by default) - 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage) - 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial) - 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.) So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.
        ori_b 11y ago
        As far as I'm aware, mobile doubleclick ads need a WebView with Javascript and shouldOverrideUrlLoading(). I'm not sure about others. How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
        adamdoupe 11y ago
        In our study we didn't differentiate (from a security perspective, if you are vulnerable because you use a WebView when showing ads, then you are still vulnerable), so I don't have data for that. It would be interesting data, although determining WebView for ads statically might be tricky.
- wvenable 11y ago
  > there are a ton of native apps that could be just as functional as a responsive web site That is probably true but most would require 10x the development effort at least and be obsoleted much sooner. And then users don't want generic lowest common denominator applications; users want software to make the best use of the platform.
  - denniskane 11y ago
    If we turn the web itself into an actual developer (and user) friendly platform, then we could probably start making better use of it as an application delivery vehicle. To enable this, I've been furiously working on this OS-in-a-browser concept for the past 3+ years: https://linuxontheweb.appspot.com https://linuxontheweb.appspot.com
    - wvenable 11y ago
      "This site relies upon cutting-edge web technologies that only Chromium-based browsers have implemented." This might as well be Java.
      - efes 11y ago
        > This might as well be Java. Chromium specific certainly isn't as good as open standards, but it isn't as bad as Java. Once chromium is ported to something it doesn't face legal uncertainty.
        pjmlp 11y ago
        Everyone that follows the Java license never had any issues. Only the two companies that tried to screw Sun had any issues with it.
        efes 11y ago
        If you write a free application that runs on Java on the raspberry Pi you (probably) owe Oracle nothing. If anyone builds a console around that raspberry Pi, Oracle probably is owed money because the device is no longer a general machine. That is very different than chromium or anything else that is license compatible with your typical Linux distribution. Whether or not someone owed damages is immaterial to the problem of trying to get everyone an appropriate license who might want to run your software in contexts you haven't imagined yet.
kitsunesoba 11y ago
I think that one day, web apps by default could work, but before that can happen the web must see sweeping change. The lackluster performance and high resource usage associated with web apps is a direct consequence of the complex patchwork nature of each component involved. Quite simply, the web was not designed to be used the way we’re using it, and evolving standards have made browser rendering engines horrifically complex (and in some cases convoluted). What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at minimum with little to no regard for legacy. In the 90s, we didn’t know what we needed but now the picture is crystal clear. Should we use this knowledge to design a new web, I’m positive that the result would be just as open as the web is now while performing tens or hundreds of times better — it’d likely be good enough to make web apps competitive with native apps under a far wider set of circumstances.
- pcwalton 11y ago
  You'll have to explain why in details, not at a high level. In particular the fact that a replacement could perform "tens or hundreds of times better" is an extraordinary claim. CSS has tons of problems, but almost every replacement for CSS that I've seen proposed would almost certainly have worse performance characteristics than CSS, optimally implemented, would. Most of them kill parallelism and kill opportunities for optimal GPU usage—they're proposed cures that are worse than the disease. The problem is mostly that browsers don't implement CSS as well as they could due to legacy, not that the technologies are fundamentally flawed (though this is not to say that they're not improvable, far from it). To create a better architecture, you first need to have an in-depth understanding of what the problems in CSS actually are. Otherwise, you'll just trade one set of mistakes for another. (In particular, a CSS replacement that optimizes for Web developer productivity will not necessarily have acceptable performance characteristics—too often, people assume that "easy to develop in" implies "runs fast", which in fact these concerns are often in direct opposition.)
  - ben0x539 11y ago
    can't wait for servo "strict mode" css!!
- 11y ago
bad_user 11y ago
I've seen this anecdote given as rationale, but you can't say that the "web app" model on iPhones failed when Safari doesn't give you the needed functionality to make web apps. For example iPhone Safari does not do push notifications, an essential ingredient if you want web apps, whereas Chrome on Android does. With Chrome on Android you can do Facebook's Messenger without installing anything. And while iPhone Safari led the way with some useful additions, like the possibility of specifying higher resolution icons for "Add to Homescreen", they dropped the ball on such improvements since iPhone 3G. In fact iPhone Safari is behind in implementing web standards. Apple also rejected Adobe's Flash and I concede that was for good reasons, but that left a huge void in how media, like video and games, could be delivered. You know, things like HTML5 Video and WebGL came after that. You also have to take into account that the first two models (iPhone 1 and iPhone 3G) had poor resolution, poor hardware and poor battery life by today's standards. So you know, if Safari on iPhone 1 is the anchor by which you judge native apps, well of course native apps are better. You also make it sound like "the people" forced Apple to open their SDK. Oh come on, you can't be that gullible. An SDK was inevitable. What's the point of building your own OS if you can't lock people into its APIs? That's a lesson Microsoft taught us. The only reason for its delay was them taking the time to figure out how to control it. Do you remember when Google Voice along with other apps where rejected because they "duplicated existing functionality"? You may not see it, but web apps have been winning for some time and there's no end in sight. When Google Voice was rejected by Apple, Google still delivered its functionality by means of a web app. When the Google Maps integration app was replaced by Apple with their own, which I might say it is inferior and unusable in my city, for a while iPhone users used Google Maps on the web, as it's very much usable. All it takes for web apps on mobile phones to be more common is for the browser makers to implement the needed functionality. Right now the front-running in implementing web standards relevant for mobile phones is Google's Chrome and sadly not Firefox (though I hope that will change). And I must say it works well.

Spooky23 11y ago

Don't forget Facebook's HTML5 focus.

benlower 11y ago

Fair points. I think it's more nuanced. Native apps are great and necessary for many scenarios. However, there are a ton of native apps that could be just as functional as a responsive web site. Sure there were issues with discoverability which the app stores helped with in the beginning (now I think it's just as hard to get noticed in the store as it is on the open web). I don't think "web apps are the future of mobile". But I do think there is a better separation of native apps and mobile/responsive web apps.

wwweston 11y ago
What's more -- a significant number of apps ARE a wrapper around a UIWebView or something like it.
- adamdoupe 11y ago
  We've studied this and found that ~85% of the free apps on the Google Play store use a WebView (I like the term "mobile web app"): http://adamdoupe.com/publications/large-scale-study-of-mobile-web-app-security-most2015.pdf http://adamdoupe.com/publications/large-scale-study-of-mobil...
  - nodamage 11y ago
    There's a big difference between an app that 'uses a WebView' to render specific pieces of content or clicked links, and an app that is basically a thin wrapper around a WebView. Can you clarify whether your ~85% number is referring to the former or the latter?
    - adamdoupe 11y ago
      Sure! The short version is that I don't know. We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps). However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage. We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView. Of those 998,286 apps: - 97% enable JavaScript (which is off by default) - 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage) - 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial) - 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.) So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.
      - ori_b 11y ago
        As far as I'm aware, mobile doubleclick ads need a WebView with Javascript and shouldOverrideUrlLoading(). I'm not sure about others. How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
        adamdoupe 11y ago
        In our study we didn't differentiate (from a security perspective, if you are vulnerable because you use a WebView when showing ads, then you are still vulnerable), so I don't have data for that. It would be interesting data, although determining WebView for ads statically might be tricky.
wvenable 11y ago
> there are a ton of native apps that could be just as functional as a responsive web site That is probably true but most would require 10x the development effort at least and be obsoleted much sooner. And then users don't want generic lowest common denominator applications; users want software to make the best use of the platform.
- denniskane 11y ago
  If we turn the web itself into an actual developer (and user) friendly platform, then we could probably start making better use of it as an application delivery vehicle. To enable this, I've been furiously working on this OS-in-a-browser concept for the past 3+ years: https://linuxontheweb.appspot.com https://linuxontheweb.appspot.com
  - wvenable 11y ago
    "This site relies upon cutting-edge web technologies that only Chromium-based browsers have implemented." This might as well be Java.
    - efes 11y ago
      > This might as well be Java. Chromium specific certainly isn't as good as open standards, but it isn't as bad as Java. Once chromium is ported to something it doesn't face legal uncertainty.
      - pjmlp 11y ago
        Everyone that follows the Java license never had any issues. Only the two companies that tried to screw Sun had any issues with it.
        efes 11y ago
        If you write a free application that runs on Java on the raspberry Pi you (probably) owe Oracle nothing. If anyone builds a console around that raspberry Pi, Oracle probably is owed money because the device is no longer a general machine. That is very different than chromium or anything else that is license compatible with your typical Linux distribution. Whether or not someone owed damages is immaterial to the problem of trying to get everyone an appropriate license who might want to run your software in contexts you haven't imagined yet.

kitsunesoba 11y ago

I think that one day, web apps by default could work, but before that can happen the web must see sweeping change. The lackluster performance and high resource usage associated with web apps is a direct consequence of the complex patchwork nature of each component involved. Quite simply, the web was not designed to be used the way we’re using it, and evolving standards have made browser rendering engines horrifically complex (and in some cases convoluted). What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at minimum with little to no regard for legacy. In the 90s, we didn’t know what we needed but now the picture is crystal clear. Should we use this knowledge to design a new web, I’m positive that the result would be just as open as the web is now while performing tens or hundreds of times better — it’d likely be good enough to make web apps competitive with native apps under a far wider set of circumstances.

pcwalton 11y ago
You'll have to explain why in details, not at a high level. In particular the fact that a replacement could perform "tens or hundreds of times better" is an extraordinary claim. CSS has tons of problems, but almost every replacement for CSS that I've seen proposed would almost certainly have worse performance characteristics than CSS, optimally implemented, would. Most of them kill parallelism and kill opportunities for optimal GPU usage—they're proposed cures that are worse than the disease. The problem is mostly that browsers don't implement CSS as well as they could due to legacy, not that the technologies are fundamentally flawed (though this is not to say that they're not improvable, far from it). To create a better architecture, you first need to have an in-depth understanding of what the problems in CSS actually are. Otherwise, you'll just trade one set of mistakes for another. (In particular, a CSS replacement that optimizes for Web developer productivity will not necessarily have acceptable performance characteristics—too often, people assume that "easy to develop in" implies "runs fast", which in fact these concerns are often in direct opposition.)
- ben0x539 11y ago
  can't wait for servo "strict mode" css!!
11y ago

bad_user 11y ago

I've seen this anecdote given as rationale, but you can't say that the "web app" model on iPhones failed when Safari doesn't give you the needed functionality to make web apps. For example iPhone Safari does not do push notifications, an essential ingredient if you want web apps, whereas Chrome on Android does. With Chrome on Android you can do Facebook's Messenger without installing anything. And while iPhone Safari led the way with some useful additions, like the possibility of specifying higher resolution icons for "Add to Homescreen", they dropped the ball on such improvements since iPhone 3G. In fact iPhone Safari is behind in implementing web standards. Apple also rejected Adobe's Flash and I concede that was for good reasons, but that left a huge void in how media, like video and games, could be delivered. You know, things like HTML5 Video and WebGL came after that. You also have to take into account that the first two models (iPhone 1 and iPhone 3G) had poor resolution, poor hardware and poor battery life by today's standards. So you know, if Safari on iPhone 1 is the anchor by which you judge native apps, well of course native apps are better. You also make it sound like "the people" forced Apple to open their SDK. Oh come on, you can't be that gullible. An SDK was inevitable. What's the point of building your own OS if you can't lock people into its APIs? That's a lesson Microsoft taught us. The only reason for its delay was them taking the time to figure out how to control it. Do you remember when Google Voice along with other apps where rejected because they "duplicated existing functionality"? You may not see it, but web apps have been winning for some time and there's no end in sight. When Google Voice was rejected by Apple, Google still delivered its functionality by means of a web app. When the Google Maps integration app was replaced by Apple with their own, which I might say it is inferior and unusable in my city, for a while iPhone users used Google Maps on the web, as it's very much usable. All it takes for web apps on mobile phones to be more common is for the browser makers to implement the needed functionality. Right now the front-running in implementing web standards relevant for mobile phones is Google's Chrome and sadly not Firefox (though I hope that will change). And I must say it works well.