找 iOS URL Scheme 太麻烦,所以我做了个索引站

前段时间我想找几个常用 App 的 iOS URL Scheme。

一开始以为这事很简单：搜一下 App 名，加上 URL Scheme，应该就能找到。结果真正找起来才发现，资料很散。有的在很老的博客里，有的在 GitHub issue 里，有的只出现在别人整理的片段里，还有一些要从 App 的 Info.plist 或历史记录里翻。

更麻烦的是，找到不代表能用。

有些 Scheme 只是能打开 App，不能跳到具体页面；有些在旧版本里有效，新版本已经失效；有些入口只在国内区 App 里存在；还有些链接看起来像 Scheme，但其实更接近 Universal Link 或 WebView 跳转。

所以我干脆做了一个小站：awesome-ios-url-schemes。

项目地址：https://github.com/SWHL/awesome-ios-url-schemes

在线地址：https://swhl.github.io/awesome-ios-url-schemes/

它现在不是特别复杂，本质上就是一个静态站点，加一份结构化 JSON 数据。目前收了 173 个 App, 1441 条 Scheme。数量不算夸张，但已经比散落在浏览器收藏夹和搜索结果里好维护得多。

我想解决的其实不是“列出来”

网上并不缺 URL Scheme 列表。

但很多列表的问题是：它们通常只是一个 Markdown 表格，时间久了之后很难判断哪些还能用，哪些只是历史记录。你看到一条 xxx://scan，但不知道它来自哪里，不知道有没有人验证过，也不知道它属于扫码、搜索、付款码，还是只是打开 App。

我想要的是稍微多一点结构。

所以项目里每条 Scheme 不只是一个字符串，还会记录这些东西：

• 它属于哪个 App
• App 的 Bundle ID 是什么
• 这个 Scheme 大概是做什么的
• 它属于哪类能力，比如扫码、搜索、内容详情、导航、设置
• 已知地区是哪里
• 有没有参数
• 是普通 Scheme, Universal Link，还是 WebView
• 当前状态是已验证、部分可用、可能失效，还是未知
• 资料来源或验证方式是什么

这些字段看起来有点啰嗦，但后面会省很多事。

比如我想找“所有能打开扫码页的 Scheme”，就不需要全文搜索“扫码”“扫一扫”“scan”各种关键词，只要按能力筛选。想找某个 App 的全部入口，也可以按 App 聚合。想让别人反馈失效，也能精确到某一条记录，而不是对着一整篇列表留言。

为什么做成静态站

这个项目用 Astro 写，部署在 GitHub Pages 上。

其实这里没有什么复杂架构。URL Scheme 这种数据读多写少，用静态站点就够了。静态页面访问快，不用管服务器，也不需要数据库。数据就放在仓库里，Git 本身就是版本记录。

我也不想为了一个索引站搞一套后台。

现在的流程是：数据放在 src/data/schemes.json，分类、能力标签和来源分别放在几个独立 JSON 文件里。Astro 负责把这些数据渲染成页面，同时也暴露出 JSON 和 Markdown 形式的数据出口。

本地跑起来也很直接：

pnpm installpnpm run validate:datapnpm run dev

如果只是改数据，重点反而不是前端构建，而是先跑校验。因为这类项目最容易坏的地方不是页面样式，而是 JSON 里某个字段拼错、某个 URL 重复、某个分类 ID 不存在。

首页主要围绕查找和验证

首页没有做成很重的产品页。

我更希望它打开后就能直接查，所以核心就是搜索、筛选和复制。

现在支持按 App 名、Bundle ID, URL、用途、分类等内容搜索，也可以按分类、能力、状态、证据类型筛选。结果有三种看法：按 App、按能力、全部列表。

这个“按能力”对我自己挺有用。因为很多时候我不是为了找某个 App，而是想知道“有哪些 App 支持扫码入口”“哪个地图类 App 可以直接导航”“哪些 App 有搜索 Scheme”。如果数据只有字符串列表，这种问题就很难回答。

每条 Scheme 旁边有复制按钮，也有“可用”和“失效”的反馈入口。点反馈会打开一个预填好的 GitHub Issue，把 App, Scheme、用途和反馈类型带进去。

