在 iPic 周岁时，说说这款让我骄傲的产品

2016 年 7 月 4 日，图床神器 iPic 上架 Mac App Store，虽说这是个好记的日子：美国独立日，但其实我还是忘记了。是前几天一条银行扣款短信提醒了我，刚开始我还觉得奇怪：我最近没在 MAS 上买软件呀？后来一查才知道：这里 iPic 高级版第二年的扣款短信。

Git 历史显示，iPic 项目始建于 2016 年 5 月 19 日。事实上，因为已经过了这么长时间，我也记不起 iPic 一路走来的点点滴滴，很难像 Klib 那样有系统性的总结。这里主要回忆一些关键的点，或者我觉得有意思的，拿出来与大伙一说。

文章很长，我也并不知道你大概需要几分钟读完；不喜欢读长文的，现在就可以关闭了，去找些你更感兴趣的吧。

------------- 长文开始警戒线 ----------------

iPic 带给我的骄傲

我最骄傲的，是 iPic 开创了 macOS 图床工具这一品类。在 iPic 之前，你在 macOS 中是找不到类似工具的，而在 iPic 之后，接连有多款 App 出现，甚至包括 Windows 版。曾经，你在 Mac App Store 搜索「 iPic 」，会有多款类似产品。使用「 iPic 」作为搜索关键字，也算是他们向我致敬的一种方式吧。不过，现在没有了，因为我向苹果举报、苹果向他们发律师邮件，他们已经去掉这一关键字了。

如果你在 macOS 平台找到比 iPic 更好的图床工具，告诉我。

Swift 带来的尴尬

Swift 是 2014 年中发布的，iPic 是 2016 年初启动的。虽说已过 1 年多，但对于一门编程语言而言，还是太短了。主要的问题是：不成熟，导致厂商对 Swift 的支持非常有限。比如，iPic 需要集成各家图床所提供的接口。对于一些较成熟的语言，比如 JavaScript、Python 等等，厂商可以直接提供了 SDK，只需要调用简单的接口，就可以实现图片上传这样的操作。

而对于 Swift 这么年轻的语言，肯定是没有 SDK 的，这就需要我 一个个去集成各个服务商的 REST API，这一过程相当繁琐。其中，大量的时间花在 OAuth 的实现上。不过，好在 OAuth 是相对标准的东西，各家的实现也大体相当，多支持几个图床，能重用的代码也多了。

另外，做这种相对 SDK 来说偏底层的东西，也是有好处的。比如，可以多一些对 OAuth 的理解；在设计 Klib 后端接口时，也能多参考这种工业级的 REST API 设计规范；等等。

其实，在这个过程中也会有很多有意思的发现，比如，阿里云的 OSS 接口基本是复刻 Amazon S3，连参数名都一样。Amazon S3 果然是企业级的，权限系统什么的很复杂，一般人很难搞定，而后来的阿里云则对中小用户更友好些。当然，只是模仿接口也未可厚非，但总会让人看轻一些：不要把 S3 中一些不好的设计也抄了去才好 😂

期间，也经历了 Swift 2.2 > 3.0 的升级，感觉比较多的变更都是语法层面，甚至可以说是变量名方面。个人感觉，我愿意给 Swift 版本升级多一些体谅：虽说确实会带来一些麻烦，但总比裹足不前要好。

顺便说一句，我所有的产品都是纯 Swift 的：Klib、iPic、iPic Mover、iPaste、iTimer、iHosts

我不愿增加一个额外的选项

首先吐槽一下七牛的接口。

七牛起初只有几个区域（好像是华北、华东，具体忘了），每个区域的不同的图片上传地址。后来，七牛增加了新的区域，每个区域又有新的上传地址。关键问题在于，Bucket 的名字在各个区域中不能重复的，但七牛却没有提供根据 Bucket 名字查询其所在地区的接口。这就意味着，在 iPic 的图床配置中，用户需要额外指定 Bucket 所在地区。这在我看来，是相当傻的。我相信，很多用户在创建结果后，并不记得 Bucket 所在地区，这就使得在配置图床时，遇到了额外的困难。

我实在不想增加这一设置项，所以实际上我是这么做的：用户不需要指定地区，iPic 自动尝试所有地区。如果图床的其他信息如 Key 是正确的，则可以找到正确的地区。这一方案，唯一问题是：一旦七牛又新开了区域，iPic 就得多尝试一个地区。至少，iPic 需要从服务器端获取七牛所有的区域列表，多了一点点维持工作量。不过，为了减少界面上一个设置项，这些都是值得的。

