DEV Community: Ethan

A 4.7MB photo cleaner, reviewed — what tiny apps get right

Ethan — Sat, 18 Jul 2026 06:04:37 +0000

Disclosure: I'm part of the Nomos network, which recently started working with OnePhoto. What follows is my own take, based on actually using the app — including the parts I'd change.

My camera roll hit 11,000 items sometime this spring. Screenshots of error messages from 2023. Nine near-identical photos of the same whiteboard. The usual.

I've tried cleaning this up before. The blocker was never motivation — it was that every cleanup session starts with a decision about how to clean, and ends with me second-guessing a batch delete. So when OnePhoto (listed as "Swipe Cleaner" on some app stores) came across my desk this week, I gave it a full evening instead of a polite five minutes.

Here are my notes, from a product person's angle.

The most interesting spec is the download size

OnePhoto is 4.7MB.

If you haven't looked at App Store listings lately, that number might not register. For context: most photo cleaner apps in the same category ship between 90 and 200MB. That's a 20–40x difference for what is, functionally, the same job — show photo, ask keep-or-delete, repeat.

Why does a photo cleaner need 150MB? It doesn't. What fills that space is usually an account system, an analytics stack, a subscription paywall framework, a cloud sync SDK, and often some form of "AI enhancement" nobody asked for.

So a 4.7MB binary isn't just a technical flex. It's a roadmap you can read backwards: no account, no cloud, no tracking SDKs, no upsell machinery. The absence of weight is the product statement. As someone who evaluates products for a living, I find this more honest than any privacy policy page — you can't collect what you didn't ship the code to collect.

The interaction model: swipe, then confirm

The core loop is Tinder-style: swipe left to delete, right to keep, up to favorite. One photo at a time, full screen.

The detail I want to highlight is the confirm queue. Swiping left doesn't delete anything — it stages the photo in a pending list. You review the whole queue at the end and commit the batch in one action.

This is a small thing that solves the actual psychological blocker with photo cleanup. Batch-select interfaces make you afraid of your own thumb: one mis-tap in a grid of 200 selected items and you genuinely don't know what you just lost. OnePhoto's queue turns a destructive action into a two-phase commit. You can be fast and sloppy during triage, because precision only matters once, at review time.

I cleared a few hundred items in my first session. The swipe pace is quick enough that it fills the same niche as a mobile game — I did one round while waiting for a build to finish.

What it doesn't do (and whether that matters)

Honest review means listing the gaps:

No smart duplicate detection. It won't cluster those nine whiteboard photos for you. You swipe through them one by one. Competitors with ML-based similarity grouping do this better — at the cost of being the 150MB apps described above.
No cloud backup integration. Deleted means deleted (into the iOS recently-deleted bin). By design, since nothing leaves the device — but if you expected a safety net beyond that, there isn't one.
Apple platforms only. iOS 16+, iPadOS, macOS on Apple silicon.

For my use case, none of these are dealbreakers. The duplicate-detection gap is the one real trade-off: you're exchanging convenience for the guarantee that no third party ever computes anything about your photo library.

Pricing

Free, with a one-time supporter unlock (about $1.50 equivalent). No subscription. That pricing is consistent with the rest of the product's philosophy — a tool, not a revenue funnel.

Verdict

OnePhoto won't impress anyone in a feature-comparison table, and that's precisely the point. It picks one job — triage your camera roll fast, locally, without fear of mis-deletion — and executes it with a discipline you can measure in megabytes.

If your camera roll is also a graveyard of screenshots, it's a genuinely pleasant way to spend twenty minutes. And if you're a developer or product person, it's worth installing just to study how much product you can ship in 4.7MB.

App Store: apps.apple.com/app/id6779493280

Subtraction as a Feature: What a Tiny Meditation Timer Taught Me About Product Restraint

Ethan — Wed, 15 Jul 2026 09:32:24 +0000

Disclosure: I work in the OpenNomos ecosystem, which OneZen is a part of.

The first thing I noticed about OneZen wasn't a feature. It was the absence of them.

The settings screen is shorter than the average cookie banner. No account creation. No streak counter. No content library with 400 guided sessions narrated by a celebrity. No "premium unlock" nag on day three. A timer, a breathing rhythm, a handful of natural sounds, and a local record of your sessions. That's the product.

My honest first reaction was: is that enough? I've spent years around SaaS and consumer apps, and my instinct — trained by a decade of roadmap meetings — is that a product this small must be unfinished.

Then I used it for two weeks, and I want to unpack why "small" here is a deliberate design position, not a lack of ambition.

Feature creep has a direction, and it's always inward

