The swipe-cull workflow: why undo is the only thing that made us sleep at night
Two weeks before launch, a beta tester sent a message that made me stop work for an hour. She'd deleted 200 photos in quick succession using the swipe workflow, felt the relief, then realised she'd removed a handful she wanted to keep. The panic in her message was real. That's when I understood: the speed of the swipe-cull workflow only matters if you know you can undo.
Why speed matters, but safety matters more
When you're facing 5,000 photos on your phone and you've finally decided to actually deal with it, you don't want friction. You want to move. Swipe left to delete, swipe right to keep. Tap through a hundred photos in five minutes and feel the weight lift off your device and your mind.
But here's what most cleaning apps get wrong: they treat that speed as the whole point. Delete fast, move on, done. What they miss is that nobody makes perfect decisions at speed. You might swipe left on a photo thinking it's a blurry duplicate, only to realise half a second later that it's actually the candid you were looking for. By then, it's gone.
That's why undo had to be more than a nice-to-have. It had to be reliable, instant, and always there. Not buried three taps deep. Not explained in a tutorial you skip. Just there, ready, because we knew people would need it.
How the undo actually works (and why it's harder than it sounds)
The undo in Culr's swipe-cull workflow lets you step back one photo at a time. You've deleted a photo by mistake? Tap undo. It comes back. You can keep undoing through your recent decisions as far back as you need. One deletion. Ten deletions. A hundred. We hold the full history of your session, so you're never locked into a decision you didn't mean to make.
What made this tricky was the iCloud integration. Before we delete anything, Culr checks whether that photo has synced to iCloud yet. If it hasn't, we keep a local backup before we actually remove it from your phone. If it has, we know it's safe to delete because you can recover it from iCloud later if you absolutely need to. But here's the catch: we had to make sure the undo workflow respected that status check every single time. If you undo a deletion, that photo has to come back with the same iCloud safety verification it had before. You can't undo a photo back into an unsafe state.
That meant building undo as a proper state machine, not just a quick revert button. It took longer to build, but it meant we could sleep.
The real-world version: wedding photographers and the photographer mode
One of our early users was a wedding photographer in Yorkshire who came to us with a specific problem. After a shoot, she'd have 3,000 raw photos, and she needed to cull them down to maybe 600 keepers in an afternoon. She was doing it in her phone's built-in gallery app, one photo at a time, no grouping, no context. It was brutal.
We built Photographer Mode for people like her. The app groups photos by shoot, using a two-hour gap as the boundary. So a morning ceremony is one shoot, the reception is another. Then within each shoot, you swipe through and keep or delete. Undo works the same way. But here's where it gets powerful: when you're culling a 200-photo shoot and you change your mind on three of them halfway through, you don't have to start over. You undo those three and move on.
The other thing we added for photographers was burst ranking. When your camera fires off a burst of ten photos in a second, Culr measures the sharpness of each frame and highlights the keeper, the one where everyone's eyes are open and the moment is sharp. You can still keep the others if you want. The undo still works. But now you're not culling blind.
The workflow in practice: what actually happens when you swipe
You open Culr and it shows you a single photo. You swipe left to delete, right to keep. The next photo appears instantly. No loading. No thinking. Just rhythm. After you've made your decision on a photo, if you change your mind within that session, you tap undo. The photo reappears. You can keep undoing back through your recent decisions as far as you want to go, and each time, that photo goes back into your camera roll in exactly the state it was before you swiped on it.
The reason this matters beyond just convenience is psychological. When you're trying to make quick decisions about 500 photos, the threat of permanent loss slows you down. You hover over each one longer. You second-guess yourself. But if you know you can undo, you move faster and more honestly. You swipe left because that photo really doesn't serve you, not because you're afraid to delete anything.
On the Pro plan, you can pair this with Scheduled Auto-Clean, which runs on your phone in the background on the days and times you set. But with the swipe-cull workflow, most people just want to sit down once and get it done. Both approaches work. That's the point. You choose your pace.
What we didn't build (and why that matters)
Early on, someone suggested we add a "confirm delete" dialog. A popup. A second chance before the photo actually goes. We said no. That would break the flow. The entire point of the swipe-cull workflow is that it's frictionless. You move. The undo is your second chance, but it's not in your way while you're working. It's there if you need it, not inserted between every decision.
We also didn't build some kind of recovery bin where deleted photos sit for 30 days waiting to be permanently removed. That's common in other apps and it adds complexity. Our approach is simpler: before any photo is deleted, we check iCloud. If it's synced, it's recoverable from iCloud anyway, so we don't need to hold it. If it hasn't synced, the undo in your current session is your lifeline. That's one less system to maintain and one less reason to doubt whether your photos are actually gone.
The simplicity of that design, I think, is why it works.
The swipe-cull workflow only works if you trust it, and you can't trust it if you don't believe you can undo. Have you ever deleted something important by accident and wished there was a second chance? That's the entire reason this feature exists.