其实，不止七牛，别的图床也有类似的问题。不过，要好一些。比如，Amazon S3 如果选择错误的地区上传，返回结果中会包含正确的地区，选用即可。

这样以后，七牛、又拍、阿里云 OSS、Amazon S3 的图床配置界面一模一样，这降低了用户的使用成本，也让我很满意。

开放图片上传能力的 iPicUploader

iPic 一个比较重要的场景：在使用 Markdown 写文章时，插入图片。那与其单独使用 iPic 这样一个额外的 App，直接使用 Markdown 编辑器来插图，岂不更好？不过事实上，仅有少量的 Markdown 编辑器支持图床功能（如我在用的 MWeb ），大部分并不支持。

正巧，Typora 作者联系上我，希望与 iPic 集成，可谓一拍即合。

于是，我好好研究了在 macOS 沙盒限制下，各个 App 间通信的方式。最后，我选择了「私有剪贴板」这种方式（这个名字是我自己取的），既可以安全地上架 Mac App Store，也不会对用户的通用剪贴板造成干扰。事实上，在我向 Bear （对，就是前段时间大红大紫的 Markdown 编辑器 Bear ）介绍时，他们也夸赞这种方式。只可惜，他们没接入 iPic …

具体的步骤：

• Typora 集成 iPicUploader 这个开源的 iPic 上传助手
• Typora 等 Markdown 编辑器，当用户通过拖拽等方式上传图片时，读取图片信息，写入「私有剪贴板」，然后等待返回结果
  • 注：之所以要由 Typora 读取图片信息，是因为 iPic 处于沙盒模式中，如果客户端仅仅发送一个文件路径，iPic 是没有权限读取的
  • 另外，iPicUploader 也能检测 iPic 是否安装、当前是否在运行等情况
• 当 iPic 运行时，会监控「私有剪贴板」中的内容。一旦发现有待上传的图片，则上传、并将图片地址写回「私有剪贴板」
• Typora 得到上传结果，即图片的 http 地址，更新 Markdown 中的图片链接

事实上，从客户端的角度，使用过程比上述文字描述要简单的多：只要在项目中集成 iPicUploader，通过一个接口调用就可以了：

let imageFilePath = "/Path/to/the/pic.jpg"

iPic.uploadImage(imageFilePath, handler: { (imageLink, error) in    
	if let imageLink = imageLink {
		// Image uploaded        
	   
	} else if let error = error {
		// Some error happened
	}
})

当然，做这事也不是纯粹因为对开源世界的热爱，我自然是有私心的：傍大款。比如，像 Bear 这样级别的产品如果集成 iPic，那对 iPic 自然是极好的。只可惜，大部分邀约都没有反馈，最终成产品的只有 Typora …

自立山头的 iPic Mover

除了配合 Markdown 编辑器，我还单独开发了 iPic Mover，核心功能是：通过 iPic 上传 Markdown 中的图片（包括本地或网络图片）至新的图床，并替换 Markdown 中的图片地址。

主要的使用场景：

• 将博客中的图片整体搬家至新图床
• 使用 Markdown 编辑器编辑文章后，一键上传本地图片

其实，这个功能确实可以作为 iPic 的一部分。这样，至少可以省去单独为 iPic Mover 这款 App 设计 Logo，运营推广等多方面的资源。不过，我还是不想因为这个小众的功能，让 iPic 主体变得复杂。毕竟，大部分 iPic 用户并不需要这个功能。如果不需要却要天天看见这个功能，我是觉得不爽的。

免登录上传图片至微博

iPic 默认上传图片至微博图床，且无需登录。为什么一定要做到无需登录呢？主要是为了实现「开箱即用」的效果。想想一个国际友人，在下载 iPic 后，还需要注册一个微博账户才能用、注册界面丑陋且多年未更新，那是怎样的画面？

其实，iPic 要实现开箱即用：即安装后就可以上传图片至微博，技术上还是有些复杂的。不过，严格来讲，把微博当图床来用，本身确实是在道德上无法站住脚的，怎么说都有滥用微博资源的嫌疑。出于这一点，我就不在文章中详细介绍了，大家也不要私信问我，我不会回答。不过，想想我经常看的，包括 App 启动广告、女性生理期用品在内的微博广告，我心里就觉得舒服一些了。

关于 iPic 付费模式

iPic 的付费模式是：

