It has frustrated me for a LONG time that we have all collectively seemingly decide to break links.
It used to be that you could click a link in an app, it opens in your web browser where you're already logged in to the relevant service, so you get to see the content the link points to.
These days, you click a link in an app, it opens in an in-app web view where you're not logged in, so you just see a login screen.
Not even the "open in Safari" button works, since by the time you have the opportunity to click it, you've already been redirected to the login page. You literally have to long-press on the link, copy it, switch to your browser, and paste it in to the omni-bar. I don't understand how this god forsaken industry's UX "experts" have all agreed that this should be the universal user experience.
It's especially bad in apps like Slack, where 99% of the links I'm ever interested in are links to our internal gitlab, some internal knowledge base article, some internal tool, or some other thing that requires being logged in to view any of the content. Links just plain do not work almost ever in Slack without the manual long-press -> copy -> switch to Safari -> paste dance.
This behavior (as far as I can tell) has broken the Expensify iOS app for us at work. We have a conditional access policy that requires a “compliant” device to succeed the SSO login. However, only the iOS Edge browser can prove compliance and Expensify refuses to hand over that login process to the Edge browser preferring to use its own built-in browser. So login fail and as far as I can tell there is nothing we can do about it except for exempt that app from the conditional access policies.
The reason Expensify does that is because they want/need access to the cookies from the login flow. The in app browser provides the hosting application access to those, but they can't access Safari's cookiejar. The modern way of doing it is to put the login in Safari (or iOS's dedicated "in app browser for logins") and then redirect to something like expensify://login_complete?token=xxxxxx, which pops back over to the app. This is mostly tech debt on Expensify's part, but it might not solve the Edge vs. Safari issue.
I wonder what iOS Edge does which iOS Safari doesn't do, considering both are just UIs over WebKit...
Not that it matters, it's still an excellent example of stuff not working because links don't work as links anymore.
> I wonder what iOS Edge does which iOS Safari doesn't do
Being a "Managed App" through MDM/Intune. Typically it's used when installing corporate apps in a BYOD scenario. The managed apps are isolated from information sharing with unmanaged apps, e.g. policies can be applied preventing copy/paste, access to Files.app, etc. It (and it's isolated storage) can also be remote wiped without nuking the whole device. Edge.app still uses the Safari rendering engine, etc. like is generally the case with 3rd party browsers on iOS.
You can't do this with Safari.app unless the whole device is managed, which doesn't work well for BYOD.
We have this policy at work and it’s infuriating. I had to install edge once to access some work resource and immediately uninstalled it. I can’t even access our GitHub without it, even through the official app.
Maybe what breaks that process is what Edge does not do and Safari does. There is more to a browser than the rendering engine. Furthermore, does Safari still uses an optimized JS engine that the other browsers cannot use?
> I wonder what iOS Edge does which iOS Safari doesn't do
I don’t know whether that’s right, but I read “We have a conditional access policy that requires a “compliant” device to succeed the SSO login. However, only the iOS Edge browser can prove compliance” as “our access policy does not allow logging in from Safari”. If that’s true, it’s not something Edge or Safari does or doesn’t do.
> I wonder what iOS Edge does which iOS Safari doesn't do, considering both are just UIs over WebKit...
"just" is not an appropriate word here. There's a ton of functionality in the native UI and non-WebKit code.
I hate in-app browsers, too, but there is a Slack setting that will let you open in Chrome or Safari (choosing Safari opens whatever your default iOS browser is).
You can change the Browser Application setting under Preferences after tapping on your Avatar in the Slack app.
> you click a link in an app, it opens in an in-app web view where you're not logged in
But you could be. You could log in from the in-app web view, and it would be remembered and compartmentalised in that app, so that next time you click a link you’re logged in.
Nowadays most providers (and IT teams managing SSO) log out stale sessions quickly, so by the time he clicked another link to it in Slack he'd probably be logged out, again.
It really is a bad user experience all around.
If it happened that fast, then logging in outside the in-app browser wouldn’t make much of a difference, you’d have to be constantly doing it anyway.
I could be, but I'm not. And I don't want to compartmentalize logins to Slack.
To be clear, what I meant is that the logins inside the in-app browser do not affect the other in-app browsers and the main browser. I understand this is not your preferred solution, but it is a way to make the situation suck less.
This sounds like a fantastic way to get phished.
That makes no sense. Are you getting phished from clicking a link someone you know posted in your internal company Slack? And use a password manager, those make sure the domain is correct.
Every app and their mom uses the webview bullshit - it's not just your work slack.
Now you're logging into the same thing in multiple different places. Obviously, the odds of you getting phished go up significantly.