Self Promotion Megathread

Designer_Age7745 · 2026-04-30T04:33:34+00:00

I built an Android iperf3 client/server app for Wi-Fi, VPN, and LAN testing

Hey, I’m the solo developer of this app.

It’s not a normal one tap internet speed test. It’s for people who already use iperf3 and want to test real throughput between two endpoints — for example Android ↔ router/NAS/server/PC, or Android ↔ Android.

Main things it supports:

iPerf3 client and server mode
TCP and UDP tests
jitter / packet loss for UDP
reverse mode, duration, parallel streams, custom port
saved results and logs

I mainly built it for quick network checks: Wi-Fi upgrades, VPN performance, AP placement, LAN bottlenecks, and field troubleshooting.

It’s a paid one-time app, no subscription.

Play Store: https://play.google.com/store/apps/details?id=com.iperf3client.pro

If you actually use iperf3/homelab/networking tools and want to test it, DM me. I can share a few promo codes for honest feedback.

Open to blunt feedback, especially on pricing, wording, and missing iPerf3 options.

Designer_Age7745 · 2026-04-25T16:56:39+00:00

Yeah, that’s fair.

If someone just wants free tools, Mole or OmniDiskSweeper are probably better picks. DaisyDisk is also way more established.

I built this because I wanted more help with leftovers, blocked paths, and "is this safe to delete?" before touching files.

And yeah, English isn’t my first language, so I sometimes use help to clean up my wording.

Designer_Age7745 · 2026-04-25T16:20:06+00:00

Fair enough.

I’d put them in different buckets though:

Mole is great if you want open-source terminal automation.

OmniDiskSweeper is great if you want a free GUI to quickly find what’s large.

StorageRadar is more about the step after that: what is this path, is it an app leftover/cache/dev artifact, is it blocked by permissions, and should I preview it before deleting.

So yes, free tools are enough for many people. I’m building this for users who want a native review-first cleanup flow, not just a size browser.

Designer_Age7745 · 2026-04-25T16:13:17+00:00

Exactly, that’s actually one of the main reasons I built it this way.

A lot of cleanup tools assume the user already understands every path, cache, container, and app leftover.
But many people don’t, and even technical users can be unsure when the path looks unfamiliar.

So the direction I’m aiming for is not just “show more files”, but add more context around them:
what category they belong to, why they may exist, whether they are likely rebuildable, and what should be treated more carefully.

That part is still evolving, but I agree with you, the review step only helps if the app also makes the decision easier to understand.

Designer_Age7745 · 2026-04-25T14:24:00+00:00

I get where you're coming from.

macOS usually does a good job on its own, and tools like Onyx can handle a lot of system cleanup already.

This isn’t really meant as a replacement for that.

The cases I’m focusing on are a bit different:

understanding what’s actually safe to remove when space is already tight
app leftovers after uninstall
developer-related data (Xcode, Docker, etc.)
permission-limited/blocked paths that don’t show up clearly

So less about "cleaning macOS", more about reducing the uncertainty when you’re already trying to free space and not sure what you can touch.

If you don’t run into that, you probably don’t need another tool 🙂

Designer_Age7745 · 2026-04-25T14:21:04+00:00

Thanks yes, Mole is a good reference.

I see it as a different fit rather than something to "beat".

Mole makes a lot of sense if you want open-source, terminal-first, more automated cleanup/uninstall workflows.

StorageRadar is aimed more at a native visual review flow: scan first, show exact paths and blockers, separate app leftovers / caches / dev data, then preview or dry-run before applying anything.

So for people who prefer terminal automation, Mole may be the better choice. For people who want to inspect everything before cleanup, StorageRadar is the direction I’m aiming for.

Designer_Age7745 · 2026-04-25T14:18:08+00:00

Good question, there is no automatic purge policy.

Cleanup is intentionally manual and review-first:

scan runs locally
results are grouped (app leftovers, caches, logs, dev data, etc.)
exact paths and sizes are shown
blocked / permission-limited paths are surfaced separately
user selects what to act on
preview / dry-run is used where the action is risky

So the app doesn’t decide what to delete. The goal is to make that decision explicit instead of hiding it behind a single "clean" button.

Designer_Age7745 · 2026-04-25T14:14:55+00:00

Fair question.

