[1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...
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.
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.
How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
It would be interesting data, although determining WebView for ads statically might be tricky.
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.
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.
Only the two companies that tried to screw Sun had any issues with it.
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.
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.
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.)
Except the Web had already been invented at Xerox PARC and further explored at ETHZ using native technologies, so I guess some had already a pretty good idea.
Surely there are some hiccups left in the design that come from its organic growth and could be smoothed out; but those are not as much as you would think, and most of that work has already been done in html5+ES6.
The end result is a platform that is great for zero-install distribution of web applications AND web documents. A new framework that centered only on the first goal would be severely limited, and a new one that served for both would look a lot like the current one.
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.
This argument is made frequently, and I don't get it. With a typical web app, you have no idea what the backend is doing, and your data is stored on servers owned by third parties. At any time they can revoke your access, go out of business, share your data with others, or change the app in user-unfriendly ways. An open source Android app that runs and stores data locally (perhaps with an option for cloud storage) seems much more "open" than that.
That is, I can't just create an app and throw it up on a server like I can with a website. It needs to be "approved" first. That's a HUGE barrier to openness that the web never had, and hopefully never will have in the future.
And, even though mobile apps run natively, I don't think one can be very confident that they're any more private than a typical website...analytics & the drive for data is there regardless of medium.
I agree completely about the privacy thing though. I guess it's a bit easier to see when a native app is sending data over the network with the right tools but in general, there's just as much room for abuse with either model.
Apps on the Marketplace are deployed to a device and run locally, offline - complete with an intricate permissions model. The only 'web' aspect is being written in HTML/JS/CSS and the extent to which they integrate with the cloud. No less open than the github hosted, Android app scenario you mention. Maybe Firefox OS does need an f-droid equivalent for a free app catalogue though, if and when Mozilla pull the Marketplace servers down.
So be aware of the distinction between mobile web 'apps' and mobile web sites.
So like Android, except using HTML/JS/CSS which I'd consider either an irrelevant implementation detail or a negative.
No less open than the github hosted, Android app scenario you mention.
Sure, no less and no more. The real issues are whether the user is allowed to run the app without explicit permission from the OS vendor, and whether they're required to hand control of their data to a third party. Once we have the answers to those questions, whether the app is written in JS or Java or Swift or C++ doesn't really matter in terms of openness.
OneDrive having a web client doesn't make it open. If you think about OD as just a way to access and share files then it's probably open since the web client will run in any modern browser. However if you think of OD as a platform of sorts then I wouldn't consider it open since, to my knowledge, MSFT controls everything about it and it's not standardized.
http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is...
time to move on I guess
Web is never going to be as feature rich as native, until the browser becomes nothing more than yet another JavaScript VM.