Anti-spam app · iOS · Android · 2026
stop spamOnboarding for an anti-spam app means asking for critical permissions: access to calls, messages and filters. It was the screen where people dropped off before they ever got protected.
I split the permissions into protection levels and added a progress meter and blocked-spam counters, so a dull system dialog became a visible benefit. Less anxiety, fewer reflexive “Don’t Allow” taps. Onboarding conversion went up 25%, drop-off went down 30%.
An anti-spam app is useless without system permissions: no access to calls and messages, nothing gets blocked, and the app is just a pretty icon. But to grant them, the user clicks through a series of “Allow access to…” system dialogs that are alarming, confusing and dull. That’s where people got lost: they installed the app but never reached working protection.
The job wasn’t to make “please tap Allow” look prettier. It was to explain why each permission matters and turn a mandatory, boring step into clear progress. Not cosmetics on top of a system dialog, but meaning: what the user gets for each access they grant.
Drop-off research: I took the onboarding funnel apart and found which system dialogs made people leave before they got protected.
Onboarding redesign: I rebuilt the screen flow, from “give us access” to “here’s what you get for it”.
Gamification: I came up with the “protection level” meter and blocked-spam counters, progress you can see and want to finish.
Mock-ups and prototype: I designed screens and states for iOS and Android, working around each platform’s system dialogs.
Product and analytics: we aligned on funnel metrics, where exactly conversion sagged and which permissions protection can’t work without.
iOS and Android engineering: I found out which system dialogs we could trigger and in what order, what each platform allows and what it doesn’t. Cheaper to learn before the mock-ups than after.
Marketing and app stores: we agreed that onboarding has to deliver on the store listing’s promise, “we block spam”, right away instead of disappointing on the first screen.
ImpactOnboarding reads as one story, not a pile of random system pop-ups.
I built two versions of onboarding and tested them with users. Version 1 was the familiar one: system dialogs back to back with short captions. Version 2 was gamified: a protection level meter, block counters and a “why” screen before each request. Then I looked at funnel numbers, not personal taste.
“I want to know why the app needs my calls before I agree.” Version 2
“I want to see that the access already does something, not that it’s just taken up front.” Version 2
“I want to know how many steps are left until I’m protected.” Version 2
I measured onboarding conversion (did the user reach protection switched on), drop-off at each system dialog and time to complete. The gamified version won, with a clear lead in how many people made it to the end.
Completion: roughly a quarter more people made it to protection switched on, mostly thanks to the progress meter and block counters.
User peace of mind: the “why” screen before each request took the anxiety out, and reflexive “Don’t Allow” taps dropped noticeably.
+25% conversion and −30% drop-off are real onboarding metrics after release. The clarity ratings come from user testing, not production, and are marked in the code as an “estimate”.
Badges and levels for blocked spam: onboarding flows into retention, and protection becomes a long game.
Suggest the next permission when it’ll be most useful, instead of dumping them all at launch.
Screens and states are designed for both platforms, so engineering builds onboarding without asking about every screen.
More case studies
I’ll walk you through the details when we meet, and show you what didn’t fit on the page.
