[tech234a]

I’ve been using uBlock Origin Lite on iOS for several months now, but one shortcoming I see with the newer WebExtensions implementation in Safari is that WebExtensions can’t be used with the in-app Safari views, meaning extensions such as this one don’t work with in-app Safari views. There was an older Safari content blocker API that did work with the in-app Safari views, but it seems like apps are being updated to stop using it. As a workaround, I’ve been trying to set my apps to open the Safari app for links where possible, but I would have preferred to use the in-app Safari views.

[djxfade]

As a side note, I personally HATE apps that opens links in an in-app web view (apps like Instagram, Facebook, etc). I really wish Apple could have a system wide preference where it could force in-app web views to open in the browser.

[mort96]

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.

[ptk]

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.

[FateOfNations]

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.

[mort96]

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.

[FateOfNations]

> 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.

[phatskat]

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.

[pmontra]

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?

[Someone]

> 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.

[lapcat]

> 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.

[ericrallen]

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.

[latexr]

> 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.

[mh-]

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.

[latexr]

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.

[mort96]

I could be, but I'm not. And I don't want to compartmentalize logins to Slack.

[latexr]

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.

[array_key_first]

This sounds like a fantastic way to get phished.

[latexr]

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.

[array_key_first]

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.

[OGWhales]

I also love that app sizes get super bloated (several gigs per app) due to cached safari data from the in-app web view. Seems the only way to clear it is to go into settings and wipe the website data for safari entirely. I don't believe app developers can clear this themselves either, despite it appearing as their app taking up so much space when really it's just due to safari cache that seemingly doesn't clear on its own.

[lou1306]

THAT is the source for the bloat? Oh dear. Absolutely shambolic. It is embarrassing that iOS gives no way to just completely nuke an app's cache, short of reinstalling the app.

[phatskat]

Some apps have a setting to clear data and I swear I’ve seen cached data in that before but I could be mistaken

[lou1306]

I know they do, but the effectiveness of these "clear data" settings varies wildly and it's mildly infuriating. For instance, in my experience Telegram's works pretty well, X's not at all.

[phatskat]

Oh absolutely, and a lot of apps don’t seem to offer the option at all anymore from what I can see.

[technothrasher]

I get more frustrated from when they go the other direction. Google Maps, for instance. When I go to the website, it asks if I'd like to use the app instead, with the usual dark pattern of having the "no" button greyed out. But after I tell it no, as soon as I touch the search bar, it automatically opens the app anyway. I wish there was a setting in Safari that disabled websites from opening apps.

[ljm]

Add to that list:

- showing focus-stealing modals when loading the page/app, which breaks the quick look functionality on iOS

- interrupting your workflow with tutorial popups (especially multi-step ones that point to different parts the screen) that demo or upsell a new feature, requiring you to dismiss them to continue

- not having an option saying "I'm a power user, stop explaining shit I already know"

To be honest, if the concept of growth hacking was erased from the universe, pretty much none of this crap would exist. Atlassian, Browserstack: I'm looking at you.

[macNchz]

> I wish there was a setting in Safari that disabled websites from opening apps.

This has been one of my biggest iOS peeves for a long time—I really wish that installing an app wasn’t a commitment to letting it handle all of the links it wants to.

It’s particularly annoying because a lot of apps are terrible at actually handling the link: the app will show a login screen or some kind of interstitial and then just forget where you were going. That stupid behavior isn’t limited to web links either, it’s really great when it’s the app’s own push notification (thus irretrievable once tapped), but which the app will not even open properly 100% of the time.

There are a couple of imperfect workarounds (long pressing, incognito), but mostly I’d just rather have an option to limit or disable this behavior entirely—in the absence of that I’ve actually just uninstalled all of the worst offenders, I’m sick of having a million damn apps.

[array_key_first]

Not sure about iOS Firefox, but on Android you can disable that altogether. Turn off "open links in apps".

[noname120]

> letting it handle all of the links it wants to

It doesn’t. App developers have to verify that they own the corresponding domain names that they want to handle with their apps: https://developer.apple.com/documentation/xcode/supporting-a...

[macNchz]

I understand that, what I was getting at is more that I, as a user, have little insight or control around when or where my phone will decide to open an app when I click a link, vs continue to work like a normal browser. The app developers declare their associations and url patterns and that's it.

[noname120]

