Comment by joshstrange | Hacker News Reader

Comment by joshstrange | Hacker News Reader

I was super confused by this since to the best of my knowledge SFSafariViewController blocks anything like this, you, as a developer, cannot inject anything or peak into the view it creates. Then I got to the bottom and realized I was correct, but FB/Meta/IG/etc aren't using SFSafariViewController and instead using the older ways to embed a web view.

Honestly I thought all other methods had been deprecated and had no idea apps could still make use of the less secure (for the user) options. Trust me, as a developer I've wanted to reach inside a SFSafariViewController many times to make my life easier but in the end I've just grumbled and assumed it's not possible and worked around it.

I wish there was a privacy-safe way to get the best of both worlds but due to bad actors I doubt that will be possible. I need to look more into App-bound domains but I don't think even that will give me what I really wish for (a way for the page loaded in SFSafariViewController to tell my app something). Something like postMessage support for SFSafariViewController would be amazing and be safe privacy-wise I think since the contained page would need to support sending/receiving messages instead of just having code injected against their will.

Yes, developers are able to leverage WKWebview on iOS and a Webview on Android.

One thing about both webviews is that there are callbacks with these implementations that developers can choose to open a link in the embed webview or not. It might be useful for privacy/security for Apple/Android to force developers to allow-list a domain (like iOS's Associated Domains) or such that an embedded webview can load (besides local html and files). It might be something in addition to the developer's callback.

iOS WKWebview: https://developer.apple.com/documentation/webkit/wkwebview Android Webview: https://developer.android.com/guide/webapps/webview Associated Domains: https://developer.apple.com/documentation/Xcode/supporting-a...

At our company we use Cordova for all our apps, which means we have to use WKWebView in order to render our application. As does ever Cordova app.

I have started moving from an SFSafariViewController to a WKWebView in my app. In my case, we have a discussion forum that I wanted to display in a sidebar alongside the app, so people could get help while they work. I also wanted to intercept clicks on certain files to open them directly in the app — making it easier for users to check out other work on the forums.

However after reading this article what I will be doing is intercepting any links from my WKWebView to domains outside of my forums and opening them in an SFSafariViewController. I have no intention of tracking anyone, but neither do I want the responsibility or reputation for domains outside of my control

As a user I’d like to discourage this. If you use SFSafariViewController, the user’s extensions and content blockers load automatically. If you use WKWebView they don’t load at all. I’m one of those users who depends on these and every time a developer uses WKWebView instead it drives me up a wall. Plus, the UI is shared between Safari and it’s easy to jump out.

In this case, I cannot show a SFSafariViewController side-by-side with the main app on iPad (as it can only be presented modally). On this site there are no ads, and no content to block, it is simply a discussion forum about the app.

I'd be happy to put a Safari button on the WKWebView sidebar version, but as it is a coding app and the forums are full of helpful code snippets, having it appear alongside the code editor seems like a valuable proposition.

The big advantage of using WKWebView is that when a user posts a zip file containing their project you can simply tap on the link to run the project and see the results. You can also easily share your code to the forum by tapping a button in the app's UI to post it to the thread.

These sorts of native<->web integrations are not possible with SFSafariViewController. However I would not want these integrations on any outside domains, and so would push the user back onto SFSafariViewController if, for example, they opened a discussion and tapped a link to an external blog or article.

Edit: perhaps I am not explaining this well. Here is an example of what is happening in my app https://twitter.com/twolivesleft/status/1557378008495058944

How come that my apps get rejected if i don't use SafariViewController but they can publish them?

Exactly my thoughts too.

How is that possible that Google Play and Apple store allow apps like this to get published?

Yes

What are you trying to use? There's no restriction on using WKWebView. If you try to bypass Webkit, you'll get rejected for sure, but you are not forced to use SFSafariViewController

I am using the inappbrowser for Cordova, that i am sure uses WKWebView, but as soon as the app store testers see the webview, they reject the app and want me to use SafariViewController. Happened to all my latest app submissions/updates

I think we both might be mistaking the required move from UIWebView to WKWebView (instead thinking we had to move from WKWebView to SFSafariViewController).

> ITMS-90809: Deprecated API Usage - New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).

I get this problem while using Cordova inappbrowser that uses WKWebView.

But the solution isn't to enforce a specific browser or way to access web content. The solution is to educate users about the toxic software landscape on smartphones and the security threats of using apps. Ironically these supposedly checked apps behave vastly worse than the vast majority of software you can just install on a less locked down system. Because there the better alternatives mostly win.

I wouldn't say WKWebView is 'the old way', it isn't marked as deprecated and just because there's a new class that's easier to use doesn't mean they replace older classes that let you do more stuff. As you've found out, you've run into problems, but I have no idea why you would think not to use WKWebView if you can't do what you need.

That said, in general, never, ever use in app browsers for surfing the web. We use them for specific pages on our website that should interact back to the app, otherwise we tell the system to open the URL in the user's browser

This is what was confusing me, e-mails we got in years past about moving from UIWebView to WKWebView. In my head I misremembered that as needing to move from WKWebView to SFSafariViewController.

There are a couple apps where we are using SFSafariViewController but WKWebView would make our lives easier so I need to go back and look at switching those out.

> ITMS-90809: Deprecated API Usage - App updates that use UIWebView will no longer be accepted as of December 2020. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).

I remember those, but we'd moved to WKWebView almost as s soon as Apple marked it deprecated.

We don't have many web views anymore, we still use a couple for signup and for the user to change their privacy settings because we need to change some behaviours based on the results, so we inject something to know if the user made changes and close the view. But there's no way for the user to navigate out to the greater web from the pages. Anything else and we instruct the os to open URLs

Reply on news.ycombinator.com