我主要工作是 iOS app 開發，現在工作有很大一部分是在終端機裡與 AI agent 協作：研究方案、規劃功能、修改程式碼、分析 crash，最後再由人進行審查與驗收。
現在的 model 都很強大，真正影響成果的已經不是 prompt 寫得多漂亮，而是能否提供完整 context、把重要知識外部化，並將重複流程工具化。這篇文章會整理我日常工作流程，以及幾個已經實際使用的案例，希望能跟各位交流分享，聽到更多人的使用案例。
繼續閱讀 ➜在開發 iOS 應用程式時，使用 Swift Package Manager (SPM) 來模組化程式碼已經成為主流做法。然而，當你在 Swift Package 中實作多國語言支援時，可能會遇到一個令人困惑的問題：Package 內的本地化在測試時運作正常，但整合到主專案後卻失效了。本文將深入探討這個問題的根源，以及如何透過 CFBundleLocalizations 和 CFBundleAllowMixedLocalizations 這兩個 Info.plist 設定來解決。
當我實作畫面流程時，我會為一組「流程」建立一個 Coordinator。如果這組流程很複雜，它可以拆分成多個「子流程」，那每一個子流程也會有對應的 Sub-Coordinator。主流程的 Coordinator 可以管理子流程的 Sub-Coordinator。
Coordinator 用來管理流程的畫面，它負責建立畫面、傳遞資料給畫面、回應畫面的請求、移除畫面等等。如果用 tree 來理解畫面流程的話，Coordinator 就是 root，各個畫面就是 leaf。換個角度看，Coordinator 像一個容器 — 它自己不產出畫面內容，而是決定裡面放哪些畫面、什麼時候切換。
繼續閱讀 ➜在專案開發到一定規模後，你可能會發現某些 feature 其實相對獨立：它們有自己的流程、畫面、資源檔，甚至可以被其他專案重用。這時候，最乾淨、最有彈性的做法，就是把它抽成 Swift Package。
以我最近在做的功能為例，它是一個完整的獨立模組 - 有多個頁面、支援多國語言、使用圖片與動畫資源。為了避免日後整合時出現命名衝突、相依過重或編譯過慢的問題，我選擇把它獨立成一個 Swift Package。在將 feature 抽出到 Package 的過程我也踩到了一些坑，趁著這個機會記錄下來，以免日後忘記。
建立專屬的 Swift Package 有幾個明顯的好處：
When developing iOS and macOS applications, formatting lists is a common requirement. Whether it's terms and conditions, setting options, or tutorial steps, we often need to present ordered or unordered list content. However, Apple's native frameworks have relatively limited support for list formatting, which often puts developers in a dilemma: existing solutions aren't perfect, while heavier solutions seem like overkill.
To solve this problem, I developed FormattedListKit, a lightweight yet fully-featured Swift Package specifically designed for creating beautifully formatted ordered and unordered lists.
繼續閱讀 ➜在網路上已經有很多關於 iOS Share Extension 的教學，例如這裡就有一篇。有需要的人可以自行在網路上搜尋，這邊就不多作著墨。我這次想要分享的主要是在開發 share extension 的過程遇到一些要注意的事項，以及踩到的一些坑。
我的開發環境是 macOS Sonoma + Xcode 15，使用 Swift 開發。
要建立一個 share extension 很簡單，就是在你的專案新增一個 target 然後選擇 Share Extension 即可。Xcode 會自動幫忙產生必要的檔案，以及做好基本設定。
