Where this is going.

Now

• 1.3.0 is out. The core reads JPEG, PNG, WebP and HEIC. JPEG is the weathered path — verified on macOS 26.5.2 arm64 and Linux aarch64/x86-64, 741 checks, 8/8 suites, zero warnings — and PNG, WebP and HEIC are newer, each with its own suite and fuzzing. The guarantees page is honest about what has and has not been cross-checked for each.
• ScrubPony for Android is out. The same core on the phone, a direct download today with an F-Droid listing in progress. iOS is in development.
• Field reports. The most useful thing right now is real files the fixture corpus does not cover — phone HEICs especially. A file this misreads is worth more than a description of how it misreads it.

Next

• A Homebrew tap. Single biggest usability win left. git clone && make is a small ask for developers and a large one for everybody else. Nothing is published yet, and the install page will not print a brew install line before there is one to run.
• A manual page. --help covers the flags, but man scrubpony is where people look, and it belongs in make install.
• Wider platform reports. The BSDs should work untouched — same POSIX surface — but they are untested rather than supported, and that wording only changes when somebody has actually run the suite there.
• Cross-verifying the newer formats. PNG, WebP and HEIC each need what JPEG already has: a real libFuzzer run, an exiftool cross-check, and a run on macOS hardware. Until then they are marked as newer and less weathered, on purpose.
• iOS. In development — the same core, the third front end after the command line and Android.

Exploring

These are under consideration, not commitments. They ship when they can be done right, or not at all:

• AVIF. The obvious next container now that HEIC is in: it shares the ISOBMFF structure, so much of the machinery is already there. It is not tested yet, so it is not claimed.
• More prebuilt binaries. The signed Android APK is the first — a downloaded binary you can check against a published checksum and signature. Doing the same for the desktop tool is a real supply-chain question: if it happens it happens with reproducible builds and signatures, or it does not happen.
• A policy file. Letting the keep/drop table be overridden per-run. Tempting, and also the fastest route to somebody configuring themselves back into leaking GPS. Probably no.
• Parallel walking. 1,200 files in 3.2 seconds is already fast enough that this is a solution looking for a problem. It would be revisited if somebody turns up with a library where it is not.

Not planned

• Windows. Out of scope by design. O_NOFOLLOW, POSIX permission bits and rename-over-an-existing-file all behave differently there, and those are exactly the things the safety guarantees rest on.
• Editing metadata. Removing is a much smaller problem than writing, and keeping the scope there is what makes "provably did not touch the pixels" a claim worth making. exiftool already does the writing job well.
• A GUI on the command-line tool. scrubpony reads directories; that is the interface, and it stays that way. Tapping and sharing is what the phone app is for — a separate front end, not a window bolted onto the CLI.
• Re-encoding, resizing, or watermark removal. All three would mean touching pixels, which is the one thing this tool exists not to do.

Have an opinion on priorities? Tell the developer directly — the roadmap genuinely bends to real feedback.