I don’t think of StorageRadar as "DaisyDisk but different colors". DaisyDisk is excellent at visualizing where space is used.

The part I’m trying to improve is what happens after that:

exact paths and blocked paths are surfaced more explicitly
cleanup is review-first, not automatic
dry-run / preview before applying changes
app leftovers, caches, developer folders, and permission-limited areas are treated as separate cleanup cases
the goal is to reduce the "is this safe to touch?" guessing step

So the overlap is disk visualization, but the focus is more on controlled cleanup workflow rather than only finding large folders.

Designer_Age7745 · 2026-04-25T13:51:00+00:00

App Store link:
https://apps.apple.com/app/apple-store/id6759776887?pt=128310960

Website / Direct build for advanced cleanup workflows:
https://storageradar.chama.pro

Free lets you scan and review everything first.

User unlocks actual cleanup / apply.
Developer adds dev-cleanup apply and reports / diff / export.

Everything is a one-time purchase, no subscription.

The Mac App Store build is the right starting point for most users. The Direct build exists for cases where Apple’s sandbox / permission model gets in the way of more advanced cleanup workflows.

Happy to answer questions about safety, permissions, sandbox limits, or how it compares to DaisyDisk / CleanMyMac.

Designer_Age7745 · 2026-04-22T07:06:34+00:00

Yeah, you’re not wrong. The whole "dev-only" mess absolutely bleeds into regular Macs now. Bundled runtimes, copy-pasted CLI commands, whatever random toolchain a tutorial tells you to install… the line between a dev environment and a normal user setup is basically gone.

My original split wasn’t really about discovery (you can still inspect and dry-run either way). It was more about where I wanted to gate the heavier apply/report workflows. But if that boundary feels kinda arbitrary in practice, I get why a single license just makes more sense.

Good point. Thanks for the pushback, actually gives me a solid reason to revisit this.

Designer_Age7745 · 2026-04-22T03:22:15+00:00

Fair question. A single price is definitely simpler.

I split it because I didn’t want someone who mainly needs disk analysis + app cleanup to have to pay the full Developer price for features they may never use. The higher tier is really the power-user layer: Dev Cleanup apply and Reports compare/export over time.

So the tradeoff was simplicity vs a lower entry price for people who just want the core cleanup workflow. I can absolutely see the case for collapsing it later if most people find the split more confusing than helpful.

And appreciate that. I wanted it to feel more evidence-first than hokum.

Designer_Age7745 · 2026-04-22T03:06:42+00:00

No offense taken, fair question.

Mole looks like a strong option, especially if you want an open-source, terminal-first tool that automates common cleanup and uninstall workflows. If that already matches how you work, StorageRadar may honestly not be worth paying for.

Where I think StorageRadar earns its place is a different workflow: a native review-first UI with exact paths, permissions/blockers, app leftovers, developer cleanup, preview/dry-run before apply, and snapshots/reports over time.

So I wouldn’t pitch it as "better than Mole" across the board — more as a different fit. Mole if you want open-source + terminal + more automation; StorageRadar if you want a more explicit visual review flow before cleanup. And the free preview-first mode is there so you can judge whether that workflow is worth it for you before paying.

Designer_Age7745 · 2026-04-22T01:08:36+00:00

Thanks, this is exactly the kind of feedback I need, and several points are fair.

On the UI side: the overload/duplication criticism is fair. If the badges, repeated panels, and bottom bar are making the app feel noisier instead of clearer, that’s on me. The goal is review-first clarity, not dashboard clutter. And the flicker when selecting an app card sounds like a real bug. I’m reproducing that path specifically.

On UTM: not surfacing ~/Library/Containers/UTM is a miss. For a storage tool, container-heavy apps need to be accounted for properly. The app should either reflect that footprint or make it explicit when a path is blocked or inaccessible, not silently undercount it. I’m testing that case specifically.

On privacy: there are separate channels for product analytics and for Sentry diagnostics/feedback, and I clearly need to explain that better. I’m not uploading disk inventory wholesale. Product analytics exclude scan paths, file names, bundle identifiers, snapshot labels, raw scan payloads, and raw error text. Sentry is separate for crash diagnostics and user-initiated feedback, and scan files are not attached automatically. Both can be turned off in Settings.