这个设计有点朴素，但够用。

我不想让用户为了反馈一条失效记录，还要自己组织一堆格式。能少填一点就少填一点，维护者看到的信息也更统一。

顺手加了一个 Bundle ID 查询

做这个站的时候，我发现另一个常见小麻烦是 Bundle ID。

很多时候手上只有 App Store 分享链接，但要写规则、做跳转、排查问题时，又需要 Bundle ID。于是我在首页加了一个 Bundle ID 查询框。

它的实现也没用后端。页面从 App Store URL 里解析出 App ID，然后在浏览器端调用 Apple Lookup API，拿到 App 名和 Bundle ID。

这不是一个多高级的功能，但实际用起来很顺手。尤其是整理数据时，可以少开几个网页。

因为它跑在 GitHub Pages 上，有时可能会被网络环境或浏览器插件影响，所以页面里也留了一个 fallback 链接，必要时可以直接打开 Apple Lookup API 看原始结果。

贡献流程尽量自动化，但不完全自动

数据类项目最怕两件事：没人愿意提交，或者提交了之后维护成本太高。

所以我做了一个 Issue 到 PR 的流程。

用户可以通过 Issue 提交新的 Scheme，也可以反馈已有 Scheme 可用或失效。GitHub Actions 会读取 Issue 内容，调用脚本更新 src/data/schemes.json，然后跑一遍数据校验。如果没问题，就自动开一个 PR。

维护者要做的是审一下这次数据变更，而不是从 Issue 里手工复制字段。

这里我没有让机器人直接合并，因为 URL Scheme 这种东西很容易出现误报。比如某个链接在提交者手机上能打开，但在另一个地区、另一个 App 版本里可能不行。自动生成 PR 已经能省掉机械劳动，最后一步还是留给人判断更稳妥。

数据校验是这个项目里比较重要的一块

现在项目里有一个 Python 脚本：scripts/validate_data.py。

它会检查 JSON 格式、slug 是否重复、分类和能力标签是否存在、Scheme URL 是否重复、状态和类型是否合法、日期格式是不是 YYYY-MM-DD 等。

这些检查看起来普通，但对这个项目很关键。

因为数据会不断增加，而且未来可能来自不同人的提交。如果没有校验，很容易慢慢积累出一堆小问题：同一个 URL 出现两次、某条记录引用了不存在的分类、某个状态写成了 verifyed，页面还能构建，但筛选就会开始出现奇怪结果。

现在部署流程里也会先跑数据校验，再构建站点。也就是说，数据结构不对时，不会直接发布到线上。

现在还不完美

这份索引还远不是“权威资料”。

很多 Scheme 目前只能标成 unknown，因为我还没有逐条在真机上验证。部分来源也只是社区资料或历史整理，准确性要继续靠后续反馈来提高。

另外，URL Scheme 本身就不是一个特别稳定的接口。App 更新后入口可能改掉，系统策略也可能变化。有些 App 甚至不会公开这些能力，只能靠观察和测试。

所以我更倾向于把它看成一个“可验证的数据集”，而不是一份一次写完就结束的清单。

后面比较想继续补的方向有几个：

• 给更多记录补充真机验证结果
• 增加 App 版本、iOS 版本、测试设备等信息
• 补充海外 App 和开发者工具类 App
• 对 Universal Link 单独记录 fallback 行为
• 提供更适合脚本读取的数据导出

这些都不难，但需要时间慢慢补。

小结

awesome-ios-url-schemes 是我为了解决自己查 iOS URL Scheme 麻烦而做的小项目。

它没有复杂后端，也没有很重的交互。核心就是把散落的 Scheme 整理成结构化数据，再用一个静态站点把搜索、筛选、复制、反馈这些基本动作做好。

如果你只是偶尔查一个 App 的 Scheme，可以直接用网页。如果你在做 iOS 调试、快捷指令、自动化脚本，也可以直接读项目里的 JSON 数据。

后续如果你发现某条 Scheme 可用、失效，或者知道新的入口，也欢迎在 GitHub 上提交 Issue。这个项目的价值，很大程度上会来自持续验证。