The three taps problem
Last spring, a user messaged us: 'I found out my weather app has calendar access. I don't even want to know why. But getting to Settings to turn it off took me five minutes of hunting.' She wasn't complaining about Guard. She was complaining about iOS itself.
When knowing the problem isn't enough
Guard's core job is simple: show you which of your installed apps have access to sensitive data, and tell you the privacy risk. That part we got right. The permission dashboard screens up all 12 demo apps, each with a risk score. Tap on Spotify. You see it wants access to your calendar, photos, contacts. You think, 'That's unnecessary.'
Then what? iOS doesn't make it easy. You have to navigate to Settings, find Privacy, scroll to Calendar, tap Spotify again, and toggle it off. Three separate screens. Multiple taps. And if you're checking five or six apps, you're doing this dance five or six times.
The first time a user asked us why Guard didn't just let them revoke permissions directly, I understood the question immediately. It felt like we were stopping halfway through the job. We showed you the problem and then sent you off to find the solution yourself.
The sandbox problem nobody wants to hear about
I spent a frustrating week reading Apple's developer documentation. The honest answer is this: iOS doesn't let third-party apps revoke permissions on behalf of users. The sandbox is locked tight. No app can modify your settings from the background. It's good security design, but it meant we couldn't build what users were asking for.
So we built the next best thing. A deep-link. One tap from Guard's permission dashboard takes you directly to the exact iOS Settings screen where you need to be. Not to Settings root. Not to Privacy root. To the specific app, the specific permission, ready to toggle.
It sounds small. It's not. The difference between five minutes and thirty seconds matters when you're auditing five apps. And more importantly, it meant we were actually solving the problem people mentioned, rather than pretending the friction didn't exist.
Getting the detail right nearly broke us
The deep-link should work for every permission type: Camera, Microphone, Photos, Contacts, Calendar, Health, Location, and so on. But iOS Settings doesn't give you a straightforward URL scheme for all of them. Some permissions require specific app IDs. Others have sub-settings. Apple's own apps behave differently than third-party apps in certain cases.
We tested with forty or fifty real apps. Some worked on the first try. Others didn't. A few opened Settings but landed you in the wrong place. That felt worse than no link at all. We went through three or four iterations of the URL structure before we got it consistent enough to ship.
By the time we launched, the deep-link worked for the most common permission types. It's one of those features users don't notice if it works, but they notice immediately if it breaks. We've kept refining it. Some users have sent us feedback about edge cases we hadn't caught. We fix those.
Why it matters that it's free
The deep-link revoke feature is baked into the free version of Guard. No paywall. No upgrade needed. That was intentional.
The premium tiers, Personal Pro and Family, add real-time alerts when an app changes its permission requests, a clipboard safety check, detailed tracking information, and on Family tier, a hub to manage six devices with child controls. Those are features that took real work and ongoing maintenance. They belong behind a payment.
But the core act of revoking a permission? That's foundational. If we show you that an app has access to something it shouldn't, we have to give you a fast path to fix it. Putting that behind a paywall would have felt like holding users' privacy hostage.
What this taught us about building privacy tools
A privacy app can feel responsible just by showing you the problem. 'Look how exposed you are.' But responsibility is friction reduction. It's taking the information you now have and making the next step as easy as possible.
Every privacy-conscious person knows they should audit their app permissions. Most don't, because it takes time and the process is buried in Settings. Guard addresses both: it brings the problem to the surface, and the deep-link removes the friction of fixing it.
We didn't build the most technically complex feature. We built the most useful one for the actual problem people face.
Has the friction of managing your app permissions kept you from doing it? That's the moment we built for.