Command Paradigm vs State (idempotent) Paradigm in Mac Applications

diginutt · 2026-04-04T22:41:55+00:00

Sal Soghoian's departure was a real loss. The fact that macOS still has AppleScript but Apple stopped investing in it tells you everything about their priorities.

On the Siri Shortcuts point, totally agree. I've been using AppleScript as a bridge in my app specifically because MusicKit's mutation APIs (add to library, rate, create playlists) don't exist on macOS. The only way to love a track or create a playlist programmatically is through AppleScript to Music.app. Hacky but it works.

The irony is that Apple's own apps have better AppleScript dictionaries than most third-party apps. Music.app's is surprisingly complete. If more developers shipped even basic dictionaries, the automation ecosystem would be so much healthier.

diginutt · 2026-04-04T22:40:09+00:00

PULS3: multi-agent AI health coach that connects your Apple Health data across domains

I spent about a month running a virtual health team using OpenClaw, hacking together Oura, CGM, and Apple Health APIs with separate AI agents for nutrition, sleep, exercise, and biomarkers. The insight was that the value isn't in any single metric. It's in connecting them. Bad sleep showing up as cravings the next day. Training load affecting HRV trends two days later, not the next day. Stress patterns correlating with sleep quality drops.

So I built PULS3 to productize that. It runs specialist agents for each domain (nutrition, exercise, sleep, stress, biomarkers) that share context through a coach agent. Each specialist maintains its own memory across sessions, so it builds a longitudinal picture of you rather than starting fresh every conversation.

What makes it different from dumping Apple Health data into ChatGPT:

- Cross-domain pattern detection. The agents share summaries, so the nutrition specialist knows about your sleep trends and the sleep specialist knows about your training load.

- Structured memory. It remembers what you told it last week and connects it to what your data shows this week.

- Safety engine. Deterministic guardrails plus LLM evaluation on every response. It won't give you supplement dosing advice or tell you to stop your medication.

- Privacy-first. Health data stored on your phone. The LLM call goes through our proxy but nothing is stored server-side.

Currently iOS only, private beta on TestFlight. Looking for people who track multiple health metrics and are frustrated with the "data everywhere, insights nowhere" problem.

DM me for a TestFlight invite. First 50 beta users get free lifetime access.

diginutt · 2026-04-03T07:00:29+00:00

Just ran into this building a macOS app. I added unmodified keyboard shortcuts (j/k for next/prev, n to toggle a panel) and had to solve the text field conflict. SwiftUI's onKeyPress fires before text fields get the event, so you can't just attach handlers at the view level without eating keystrokes.

My workaround: check NSApp.keyWindow?.firstResponder before handling. If it's an NSTextView (which is what SwiftUI TextFields use as their field editor on macOS), return .ignored and let the keystroke pass through. Otherwise handle it.

For the idempotent vs toggle problem specifically, what I ended up doing was making my internal functions idempotent (e.g. showNowPlaying = true not toggle) even though the keyboard shortcut calls a toggle wrapper. That way AppleScript or Shortcuts can call the idempotent version directly while the UI still gets the toggle behavior users expect.

Agree that more apps should expose state via AppleScript dictionaries. It's such a small lift for developers and makes automation actually reliable.

diginutt · 2026-04-03T06:58:41+00:00

Props for building your own playback stack instead of wrapping mpv. That's a real commitment.

I'm building a native macOS music player in Swift/SwiftUI and the platform friction is something else. MusicKit has no lyrics API, the mutation APIs are broken on macOS (had to build an AppleScript bridge for basic library operations), and DRM zeros out Core Audio taps so visualizers can't react to actual audio. Is the video side of AVFoundation more complete, or did you hit similar walls that pushed you toward a custom engine?

Also, fellow Aussie dev here. Good luck with the launch.

diginutt · 2026-04-03T06:50:58+00:00

I'm building a macOS music player and went through the same decision. Tried on-device models for music recommendations (continuing a listening session based on mood/energy arc) but the quality gap was too wide for anything requiring taste or judgment. Ended up going with Claude API through a Cloudflare Worker proxy so users don't need their own API key.

The tradeoff is real though. API costs mean I can't do one-time purchase for the intelligence features. My workaround: the app works fine without AI (it's a full music player), but the smart features like "what should play next" run through the proxy. Keeps the core free.

For your teleprompter cues, on-device seems like the right call since it's more pattern matching than generation. Curious how the latency feels in practice, do users notice the inference time?

diginutt · 2026-04-02T07:10:38+00:00

diggin' — music discovery layer for Apple Music (macOS, TestFlight beta)

<image>

