3 ms·

There is actually "negative" support in iOS. You can add a website to your homescreen in safari, but when you do it uses a different rendering engine, with dif

There is actually "negative" support in iOS. 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.

tinus_hn 9y ago
Can’t you automatically detect this problem and tell the users when they try to do this?
- Klathmon 9y ago
  Yes, but people become untrustworthy very quickly. 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.
  - tinus_hn 9y ago
    You could check if one of the features that is only available on the home screen is available
    - Klathmon 9y ago
      That's kind of what I do when checking the `navigator.standalone` property, but it means I'm basically doing useragent sniffing by a different name, since if they fix this in iOS 12 I'll need to update my app so they can use it.
JepZ 9y ago
Wow, thats a bummer. Didn't know about that. Anybody knows why Apple is doing that?
- Klathmon 9y ago
  I've heard a few different things. 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).
  - mephitix 9y ago
    This is news to me. I thought WkWebview used the same internals as mobile safari. So it's just the JS engine/Nitro that's the same?
    - Klathmon 9y ago
      I'm not even sure what is the same and what is different, and there isn't anywhere that I found that explains it easily (if it can even be explained easily). 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]; However apple would then deny your app in the app store if you did that... So I genuinely don't know what to think. Oh, and SFSafariViewController won't even save you, as that doesn't support WebRTC either...

tinus_hn 9y ago

Can’t you automatically detect this problem and tell the users when they try to do this?

Klathmon 9y ago
Yes, but people become untrustworthy very quickly. 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.
- tinus_hn 9y ago
  You could check if one of the features that is only available on the home screen is available
  - Klathmon 9y ago
    That's kind of what I do when checking the `navigator.standalone` property, but it means I'm basically doing useragent sniffing by a different name, since if they fix this in iOS 12 I'll need to update my app so they can use it.

JepZ 9y ago

Wow, thats a bummer. Didn't know about that. Anybody knows why Apple is doing that?

Klathmon 9y ago
I've heard a few different things. 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).
- mephitix 9y ago
  This is news to me. I thought WkWebview used the same internals as mobile safari. So it's just the JS engine/Nitro that's the same?
  - Klathmon 9y ago
    I'm not even sure what is the same and what is different, and there isn't anywhere that I found that explains it easily (if it can even be explained easily). 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]; However apple would then deny your app in the app store if you did that... So I genuinely don't know what to think. Oh, and SFSafariViewController won't even save you, as that doesn't support WebRTC either...