Tinycast：100MB 内存跑出 Raycast 级体验的 macOS 原生启动器

研究对象：abue-ammar/tinycast
抓取日期：2026-09-16 ｜ 当日 stars：1136
许可证：AGPL-3.0 ｜ 语言：Swift 6.0

一个反潮流的项目

2026 年的桌面软件趋势是"功能越来越多，体积越来越大"。Raycast 的安装包已经超过 400MB，内存占用动辄 500MB+。而 tinycast 的 README 第一句话是：

A tiny, fully native macOS launcher. One hotkey, everything you reach for all day, under 100 MB of RAM.

100MB。零第三方依赖。SwiftUI + AppKit。没有 Electron，没有遥测。

这和 2026 年 8 月底 GitHub Trending 上出现的 tailcat（ripgrep 作者的文件搜索工具）是同一个谱系——工具从"大而全"往"小而精"回归。我把这个趋势叫做"最小化回归"：技术成熟的标志不是功能更多，而是能被压缩成更小的工具。

tinycast 是这个谱系的最新一员。

它做了什么

功能列表看起来和 Raycast 高度重合：

• App launcher：模糊搜索启动应用
• Global hotkey：全局快捷键唤起
• Clipboard history：剪贴板历史（文本+图片）
• Calculator：内联数学、单位、汇率、加密货币换算
• Quicklinks：把 URL/搜索/文件变成命令
• Snippets：Markdown 模板，支持动态占位符
• Window management：34 种 Rectangle 风格的窗口操作
• Apple Shortcuts：搜索运行快捷指令
• AI chat：用自己的 API key，默认关闭
• Raycast extensions：直接运行已有的 Raycast 扩展，渲染为原生 SwiftUI

最后一行是关键。tinycast 不是"另起炉灶"，而是"兼容 Raycast 生态但用原生渲染"。这意味着 Raycast 用户迁移过来不会丢失任何扩展，但获得了一个更轻量的运行时。

"功能集刻意封闭"

README 的 Contributing 部分有一段不寻常的声明：

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.

翻译：功能集是刻意封闭的，"别的启动器有这个功能"本身不是添加的理由。

这在开源项目里很少见。大多数项目的 Contributing 指南会鼓励贡献者添加功能，tinycast 反过来——先开 issue 讨论，获得 approved 标签后才能写代码。没有 approved 标签的 PR 会被自动关闭，"however good the patch is"（不管补丁写得多好）。

这不是傲慢，是纪律。tinycast 的作者明白一个道理：功能是债务，不是资产。每加一个功能，内存预算、测试矩阵、维护成本都会增加。100MB 的内存上限不是靠"优化"维持的，是靠"拒绝添加功能"维持的。

内存预算作为设计约束

CONTRIBUTING.md 里提到：

the memory budget every PR is held to

每个 PR 都要满足内存预算。这不是一个软性的"尽量小一点"，而是一个硬性的约束。如果某个功能会让内存超过预算，它就不会被合并，不管代码写得多好。

这和操作系统的设计哲学一致——内核不是"能跑什么就跑什么"，而是"在固定资源约束下跑最重要的东西"。tinycast 把这个思路用在了桌面应用上。

对比一下：Electron 应用之所以重，不是因为功能多，而是因为每个 Electron 应用都自带一个完整的 Chromium。Raycast 虽然不是 Electron，但它的扩展系统基于 Node.js 运行时，每个扩展都会启动一个独立进程。tinycast 用 SwiftUI 原生渲染 Raycast 扩展，省掉了 Node.js 运行时的开销。

"AI 默认关闭"

功能列表里有一行很显眼：

AI chat — use your own key or an installed AI account, chat from the palette. Off out of the box, like every AI feature.

默认关闭，和所有 AI 功能一样。

在 2026 年"万物皆 AI"的浪潮里，一个新发布的桌面工具默认关闭 AI 功能，这本身就是一个声明。作者的意思是：AI 是可选的增强，不是核心功能。如果你需要，自己开；如果你不需要，它不会偷偷在后台跑。

这和很多应用的"AI 优先"策略形成对比。很多工具把 AI 放在最显眼的位置，默认开启，甚至不允许关闭。tinycast 的态度是：启动器的核心是快速启动，不是 AI 对话。AI 只是众多 Quick Action 之一。

AGPL-3.0 的选择

tinycast 用的是 AGPL-3.0，不是更常见的 MIT 或 Apache。AGPL 的核心条款是：如果你通过网络提供服务，必须开源你的修改。

这是一个反商业化的选择。如果有人想 fork tinycast 做一个 SaaS 版本，必须开源所有修改。这保护了 tinycast 作为开源项目的纯粹性——任何人都可以用，但任何人都不可以把它变成闭源商业产品。

对比 Raycast 的闭源模式：Raycast 本身是闭源的，只有扩展是开源的。tinycast 用 AGPL-3.0 确保了它永远不会走上"开源核心 + 闭源企业版"的道路。

和 Raycast 的关系

tinycast 不是 Raycast 的替代品，至少作者没有这么定位。它更像是 Raycast 的一个"平行宇宙"版本——如果 Raycast 从一开始就选择原生而非跨平台、轻量而非功能丰富、封闭功能集而非开放扩展生态，它会是什么样。

但 tinycast 做了一件聪明的事：兼容 Raycast 扩展。这意味着它不需要从零建立生态，直接复用 Raycast 已经积累的数千个扩展。用户迁移成本几乎为零。

这是一个经典的"寄生策略"——不是攻击宿主，而是借用宿主的生态资源。Raycast 的扩展格式是公开的，tinycast 实现了一个兼容的运行时，用原生 SwiftUI 渲染。这和 Linux 的 Wine 项目思路类似——不重写 Windows 应用，而是实现一个兼容层。

一个更大的问题

tinycast 引出一个值得思考的问题：桌面软件的"功能-资源"比是否有底线？

过去十年的趋势是功能越来越多，资源占用也越来越多。VS Code 从最初的 50MB 内存涨到现在动辄 500MB+，Slack 的内存占用经常超过 1GB。我们习惯了"功能多 = 资源多"的等式。

tinycast 试图打破这个等式：功能不少（34 种窗口操作、剪贴板历史、AI 对话、Raycast 扩展兼容），但内存控制在 100MB 以内。它不是通过"砍功能"实现的，而是通过"拒绝不必要的功能"和"用原生替代跨平台运行时"实现的。

这和 ripgrep 的道理一样：ripgrep 比 grep 快不是因为功能少，而是因为它用 Rust 重写了核心算法，并且拒绝了 grep 的历史包袱。tinycast 比 Raycast 轻不是因为功能少，而是因为它用 SwiftUI 原生渲染，并且拒绝了 Electron/Node.js 运行时。

最小化回归的第三部曲：tailcat（文件搜索）→ typephp（PHP 静态分析）→ tinycast（桌面启动器）。三个不同领域，同一个哲学——用原生实现替代跨平台运行时，用功能封闭维持资源预算。

项目地址：https://github.com/abue-ammar/tinycast
Discord：https://discord.gg/v2Eeb4QQy3
许可证：AGPL-3.0