这是一系列正在进行的文章，记录我实现一个Mac App的过程，从最初的想法，到产品设计、编写代码，最后到产品上线。
本系列文章预计共有三篇，本文为第一篇。
昨天在 Vercel 上看 Anybox 网站的访问统计，其中有个从未见过的网站，自然而然的，我想了解关于 Anybox 的评论。这是一个频繁更新的个人博客，首页的三篇文章里都未提及 Anybox。归档列表也比较长，而且篇幅不短，肉眼搜索无果，只好使用谷歌的站内搜索。
我使用的浏览器是 Chrome，具体操作步骤：
可以看到，这个操作即使可以完全使用快捷键完成，它仍然需要敲击多次键盘，特别是在删除 URL 路径时。简而言之，它费手指。
从上面的操作我们可以看到，未知部分仅有关键词。我们可以从当前标签页获得网站，然后拼凑出网址并在浏览器中打开。
这种需求就是为什么我们使用启动器 App：通过每个启动器都支持的自定义动作实现特有的需求。
比如如果我要在 Raycast 内实现这样的一个扩展，大概步骤会是这样：
以我编写过多个 Raycast 扩展的经验预计，实现这个扩展用时不会超过一小时。
当然，如果我花了这一个小时去写这个扩展，也就不会有这篇文章了。
我的问题很容易解决，但是不会写程序的其他人呢？
这几年我写的几个应用，从最早的 Seamless，到 OK JSON，再到 Anybox，这些应用的最初想法都来源于我自身的需求。我相信，作为一个普通人，我的需求也不特殊，总会有部分人也有着同样需求。
不过，我也承认，这些都是小众需求。我的几个应用都是收费应用，现在面临着一样的问题，如何让他们被更多人知道。所以某种程度上，这个应用也是一种 #BuildInPublic 的尝试。
按照目前的想法，这个应用就是一个可自定义搜索引擎的应用，不同之处就是提供了当前标签页信息。它的交互应该是这样的：
Raycast 可以添加 Quicklink，Alfred 可以添加 Web Search，LaunchBar 也可以添加 Action。我前几年用过一个叫 Haste 的应用，它可以通过全局快捷键呼出自定义搜索引擎面板。这些都说明，自定义搜索引擎的可替代品太多了，如 Alfred 和 LaunchBar 可谓将效率优化到极致，而新晋应用 Raycast 则通过优秀的设计降低工具门槛，效率上也可通过配置达到前辈水平。
如果我们做一些简单的商业调查，会发现上市已五年的 Haste 应用，在中国区的 Mac App Store 仅有区区 20 个评分。换言之，这个自定义搜索引擎应用，它的商业前景是很渺茫的。
所以，得加功能。
既然这个应用已经需要通过 Apple Script 和浏览器交互了，那就想想这上面能做的事情还有什么吧。
除搜索外，复制当前标签页的 URL 也是一个常用功能，还可以支持 Markdown 形式复制。另外还可以支持搜索书签、历史记录、标签页等。
大概一年前，我就有想过写此系列文章，当时设想的应用是搜索菜单项应用，交互恰好和这个搜索引擎应用一致，所以不妨添加此功能。
「搜索菜单项」这个功能，我虽然不用，因为常见的操作我通过快捷键完成，但它其实很常见。
Raycast 有内置扩展 Search Menu Items；Alfred 有 Menu Bar Search Workflow；Typora 的开发者也有一款名为 Paletro 的应用；知名的 Mac 工具应用开发厂商 Many Tricks 旗下有一款偏向鼠标操作的 Menuwhere；还有来自独立开发者 Roey Biran 的 Finbar。举的这些例子说明这个功能是有市场和认知度的，并不会无谓地复杂化应用。
总结目前设想的功能：
在开发一个应用时，设计总会和最终产品有区别，这其中可能是因为技术问题，也可能是因为投入思考的时间更多，有更好的设计。但在写代码前就通过文档或原型定义产品，总归是更好的。我们的大脑内存有限，写文档或者画原型的过程，不仅是思考过程，也是存储过程，除了让产品的逻辑更清晰外，还能让我们记下思维结果，不至于遗漏或重复。
俗话说得好，工欲善其事，必先立其名。
应用名称确定好后，其实也就确定了这个应用的边界。
但对我而言，在写代码前就需要想好名字的原因是，在苹果的应用开发工具 Xcode 内新建一个应用时，需要输入一个唯一的应用包名（Bundle Identifier）。惯例是使用反向 DNS 格式（Reverse-DNS Format）。比如苹果的官网域名是 apple.com，苹果浏览器 Safari 的包名则是 com.apple.Safari。应用包名在应用上线前都是可以更改的，但一旦开始写代码了，代码内难免出现应用名称，这个也需要一同修改。为了减少麻烦，我一般会在新建项目前确立好应用名称。
这个应用和浏览器相关甚重，所以名字中需体现这一点，我想到了这些名字：
可以看到，我的创意实在有限，这些名字基本上就是「浏览器助手」不同翻译。
里面我最喜欢的是「Browser Sidekick」。
如果你用牛津高阶词典查一下「sidekick」释义，你会发现如此例句：Batman and his young sidekick Robin。
当下我就觉得是它了，就是这个意思，这个应用就是你的罗宾！但该死的是，这个名字已经被一个浏览器抢走了，这意味着我需要直接放弃「sidekick」这个词，连带划去「Web Sidekick」。
剩下的名字里，「Browser Assistant」听起来太资本主义了，让人想起上班；「Browser Helper」让人想起早些年的 IE 浏览器流氓插件。「Web」这个词虽然比较短，但不如「Browser」准确，所以名字基本可以确定为「Browser something」，其中 something 为「sidekick」的同义词。
打开 macOS 的词典应用，里面有本《American English Thesaurus》词典，虽然没有「sidekick」的同义词，但可查阅「helper」可得到：
assistant, coworker, fellow worker, workmate, teammate, helpmate, helpmeet, associate, aider, aide, colleague, supporter, partner, collaborator, abetter; subordinate, deputy, auxiliary, second, second in command, number two, right-hand man, right-hand woman, wingman, attendant, junior, acolyte; accessory, accomplice, henchman; sidekick.
结果可谓理想也不理想，合理选择并不多。「aide」听起来太政治了，于是只剩下「deputy」，那就叫「Browser Deputy」吧。
名字确定后，也可以注册域名了。
对于 iOS 应用而言，网站和域名的重要性并不如 macOS 应用。因为大部分人只会在 App Store 内搜索并下载 iOS 应用。而 Mac App Store 远远不如 App Store 活跃，搜索引擎给其带来的流量仍是很重要的。而且因为应用有搜索菜单项这个需要去除沙箱才能实现的功能，所以无法上架 Mac App Store，更需要做好网站，提高下载转化率。
但另外一方面，一个 app 后缀的域名，一年需要 15 美元；虽然独立域名看起来美观一些，但同一个开发者之间的应用在域名上看不出关联，不能互相推广；而且域名多了之后，相关的网站项目也多，维护和续费也麻烦，接入 Paddle 的支付 SDK 时，新域名都要审核。权衡之下，决定不注册新域名，直接使用开发者域名 anybox.ltd。
产品设计已完成，名字也已确定，下一步就是新建项目，然后编写代码，实现应用。
大多数细节只有在具体深入后才会发现。下篇文章会和大家分享 Browser Deputy 的具体开发过程，虽然不会设计到具体的代码，但也会有一些相关的技术思考，比如选用的 UI 框架，是 AppKit 还是 SwiftUI。
下次再见！
你可以在 Twitter 上找到我：@fengtieshan
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。