To solve this, I built ShortGuard.

Technical Implementation

Since Apple doesn't provide a "Shorts-only" blocking API, I had to implement a local filtering layer. ShortGuard uses the NEVPNManager API and a local Root Certificate to intercept and filter specific network requests.

100% Local: All traffic filtering happens strictly on-device. No user data is ever collected or transmitted to external servers.

Granular Control: It identifies and drops requests to specific endpoints that serve YouTube Shorts.

Current Behavior: Due to how the initial YouTube payload is structured, you might still see the very first Shorts video in the feed. However, ShortGuard successfully blocks the "infinite scroll" mechanism, preventing you from falling into the scrolling rabbit hole.

The Apple Rejection

After months of development, Apple rejected ShortGuard under Guideline 2.5.1, stating that using a VPN profile or root certificate to block content in third-party apps is "not appropriate."

I pointed out a clear double standard: pro-level tools like Proxyman are permitted to use this exact technical architecture to intercept and block traffic. Why is this technical approach considered "appropriate" for a developer utility but "inappropriate" for a user's digital well-being tool?

Apple maintained their stance and rejected my final appeal.

Free Release via TestFlight

I believe users should have the right to control their own network traffic to protect their focus. Since Apple won't allow a formal App Store release, I’m making ShortGuard available for free via TestFlight to anyone who needs to regain their focus.

TestFlight Link: https://testflight.apple.com/join/eTKmdWCU

If this tool helps you reclaim your time from the algorithm, feel free to buy me a coffee: https://buymeacoffee.com/callmejustdodo

I'm just happy to see this project finally in the hands of people who need it.