本文讲述了开发者MihhailLapushkin从Web开发转向Mac应用，创建Paper文本编辑器的历程，强调原生体验、精简设计和目标明确的开发策略。他分享了选择Objective-C、不依赖第三方库以及坚持极简主义的开发决策。
2015年，我是一个普通的全栈Web开发。
我有一台Mac，玩了一段时间以后，我就被它充满活力的应用生态系统所吸引了。
有一天，我看到了一个叫做IA Writer的Markdown编辑器，又简单又优雅。
我也决定自己做一个。
怀着满腔热情，我开始学习如何制作Mac原生文本编辑器。
XCode，AppKit，Objective-C，所有这一切对我来说都是全新的。
我打算把我的文本编辑器叫做Paper，它就像一张纸，非常简洁。
重要的决定
我的第一个决定就是：这个应用一定要是原生的！
我是Web开发，完全可以复用Electron这样的框架，但是我不想用它。
我宁愿学习全新的技能，为用户提供最好的体验。
这个体验就是：软件很小，下载速度超快，使用起来是原生的UI。
这样才能与其他非常精美的编辑器竞争。
我不想缩短开发时间，因为我拥有世界上所有的时间。
第二，我选择了Objective-C。
2015年，Swift刚刚出现，我做了一个实验，用Objective-C和Swift分别在XCode中写了一个空的项目，然后检查各自生成的.app包。
我惊讶地发现，Swift中嵌入了完整的运行时，.app包是5M，而Objective-C只有几十K。
（如果你现在进行这个实验，差异不会那么大）
我想要最好的，宁愿付出更难学习和语言过时的代价，以便得到更精简的软件包。
第三， 我不想依赖第三方。
从自己不熟悉的生态系统中，选择依赖项，这实在是不容易。
恐怕大家都有这样痛苦的经验：在编写一行代码之前，添加一大堆不知道的第三方包和库......
我要构建一切内容，这样我可以按需定制，获得一点竞争优势。
比如Markdown的解析引擎，因为Paper不想那些传统的编辑器，并不支持全部的Markdown语言，所以在解析引擎中我只需要写我需要的代码，并且我可以做大量优化。
Paper 仅使用 AppKit 和 UIKit 中的本机 UI 元素，因为它们的维护开销最低：由Apple自动更新，向后兼容，保证在每个设备上工作。
我的愿景
非常简单，超越IA Writer，更加精简，更加优雅，让用户专注于写作这件事。
为了实现目标，我尽最大可能减少干扰。
应用程序窗口内没有一个按钮。
没有标准的“首选项”窗口，将所有内容分散到菜单项和菜单小部件中。
将滚动条缩小为2个像素的线。
上下滚动时可以隐藏标题栏，使得编辑器周围的空白可以拖动
不知道是否有人注意到了我这些努力，很可能是有的，因为有人写了一个非常简洁的评论，我至今依然将其作为宣传语：
这是一个超级干净的写作空间，有大量可配置的东西，当你不需要时，它们可以隐藏在实现之外。
根据我的观察，奉行极简主义的写作软件通常会走向两条路：
（1）变得流行，为了满足大量用户的新需求，偏离极简主义初心，变得复杂起来。
（2）继续保持极简和小众，最终被创造者所抛弃。
Paper不会走（1），但是可能在(2)的路上。
我的计划是：让Paper永远保持它发布时的样子，拒绝增加多余的视觉混乱，正如用户所说：
请不要让 Paper 变得更复杂！市面上有很多“全功能”编辑器，但它们不适合专注写作。
同时，通过缓慢的、可预测的更新节奏，我会向应用程序的边缘地带添加功能，同时保持默认路径超级干净。
与浏览器中可预测的JavaScript运行时相比，闭源原生UI是一个脆弱的地方。
如果你不努力的投入精力去重构应用，fix bug，很快，你的软件就会因为崩溃而被大家弃用。
架构设计
我发现将Paper的代码看做两个作用域非常方便
1.应用程序作用域
包括菜单，状态栏，图标，暗黑模式，全局配置，单实例视图
2.文档作用域
视图和逻辑的集合，存在于表示单个文档的视图控制器中。
一个新的文档作用域在文档打开的那一刻产生，在文档关闭的那一刻死亡。
与单一应用程序作用域不同，多个文档作用域可以同时存在
对每个作用域，我都会定义一个storyboard，完成以下功能：
描述作用域内使用的各种视图和小部件
充当依赖注入容器，将作用域内所有的模块粘合在一起。
付费功能
从2015到2017年，订阅制在App Store中还不普遍。大家还都是付费下载，但是我觉得如果不使用的话，大家不会为一个不知名的App付费。
我其实并不想设置什么“付费墙”或者试用期啥的，我想给用户提供更好的体验，我的办法就是给专业版（Pro）的某些视觉效果收费，对于基本功能如文件同步、PDF导出等保证免费。
然后我让大家无限期的试用，感受外观和效果，如果大家觉得不错的话，就可以购买Pro版。
当然，必须得有办法防止无限期地使用高级功能而不掏钱，最早的时候，我设置了一个60秒的定时器：如果有一个Pro版的功能处于激活状态，就提醒人们购买。
说实话，60秒提醒一次挺烦人的，后来，我想了一招，把这些提醒和文字联系起来，一旦你用Paper开始写作，每输入几百个字符提示一次，这样大家就可以尽可能不受干扰的情况下尝试所有功能。
事实证明，从用户反馈看，这种和文字结合的付费提醒方式很不错：
“......Paper可以让你随意摆弄和测试专业功能，而不是锁在付费墙后面（这也是我不喜欢很多应用的原因）....你不必相信我说的，自己跳进去看看，Paper让你试用每一个特性...”
粗糙的部分
文本编辑器有太多的功能了，复制粘贴、拖放、撤销、插入符号交互、从右到左的语言、非字母语言、听写、语音文本、扫描文本、文本中的非文本对象、点击并按住链接预览、文本搜索替换、拼写检查、自动更正、自动完成、人工智能建议......
你还得被新版的操作系统摆布，它可能增加了新的方式来插入、更新文本，和文本交互。
在iOS上，弄清楚“文本编辑器矩形”背后的数学原理尤其难，因为有各种因素，例如灵动岛，主页栏、动态显示的软件键盘，这些都会造成阻碍。
输入语言和字体也是一个令人头疼的问题。
字母语言相对容易处理，因为大多数主要字体甚至支持古怪的字形，例如元音变音和西里尔字母。
然而，非字母语言需要特定的字体来显示其字形。
幸运的是，苹果系统为每种非字母输入语言至少预装了一种字体。
唯一的问题是：没有 API 将输入语言映射到支持的字体 - 所以我不得不用大量的switch语句暴力破解它。
还有就是批量更新，对简单的情况很容易，但是对于那些边边角角的情况，处理起来太痛苦了，比如加粗一段文本就耗费了很多步骤
用户反馈
Paper最早用的是一个叫做HockeyApp的平台，Mac版自带聊天功能，这可比电子邮件反馈好多了，用户可以直接启用聊天，进行反馈。
微软收购了 HockeyApp后， 将其变成了 AppCenter，聊天功能没有了。
没办法，我只好自己做：
后来我还发现了一些小“秘密”，我写了一些代码，能够从用户未发送消息中查找一些关键字，然后自动回复。
自动回复回答了很多常见的问题，大大减少了我的“客服”工作量。
软件发布
我会收集聊天中的反馈，每月做一次新版本发布。
我会使用单个递增的数字做版本号，这是个简单的事情，为啥要用2个以上的用点分隔的数字呢？
这是我的release note 模板：
我觉得release note 一定得简单，这样用户才能真正阅读。
错误修复，微调，较小的功能通常不会提及，我不喜欢类似“我们已经修复了一些错误并进行了一些性能改进”这样的废话。
不断地更新让用户觉得他们的订阅是值得的，也会告诉App Store算法，这个应用没有被放弃。
最后，正是这种缓慢而稳定的节奏让我能在未来几年继续做这件事情。
后记
这篇文章翻译来自https://papereditor.app/dev，作者是Mihhail Lapushkin，一个爱沙尼亚的程序员。
原文中有更多章节，我做了删减，翻译也不是直译，而是在保留原意的情况下，转换成了更轻松的风格。
这篇文章让我最为感慨的是这么几点：
1.跨界开发
一个Web开发，毅然进入桌面领域，学习全新的知识，并且获得成功。
所以，喜欢什么东西，就动手搞起来吧，别把现有的技术栈自己给圈住了。
现在AIGC很厉害，完全可以利用起来。
2. 目标明确，追求极致。
他追求的就是最佳的用户体验，为了缩小软件大小，直接用最“原始”的Objective-C。
为了完全掌控，竟然不依赖第三方类库，完全从头打造。
在我的记忆中，可能只有SQLite的作者也是这么干了。
3. 不但会编程，还得有艺术品位。
这个Paper编辑器界面做得赏心悦目，就连这篇文章的网站也做得让人看起来非常舒心。
可见Mihhail Lapushkin不但是个程序员，还是个优秀的用户体验设计师，很有艺术品位。
这一点我很羡慕，我一直在弄后端，就是因为搞不好界面相关的东西。
程序员众多，把不同领域的知识结合起来，才能脱颖而出啊。
4.长时间打磨，真有时间
2015年开始做，2017年作出第一个版本，在Mac上发布，2019年发布iOS版本。
然后就是持续的打磨，到今年已经9年了。
除了真正喜欢之外，很难找到别的原因了。
Mihhail Lapushkin说“我拥有世界上所有的时间”，嗯，这些国外程序员确实太幸福了。
全文完，觉得不错的话点个赞或者在看吧！
近期精彩：
巴西都发明两门流行的编程语言了！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