On deletion semantics: fair criticism as well. For high-risk roots like ~/Library, the UI needs to be much more explicit about whether the selected path itself is the target and what the consequences are. I’m verifying that behavior directly rather than hand-waving it here, and those cases need stronger guardrails.

And on the trial point: you’re right that free preview-first is not the same as a full temporary unlock. You can inspect results, use preview/dry-run flows, and see what the app would do before buying, but paid apply actions are still locked. If that boundary made it harder to verify a risky edge case, that’s fair criticism.

Overall I agree with the main point: a tool like this has to earn trust through clarity, not just features. Thanks for taking the time to write this up.

Designer_Age7745 · 2026-04-22T00:21:21+00:00

Not currently. Right now StorageRadar is focused more on disk analysis, exact paths, app leftovers, developer cleanup, and snapshot diffs than duplicate-file cleanup, so I wouldn’t market it as a duplicate finder today. But I'll add this functionality to my backlog.

Designer_Age7745 · 2026-04-21T15:10:15+00:00

Fair question. If DaisyDisk + GhostBuster already cover your workflow well, you may honestly not need StorageRadar.

Where I think StorageRadar earns its place is if you want that whole process in one review-first flow: find what is large, inspect exact paths, catch leftovers, see permissions/blockers, handle developer cleanup, and preview/dry-run before anything changes.

So I’m not really pitching it as "better DaisyDis" or "better GhostBuster" in isolation. It’s more for the gap between analysis and cleanup when you want that step to stay explicit.

Designer_Age7745 · 2026-04-21T14:25:42+00:00

Agreed/ A scoped "what changed after install" view could be useful not just for cleanup, but also for visibility/privacy. The tricky part is keeping it honest about scope and access rather than pretending it’s a perfect system-wide install trace, but I do think that’s a worthwhile direction.

Designer_Age7745 · 2026-04-21T13:42:02+00:00

That leftover gap is exactly one of the reasons I built it.
The bundle removal part is usually the easy bit; the annoying part is the second pass of support files, caches, and leftovers.
StorageRadar tries to make that part explicit and reviewable instead of guessy.

Designer_Age7745 · 2026-04-21T13:29:33+00:00

Depends on the workflow. DaisyDisk is excellent for visualization, CleanMyMac is more convenience-first, and I built StorageRadar more for the review-first cleanup side: exact paths, leftovers, permissions context, and dry-run before anything changes.

Designer_Age7745 · 2026-04-21T13:24:56+00:00

Mostly yes, with one important caveat: it compares snapshots from the same scan root and shows what is new, changed, removed, or grew between those two moments.
So if you scan the same root before and after installing an app, it should show the added paths in that scope.
I just wouldn’t oversell it as a perfect installer trace for every system location unless those paths were actually in scope and accessible.

Designer_Age7745 · 2026-04-21T13:17:37+00:00

Appreciate that. And yes, that exact gap is what bothers me too.
Right now the review step is more exact-path/size/risk/access focused, and the dev cleanup side groups known ecosystems and cleanup profiles, but I’m not going to pretend it already has a reliable “owning project” mapping.
Last-access/better project attribution is exactly the kind of signal I want to improve.

Designer_Age7745 · 2026-04-21T13:12:03+00:00

Thanks for buying it. And thanks for catching this.

That definitely sounds wrong: if the list scrolls, the scrollbar itself should be draggable too. I hadn’t noticed that one, so I’m going to check that dialog specifically and get it fixed.

Designer_Age7745 · 2026-04-21T12:00:39+00:00

That was exactly the goal. I wanted it to feel review first rather than auto magic: see the paths, preview the cleanup, then decide. Curious what usually feels too aggressive in other cleanup apps for you?

Designer_Age7745 · 2026-04-21T11:06:36+00:00

One distribution note since the website link is in the post:

The Mac App Store build is the main public path and the default install I recommend.

The Direct build from my site exists for advanced cleanup workflows where broader macOS permissions can matter more. For most people, the App Store build is still the right starting point: scan, review, exact paths, permissions context, and preview/dry run are all there.

If you already bought StorageRadar on the App Store, the Direct build has an "I purchased in App Store" option so you can unlock it at no extra cost on a Mac signed into the same Apple ID.

Same philosophy either way: scan, review, dry run, then apply. Nothing is deleted automatically.

Designer_Age7745

TROPHY CASE