1. Nothing you visit gets saved in your history. So many times I'm looking through my history thinking "I could have sworn I read an article about this..." only to eventually discover (if I'm lucky) that it was in Twitter's stupid in-app browser. But oh well, never going to find that article again! The irony of the APP knowing everything you visit but you never getting to remember what you visited.
2. All your logins are gone! I actually pay a bunch of stupid newspapers just to click on links in Twitter and STILL be told I can't read the article because of course I'm not logged-in in the in-app browser. UGH.
You could imagine a world where iOS tried to balance the desire of an app to not bounce you out with a more "integrated experience" by providing an "in-app" browser that was completely controlled by the OS, modifying your history, keeping you logged in, running out of process, and being able to be "adopted" as a tab in Safari, but instead they just made "SFSafariViewController" which does none of these things and instead just makes it really really easy for all apps to incorporate these infuriating in-app browsers.
> instead they just made "SFSafariViewController" which does none of these things
Actually, SFSafariViewController acts as a full Safari without giving any ability to the developer to inject scripts or receive data to track you(except for ad taps through Private Click Measurement). It's actually a nice solution, it shares cookies(non-session ones) with Safari.
Right... by "none of these things" I meant... the stuff I listed, which for the record is not incompatible with isolating the browser from the initiating app. It would be totally viable to give SFSafariViewControllers "write only" access to your history (implemented as just an API call that SFSafariViewControllers makes to notify the OS of a page navigation, which it can then store the URL of in your history, so that when you go to history in Safari later, it would show up there). Similarly, there could be a very nice "adopt as tab" button that would "rip" the view controller out of the enclosing app and just plop it into Safari proper, complete with it's back-forward list/history, and make it really easy to transition from the app to Safari without the much less ideal "open in Safari" button that loses navigation/page-state/etc. In other words, the way SFSafariViewController could work is that you are in Safari (forcing the full screen experience), just with a "Done" button that takes you "back" to the app (or an adopt button that "solidifies" the app switch. Think something more akin to the "app banner" that Safari shows when you go to an app's page, just with a nice transition of the webpage coming in from the app, kind of like the old Mail animation from iOS 1). This actually accommodates both goals: you get the real "full Safari" (again, you have effectively opened the link in Safari), but a nice little "Done" button to let you get back to what you were doing in the initiating app, which is the only "good faith" thing the app should care about (obviously we don't care about accommodating tracking/etc.).
I like the "adopt as tab" button idea a lot and generally agree but I also see the associated risks with other suggestions.
For example, write only access to history will also mean SEO-consultant-type people paying app developers to write certain websites to the users history. When Safari does suggestions on the address bar, browsing history is a major source.
The only caller of said API would be the SFSafariViewController itself, the same way the Share Panel can see your Contacts despite you not having given the app that opened the Share Panel Contacts "access". This way, only organic page navigations get recorded (or at minimum is equally susceptible to any history pollution as a normal web page that you encounter). The idea was not to have SFSafariAddURLToHistory(), apologies if that's the way it came off.
The original SFSafariViewController did share cookies with regular Safari. The documentation says
> In iOS 9 and 10, it shares cookies and other website data with Safari.
I was also also disappointed that they removed it in iOS 11. But it's still a step-up from other even more horrible in-app browsers like in Instagram, which are implemented with WKWebView. I refuse to read anything in those in-app browsers; I always manually open them in Safari.
lol what you’re describing as a ‘feature’ is actually insecure & vulnerable. There are strong security reasons why Apple mandates WKWebView and bans SFSafari.
SFSafariViewController is not banned. It's recommended by Apple for some use cases. It says,
> If your app lets users view websites from anywhere on the Internet, use the SFSafariViewController class. If your app customizes, interacts with, or controls the display of web content, use the WKWebView class.
Right, I know. I mentioned SFSafariViewController in my post. I am saying, in the 9 years since SFSafariViewController was introduced, Apple could have made the experience with SFSafariViewController better, for example by having pages you visit in a SFSafariViewController get saved into your normal browsing history (this can be done without giving Twitter access to anything, it can simply notify the OS of an internal navigation, and then the OS can add that item to your Safari history. If SFSafariViewController runs out-of-process, then it can be even simpler than that). I then wouldn't have to keep a weird mapping in my head of what "app" I read an article in to ever get back to it. This would go a long way in closing the gap with the benefits you get from opening a link in Safari proper instead of viewing it in-app.
On everything other than iOS (desktop and iPad), I either use Twitter in the browser or it is reasonable to just have links open in the main browser. Using Twitter in Safari on iOS (on the phone, to distinguish it from iPadOS), you end up with kind of the reverse problem of needing to fish around for Twitter in tabs. If Safari on iOS had a better "save web app"/site-specific browser story, then this could possibly remedy some of these problems (or if they implemented some of the basic ideas I described, like storing history).
1. Nothing you visit gets saved in your history. So many times I'm looking through my history thinking "I could have sworn I read an article about this..." only to eventually discover (if I'm lucky) that it was in Twitter's stupid in-app browser. But oh well, never going to find that article again! The irony of the APP knowing everything you visit but you never getting to remember what you visited.
2. All your logins are gone! I actually pay a bunch of stupid newspapers just to click on links in Twitter and STILL be told I can't read the article because of course I'm not logged-in in the in-app browser. UGH.
You could imagine a world where iOS tried to balance the desire of an app to not bounce you out with a more "integrated experience" by providing an "in-app" browser that was completely controlled by the OS, modifying your history, keeping you logged in, running out of process, and being able to be "adopted" as a tab in Safari, but instead they just made "SFSafariViewController" which does none of these things and instead just makes it really really easy for all apps to incorporate these infuriating in-app browsers.