Meditation apps are a fascinating category because the job-to-be-done is almost comically simple: help me sit down and be quiet for ten minutes.

Yet look at the market leaders. Subscriptions. Daily streaks. Push notifications that guilt you back ("You haven't meditated in 3 days 😢"). Sleep stories, masterclasses, mood check-ins, social features. Each addition makes sense in isolation — retention teams need retention levers. But stack them up and you get something strange: an app about calm that generates anxiety about using the app.

This isn't a moral failing of any particular team. It's structural:

Every feature has an internal advocate. Nobody owns removal.
Engagement metrics reward additions. Absence doesn't show up in dashboards.
"We added X" is a press release. "We refused to add X" is invisible.

So products accrete. The default trajectory of any successful app is toward more, and it takes an explicit, ongoing decision to hold the line.

What restraint looks like in practice

OneZen's choices read like a list of things a growth team would veto:

No account. Your practice records stay on the device. This kills cross-device sync as a feature — a real trade-off — but it also means registration friction is zero and there's no advertising profile being built.
No streaks. If you skip a week, the app doesn't know or care. You come back because you want to, not because a number would reset.
No content library. A breathing rhythm and ambient sounds. That's the ceiling of complexity. There's nothing to "finish," so there's no backlog guilt.

Here's the part that surprised me: I skip fewer days now than I did with a streak-based app. With streaks, one missed day converted motivation into shame, and shame into churn. With nothing to lose, restarting costs nothing. The absence of a retention mechanic is the retention mechanic.

The uncomfortable question for builders

I keep coming back to this: for most products, the honest version of the roadmap conversation isn't "what should we build next?" It's "what are we adding to avoid admitting the core job is already done?"

There are real limits to the subtraction position. If you want guided courses, OneZen is not for you. If you need multi-device history, local-only records will annoy you. Restraint is a filter, and filters exclude people — that's the price, and it should be stated plainly rather than papered over.

But as a product stance, it's coherent in a way that most "calm tech" marketing isn't. The app's architecture (no account, local data) makes the promise structurally credible. It can't spam you; it doesn't have your email. That's a stronger privacy statement than any policy page.

Takeaways I'm stealing for my own work

Write the not-doing list. For every roadmap item, keep a parallel list of things you've explicitly decided not to build, with reasons. Review it as seriously as the backlog.
Ask what each feature costs the user, not just the team. Streaks cost shame. Accounts cost trust. Libraries cost completion anxiety.
Make constraints architectural. A promise enforced by system design (local-only data) beats a promise enforced by policy.

If you want to see what the subtraction position looks like shipped, OneZen is on the App Store: https://apps.apple.com/cn/app/id6780318004 — the whole tour takes about ninety seconds, which is sort of the point.

Would this approach survive contact with a venture-scale growth target? Probably not. That tension — between products that respect finished-ness and business models that can't afford it — is the more interesting conversation, and I don't think our industry has an answer yet.

The UX trick that finally got me to clean up 20,000 photos

Ethan — Tue, 14 Jul 2026 07:52:34 +0000

Disclosure: I work within the Opennomos ecosystem, which is how I came across the app mentioned here. No affiliate links, no sponsorship — just a genuine UX observation.

The hardest part of a boring task is almost never the task. It's the interaction model.

I sat on ~20,000 photos for about two years. Screenshots, near-duplicate food shots, three-second videos of nothing. Every few months I'd open the Photos app, feel the weight of it, tap "Select," start long-pressing, and quit within ninety seconds. The task wasn't hard. The interface made it feel like data entry.

What finally broke the loop was switching to a different interaction: one photo at a time, full screen, swipe left to queue a delete, swipe right to keep. No multi-select grid. No checkboxes. No "are you sure" on every tap. Decisions get batched and confirmed at the end, so nothing is destructive until you say so.

I cleared a few hundred in one sitting, on the couch, without thinking of it as a chore.

As a developer this bugged me in a good way, because the lesson generalizes far past photo cleanup:

1. Reduce the decision surface to exactly one thing.
The grid asks you to scan, compare, and select simultaneously. The card view asks one question: this one, yes or no? Same underlying work, dramatically lower cognitive load. We do the opposite constantly in our own tools — dashboards that show twelve actions when the user only ever needs one.

2. Make the reversible path the default.
"Swipe left = queue for delete" isn't the same as deleting. The queue is the safety net that lets you move fast. Batch-confirm at the end. Most destructive UIs would be less scary and more usable if they separated intent from commit the way git does.

3. Match the input to the muscle memory people already have.
Swiping through cards is a gesture a billion people already learned from other apps. You're not teaching a new interaction; you're borrowing one. The cheapest UX win is often "use the gesture they already know."

