I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. It makes more sense than the current navigation stack style presentation, and the extra context of the spawning app being visible around the top edges under the sheet would be helpful in app switcher.
The reason SFSafariViewController switched to per-app containers is because the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes, dampening the benefits of it being out-of-process and isolated from the spawning application. I suppose it might be nice to have a setting to toggle this behavior, but it'd need to have disclaimers with red text next to it to prevent advertisers, etc social engineering users into toggling modes.
> the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes
How did this work, exactly? Was the app able to observe/interact with the SFSafariViewController in any way? In my mind, the SFSafariViewController should literally "be" a Safari tab, in the sense that once it's open, the spawning app has no more connection to it than it would have to a tab in Safari itself which it caused to open; other than the fact that this tab would be 1. modal on top of the app, like a sheet; and 2. the app would be told when you closed this sheet, so that it could pause anything actively going on "underneath" the sheet until it was closed.
(And, to be clear, the Safari tab would be running _in_ Safari, and just composited onto the sheet, rather than running inside the app process in any way. This is how OS file-pickers et al work, which is what I was trying to get across with that comparison.)
The closest analogy would actually be within the browser itself: one browser tab using JS window.open(target=_blank, opener=false) to open another browser tab within the same browsing profile, where the new tab loads a page from a different origin; where when that new tab gets focused, the original tab gets obscured, and so the page it has loaded is given a visibilityStateChanged event; followed by another one when you close the new tab and the original tab comes back to focus.
No, apps didn’t have any more ability to observe/interact with the view controller than they do now. SFSafariViewController has always been a separate process spawned by the OS, not the app. It was for all intents and purposes a “real” Safari tab the app couldn’t touch.
The way tracking was happening is by apps putting an identifier in the URL, which JavaScript put into the linked page by the authors (social media widgets, Google Analytics, etc) would pick up on the cookies and other identifiers in the SFSafariViewController session carried over from “real” Safari and then tie those with the URL identifier. Boom, Twitter, etc have a nicely fleshed out tracking/advertising profile to attribute to that clicked link, even though they didn’t use a custom webview.
This is exactly how tracking works with regular browser tabs, too. The only way to mitigate it is to give each app its own separate Safari container for SFSafariViewController to run in and encourage devs to use SFSafariViewController instead of the full browser.
The reason SFSafariViewController switched to per-app containers is because the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes, dampening the benefits of it being out-of-process and isolated from the spawning application. I suppose it might be nice to have a setting to toggle this behavior, but it'd need to have disclaimers with red text next to it to prevent advertisers, etc social engineering users into toggling modes.