I agree, it’s pretty obnoxious… But there is the same problem on Android, app handlers for verified domains cannot be disabled there, only the handlers for unverified domains (which are unticked by default, so opt-in).

[nullfield]

From what I can tell, Kagi’s Orion browser will let you control app launching.

[bazmattaz]

My favourite part is when it opens a form or something to fill out but if you navigate away from this in-app web view to another app and back (say to get a password) you lose the session. It’s incredibly frustrating

[IshKebab]

Yeah Gmail does this on Android. Super annoying. You basically have to remember to always click "open in chrome". It's not like it even does anything different because it's already open in chrome, just in a tab that it will throw away at the drop of a hat.

[JKCalhoun]

That's generally annoying though — web sites that can't preserve your session if you should click a link and then try to go back.

[RileyJames]

I couldn’t agree more.

I find gmail to be the absolute worst offender in this category.

1. They dark pattern you into downloading their browser (they give three options, two of which are chrome)

2. In not launching iOS, I’m not logged into the session I may already have open in safari. Which is incredibly painful for any product that sends notifications via email, which id like to action.

And if I do login, and it asks for an email verification code… fail. I can’t access it in gmail without closing the browser…

3. Their in app browser (or the way they re-write links?) doesn’t seem to play nice with opening the corresponding app. Never seems to work.

Incredibly user hostile.

Is there a better alternative mail client I can use with gsuite?

[mh-]

I use the Gmail app and just have it set to always use the default browser?

Gmail app -> hamburger menu (top left), scroll down to settings, Default apps, Browser = "Default browser app (Configure in iOS settings)".

I think I must be misreading your concern - if so, not intentional.

[QuiEgo]

What does "better" mean to you? The native Apple Mail app works with Gsuite.

[semiquaver]

I’d think it was about tracking if I didn’t know that the ios api most apps use gives no access to what the user is doing. I feel like it must be some folk wisdom among app developers about “keeping people in the app”. It’s especially bad since the implementation always seems to struggle hard with self-links, eg if you open a web link in X then follow a link in the story to a tweet you get a broken result in most apps.

[dostick]

This small technical annoyance is one of the biggest issues… of modern society. They do that deliberately to keep users within their apps to drive up engagement. Which in turn drives down exposure to different opinions by keeping the user within the app driven by the same algorithm uninterrupted. If they to change default opening of web links as you would expect it, their revenue numbers would drop dramatically.

The lawmakers should be competent enough to recognise this problem and have laws against keeping people within the apps for no reason. (The only reason may be to use the web sign-in).

Imagine on desktop computer os, you click a link within WhatsApp app and it opens a window within that app and load the webpage there, without your login cookies, and makes you login if you need using mouse with on-screen keyboard only…

[Mistletoe]

Gmail insists on doing this and always screws it up.

[OGWhales]

On iOS I have the chrome and gmail app installed and it always opens my links in chrome. Does it use the built-in browser if you don't have chrome?

[Mistletoe]

Yes I don’t have Chrome just Safari and it used to still insist on doing this. So it had none of my passwords saved etc. and was some brain dead Gmail browser.

I just tried again and it opened Safari, so maybe at some point they enabled a way to tell it to not do that? I see in the Gmail settings I have a setting checked for use default browser app.

So if you fixed this Gmail or iOS people thank you!

[bazmattaz]

Gmail is the worst for this

[JohnTHaller]

The main point of it is to force ads and tracking links. It's just anti-privacy. Any app that does it without a permanent way to disable it doesn't respect its users.

[braebo]

I wouldn’t mind if it didn’t break OAuth flows on _some_ webviews on _some_ operating systems. Miserable rabbit holes mitigating all the edge cases.

[tracker1]

Same thing in Android... I'd just prefer to launch the default browser (Brave in my case).

[mrguyorama]

Not the same thing.

Every link I click on my Android phone opens up and uses my preferred browser; Firefox.

What are you seeing different?

[tracker1]

By default in X, Facebook and even Google News, you get an in-app browser by default.. you can change the behavior, but it's definitely the default. Just switched to a new phone and have been updating a lot of the settings as I notice them.

[uxjw]

Meta uses the in app browsers to inject trackers on every site you visit. https://krausefx.com//blog/ios-privacy-instagram-and-faceboo...

Probably others doing the same. I always open pages in full safari and use NextDns to block trackers in all apps.