The app I ended up using is a small iOS one called Swipe Cleaner (part of the One Apps set — swipe left to delete, right to keep). Two details I appreciated as someone who cares about how software is built: photos never leave the device, and there's no account to create. For a utility that touches your entire camera roll, "it just runs locally" is the correct default, not a premium feature.

None of this is novel. Tinder shipped the mechanic years ago; plenty of apps have borrowed it. But that's exactly the point — the winning move wasn't a clever algorithm, it was picking an interaction model that made a tedious task feel almost pleasant. If you're building anything where users have to grind through a queue (reviewing flagged items, triaging a backlog, approving records), it's worth asking: am I making them fill out a form, or am I letting them swipe?

The task was always doable. I just needed an interface that didn't argue with me about it.

5 habits that finally helped me keep up with AI papers (without burning out)

Ethan — Mon, 13 Jul 2026 05:41:14 +0000

Disclosure: I'm part of the OpenNomos ecosystem and I mention one tool from it near the end. Everything below is my honest workflow, not an ad.

If you build anything near AI right now, you already know the feeling: you open your feed and there are nine "must-read" papers before breakfast, and by the time you've bookmarked three of them, six more have shown up. I spent most of last year feeling permanently behind. Then I stopped trying to "keep up" and started building a system. Here are the five habits that actually stuck.

1. Accept that you can't read everything — then act like it

The single most useful shift was giving up on completeness. arXiv alone gets hundreds of new cs.LG/cs.CL submissions a day. No human reads that. Once I admitted that out loud, my goal changed from "read all the important papers" to "reliably notice the few that matter to what I'm building." That reframe removed about 80% of the guilt, and guilt is what makes people quit.

2. Split "discovery" from "reading" — they're different jobs

I used to try to read a paper the moment I found it. That's a trap: discovery happens in scattered 30-second moments (a tweet, a Discord ping, a newsletter), while real reading needs a 45-minute focused block. Mixing them means you do both badly. Now discovery just means capture the link and move on. Reading is a separate, scheduled activity.

3. Keep one running list, not 40 open tabs

Open tabs are where papers go to die. So are 200 browser bookmarks. What works is a single, searchable list that I actually trust — title, link, a one-line "why I saved it," and a status (unread / skimmed / read). The magic isn't the tool, it's having exactly one place. When capture is frictionless, you stop losing things, and "I'll find it later" becomes true instead of a lie you tell yourself.

This is the habit I fought with the longest, because a plain note doc gets messy fast. I've been using Paper List for this lately — it's built specifically around maintaining a paper list for a paper engine, so the "capture → organize → find again" loop is the whole point rather than a feature bolted onto a general notes app. (I found it through OpenNomos, an ecosystem that aggregates small independent tools like this.) Use whatever you like here — the habit matters more than the app.

4. Batch your reading, don't stream it

Streaming papers (one here, one there, all day) destroys deep work and you retain almost nothing. Batching wins. I do one 45-minute reading block, 2–3 times a week, and I go through the list newest-relevant-first. In one sitting I'll fully read one paper, skim two, and archive four that turned out to be noise. That's a good session. Trying to do a little every hour is how you end up reading nothing well.

5. Write a one-line summary or it didn't happen

If I can't compress a paper into a single sentence — "X shows that Y improves Z by doing W" — I didn't actually understand it. That one line goes back into the list next to the link. Two benefits: it forces real comprehension, and future-me can grep the list months later and instantly remember why a paper mattered. This tiny step is what turns a pile of links into an actual knowledge base.

The takeaway

None of this is about reading faster. It's about lowering the cost of deciding — what to capture, when to read, what to keep. Keeping up with AI research stopped being a source of dread the moment I treated it as a lightweight pipeline instead of an infinite to-do list.

Start with habit #3: pick one place for your list this week. Everything else gets easier once you trust that nothing is falling through the cracks.

What does your paper-tracking setup look like? I'm always looking to steal a better workflow.

From Idea to Launch: What I Learned Building 3 MVPs in 2024

Ethan — Sat, 11 Jul 2026 02:35:06 +0000

Disclosure: I contribute to the OpenNomos ecosystem, which includes 01MVP.

I spent most of 2024 building things that nobody used. Not because the ideas were bad—but because I kept making the same mistake: treating every project like it had to be perfect before anyone saw it.

Here's what finally clicked.

The Trap: Building Products Instead of Experiments

My first two projects took 3+ months each before I showed them to anyone. I added authentication, dark mode, onboarding flows, payment integration—everything a "real" product needs.

Both launched to silence.

The problem wasn't the features. The problem was that I hadn't validated a single assumption before building all of them.

