You can add a website to your homescreen in safari, but when you do it uses a different rendering engine, with different levels of support.
Take WebRTC which was recently (partially) added to iOS. It will work great in safari, but if you add the site to your homescreen, it is no longer supported.
The job of telling users to remove homescreen shortcuts to use a new feature is a nightmare.
It doesn't make any sense to them, so they distrust it. Especially because we had been encouraging the act of bookmarking our web app on the homescreen for years (since it works great for our use case! Offline access is possible, loads quickly, no worries of apple shutting us down, and it's as cross platform as it gets). Also the wording is difficult. Telling users to open this same page, but in safari is confusing, and they need to login again, and navigate to that page again.
Imagine if a website told you that if you had previously "bookmarked" their page in your desktop browser, that you had to remove the bookmark to use a feature. You'd be skeptical at the very least right? It's a strange request...
Not to mention that even detecting it is kind of broken. The feature looks like it's available (opposed to pre ios 11 where the functions didn't exist), but when you go to use them they throw a generic exception (which can mean anything from they are in the "added to homescreen" browser on ios, the camera randomly crashed on android, another app is currently using the camera, or it just didn't work for some unknown reason).
So we have to check for the nonstandard `navigator.standalone` property, then just assume it won't work for the user. If iOS 12 adds support for this, we will need to update our app again and remove this block, but only if they are on iOS 12...
It's just a giant fucking mess.
Anybody knows why Apple is doing that?
The cynical part of me wants to think that it's because by hurting it in WebViews and in a desktop-shortcut they can "support" these technologies without fear of them cutting into their app store sales/numbers.
But I have heard that there are some shitty technical problems with it.
Safari is not the same as a WebView when it comes to the code, and apparently a desktop-shortcut app runs in a WkWebView. So while they were able to add these features to Safari, the process of adding them to a WebView is much harder since it's intertwined with the OS so heavily.
According to someone I talked to a while back, WebViews and Safari in iOS are different enough that sharing code isn't exactly easy or straightforward.
But then the cynical part of me kicks back in and thinks that they shouldn't be following into the footsteps of Internet Explorer which hit the same traps and potholes (the integration with the OS meant new feature were extremely difficult to add, and the browser lagged behind because of it).
I think the difference might just be in the rendering engine. So Safari uses "safari", and WkWebView uses straight WebKit? But even that isn't true since there are things that WkWebViews support that WebKit doesn't...
But there are many differences between them. The WebRTC stuff above as one, but also things like appcache manifest stuff didn't work in WkWebView in iOS 9 (even though it worked in Safari). And that violation was especially egregious because it could be enabled by calling a single private Objective-C method like this
[_wkWebView.configuration.preferences _setOfflineApplicationCacheIsEnabled:YES];
So I genuinely don't know what to think.
Oh, and SFSafariViewController won't even save you, as that doesn't support WebRTC either...
I forgot to actually test that a proof-of-concept of a new feature using WebRTC in a WebView until it was already like 70% done. I heard it worked in iOS 11, I tried it in safari and developed it like that, then once I started more in depth testing and integration I saw the problem.
So now I make sure I test everything in a WebView (if needed), as an "added to homescreen" web app, and as a safari tab ASAP.
On Android it's possible for example to run Facebook as a web app, because Chrome on Android can deliver notifications, keeping that connection persistent, so even after the page has been closed.
And this is pretty cool because the browser is a much better sandbox than the OS. Now I use an iPhone and I'm very uncomfortable giving access to my photos to Facebook just for uploading a file.
Every time browsers get new features people (ESPECIALLY ad networks) abuse it for tracking and other nefarious purposes.
Battery level, light level, probably even gyroscope stuff. Hell they fingerprint canvas which isn’t even an iOS thing.
I don’t want these issues. I LIKE these restrictions so random sites I visit (and even worse random code injected in them) can’t watch me as easy.
Apps have issues but I control what apps I download and can delete them. At least I have a _chance_ there.
That's not an argument. Desktop browsers have features and add-ons for the privacy conscious right now. You can block trackers, third party cookies, JavaScript execution and anything you need. Personally I feel much, much safer loading a website than when executing a binary on my computer or phone.
You can block any elements on any website from loading, but you can't inspect application binaries and block specific elements from it — only requests to certain IPs or domains, if you had root access that is.
Can you block Facebook's in-app advertising on your iPhone? You can't and even more so, the app insists on opening all URLs in its own dumbed down view instead of Safari, which means they track those visits and their duration as well, probably without content blocking active, because AFAIK it doesn't work in web views.
Well I can block Facebook's ads and tracking in my Firefox for Android, since it supports extensions and it probably works using iOS Safari's content blockers as well.
(I avoid the vast majority of ad laden apps anyway, partlybfor tracking reasons).
The website operator/publisher is the one choosing to track you (or not). Not some magic third party.
If you don't trust example.com from tracking you, you certainly cannot trust example.App from tracking you.
For web, the technology is at least transparant and you can detect being tracked. With native apps, there is nothing you can do, other than reverse engineering the binaries, monitoring internet-traffic and hoping that example.App was built with privacy in mind.
If I download the example.com app then any tracking is limited to what they included either themselves or through an SDK. I know that $random_advertiser doesn’t get to execute their own code.
You either trust them, or you don't. If you don't trust the ad-networks they embed in their site then you don't trust them.
> If I download the example.com app then any tracking is limited to what they included either themselves or through an SDK.
You either trust them, or you don't. If you decide you trust the ad-networks they embed in their site then you can trust them.
Both are no different. Other than that you can evaluate the first quite easily but not the latter.
My point is that it is silly to trust someone from including advertising and tracking on one platform (binary-app) but not when they do the exact same on another (html-app).