🤕開發者職業傷害──Dependency 的故事、事故與世故
開發者無可避免要依賴第三方工具與服務，但這些依賴背後藏著什麼風險？我在職涯早期，曾因一項免費同步服務突然下架，白忙了數個月，卻也因此建立了看待 dependency 的深刻觀點。這篇從實際經驗談起，分享我如何判斷、選擇，甚至參與貢獻 dependency，來有效降低風險。
今天來分享一個我個人 iOS 開發職涯早期遇到的重大傷害，以及它教會我的事情。
故事
大約在 2015 年初，也是我接觸 iOS 開發不到三年的時候，我正在幫自己的第一個獨立開發 iOS App，「快速筆記軟體 NoteBox」 ，升級雲端同步的功能。
NoteBox 本來就有雲端同步，只是我最開始偷懶使用 iCloud Key-Value Store。
你可以把 iCloud KVS 當作一個沒有衝突解決機制的雲端版 UserDefaults。當然，它的容量限制也絕對不是很好的長期儲存方案。
當時 Apple 已經發表 CloudKit，有著不需要使用者額外登入的好處，自然是重要選項之一。
另一方面，NoteBox 本來就有整合 Dropbox SDK，以利使用者一鍵把筆記輸出成檔案放在 Dropbox。
當時 Dropbox 有個叫做 Datastore API 的服務，提供給 mobile app 開發者很方便能同步非檔案的資料，類似後來推出的 Firebase Realtime Database，而且使用起來非常簡便。
它內建自動同步、衝突處理、離線儲存等功能。
重點是，它的同步速度非常迅速。兩台手機開著 NoteBox 在前景，在一台手機新增筆記，不到半秒就可以在另一台看到。
Datastore API 簡便且高效能，並且在各種多裝置 + 離線操作的測試條件之下，它都能正確合併資料。讓我對它十分有信心。
而且它還沒有跟開發者收費呢（！）
不過因為不是每個使用者都會登入 Dropbox，所以我同時做了 CloudKit 與 Dropbox Datastore 兩套方案，打算讓使用者自行選擇。
CloudKit 同步要寫得好不容易，需要考慮很多錯誤處理（這個情況，直到 2023 年 Apple 推出 CKSyncEngine 才變得比較簡單）。所以，雖然 Datastore 三兩下就串接完畢，我還是得在 CloudKit 上面花費大量時間開發及除錯。
還有，在兩種雲端儲存方案之間切換的機制也要做到好，也花了我不少力氣。
事故
好不容易，就在我開發完畢兩套全新的同步機制、自行測試完畢，準備要把新版送審上線的時候，