Disclosure: I work on Swipe Cleaner.
Most "clean up your camera roll" apps start the same way: create an account, grant full library access, and then — often without saying so loudly — upload thumbnails or full images to a server to "detect duplicates" or "find blurry shots."
For a photo library that quietly contains passports, whiteboard snapshots, and the occasional screenshot of a 2FA code, that always felt backwards to me. So when we started building Swipe Cleaner (an iOS photo cleanup app), we picked one hard constraint up front:
No account. No uploads. Every decision happens on the device.
That single rule shaped almost every design choice that followed. Here's what changed.
1. The review model: swipe, don't auto-delete
The tempting shortcut is to run a model that scores every photo and auto-suggests deletions. But "smart" auto-deletion is exactly where these apps lose people's trust — one wrong call and you've lost a photo you cared about.
Instead the core loop is manual and boring on purpose: you see one photo at a time and swipe. Left to trash, right to keep. You can start from All Photos, Videos, Screenshots, Favorites, or a timeline. It turns a vague, overwhelming task ("I have 12,000 photos") into a series of one-second decisions.
2. Nothing is actually deleted until you confirm the batch
This is the part I'd defend the hardest.
Swiping left doesn't delete anything. It moves the photo into a pending-delete queue. You keep swiping, build up a batch, and only at the end do you review the whole batch and confirm once. The actual deletion then goes through the system PhotoKit flow — so iOS shows its own confirmation, and the files land in "Recently Deleted" where they're recoverable for 30 days.
Two safety nets (our batch review + the OS's own trash) instead of an irreversible tap. For a destructive action, that redundancy is worth the extra step.
3. On-device means "smart" features have to be cheap
Without a server, you can't lean on heavy ML pipelines. So the useful features are the ones that are genuinely local and fast: sorting by file size (surprisingly effective — big videos are usually the real storage hogs), grouping, and running smoothly on large libraries without a long first-time "scan everything" delay.
Constraint as a feature: because there's no upload step, there's no waiting for a network round trip, and there's nothing to leak. The app works the same on a plane as it does on wifi.
What I'd tell another builder
If you're building anything that touches personal data, try writing your privacy constraint as a technical constraint before you write the marketing copy. "We don't upload your photos" is a nice sentence. "The app has no backend that can receive a photo" is an architecture — and it forces better decisions.
The core cleanup is free; there's a supporter tier for longer-term stats and an advanced queue, but the privacy model is the same either way.
If you're on iOS and your storage is permanently "Almost Full," you can try it here: https://apps.apple.com/cn/app/id6779493280
Curious how other people handle the delete-confirmation UX in destructive-action apps — do you prefer a batch review, or immediate undo?
Top comments (0)