On-device by default: what I learned building a storage cleaner and a medical records app for iPhone

Two of my iPhone apps handle very different data: one handles photos and videos, the other medical records. They ended up with the same architecture decision: everything runs on the device, and we run no server that ever receives user files. Here's why, and what that changes in practice.

The storage problem nobody's cleaner actually solves

Most "phone storage cleaner" apps show you your whole photo library sorted by size. That's the wrong list. With iCloud Photos and Optimize iPhone Storage turned on, your library might be 800 GB at full size while only 12 GB actually sits on the device. Deleting a 4 GB video whose original lives only in iCloud frees nothing locally.

SnapClean is built around that distinction:

1. Measure: check what's actually stored on this iPhone and mark items whose originals live only in iCloud.
2. Review: show one list with the biggest local offenders first, filterable by similar shots, screenshots, large videos, and large files.
3. Clear or compress: every change is confirmed. Screenshots and large videos can be compressed in place, and the original stays recoverable for 30 days once the new copy is safely saved.

The detail I'm proudest of is the honest delete receipt. After every batch, it shows what was genuinely freed now and what is still sitting in Recently Deleted for the next 30 days. Most cleaners show one optimistic estimate.

All analysis runs on-device: no uploads, no account, no ads, and a one-time purchase instead of a subscription.

Medical records: the data you least want on someone else's server

ScanMind organizes the paperwork a clinic hands you, plus PDFs from patient portals. You photograph the paper or import the PDF, and ScanMind reads it, files it by person, and makes every word searchable.

• Text recognition runs on the iPhone and keeps working in airplane mode.
• Files live in the user's own iCloud. We run no server that receives them.
• Separate profiles per person ("Mom's file" and "Dad's file"), with a handoff when family needs to take over.
• One printable page for the nurse: medications, diagnoses, surgeries, allergies, and recent records.

The free plan is permanent: one profile, unlimited scans and imports, OCR, full-text search, and clean PDF export. If someone cancels Pro, every record stays readable and exportable. When you're holding people's medical history, that should be the default.

What "on-device" costs you as a developer

It's not free. You give up:

• Server-side analytics on content. You can't learn from what users scan.
• Easy cross-platform. No web app reading the same database.
• Big models. You're bounded by what runs well on an iPhone.

What you get:

• A privacy policy that's short and true.
• No breach surface for the most sensitive data.
• No backend bill that grows with users, which matters a lot for an indie dev.
• Offline by default. A clinic waiting room with one bar of signal is a normal use case, not an edge case.

For utility apps that touch personal files, I think on-device should be the starting point, and you should have to justify the server, not the other way around.

Other small apps I've built, including habit and fitness apps with the same "no account" approach, are at qumge.com/en/products.