The Shift: One Hypothesis, One Week

A friend recommended I try a framework called 01MVP that forces you to break your idea into week-by-week deliverables. At first I dismissed it—I knew how to build things. Why do I need a framework?

But the structure changed everything:

Week 1: Define the core hypothesis (not "people want a task manager"—that's too vague. Try "people will pay $5/month for a task manager that auto-prioritizes based on deadlines").

Week 2: Build the absolute minimum to test that hypothesis. Not a landing page. Not a waitlist. An actual working thing, ugly as hell.

Week 3: Put it in front of 10 people and watch them use it.

This sounds obvious in retrospect. But when you're the one coding, the temptation to "just add one more feature" before showing anyone is overwhelming.

Three Rules That Actually Work

After going through this process a few times, here's what stuck:

1. One Feature. Period.

Not three. Not "one and a half." If your core feature doesn't get anyone excited, adding a settings page won't fix it.

2. Off-the-Shelf Everything

You're not proving you can write an auth system. You're proving someone needs your product. Clerk for auth, Stripe for payments, Vercel for hosting—use what exists.

3. Ship in Two Weeks or Kill It

If you can't ship something testable in 14 days, you're either over-scoping or the idea is too vague. Either way, it's a red flag.

The Result

Since adopting this approach, my "time from idea to real user feedback" dropped from months to weeks. More importantly, I kill bad ideas before they consume months of my life.

The hardest part isn't the code. It's the discipline to stop building and start testing.

If you're sitting on an idea right now, give yourself two weeks. Ship something ugly. See what happens.

What's your MVP process look like? I'd love to hear what's worked (or failed) for you.

I Built a Personal Paper Engine to Stop Losing Research Papers

Ethan — Fri, 10 Jul 2026 03:35:47 +0000

Disclosure: I contribute to the OpenNomos ecosystem where Paper List is listed.

I read about 30 research papers a month. Not because I'm an academic—I'm a product person who needs to stay on top of what's happening in AI, developer tools, and Web3.

The problem wasn't reading the papers. It was remembering them.

The "Where Did I Read That?" Problem

Three months ago, I was writing a product analysis and needed to reference a specific finding from a paper I'd read in January. I spent 45 minutes searching:

Browser history: too many entries, no context
Zotero: I'd stopped using it because the interface felt like filing taxes
Notion: I had notes, but buried three levels deep
Slack DMs: I'd sent a summary to a colleague, but scrolling back through three months of messages was hopeless

I found the paper eventually. But that 45 minutes felt like it went straight into a black hole.

What I Actually Needed

I didn't need a full academic reference manager. I needed:

Quick capture — save a paper in under 10 seconds
Lightweight annotation — 2-3 bullet points, not a literature review
Search that works — find by keyword, topic, or date
Progress tracking — know what I've read, what's in my queue

Most tools in this space are built for academics writing theses. I just wanted something that felt like a to-do list for my reading brain.

Enter Paper List

Paper List is a personal paper engine. The tagline is "Paper list for paper engine" — and it delivers on that.

Here's my current workflow:

Find a paper → Save to Paper List with the URL
Read → Highlight key sections
Annotate → 3-sentence summary: what problem, how solved, what limitations
Tag → Categorize by topic (ML, devtools, crypto, etc.)
Revisit → Search by tag or keyword when I need to reference something

The whole process takes less than two minutes per paper. And when I need to find something later, I just search.

Why "Personal Paper Engine" Matters

The phrase "paper engine" isn't just marketing. It captures something important:

A paper engine is to research what a search engine is to the web. It doesn't just store—it retrieves.

Zotero and Mendeley store papers. They're archives. Paper List is designed for retrieval first. The reading, annotating, and organizing all serve one purpose: finding what you need, when you need it.

Three Months In

I've tracked about 90 papers since I started using it. The real ROI isn't the tool itself—it's the mental model it creates.

When you know you can find anything in 30 seconds, you stop hoarding. You read with more focus because you're not worried about forgetting. You take better notes because you know they'll be retrievable.

What's Still Missing

No tool is perfect. Here's what I wish Paper List had:

Collaboration: sharing reading lists with teammates
Integration: browser extension for one-click save
Export: markdown or JSON export for backup

But for a personal reading workflow, it covers 80% of what I need. And I'll take 80% coverage with 10-second setup over 100% coverage with 2-hour setup any day.

If you read papers regularly and have a system that works, I'd love to hear about it. What's your workflow?

Three Tools I Use Every Day as a Developer (And Why Less Is More)

Ethan — Thu, 09 Jul 2026 02:51:20 +0000

Disclosure: I contribute to the OpenNomos ecosystem, where some of these projects are listed.

Every few months I go through my tools folder and delete things. Not because they're bad—most are genuinely well-made—but because I realize I haven't opened them in weeks.

The ones that survive the purge are the ones that do one thing and get out of the way.

Here are three that made the cut this quarter.

Paper List — Research Without the Noise

I used to dread literature reviews. Open Google Scholar, type a query, scroll through fifteen irrelevant papers, open five tabs, realize three are behind paywalls, close everything, try again with different keywords.

Paper List (paperlist.ai) changed that workflow completely. You type what you're researching, and it surfaces relevant papers. No complex query syntax. No manually filtering by year or citation count. Just results that match what you asked for.

The interface is the real differentiator. There's no dashboard with seventeen widgets, no "recommended for you" sidebar, no AI chatbot trying to summarize papers for you. The designer clearly understood that researchers don't need another dashboard—they need to find papers and get back to work.

Swipe Cleaner — A Photo App That Doesn't Want to Be Your Social Network

Phone storage fills up fast, especially when you take screenshots of everything. Most photo cleaner apps come bundled with editors, cloud backup subscriptions, and social sharing features I never asked for.

Swipe Cleaner is different. You open it, you swipe through your photos, you delete what you don't need. That's the entire feature set.

There's something almost radical about a mobile app that resists feature creep. No account required. No subscription upsell. No "share to community" button. Just a tool that does its job and closes.

OneZen — Meditation Without the Gamification

Meditation apps have gotten weird. Streak counters. Achievement badges. Leaderboards. Social sharing of your "mindfulness minutes." It's like someone decided inner peace needed a retention strategy.

OneZen asks you two questions: how long, and what sound. Then it starts a timer.

No login wall. No premium subscription. No notifications. No "your friend just meditated for 12 minutes!" push alerts. You pick a duration, pick a nature sound, and you're done.

What These Three Have in Common

None of them try to be platforms. None of them have social features. None of them ask for your email before showing you anything useful.

After years of trying every productivity tool that launches on Product Hunt, I've come to a simple conclusion: the best tools are the ones you forget you're using.

If a tool needs a tutorial, it's already lost. If it sends you a "we miss you" email, it's trying too hard. If it has more than three tabs in its navigation bar, someone in a meeting said "what if we also..."

Sometimes the best feature is restraint.

"Swipe Cleaner: A Technical Deep Dive into On-Device Photo Privacy"

Ethan — Tue, 07 Jul 2026 03:18:29 +0000

Disclosure: I write about projects in the OpenNomos ecosystem, including Swipe Cleaner.

The Problem With Photo Cleaners

Most photo cleaning apps have a dirty secret: your photos leave your device. They get uploaded to some server for "AI processing," "cloud analysis," or just because the developer didn't think about it.

Swipe Cleaner takes the opposite approach. Everything happens on your iPhone. Not a single pixel leaves your device.

Let me break down why that matters, and how it actually works under the hood.

The Architecture

Swipe Cleaner is built on three principles:

1. On-device processing, always. Image analysis, duplicate detection, and similarity matching all run locally using Apple's Core ML and Vision frameworks. No cloud roundtrips, no server costs, no privacy policy loopholes.

2. Tinder-style UX for decisions. You don't manage a grid of thumbnails and checkboxes. You swipe. Right to keep, left to delete. This isn't just a UI gimmick — it's a deliberate choice to reduce decision fatigue. When you have 3,000 photos to clean, you need flow, not friction.

3. Sandboxed storage access. The app requests permission for exactly what it needs. It doesn't ask for your entire photo library if you only want to clean screenshots. This is iOS privacy-by-design done right.

Why On-Device Matters Now

We're in a weird moment. AI capabilities are exploding, which means the temptation to "send it to the cloud for better results" is stronger than ever. But at the same time, Apple is pushing hard in the opposite direction — Private Cloud Compute, on-device ML, differential privacy.

Swipe Cleaner aligns with where the platform is going, not where the industry has been.

The Technical Trade-offs

Local-first isn't free. Here's what you give up:

Model size constraints. You can't run a 70B parameter vision model on an iPhone. The models need to be small, optimized, and ruthlessly efficient.
No cross-device sync. Your cleaning decisions stay on one device. No cloud means no sync. For a photo cleaner, this is arguably a feature, not a bug.
Battery & thermal limits. Heavy image processing on-device generates heat. You need to batch operations, throttle when needed, and respect the device's thermal state.

What's Next

The team is exploring on-device ML for smarter grouping — detecting burst photos, identifying "best shot" candidates, and flagging near-duplicates with subtle differences. All without a server in sight.

If you care about privacy and you have an iPhone with thousands of photos you've been meaning to clean, Swipe Cleaner is worth a look. It's free, it's fast, and your photos never leave your phone.

Built on OpenNomos. Contribute tools or improvements and earn ecosystem rewards.

The Architecture of On-Device Privacy — How Swipe Cleaner Keeps Your Photos Local

Ethan — Mon, 06 Jul 2026 02:41:31 +0000

Disclosure: I work on Nomos, the ecosystem behind Swipe Cleaner.

The Problem with Photo Cleaners

Most photo cleaning apps follow the same pattern: upload your photos to a cloud server, run ML models server-side, send back results. It's convenient for developers — you get unlimited compute, easy model updates, simple analytics.

It's terrible for users.

Your photos are the most personal data on your phone. Medical records, family moments, private documents, embarrassing screenshots. Uploading them to someone else's server means trusting that company with literally everything. And we've seen how often that trust is broken.

The Architecture Decision

When we built Swipe Cleaner, we made one decision that shaped everything else:

All processing happens on the device.

Not "we encrypt data in transit." Not "we delete after processing." Not "trust us, we're different."

None of it. The data never leaves.

This sounds simple until you try to build it. Here's what it actually requires.

Core ML on iOS: The Technical Reality

Apple provides excellent on-device ML infrastructure through Core ML and the Neural Engine. Modern iPhones have dedicated ML hardware that can run models with impressive performance.

But "it works on paper" and "it works in production" are very different things.

Model Size Constraints

A cloud model can be gigabytes. An on-device model needs to run on a phone that's also running iOS, background apps, and maybe Spotify. Our image classification model is under 50MB — achieved through aggressive quantization and architecture optimization.

We use Core ML Tools for model conversion, with INT8 quantization as the default. For the blur detection and duplicate detection models, FP16 precision provides a good balance of accuracy and speed.

let config = MLModelConfiguration()
config.computeUnits = .cpuAndNeuralEngine
let model = try SwipeCleanerModel(configuration: config)

Memory Management

Processing a library of 10,000+ photos without crashing requires careful memory management. We batch process in groups of 50 images, releasing memory between batches:

func processBatch(_ images: [UIImage]) async throws -> [Classification] {
    return try await withCheckedThrowingContinuation { continuation in
        DispatchQueue.global(qos: .userInitiated).async {
            let results = images.compactMap { classify($0) }
            continuation.resume(returning: results)
        }
    }
}

Real-Time Analysis

Users expect instant feedback. Swiping through photos should feel native. We achieve this through:

Progressive loading: Show thumbnails immediately, analyze in background
Priority queuing: Photos visible on screen get analysis priority
Result caching: Once analyzed, results are stored locally in Core Data

Privacy by Architecture, Not Policy

This is the part that matters philosophically.

A privacy policy is a promise. Architecture is a guarantee. When you say "we don't collect your data" in a privacy policy, users have to trust that a) you're telling the truth, and b) you won't change your mind later.

