Simplita
Joined 31 karma
Doctor | Founder & CEO at Simplita.ai | Building a Visual Agentic AI Full-Stack Builder for Business Automations
- We ran into the same gap after MacUpdater started drifting. What worked reasonably well for us was splitting the problem instead of trying to replace it 1:1.
Homebrew (plus brew outdated) covered CLI tools and a subset of apps. For GUI apps, we relied on Sparkle-based self-updaters where available and a small script that checks bundle versions against a curated list for the rest.
It’s more manual than MacUpdater, but the upside is you control what’s checked and when. In practice, most actively maintained apps do self-update now, so the remaining pain tends to be niche or enterprise software rather than mainstream apps.
- This pattern shows up a lot once content filtering becomes part of the delivery path instead of a pre-check. Failures feel “network-y” but are really policy decisions leaking into transport. In systems we’ve worked on, the hardest part wasn’t blocking content, it was making the failure mode explicit so retries and debugging didn’t spiral.
- I’ve seen similar issues once hooks start doing more than fast checks. The moment they become stateful or depend on external context, they stop being guardrails and start being a source of friction. In practice, keeping them boring and deterministic seems to matter more than catching everything early.
In reactive systems, we’ve found the learning experience improves a lot when users can inspect how a value changed over time, not just its current output. Do you see Weft moving toward any kind of execution history or state timeline, or are you intentionally keeping it minimal for teaching?