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 s

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.