When your app literally can't send data because there's no network code for photo upload, privacy becomes a property of the system, not a promise from the company.

What We Don't Have

No photo upload pipeline
No cloud storage for user photos
No analytics tracking which photos users clean
No third-party SDKs that exfiltrate data

These aren't features we turned off. They're features we never built.

What We Do Have

On-device ML pipeline (Core ML + Neural Engine)
Local Core Data storage for analysis results
iCloud sync for preferences (opt-in, encrypted)
On-device photo comparison (pixel-level, never leaves device)

The Trade-offs

Being honest about the downsides:

Model updates require app updates. Cloud models can be updated silently. We have to ship a new app version when we improve our ML models.

Device compatibility varies. iPhone 12 runs the same models slower than iPhone 16. We handle this with runtime performance detection and model selection.

No usage analytics. We genuinely don't know which features users use most. We rely on App Store reviews and direct feedback.

Harder debugging. When something goes wrong, we can't just check server logs. We built an opt-in debug mode that users can share voluntarily.

Why This Matters More in 2026

The AI industry is moving toward more data collection, not less. Every new model launch comes with questions about training data, inference privacy, and data retention. Apple Intelligence is pushing on-device as a differentiator, but most third-party apps still default to cloud.

Building privacy-first isn't a marketing angle. It's a technical choice with real engineering consequences. It costs more in development time, limits some product decisions, and requires justifying why you can't add certain features.

