0711 - 在 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"nniPic.uploadImage(imageFilePath, handler: { (imageLink, error) in n if let imageLink = imageLink {n // Image uploaded nn } else if let error = error {n // Some error happenedn }n})n

當然，做這事也不是純粹因為對開源世界的熱愛，我自然是有私心的：傍大款。比如，像 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 分組及管理。同樣的，隨著大家對圖床需求的演變，一旦我想通了某一點，自然會適時跟進的。

尾巴

這篇文章很長，希望你能有與付出時間相稱的回報。不然，我不會覺得不好意思…

博客原文：0711 - 在 iPic 周歲時，說說這款讓我驕傲的產品

推薦閱讀：