[monocularvision]

This is heavily dependent on whether the app is using a WKWebView, in which the app developer has almost total control over the experience or SFSafariViewController, which essentially provides a mini-Safari with back/forward/reload/reader mode buttons with a button in the lower right hander corner that takes you to full Safari. In the latter case, the app developer has very little customization and cannot see or really control what is happening inside of the web view.

[advisedwang]

You have it backwards: whether an app injects tracking is not a result of whether they use WKWebView of SFSafariViwController. Rather, if they want to inject tracking, they _will_ use WKWebView.

[jtbayly]

Apparently iOS 26 adds new APIs that allow filtering everywhere, including in all apps. Wipr added this functionality.

[soraminazuki]

You mean URL filters? This isn't part of WebExtensions, so I don't think uBlock Origin Lite is going to support it any time soon. But since URL filters appear to operate independently from browser level blocking, perhaps apps providing this functionality could coexist with uBlock Origin Lite.

Also, as the name implies, this just looks at the URLs. So it's more comparable to DNS level blocking.

https://developer.apple.com/documentation/networkextension/u...

[nvr219]

But then I have to upgrade to iOS 26… The cure is worse than the disease!

For now I am using wireguard+pihole on a cheap VPS for all my devices. It’s not perfect (data center IP so some places block it) but it’s good enough for now. When I’m forced to update to 26 will definitely look at Wipr since I tested that out and it was really good other than the in-app issue.

[thiht]

Or just do the 26 upgrade, the Liquid Glass changes are grossly overstated, it's not a drastic change...

[JohnTHaller]

True. macOS Tahoe is far worse. It looks like a poorly designed Linux variant.

[oktoberpaard]

Without having any experience with the APIs to back up my claim, I believe that the WebExtensions API is more powerful in the sense that it allows more complex blocking rules. AdGuard seems to include both options simultaneously, where you have "advanced protection" (WebExtensions API) that only works in Safari and separate blocking lists (old API) that work in both Safari and WebView. This is precisely what keeps me from using uBlock Origin Lite.

[lapcat]

> I believe that the WebExtensions API is more powerful in the sense that it allows more complex blocking rules.

This is not really accurate.

The Safari content blocking API and the WebExtensions DeclarativeNetRequest API are comparable. The difference is that WebExtensions are JavaScript and can run in the context of the web page. With WebExtensions, you get DNR plus arbitrary JS, whereas the Safari content blocker API is native code and doesn't run in the context of the web page. The arbitrary runtime JS is what allows you to do things that you can't do with declarative content blocking rules.

You could also have a Safari content blocker with an optional WebExtension for additional functionality with no usage of DeclarativeNetRequest.

[oktoberpaard]

> You could also have a Safari content blocker with an optional WebExtension for additional functionality with no usage of DeclarativeNetRequest.

That’s exactly what AdGuard and some other content blockers do. The result is that content blocking works everywhere, but it’s most effective in Safari. As a user, I prefer that over the approach of uBlock Origin Lite, which is a pure WebExtension and doesn’t do anything outside of Safari. Too bad, because I prefer using uBlock Origin on other platforms.

[givinguflac]

I agree, and I feel it’s worth mentioning that in-app web views bypass private browsing, so they store cookies even if you run Safari in private browsing 100% of the time. PITA to clear them, buried in settings.

[lapcat]

> There was an older Safari content blocker API that did work with the in-app Safari views, but it seems like apps are being updated to stop using it.

Which apps are being updated to stop using it?

The difference is simply that the Safari content blocker API is Apple-specific, so it can be used only on iOS and macOS, whereas uBlock Origin Lite uses the cross-platform DeclarativeNetRequest API, because uBlock Origin Lite is itself cross-platform.

[tech234a]

Adblock Plus did so on iOS in version 3.0.0. I haven’t used ABP on other platforms in years but for awhile it was only of the few decent free options I knew of on Safari.

[lapcat]

Ah yes, I see in the release notes, "Rebuilt with WebExtension technology for improved ad blocking performance".

I'm not sure why they did that or whether it's actually improved, but the Apple-specific content blocker API is certainly not deprecated or anything like that.

The biggest difference is that the Safari content blocker API is native, in other words, Swift or Objective-C, whereas DeclarativeNetRequest (invented by Google) is a JavaScript API.

In-app views can't really have DNR unless they also have full browser extensions too.