I'm Theodore Harding, the person who built Shiny. This post is part of a small series about the decisions behind the app: why I built it, why the pricing is what it is, and now this. The telemetry question comes up more than any other, and it deserves a longer answer than a bullet point in an FAQ.
What “no telemetry” actually means
When I say Shiny has no telemetry, I mean it literally. There is no analytics SDK, no crash reporter, no feature-usage tracking, no session recording, no heartbeat ping. Open Little Snitch while Shiny is running and you'll see exactly two outgoing connections.
The first is a Sparkle update check. Once per day, Shiny asks a URL I control whether a newer version exists. That request contains the current app version and your macOS version, nothing else. It's how nearly every indie Mac app delivers updates without the App Store.
The second is license activation. When you enter your license key for the first time, Shiny makes a single request to verify it against the license server. After that, the validated result is stored locally. Shiny doesn't phone home on subsequent launches. The activation request is the only one tied to your purchase.
That's it. Two requests. Both predictable, both auditable, neither collecting anything about how you use the app.
Why I made that choice
The honest answer is that it followed from the kind of app I wanted to build, not from a principled stance I had to talk myself into.
Shiny sits in your menu bar, running quietly, doing one thing when you ask it to. An app with that personality doesn't phone home. It doesn't log which buttons you press. It doesn't keep a record of how many times you've cleared memory this week. That would be a different kind of software, with a different relationship to you.
There's also a trust argument. Shiny works with macOS internals: it reads memory pressure, asks the system to release inactive pages, closes orphaned helpers. That puts it in a category of app where trust matters more than usual. If I'm asking you to run something that touches system resources, the least I can do is make its network behaviour completely transparent.
And practically: for a $4.99 utility, the trade isn't a good one. You'd be giving up data so I could make slightly better product decisions. That's not a fair exchange. I'd rather have your trust than your usage stats.
What we trade for it
This is the part most posts about privacy skip over, and I'd rather not.
No telemetry means I often don't know when Shiny crashes. If the app silently exits on a particular macOS configuration, or behaves unexpectedly for a subset of users, I won't find out unless someone emails me. Most people don't. Most people just quietly stop using the app, or quietly tolerate the bug.
It also means I have no feature analytics. I don't know whether the memory readout in the menu bar is something people actually look at, or whether the "clear" animation is satisfying or annoying, or whether the preference window is ever opened. Good product teams use that data to make better decisions faster. I'm flying partly blind.
Bug discovery is slower. Without crash reports, the path from "something is broken" to "I know what is broken" runs through email. That adds friction. A single well-written crash report from a user who noticed and bothered to send it is worth more to me than a hundred silent automated pings, but getting that report requires the user to care enough to send it, and most users, reasonably, don't.
I'm not pretending these are minor costs. They're real. They slow down iteration and make certain categories of bug harder to find. I've accepted that because I think the alternative is worse, but I want to be clear that "no telemetry" is a constraint with consequences, not a free lunch.
Why it works for a small app
Shiny does one thing. That matters more than it might seem.
An app that does forty things has a surface area that's nearly impossible to test without telemetry. Something is always interacting with something else in an unexpected way. Crash reports aren't just nice to have; at a certain complexity level, they're the only way to find the bugs that only appear in production.
Shiny's surface area is small. It reads memory pressure, it calls a system API to release inactive pages, it shows you a number, and it does a bit of housekeeping on orphaned processes. The code that could go wrong is a short list. I can reason about it in my head. When bugs do surface, they tend to be narrow and reproducible once someone describes them.
The macOS sandbox also helps. Shiny runs in a sandboxed environment, which limits what it can do and what can go wrong. That's a feature, not a limitation. A constrained app is an auditable app.
And because I'm the only developer, support scales differently. When something breaks, the person who reads your email is also the person who wrote the code. There's no ticket queue. The latency between "user reports a problem" and "developer understands the problem" is a few hours, not a few days. That's the upside of being small: email replaces telemetry reasonably well when the team is one person who actually reads it.
Why I think more software should ship this way
Most software collects data not because it needs it, but because it can. The marginal cost of adding an analytics SDK is close to zero, the data might prove useful one day, and there's no one in the room arguing against it. So it accumulates: page views, session lengths, button clicks, feature impressions, cohort retention graphs that nobody looks at. None of it is malicious. Most of it is just noise that someone decided was better to have than not have.
The result is that data collection has become a default, and choosing not to collect has become an unusual decision that requires justification. I think that's backwards.
For a utility like Shiny, and for a lot of small, focused software, the right default is to collect nothing unless there's a specific reason to collect something. The burden of proof should sit on the collection, not on the abstention.
That's not an argument against all telemetry. Crash reports in a complex application are genuinely useful. Opt-in usage data for a product trying to understand which features people actually use can be collected honestly, transparently, and in a way that respects the user. The problem isn't data collection in principle; it's data collection as an unexamined default.
When you build an app with no telemetry, it changes how you think about quality. You can't rely on dashboards to tell you when something is wrong. You have to make the app good enough that problems surface through channels that require human effort to use: support email, reviews, forums. That's a slower feedback loop, but it's also a more honest one. It means you're accountable to people who cared enough to tell you, not to aggregate statistics that can be interpreted any number of ways.
I'm not arguing every app should work this way. I'm arguing that more apps should at least ask the question before reaching for the SDK. For most small, focused utilities, the answer might surprise you.
If you want to see what Shiny actually does to your Mac, read about whether Mac cleaner apps are worth it, or check whether CleanMyMac is safe for context on what the alternatives do with your data. The contrast is instructive.