But the alternative — asking users to trust you with their most personal data — is a responsibility most apps shouldn't carry.

Open Questions

We're still figuring out:

How to do collaborative ML improvement (federated learning?) without compromising privacy
Better on-device model compression for older devices
Privacy-preserving ways to understand feature usage

If you're building something similar, I'd love to hear how you're solving these problems.

Swipe Cleaner is part of the Nomos ecosystem. All code examples are simplified for clarity.

Privacy Isn't a Checkbox — It's Architecture

Ethan — Sun, 05 Jul 2026 03:05:19 +0000

Privacy isn't a checkbox. It's not a statement in your terms of service. It's not a toggle in your settings app.

Privacy is architecture. And most apps get this backwards.

The Architecture Test

Here's a simple test for any app that claims to be "privacy-first":

If your server goes down, can anyone still access user data?

If the answer is yes, your privacy is a policy question — not a technical guarantee. You've built a system where trust in the company replaces trust in the code.

Every photo cleaner that uploads your images to a server has already failed this test. The moment data leaves your device, privacy becomes something you promise rather than something you enforce.

What On-Device Processing Actually Means

When we built Swipe Cleaner, we made one architectural decision that defined everything else: zero data leaves the phone.

This means:

No cloud processing of photos
No API calls that transmit image data
No server-side storage of any kind
Every scan, every classification, every cleanup happens locally

