uBlock Origin Lite in Apple App Store
In‑app web views and broken link behavior
- Many comments complain that Safari WebExtensions (including uBlock Origin Lite) don’t work in in‑app Safari views / webviews, and that more apps are moving away from the older content blocker API that did.
- Users strongly dislike apps forcing in‑app browsers (Instagram, Facebook, Gmail, Slack, etc.), citing:
- No shared login state with the main browser, constantly hitting login walls.
- Lost form/session state when briefly switching apps.
- Broken OAuth / SSO flows, especially in corporate setups (e.g., Expensify + Edge-only compliance).
- Apps or sites aggressively forcing app opens instead of staying in the browser.
- Some see this as deliberate “keep users in the app” growth‑hacking that should be regulated.
uBlock Origin Lite vs other blockers
- uBlock Origin Lite on Safari is welcomed but several users find it underwhelming compared to:
- Wipr 2, 1Blocker, AdGuard, Brave’s built‑in blocker, or Orion with full uBlock Origin.
- Complaints about uBOL on Safari:
- UI feels clunky; permissions model awkward (must grant broad access to easily toggle per‑site).
- Only one content-blocker extension, so fewer rules than multi-extension blockers that work around Safari’s 150K rule limit.
- Some JS-based blocking breaks on back navigation (ads or Google prompts reappear).
- Others report steady improvement: more lists, custom rules, element picker, generally “good enough.”
APIs, iOS 26, and technical tradeoffs
- Discussion contrasts:
- Apple’s native Safari Content Blocker API (works in Safari and some webviews).
- WebExtensions + DeclarativeNetRequest (cross‑platform, plus optional JS in page context, but not available in in‑app views).
- Some blockers combine both (e.g., “advanced protection” via WebExtension plus classic content blockers) to cover Safari and webviews; this is preferred by several over pure WebExtension approaches.
- iOS 26 introduces URL filter APIs for system‑wide filtering (Wipr has adopted this). These act more like DNS/URL blocking and can coexist with uBOL, but uBOL itself likely won’t use them soon.
DNS-level blocking and system‑wide approaches
- Many rely on DNS‑level solutions: NextDNS, DNS4EU, Pi-hole over WireGuard/VPN, AdGuard Pro, Lockdown.
- Issues raised:
- Safari sometimes bypassing system DNS when iCloud Private Relay / advanced tracking protections are on.
- Captive portals and some apps breaking, requiring allow‑listing.
- Some prefer DNS-only blocking to avoid trusting browser extensions, while others note that iOS content blockers are sandboxed and don’t have full browsing history access.
YouTube ads, Shorts, and ethics
- Strategies to block YouTube ads on iOS:
- Safari + AdGuard / Wipr / similar.
- Vinegar extension to replace the YouTube player (no ads, background play).
- DNS/VPN tricks such as using an Albanian VPN endpoint (reported to yield no ads).
- Mixed views on paying for YouTube Premium: some object to supporting Google or its treatment of creators; others argue paying supports the platform and channels.
- Separate tools (e.g., Control Panel for YouTube) are mentioned for hiding Shorts and additional UI annoyances.
Privacy, tracking, and trust
- Concerns about in‑app browsers being used for tracking (Meta example with injected scripts).
- Confusion over which App Store adblockers are trustworthy amid copycats and vague “data collection” disclosures.
- Clarification that iOS “content blocker” components are isolated and cannot read page content, but companion extensions or app UIs might still collect limited analytics.
Platform and UX views
- Some criticize iOS for restrictions (no full uBlock Origin in Safari, no sideloading, Safari engine requirement), while others note there have been capable blockers for years and that browser choice is just one factor among many.
- A recurring sentiment: modern link behavior and engagement‑driven UX (dark patterns, forced apps, constant popups) has significantly degraded the web experience, making robust ad/tracker blocking feel essential.