> Research subject: abue-ammar/tinycast
> Captured: 2026-09-16 | Stars that day: 1136
> License: AGPL-3.0 | Language: Swift 6.0
---
A Counter-Trend Project
The trend in 2026 desktop software is "more features, bigger footprint." Raycast's installer exceeds 400MB, with memory usage often above 500MB. Meanwhile, the first line of tinycast's README reads:
> A tiny, fully native macOS launcher. One hotkey, everything you reach for all day, under 100 MB of RAM.
100MB. Zero third-party dependencies. SwiftUI + AppKit. No Electron, no telemetry.
This belongs to the same lineage as tailcat (a file search tool by ripgrep's author) which trended on GitHub in late August 2026—tools regressing from "big and comprehensive" toward "small and focused." Call it the minimalism regression: the mark of technological maturity is not more features, but the ability to compress into smaller tools.
tinycast is the latest member of this lineage.
What It Does
The feature list overlaps heavily with Raycast:
- App launcher: fuzzy search to launch apps
- Global hotkey: summon from anywhere
- Clipboard history: text + images
- Calculator: inline math, units, exchange rates, crypto conversion
- Quicklinks: turn URLs/searches/files into commands
- Snippets: Markdown templates with dynamic placeholders
- Window management: 34 Rectangle-style window actions
- Apple Shortcuts: search and run shortcuts
- AI chat: use your own API key, disabled by default
- Raycast extensions: run existing Raycast extensions directly, rendered as native SwiftUI
"The Feature Set Is Deliberately Closed"
The Contributing section of the README contains an unusual declaration:
> Tinycast's feature set is deliberately closed, and "another launcher has it" is not a reason on its own. Ask whether a feature is wanted before you ask for it.
In other words: the feature set is deliberately closed—"another launcher has this feature" is not, by itself, a reason to add it.
This is rare in open source. Most projects encourage feature contributions; tinycast does the opposite—discuss in an issue first, get the approved label, then write code. PRs without an approved label are automatically closed, "however good the patch is."
This isn't arrogance—it's discipline. The author understands: features are debt, not assets. Every feature added increases the memory budget, test matrix, and maintenance cost. The 100MB memory ceiling isn't maintained by "optimization"—it's maintained by refusing to add features.
Memory Budget as a Design Constraint
From CONTRIBUTING.md:
> the memory budget every PR is held to
Every PR must meet the memory budget. Not a soft "keep it small if you can," but a hard constraint. If a feature would push memory past the budget, it doesn't get merged—no matter how good the code.
This matches operating system design philosophy—kernels don't "run whatever can run," they "run what matters most within fixed resource constraints." tinycast applies this to a desktop app.
For contrast: Electron apps are heavy not because of feature count, but because each ships a full Chromium. Raycast isn't Electron, but its extension system runs on a Node.js runtime, spawning a separate process per extension. tinycast renders Raycast extensions with native SwiftUI, eliminating the Node.js runtime overhead.
"AI Off Out of the Box"
One line in the feature list stands out:
> AI chat — use your own key or an installed AI account, chat from the palette. Off out of the box, like every AI feature.
Disabled by default, like all AI features.
In 2026's "everything is AI" wave, a new desktop tool shipping with AI off by default is itself a statement: AI is an optional enhancement, not the core. Turn it on if you want it; if not, it won't secretly run in the background.
This contrasts with the "AI-first" strategies of many apps that put AI front and center, on by default, sometimes impossible to disable. tinycast's stance: the core of a launcher is fast launching, not AI chat. AI is just one of many Quick Actions.
The AGPL-3.0 Choice
tinycast uses AGPL-3.0, not the more common MIT or Apache. AGPL's core clause: if you offer it as a network service, you must open-source your modifications.
It's an anti-commercialization choice. Anyone forking tinycast into a SaaS must open-source all changes. This preserves tinycast's purity as an open source project—anyone can use it, but no one can turn it into a closed-source commercial product.
Contrast with Raycast's closed model: Raycast itself is closed source; only extensions are open. AGPL ensures tinycast never walks the "open core + closed enterprise edition" path.
Relationship with Raycast
tinycast isn't positioned as a Raycast replacement. It's more like a "parallel universe" Raycast—what Raycast would be if it had chosen native over cross-platform, lightweight over feature-rich, a closed feature set over an open extension ecosystem.
But tinycast did something clever: Raycast extension compatibility. It doesn't need to build an ecosystem from zero—it reuses the thousands of extensions Raycast has accumulated. Migration cost is nearly zero.
This is a classic "parasitic strategy"—not attacking the host, but borrowing its ecosystem resources. Raycast's extension format is public; tinycast implements a compatible runtime with native SwiftUI rendering. Similar in spirit to Wine on Linux—not rewriting Windows apps, but implementing a compatibility layer.
A Bigger Question
tinycast raises a question worth pondering: is there a floor for the feature-to-resource ratio of desktop software?
The past decade's trend: more features, more resources. VS Code grew from ~50MB of memory to 500MB+; Slack often exceeds 1GB. We've accepted "more features = more resources."
tinycast tries to break that equation: plenty of features (34 window actions, clipboard history, AI chat, Raycast extension compatibility) within 100MB. Not achieved by cutting features, but by refusing unnecessary ones and replacing cross-platform runtimes with native implementations.
Same logic as ripgrep: ripgrep is faster than grep not because it has fewer features, but because it rewrote the core algorithms in Rust and rejected grep's historical baggage. tinycast is lighter than Raycast not because it does less, but because it renders natively with SwiftUI and rejects the Electron/Node.js runtime.
The third chapter of the minimalism regression: tailcat (file search) → typephp (PHP static analysis) → tinycast (desktop launcher). Three different domains, one philosophy—replace cross-platform runtimes with native implementations; maintain resource budgets through a closed feature set.
---
Project: https://github.com/abue-ammar/tinycast Discord: https://discord.gg/v2Eeb4QQy3 License: AGPL-3.0