• 默认的（微博）图床免费，所有 iPic 的功能免费
• 自定义图床收费，图床包括：七牛云 、又拍云、阿里云 OSS、Imgur、Flickr、Amazon S3 共 6 款，包含了目前主流的图床，收费模式为 ￥ 58 每年

其实，默认的微博图床还是挺好的：免费、不限流量、CDN 加速、稳定可靠、支持 https 等等，主要的局限是：

• 不支持 png 格式
• 会对图片进行肉眼可见的有损压缩
• 无法删除已上传的图片
• 无法查看或管理所有自己上传的图片
• 毕竟是依赖第三方服务，多少有风险，比如新浪倒闭

相反，如果不能接受微博图床的上述局限，可使用灵活度更高的自定义图床。比如，我自己使用的是七牛图床。起初是因为七牛提供一定额度的免费流量，后来才发现是个坑：免费流量不支持 https，而我的 博客 和 产品首页 已经全面支持 https，虽说我每月也就给七牛交很少的流量费，不过多少有些受骗的感觉。早知如此，我就选择阿里云 OSS 了。

这里顺便再说个七牛的一个坑：不支持 bucket 的自定义域名。也许你会说：支持的呀？但其实，只有「融合云」是支持的。但 CDN 毕竟有缓存问题，比如在做 Klib 分享时，我并不想因为速度的提升带来很大的缓存的问题（这会带来业务的问题，详见我当时的介绍），最后还是使用了支持自定义域名的阿里云 OSS. 比如，你在访问 http://s.klib.me/share.html 时，其实是访问的阿里云 OSS 里的文件。

关于订阅模式

现在，订阅依然不为人所接受。而想想 1 年前，订阅更加被抗拒；但我还是依然坚持做吃螃蟹的人。一方面，我想有所尝试；另一方面，我觉得订阅制是对开发者友好的，进而对整个生态友好的。试想，如果开发者都坚持不下去了，也就不会再有好软件诞生。Windows 的生态就是很好的例子，我时不时听到有开发者放弃、或不愿开发 Windows 下的应用，很大的一个原因是：盗版太猖獗。很多人用盗版用得理所应当，觉得 Windows 操作系统收费是变态，OK，惹不起我还躲得起，最终吃亏的还是用户自己：没有好软件可用。

Apple 的订阅制有个细节可以跟大家分享下。对于订阅的首年，Apple 会抽成 30%，即你付的 58 中，我只能得到 58 * 0.7 = 40.6，17.4 被 Apple 拔毛了。而在第 2 年及以后，Apple 抽成降低至 15%，即我可以多得 8.7 元。虽不多，但蚊子腿也是肉。更多的，是 Apple 对开发者的支持，用户对我的肯定。

￥ 58 一年的软件贵吗？贵，尤其是在国内的软件环境里，绝对是高价。但，还是有人愿意购买。我相信，购买的人不是傻子，而是经过充分对比才做的聪明选择。￥ 58 一年对于使用 iPic 所节约的时间而言，可以忽略。用钱买效率，并不是所有人的习惯，只是高效人士的习惯。

很开心的，就是通过 iPic 认识了一群 高效人士。他们认可我的努力，认可我对产品的理解，认可 iPic 对他们带来的帮助，愿意用付费的方式来支持我继续，还通过微信群、邮件等方式，提出改进意见。在此，谢谢各位的支持。

关于 iPic 的未来

其实，就像我在小结 Klib 中已经提到了，对于 iPic 这种典型的工具型应用，其天花板是很明显的：一旦功能实现了，进一步的想象空间很小。这也是我很长时间都没有对 iPic 更新的主要原因，因为不知道怎么做才是对的。

比如，有用户提除了 Markdown 格式外，也支持 reST 等其它标记语言的格式。这样的需求肯定是有道理的。但问题是，相对而言更小众。如果列表里同时列出 Markdown、reST，对于只用 Markdown 的大多数用户而言，是种干扰，因为他们可能根本就不知道什么是 reST。当然，可以在配置在自定义链接格式。这也是有道理的，只是又增加了产品的理解难度。

对于这类的需求，我很难判断是否要加。不加，肯定会流失部分用户；加，又会对已有用户造成一定的困扰。想不好之前，我宁愿暂时什么都不做。

当然，这并不意味着 iPic 不会更新。就像同样许久未更新的 iPaste，本月会迎来重大更新：支持 Pin 分组及管理。同样的，随着大家对图床需求的演变，一旦我想通了某一点，自然会适时跟进的。

尾巴

这篇文章很长，希望你能有与付出时间相称的回报。不然，我不会觉得不好意思…