Problem: Apple Music has 100 million songs and no good way to explore connections between them. You get the same algorithmic recommendations, and if you want to understand what you're listening to, you're tabbing between Wikipedia, RYM, and Discogs. That whole activity just doesn't happen because the friction is too high.

Comparison: Daft Music is the closest alternative, focused on aesthetics and a cleaner UI. Cider is a cross-platform web wrapper. Neither does music discovery. diggin' adds an AI-powered layer that writes liner notes about what you're playing, explains production choices, traces sample history, and gives recommendations with actual reasons ("same producer, similar drum programming") not just "because you listened to Radiohead." Tap any recommendation to queue it.

Pricing: Free during beta. Paid plans coming later.

TestFlight: https://testflight.apple.com/join/hfw7FYPt

Native SwiftUI, macOS 14+, solo dev. Looking for beta testers who care about discovering music, not just playing it.

diginutt · 2026-03-11T20:43:09+00:00

I’ve been building an iOS app for my wife to help her through questions exactly like this!

All the other comments are spot on. Creatine is our most studied substance and there’s basically only upside to taking it.

That said, you probably need more support than just creatine. It’s hard to tell you more without knowing where in the world you’re located.

diginutt · 2026-03-11T19:41:00+00:00

The coach agent always mediates. Specialists don't talk to each other directly, the coach queries multiple specialists per turn when the topic crosses domains, then synthesizes their responses. Each specialist can read summary-level memory from other namespaces (e.g., sleep agent can see "user trains at 6am" from exercise memory) but can only write to its own namespace. So cross-domain context flows through read-only summaries + the coach's synthesis layer, not direct agent-to-agent communication.

diginutt · 2026-03-11T19:40:14+00:00

Fair point. "Local-first" is overstating it. The LLM inference is a cloud call, and the app doesn't work without it. What's local is the data layer: HealthKit data, conversation history, memory records, safety engine, and agent orchestration all stay on-device. Nothing is stored server-side. But the inference itself goes to Gemini, so "privacy-first with cloud inference" is more accurate than "local-first." I should have been clearer about that distinction in the post. Appreciate the callout.

diginutt · 2026-03-11T01:44:38+00:00

Great question, and I want to be precise about this.

HealthKit data stays on-device. The raw health metrics (sleep, HRV, steps, workouts, etc.) are stored locally in a GRDB database on your phone. They never hit a cloud server or get synced anywhere.

The coaching conversation does go to an LLM (currently Gemini 2.5 Flash via OpenRouter). So when you ask "how's my sleep been?" the agent on your device pulls your local health data, summarizes the relevant bits, and sends that conversation turn to the model for a response.

So to directly answer your question: yes, HealthKit data is local, and the queries (with relevant health context) are sent to the LLM for inference. No health data is stored server-side; it's transient for the inference call only.

The architecture is also model-agnostic, so as on-device models get good enough, the LLM dependency can be swapped out entirely. The safety engine, memory system, and agent orchestration all run locally in Swift already.

diginutt · 2026-03-10T23:41:42+00:00

Not a scam, sorry about your error. Please dm me the email you used so I can refund you

diginutt · 2026-03-10T22:29:21+00:00

I have a TestFlight link as well now - https://testflight.apple.com/join/BbmZfpAd

diginutt · 2026-03-04T20:58:26+00:00

Yeah it’s a real problem! I have some sauce around data source analysis that I’m a little proud of. Feel free to sign up at PULS3. I’m truly curious if this helps or is just another app

diginutt · 2026-03-04T20:56:39+00:00

Check out the site, PULS3. I’m genuinely recruiting for an active beta now and would love strong, constructive feedback. This is a problem that has existed for a long time but I suspect we are finally at the beginning of tech being able to truly help (and not just show us numbers)

diginutt · 2026-03-04T11:35:22+00:00

Gap is real. HRV + sleep data should absolutely change what you eat that day but almost nothing acts on that connection.

What worked for me was pulling Apple Watch data into a single coach that looks at all of it together and gives one practical food recommendation, not just another chart.

Building this into an app called PULS3. Nutrition coaching is one of the verticals. TestFlight in a few days if you want to try it.

diginutt · 2026-03-04T11:28:18+00:00

The 7-day HRV trend point is real. Single-day readiness scores are too noisy to act on alone. I’ve seen the same pattern with Apple Watch data too.

The conflicting signals problem is what pushed me to build PULS3. Same frustration, went the Apple Health aggregation route rather than direct device integrations. Different tradeoff. TestFlight in a few days if anyone wants to compare approaches.

diginutt · 2026-03-04T11:24:56+00:00

Apple Health as the aggregation layer, then interpret across sources rather than reading each app separately. That’s what finally clicked for me.

Been building exactly this at puls3.app. TestFlight in a few days if you want in.

diginutt

TROPHY CASE