9 ms·
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 WebExt
by tech234a 11mo ago
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 11mo agoAs 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.
- Mistletoe 11mo agoGmail insists on doing this and always screws it up.
- bazmattaz 11mo agoGmail is the worst for this
- OGWhales 11mo agoOn 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 11mo agoYes 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!
- dostick 11mo agoThis 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…
- technothrasher 11mo agoI 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 11mo agoAdd 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 11mo ago> 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.
- noname120 11mo ago> 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-associated-domains https://developer.apple.com/documentation/xcode/supporting-a...
- bazmattaz 11mo agoMy 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
- JKCalhoun 11mo agoThat's generally annoying though — web sites that can't preserve your session if you should click a link and then try to go back.
- IshKebab 11mo agoYeah 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.
- mort96 11mo agoIt 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.
- latexr 11mo ago> 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.
- mort96 11mo agoI could be, but I'm not. And I don't want to compartmentalize logins to Slack.
- latexr 11mo agoTo 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.
- mh- 11mo ago
- semiquaver 11mo agoI’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.
- braebo 11mo agoI 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.
- OGWhales 11mo agoI 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 11mo agoTHAT 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 11mo agoSome apps have a setting to clear data and I swear I’ve seen cached data in that before but I could be mistaken
- lou1306 11mo agoI 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 11mo agoOh absolutely, and a lot of apps don’t seem to offer the option at all anymore from what I can see.
- RileyJames 11mo agoI 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?
- QuiEgo 11mo agoWhat does "better" mean to you? The native Apple Mail app works with Gsuite.
- mh- 11mo agoI 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.
- JohnTHaller 11mo agoThe 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.
- tracker1 11mo agoSame thing in Android... I'd just prefer to launch the default browser (Brave in my case).
- mrguyorama 11mo agoNot 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 11mo agoBy 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.
- lapcat 11mo ago> 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 11mo agoAdblock 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 11mo agoAh 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.
- jtbayly 11mo agoApparently iOS 26 adds new APIs that allow filtering everywhere, including in all apps. Wipr added this functionality.
- nvr219 11mo agoBut 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 11mo agoOr just do the 26 upgrade, the Liquid Glass changes are grossly overstated, it's not a drastic change...
- JohnTHaller 11mo agoTrue. macOS Tahoe is far worse. It looks like a poorly designed Linux variant.
- soraminazuki 11mo agoYou 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/url-filters https://developer.apple.com/documentation/networkextension/u...
- oktoberpaard 11mo agoWithout 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 11mo ago> 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 11mo ago> 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 11mo agoI 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.
- uxjw 11mo agoMeta uses the in app browsers to inject trackers on every site you visit. https://krausefx.com//blog/ios-privacy-instagram-and-facebook-can-track-anything-you-do-on-any-website-in-their-in-app-browser 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 11mo agoThis 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 11mo agoYou 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.