4 ms·

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

by JepZ 9y ago

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...
    - mephitix 9y ago
      Well that sucks. Thanks a lot for the info.
      - Klathmon 9y ago
        No problem, hopefully you don't get caught with your pants down like I did. 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.

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

by JepZ 9y ago

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

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...
  - mephitix 9y ago
    Well that sucks. Thanks a lot for the info.
    - Klathmon 9y ago
      No problem, hopefully you don't get caught with your pants down like I did. 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.