TerminalWidget

Put script output in your Desktop/Home screen widgets.

Productivity

Developer Tools

Apple

Visit WebsiteSee on Product HuntApp Store ⧉

Dale's monitor point above is the one I would build for, and I think it needs one thing the terminal gives you for free. A terminal shows you the error. A widget shows you the last good value, forever. If the script exits non-zero at 3am, the widget does not go blank, it just keeps displaying Tuesday and looking healthy. Glanceability is the whole product, and a glance cannot tell fresh from frozen. So the feature is not a refresh interval, it is a staleness contract. Last-updated on the face, or the widget visibly decays when the exit code is not zero. Does it do anything today when a script fails, or does the previous output just persist?

Since these scripts end up needing real credentials, an API key to pull sales numbers or check service health, that's the part I'd ask about next. Does TerminalWidget just shell out and leave secrets entirely to however the script handles them, or is there any credential storage involved once that output starts mirroring over to the iPhone widget?

API health in your own list is the case I would design around, because there the widget is not a display, it is a monitor.

Widgets get read as current. That is the entire point of putting something where you glance rather than look. But the refresh cadence is not yours, particularly on iOS, where the system decides when your timeline reloads and will throttle it when it feels like it. So a green API health number on a home screen might be four hours old, and it will still be read as "fine right now", because that is what a glance means.

Which makes the age of a value part of the value. Two things I would want as a script author. A way to declare a max age, so that past it the widget renders stale rather than the last known number. And a rule for what happens when a script exits non zero: keeping the last good value is both the best looking option and the most dangerous one, because a broken monitor and a healthy service then produce an identical widget.

On Murat's point above I would argue the other way. A widget that acts on things is a widget that can be wrong expensively. Showing me something is the right scope for this. It just has to be honest about when it last knew.

We don't have a dashboard problem anymore. We have an automation problem. The winners of the next decade won't be the apps that show information—they'll be the ones that act on it. Do you agree or disagree?

this caught my eye as a macOS user. before buying i want to know: when the widget runs a script, does it run as my normal user, or is there some kind of sandbox that could limit what it can access?

love the idea of running scripts as widgets. one question before buying: does the widget process run in a fresh shell, or does it pick up my .zshrc environment? i have a few PATH additions my scripts depend on.

The macOS widget side is what I would use first. Quick question on script execution: when the widget runs its refresh, does it get a clean shell environment or does it inherit the PATH from wherever it launched? I have scripts with custom PATH entries from .zshrc and need to know if those carry over.

Sparklines from raw script output is a genuinely useful primitive. Most widget tools stop at a static number.

the sparkline widgets are genuinely a nice touch, like having a tiny dashboard without needing to alt-tab or pull up a full terminal app. one-time purchase for a universal app is honestly refreshing these days.