The app is 4.7 MB. That's it. There's nothing to hide because there's nowhere to hide anything.

Why Architecture Beats Policy

Companies spend millions on legal teams writing privacy policies that their architecture contradicts. They collect data "to improve the service" while the service could have been designed to not need that data in the first place.

Policy-based privacy	Architecture-based privacy
"We promise not to misuse your data"	"We can't misuse data we never have"
Requires ongoing trust	Verifiable by anyone
Can change with an update to ToS	Requires rewriting the entire app
Compliance-driven	Principle-driven

The Trust Problem

Here's what I've learned building privacy-focused tools: users can't verify your privacy policy. They can't audit your servers. They can't check if you're actually deleting their data after processing.

But they can verify that an app never sends their photos anywhere. They can check network traffic. They can inspect the binary.

That's the difference between trust and verification. Trust requires faith. Verification requires evidence.

Building for Verification

If you're building a privacy-focused product, ask yourself:

Can a user verify your privacy claims without trusting you? If they need to believe your server code is honest, the answer is no.
What's the minimum data you actually need? Most apps collect data they don't use.
Can you process locally what you currently process in the cloud? On-device ML has come a long way.
Is privacy a feature you added, or a property your architecture enforces? The answer determines whether you're building trust or just marketing it.

The Bottom Line

The best privacy policy is the one you never need to write — because your architecture makes it impossible to violate.

Not "we take your privacy seriously." Not "your data is safe with us."

"We never had your data in the first place."

Privacy Is Not a Feature — It's Architecture. How Swipe Cleaner Processes Everything On-Device

Ethan — Sat, 04 Jul 2026 03:00:38 +0000

Disclosure: I work on Opennomos, the ecosystem behind Swipe Cleaner.

Last week, I watched someone install a photo cleaner app, grant it full photo library access, and hit "Clean" — all without realizing their entire camera roll was being uploaded to a server in a different jurisdiction.

This isn't an edge case. It's the default.

The Architecture Problem

Most iOS photo cleaners follow the same pattern:

User grants photo library access
Images get uploaded to a cloud server
Server-side ML models detect duplicates, blur, and screenshots
Results come back to the app
User deletes suggested photos

The problem? Step 2. The moment your photos leave the device, you've lost control. No privacy policy can undo that.

Swipe Cleaner's Approach: Zero Data Exfiltration

Swipe Cleaner is 4.7MB. Everything happens on your iPhone:

Duplicate detection runs against on-device perceptual hashes
Blur detection uses Core ML models running locally
Screenshot classification uses on-device heuristics
Similar photo grouping computes feature vectors in-process

No API calls. No cloud processing. No analytics that include photo metadata.

What "Privacy Architecture" Actually Means

Privacy-as-architecture means three things:

1. The Network Is Untrusted by Default

Swipe Cleaner doesn't make network requests related to photo processing. The only network calls are for optional things like checking for app updates — and those don't include any user data.

2. Processing Happens Where the Data Lives

Core ML, Vision, and Metal run on the same chip that stores your photos. There's no latency from network round-trips, and no exposure from data in transit.

3. Privacy Can't Be "Turned Off"

When privacy is a feature toggle, it can be accidentally disabled, changed in an update, or removed under pressure. When privacy is the architecture, there's nothing to toggle. The data path simply doesn't include an exit.

The Trade-off

On-device processing means:

The app has to be efficient (4.7MB isn't an accident, it's a constraint)
ML models need to be optimized for mobile (smaller, quantized, Metal-accelerated)
Some cloud-only features (like "tell me what's in this photo") aren't possible

