> Research subject: abue-ammar/tinycast
> Captured: 2026-09-16 | Stars at capture: 1136
> License: AGPL-3.0 | Language: Swift 6.0
---
A Counter-Trend Project
The desktop software trend in 2026 is "more features, bigger footprint." Raycast's installer exceeds 400MB, with memory usage often above 500MB. Yet 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) that appeared on GitHub Trending in late August 2026—tools regressing from "big and comprehensive" toward "small and focused." I call this the minimization regression: the sign of technological maturity is not more features, but the ability to compress into smaller tools.
Tinycast is the newest 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 conversions
- Quicklinks: turn URLs/searches/files into commands
- Snippets: Markdown templates with dynamic placeholders
- Window management: 34 Rectangle-style window operations
- Apple Shortcuts: search and run shortcuts
- AI chat: use your own API key, off by default
- Raycast extensions: run existing Raycast extensions directly, rendered as native SwiftUI
"A Deliberately Closed Feature Set"
The Contributing section of the README contains an unusual statement:
> 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 contributors to add features; tinycast does the opposite—discuss in an issue first, and only write code after getting the approved label. PRs without the 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 satisfy the memory budget. This isn't a soft "try to keep it small"—it's a hard constraint. If a feature would push memory over budget, it won't be merged, no matter how good the code is.
This aligns with operating system design philosophy—kernels don't "run whatever can run," they "run what matters most within fixed resource constraints." Tinycast applies that thinking to a desktop app.
For comparison: 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 natively in SwiftUI, eliminating Node.js runtime overhead.
"AI Off by Default"
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.
Off by default, like every AI feature.
In 2026's "everything is AI" wave, a newly released desktop tool shipping with AI disabled by default is itself a statement. The message: AI is an optional enhancement, not a core feature. If you need it, turn it on; if you don't, it won't silently run in the background.
This contrasts with the "AI-first" strategy of many apps that place AI front and center, enabled 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 who forks tinycast into a SaaS product must open-source all changes. This protects tinycast's purity as an open source project—anyone can use it, but no one can turn it into a closed-source commercial product.
Compare Raycast's closed model: Raycast itself is closed source; only the extensions are open. AGPL-3.0 ensures tinycast never walks the "open core + closed enterprise edition" path.
The Relationship with Raycast
Tinycast isn't positioned as a Raycast replacement. It's more like Raycast's "parallel universe" version—what Raycast would look like if it had chosen native over cross-platform, lightweight over feature-rich, a closed feature set over an open extension ecosystem from day one.
But tinycast did something clever: Raycast extension compatibility. It doesn't need to build an ecosystem from zero—it directly 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 rendered in native SwiftUI. It's conceptually similar 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 "features-to-resources" ratio of desktop software?
Over the past decade, more features meant more resource usage. VS Code grew from 50MB of memory to 500MB+; Slack regularly exceeds 1GB. We've accepted "more features = more resources."
Tinycast tries to break that equation: plenty of features (34 window operations, clipboard history, AI chat, Raycast extension compatibility), but memory kept under 100MB. It doesn't achieve this by cutting features—it achieves it by refusing unnecessary features and replacing cross-platform runtimes with native implementations.
It's the same principle as ripgrep: ripgrep is faster than grep not because it has fewer features, but because it rewrote core algorithms in Rust and rejected grep's historical baggage. Tinycast is lighter than Raycast not because it has fewer features, but because it renders with native SwiftUI and rejects the Electron/Node.js runtimes.
The third chapter of the minimization 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