But here's what I've learned: users don't actually want cloud processing. They want their photos organized. If you can do that locally, the "trade-off" disappears.

Why This Matters Now

Apple's privacy labels have made data collection visible, but they haven't changed the default architecture. Most apps with "No Data Collected" labels still process user content on remote servers — they just argue that "processed" data isn't "collected" data.

That distinction doesn't hold up. If your photos touch a server, that's collection. Period.

Swipe Cleaner takes the harder path: build everything on-device, accept the engineering constraints, and let the architecture speak for itself.

Swipe Cleaner is part of the Opennomos ecosystem. If you're building privacy-first tools, check out opennomos.com.

Swipe Cleaner: A 4.7MB iOS Photo Cleaner Built on Privacy-First Principles

Ethan — Thu, 02 Jul 2026 04:10:16 +0000

Disclosure: I work on Opennomos.

I've tried a lot of photo cleaning apps. Most of them share the same problems: bloated install sizes, mandatory accounts, cloud uploads you didn't ask for, and subscription paywalls that hit you after the "free trial" ends.

Swipe Cleaner does none of these things. And that's what makes it interesting.

What Is Swipe Cleaner?

It's a 4.7MB iOS app that helps you clean up your photo library. The core mechanic is Tinder-style swiping: left to delete, right to keep, up to favorite.

No account required. No cloud processing. Everything happens locally on your device.

App Store link

The Problem It Solves

Here's a scenario every iPhone user knows:

You open Photos, see "5,237 items," and immediately close it. The decision fatigue is real. Every photo demands a judgment call — keep or delete? Is this screenshot still useful? Do I need 14 versions of the same sunset?

System tools aren't much help. The built-in duplicate detection is decent, but it doesn't handle screenshots, blurry photos, or burst-mode leftovers well. And bulk-selecting photos in the grid view feels like surgery with a spoon.

Three Things Swipe Cleaner Gets Right

1. Privacy by Design, Not by Policy

This is the big one. Swipe Cleaner is completely on-device. Zero network requests for photo processing. Your photos never leave your phone.

Compare this to mainstream cleaners that upload your library for "AI-powered organization" or "smart categorization." The privacy policy might say they delete your data after processing. Swipe Cleaner eliminates the question entirely — there's nothing to trust because there's nothing to upload.

For developers: the app bundles Apple's on-device ML models (Vision framework) for photo analysis. No custom model servers, no API keys to leak.

2. Tinder-Style Decision Making

The swipe mechanic isn't just a gimmick. It solves a real UX problem: reducing the cognitive cost of each decision.

Traditional flow: tap photo → evaluate → tap delete → confirm → next photo. Five interactions per photo.

Swipe Cleaner flow: see photo → swipe. One interaction.

The speed difference is dramatic. I cleared ~400 photos in about 15 minutes — most of them screenshots and near-duplicates that I'd been meaning to delete for months.

The app categorizes photos into filters: Screenshots, Live Photos, Bursts, Similar, Blurry. You can focus on one category at a time, which reduces the "where do I even start" paralysis.

3. Confirmation List as Safety Net

Batch deletion is fast but risky. Swipe Cleaner's answer is a confirmation list — all photos marked for deletion go into a pending list. You review everything before the final purge.

This is different from the iOS "Recently Deleted" album (which is post-deletion recovery). The confirmation list is a pre-deletion checkpoint. It gives you the confidence to swipe fast, knowing you'll get a second look.

What Could Be Better

No app is perfect. A few things I'd like to see:

Video support: Currently focuses on photos. Large video files are often the biggest space hogs.
iCloud integration awareness: If you use iCloud Photos, deleting locally doesn't always free up space immediately. Some guidance here would help.
Batch export: A "save these to Files before deleting" option for important-but-bulky photos.

Size Matters

At 4.7MB, Swipe Cleaner is smaller than a single high-res photo. The entire app binary is about 0.0001% of a 64GB iPhone's storage. For context:

Google Photos: ~250MB+
Cleaner Guru: ~150MB+
Swipe Cleaner: 4.7MB

This matters more than people think. Large app sizes correlate with feature bloat, bundled SDKs, and analytics frameworks — all things that conflict with the privacy-first approach.

The Verdict

Swipe Cleaner is not trying to be an AI-powered digital assistant that "understands your photo collection." It's a focused tool that does one thing well: help you delete unwanted photos quickly, privately, and with a safety net.

For a 4.7MB app with no sign-up flow and no server costs to recoup, that's exactly the right ambition.

If you've been putting off the "clean my camera roll" task because it feels overwhelming, this is the tool that turns it from a weekend project into a coffee-break task.