# 13報 > 和 13 一起成長，用好奇心勝過知識焦慮 Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### 關於⟪13報⟫ URL: https://ethanhuang13.plus/about/ Last updated: 2026-07-31T11:48:19.000Z [關於作者](#關於作者) · [About the Author](#about-the-author) 13 有著 13 年以上的 iOS 開發經驗，撰寫超過 260 期 Apple 開發者週報。並在 2026 年被 Apple 選為全球 50 名[開發者社群領袖](https://developer.apple.com/community/recognition/?ref=ethanhuang13.plus#ethan-huang)之一。 所有文章皆由 13 本人撰寫，不假 AI 生成。內容涵蓋 **iOS 技術、AI 工具實務經驗、學習、心理健康、App 產品經營、團隊領導、職涯發展**等主題文章。助你在 AI 時代成為更有自信的技術工作者。 ## 免費訂閱[⟪13報⟫](https://patreon.com/ethanhuang13/?ref=ethanhuang13.plus) - Apple 開發者週報 - 專欄文章電子報 ## 升級為[⟪13報+⟫](https://patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus) - ❤️ 支持 13 創作！ - 🤖 AI 工具實戰經驗與深度思考 - 🧠 軟體開發思維、職涯發展建議 - 💡 實用技巧與踩坑經驗分享 - 📦 推薦的套件與工具 - 😔 開發者身心健康與職業傷害 - ☀️ 2026 年新產品 [todayOS](https://today-os.app/?ref=ethanhuang13.plus) app 的經營策略 - 🎮 Bonus: 用 Mac 玩遊戲的心得 **適合對象：** - iOS 開發者想拓展視野與技能樹 - 對 AI 工具有興趣的技術工作者 - 想提升軟技能的資深工程師 - 關注學習方法與自我成長的開發者 文章提供部分試閱，歡迎參考。 請至 [Patreon](https://patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus) 進行訂閱。訂閱會員可在本站使用同一個 E-mail 登入，即可觀看全文。 ## **關於作者** 13（讀作一三），台灣人，Apple/iOS 開發者。喜歡分享技術新知與踩坑經驗。 iOS 開發相關內容： - ➕ [13報+（13 Newsletter+）](https://ethanhuang13.plus/)：給資深 iOS 開發者的付費內容，你現在正在這裡 - 📰 [13報｜Apple 開發者週報（13 Newsletter | Apple Developer Weekly）](https://ethanhuang13.substack.com/) - 🎙 [weak self podcast](https://bit.ly/weak%5Fself%5Fpodcast?ref=ethanhuang13.plus)：台灣第一個 iOS 開發者 podcast - 📺 [13 的 iOS 開發配飯吃（13’s iOS Coding Show）](https://www.youtube.com/@ethanhuang13?ref=ethanhuang13.plus)：一邊聊天一邊寫 Code 的節目 - 📺 [不上班工程師的日常（Life of an Engineer Without a Day Job）](https://www.youtube.com/@%E4%B8%8D%E4%B8%8A%E7%8F%AD%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%9A%84%E6%97%A5%E5%B8%B8?ref=ethanhuang13.plus) Apps： - [todayOS](https://today-os.app/?ref=ethanhuang13.plus)（iOS、watchOS、macOS） - [iPlayground](https://apps.apple.com/tw/app/id6751350620?ref=ethanhuang13.plus)（iOS） 歡迎追蹤我的 [GitHub](https://github.com/ethanhuang13?ref=ethanhuang13.plus)、[Twitter](https://twitter.com/ethanhuang13?ref=ethanhuang13.plus) 與 [Threads](https://www.threads.net/@ethanhuang13?ref=ethanhuang13.plus)。 ## About the Author 13 (pronounced “Yi-San”) is a Taiwanese Apple/iOS developer who enjoys sharing technical insights and hard-earned lessons. iOS development content: - ➕ [13報+（13 Newsletter+）](https://ethanhuang13.plus/): Paid content for experienced iOS developers—you’re reading it now - 📰 [13報｜Apple 開發者週報（13 Newsletter | Apple Developer Weekly）](https://ethanhuang13.substack.com/) - 🎙 [weak self podcast](https://bit.ly/weak%5Fself%5Fpodcast?ref=ethanhuang13.plus): Taiwan’s first podcast for iOS developers - 📺 [13 的 iOS 開發配飯吃（13’s iOS Coding Show）](https://www.youtube.com/@ethanhuang13?ref=ethanhuang13.plus): A show where 13 chats while writing code - 📺 [不上班工程師的日常（Life of an Engineer Without a Day Job）](https://www.youtube.com/@%E4%B8%8D%E4%B8%8A%E7%8F%AD%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%9A%84%E6%97%A5%E5%B8%B8?ref=ethanhuang13.plus) Apps: - [todayOS](https://today-os.app/?ref=ethanhuang13.plus) for iOS, watchOS, and macOS - [iPlayground](https://apps.apple.com/tw/app/id6751350620?ref=ethanhuang13.plus) for iOS Follow me on [GitHub](https://github.com/ethanhuang13?ref=ethanhuang13.plus), [Twitter](https://twitter.com/ethanhuang13?ref=ethanhuang13.plus), and [Threads](https://www.threads.net/@ethanhuang13?ref=ethanhuang13.plus). ### 文章目錄 URL: https://ethanhuang13.plus/index/ Last updated: 2026-09-14T10:36:04.000Z ## 分類 - [🧠 軟體開發思維](https://ethanhuang13.plus/tag/software-development-thinking/) (48篇) - [🤖 AI 工具](https://ethanhuang13.plus/tag/ai-tools/) (47篇) - [⚡️短篇抒發](https://ethanhuang13.plus/tag/lightning-talk/) (37篇) - [💡 實用技巧](https://ethanhuang13.plus/tag/tips/) (36篇) - [🆓 免費公開](https://ethanhuang13.plus/tag/free/) (33篇) - [😔 開發者職業傷害](https://ethanhuang13.plus/tag/developer-pain/) (23篇) - [🤝 研討會](https://ethanhuang13.plus/tag/conference/) (19篇) - [🪧 公告](https://ethanhuang13.plus/tag/announcement/) (17篇) - [📰 開發者新知與評論](https://ethanhuang13.plus/tag/news/) (16篇) - [📱 開發者體驗](https://ethanhuang13.plus/tag/dev-experience/) (15篇) - [🧐 學習如何學習](https://ethanhuang13.plus/tag/meta-learning/) (15篇) - [✍️ 學習 SwiftUI](https://ethanhuang13.plus/tag/learning-swiftui/) (12篇) - [📦 推薦 Swift Package](https://ethanhuang13.plus/tag/swift-package/) (11篇) - [🐣 iOS 開發補完計畫](https://ethanhuang13.plus/tag/ios-missing-manual/) (10篇) - [🧠 brainOS](https://ethanhuang13.plus/tag/brain-os/) (9篇) - [💸 好，買了](https://ethanhuang13.plus/tag/ok-buyla/) (9篇) - [💫 產品經營](https://ethanhuang13.plus/tag/product-building/) (8篇) - [📦 SwiftUI & TCA](https://ethanhuang13.plus/tag/swiftui-tca/) (7篇) - [🎮 用 Mac 玩遊戲](https://ethanhuang13.plus/tag/mac-gaming/) (4篇) - [6️⃣ Swift 6](https://ethanhuang13.plus/tag/swift-6/) (4篇) ## 標籤 [AI](https://ethanhuang13.plus/tag/ai/), [AI 工具小技巧](https://ethanhuang13.plus/tag/ai-tips/), [ChatGPT](https://ethanhuang13.plus/tag/chatgpt/), [Claude](https://ethanhuang13.plus/tag/claude/), [Codex](https://ethanhuang13.plus/tag/codex/), [Copilot](https://ethanhuang13.plus/tag/copilot/), [Cursor](https://ethanhuang13.plus/tag/cursor/), [MacBook Neo](https://ethanhuang13.plus/tag/macbook-neo/), [Podcast](https://ethanhuang13.plus/tag/podcast/), [Side Projects](https://ethanhuang13.plus/tag/side-projects/), [SweetPad](https://ethanhuang13.plus/tag/sweetpad/), [Swift Concurrency](https://ethanhuang13.plus/tag/swift-concurrency/), [Swift Dependencies](https://ethanhuang13.plus/tag/swift-dependencies/), [SwiftUI](https://ethanhuang13.plus/tag/swiftui/), [SwiftUI 讀完就入坑](https://ethanhuang13.plus/tag/swiftui-series/), [The Composable Architecture (TCA)](https://ethanhuang13.plus/tag/tca/), [VSCode](https://ethanhuang13.plus/tag/vscode/), [WWDC](https://ethanhuang13.plus/tag/wwdc/), [WWDC25](https://ethanhuang13.plus/tag/wwdc25/), [WWDC26](https://ethanhuang13.plus/tag/wwdc26/), [Workshop](https://ethanhuang13.plus/tag/workshop/), [Xcode](https://ethanhuang13.plus/tag/xcode/), [iOS 開發世界觀](https://ethanhuang13.plus/tag/ios-dev-world-view/), [iOS 開發配飯吃](https://ethanhuang13.plus/tag/eating-with-ios-dev/), [iOS 面試](https://ethanhuang13.plus/tag/ios-interview/), [iPlayground](https://ethanhuang13.plus/tag/iplayground/), [todayOS](https://ethanhuang13.plus/tag/todayos/), [休假](https://ethanhuang13.plus/tag/vacation/), [團隊領導](https://ethanhuang13.plus/tag/leadership/), [坑](https://ethanhuang13.plus/tag/pitfall/), [專題：探究 iPhone 的 USB 速度對開發體驗的影響](https://ethanhuang13.plus/tag/iphone-usb-speed-series/), [專題：用 SwiftUI 畫 Mac mini](https://ethanhuang13.plus/tag/learning-swiftui-draw-mac-mini-series/), [影片](https://ethanhuang13.plus/tag/video/), [生產力](https://ethanhuang13.plus/tag/productivity/), [程式比賽](https://ethanhuang13.plus/tag/programming-contest/), [語音輸入](https://ethanhuang13.plus/tag/voice-input/), [💙 工作心流](https://ethanhuang13.plus/tag/flow/), [📲 本地 AI](https://ethanhuang13.plus/tag/local-ai/), [🧑‍💻 開發者介紹](https://ethanhuang13.plus/tag/developer/) ## 2026年 ### 8月 - 2026-08-05: [💻為什麼 MacBook Neo 成了我的主力電腦](https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/) - 2026-08-03: [🛟給自己一個 Reset](https://ethanhuang13.plus/human-usage-reset/) ### 7月 - 2026-07-23: [🇹🇼冷知識：台灣是 iOS App Store 第四大市場](https://ethanhuang13.plus/taiwan-top-app-store-market/) - 2026-07-22: [🚧架設官網是基本──上架 App 前究竟有多少準備工作？（三）](https://ethanhuang13.plus/app-launch-preparation-part-3-site/) - 2026-07-10: [⚡️GPT-5.6 Sol 的第一印象：語言能力變強](https://ethanhuang13.plus/2026-07-10-gpt-5-6-impression/) - 2026-07-06: [🚧新手教學一定要做──上架 App 前究竟有多少準備工作？（二）](https://ethanhuang13.plus/app-launch-preparation-part-2-onboarding/) - 2026-07-02: [🗓️用 todayOS 的設計哲學來經營 todayOS](https://ethanhuang13.plus/todayos-meta-operation/) ### 6月 - 2026-06-28: [📰Apple 開發者週報 #266 iPlayground 也出 Podcast 啦（免費公開）](https://ethanhuang13.plus/dev-news-266-iplayground-podcast/) - 2026-06-24: [🌇上架 App 前究竟有多少準備工作？（一）](https://ethanhuang13.plus/app-launch-preparation-part-1/) - 2026-06-19: [☀️是什麼讓我決定把個人的 13 app 變成 todayOS 產品？](https://ethanhuang13.plus/why-build-todayos-from-personal-app/) - 2026-06-18: [📰Apple 開發者週報 #265 WWDC26](https://ethanhuang13.plus/dev-news-265-wwdc/) - 2026-06-13: [🤪我是每天幫 13 做東做西的 AI，他的日常根本大型精神內耗現場（免費公開）](https://ethanhuang13.plus/ai-roasts-13-daily-life/) - 2026-06-10: [🛠️打造自己的 WWDC26 學習系統](https://ethanhuang13.plus/wwdc26-strategy-build-learning-system/) - 2026-06-10: [📖給人讀的與給 AI 讀的 WWDC26 新資訊](https://ethanhuang13.plus/wwdc26-strategy-xcode-27-skills/) - 2026-06-07: [📰Apple 開發者週報 #264 全帶光就位](https://ethanhuang13.plus/dev-news-264-all-system-glow/) ### 5月 - 2026-05-29: [📰Apple 開發者週報 #263 少年們，要胸懷大志](https://ethanhuang13.plus/dev-news-263-boys-be-ambitious/) - 2026-05-29: [☀️全新產品 todayOS，幫助你掌握今天的節奏](https://ethanhuang13.plus/todayos-public-beta/) - 2026-05-26: [🤖Codex 正在成為 Agentic 時代的開發工具新典範](https://ethanhuang13.plus/codex-like-paradigm-shift/) - 2026-05-24: [📰Apple 開發者週報 #262 影響我最深刻的 iOS 開發者](https://ethanhuang13.plus/dev-news-262-ios-dev-weekly/) - 2026-05-20: [⚡️WWDC26 第一天會發生的事情](https://ethanhuang13.plus/2026-05-20-wwdc26-day1-predictions/) - 2026-05-14: [📰Apple 開發者週報 #261 繼續前行](https://ethanhuang13.plus/dev-news-261-move-on/) - 2026-05-13: [🎨沒有彩色 Mac 但想使用它們的配色](https://ethanhuang13.plus/mac-accent-color-simluate-hardware-enclosure/) - 2026-05-11: [🌸買了 MacBook Neo 才知道有這個顏色 API](https://ethanhuang13.plus/macbook-neo-color-api/) - 2026-05-08: [🖥️買 Mac Studio 的好理由](https://ethanhuang13.plus/buy-mac-studio-reasons/) - 2026-05-07: [📰Apple 開發者週報 #260 iPlayground 開賣、學生開發者夏令營](https://ethanhuang13.plus/dev-news-260-iplayground-summer-camp/) - 2026-05-06: [⚡️Codex 已經是很強的 iOS 工程師了](https://ethanhuang13.plus/2026-05-06-codex-is-great-ios-enginner/) - 2026-05-04: [⚡️信任的累積](https://ethanhuang13.plus/2026-05-04-building-trust/) ### 4月 - 2026-04-30: [📰Apple 開發者週報 #259 年費月繳](https://ethanhuang13.plus/dev-news-259-iap-12-month-commitment/) - 2026-04-23: [⚡️ChatGPT 知道我是誰](https://ethanhuang13.plus/2026-04-23-ai-recognize-me/) - 2026-04-22: [📰Apple 開發者週報 #258 Apple 50 週年、Tim Cook 退任 CEO](https://ethanhuang13.plus/dev-news-258-apple-50yr-tim-cook-ceo/) - 2026-04-14: [🎙️兩部訪談 13 的影片：ChaoCode、林聽他說](https://ethanhuang13.plus/2026-03-two-interview-chaocode-bane/) - 2026-04-13: [📱完美的狀態列不存在……才怪──iOS 開發補完計畫 #7（免費公開）](https://ethanhuang13.plus/ios-missing-manual-perfect-screenshot-status-bar/) - 2026-04-12: [🤖我的 AI 工具使用現況（2026 年 1-3 月）](https://ethanhuang13.plus/my-ai-tools-usage-2026-01-03-codex/) - 2026-04-06: [⚡️試算本地模型硬體需求](https://ethanhuang13.plus/2026-04-05-huggingface-hardware-compatibility/) ### 3月 - 2026-03-31: [⚡️基本功：設計的心理學](https://ethanhuang13.plus/2026-03-31-design-of-everyday-things/) - 2026-03-25: [⚡️基本功：閱讀第一手技術資料](https://ethanhuang13.plus/2026-03-25-basic-skill-reading-first-hand-docs/) - 2026-03-23: [⚡️我不怕被 AI 取代，不如說本來就想被取代](https://ethanhuang13.plus/2026-03-23-ai-replace-me/) - 2026-03-18: [🧑‍🏫兩年 iOS 教學回顧與洞察](https://ethanhuang13.plus/two-years-of-teaching-ios/) - 2026-03-10: [🧠經驗與記憶之謎](https://ethanhuang13.plus/experiencing-self-vs-remembering-self/) - 2026-03-09: [⚡️思緒的飛航模式](https://ethanhuang13.plus/2026-03-09-brain-airplane-mode/) - 2026-03-09: [🛠️利用 Xcode 26.3 工具完成開發循環](https://ethanhuang13.plus/xcode-tools-close-the-loop/) - 2026-03-08: [🐣Apple 開發者新聞 #257 iOS AI Summer Camp 活動預告](https://ethanhuang13.plus/dev-news-257-ios-ai-camp-preview/) - 2026-03-04: [💻MacBook Neo 太重了](https://ethanhuang13.plus/macbook-neo-weight/) - 2026-03-03: [⚡️如果 AI 只要一秒鐘就能完成指示](https://ethanhuang13.plus/2026-03-02-ai-speed-philosophy/) - 2026-03-02: [⚡️什麼叫做很會使用 AI](https://ethanhuang13.plus/2026-03-02-ai-human-boundary/) - 2026-03-02: [🐣iOS 開發補完計畫 #6 Xcode 管理學基礎篇（免費公開）](https://ethanhuang13.plus/ios-missing-manual-xcode-management/) ### 2月 - 2026-02-27: [🧠離職滿一年，思考 AI 的精華](https://ethanhuang13.plus/gap-year-ai-thoughts-essence/) - 2026-02-22: [⚡️如果你也想做自己的 ASR 工具](https://ethanhuang13.plus/2026-02-22-asr-tools/) - 2026-02-21: [⚡️Xcode 26.3 RC 2 更新](https://ethanhuang13.plus/2026-02-21-xcode-26-3-rc-2-update/) - 2026-02-20: [⚡️AI 變化太快，反而讓我更思考長期價值](https://ethanhuang13.plus/2026-02-20-ai-long-term-thinking/) - 2026-02-18: [⚡️休假時做點平常不會做的事](https://ethanhuang13.plus/2026-02-18-ai-tool-break/) - 2026-02-18: [⚡️我不再用 AI 整理工作日誌](https://ethanhuang13.plus/2026-02-18-summarize-work-log-without-ai/) - 2026-02-18: [⚡️Swift Student Challenge 提醒與策略（免費公開）](https://ethanhuang13.plus/2026-02-18-swift-student-challenge-strategy/) - 2026-02-11: [⚡️快速 AI 與慢速人類的交會](https://ethanhuang13.plus/2026-02-11-ai-human-intersection/) - 2026-02-11: [⚡️做對的事情更難](https://ethanhuang13.plus/2026-02-11-do-right-things/) - 2026-02-09: [⚡️我早該做 13+ 後台 App](https://ethanhuang13.plus/2026-02-09-should-have-built-earlier/) - 2026-02-08: [⚡️從 AI 焦慮到 AI 過勞](https://ethanhuang13.plus/2026-02-08-ai-over-work-not-sustainable/) - 2026-02-07: [⚡️什麼時候 AI 能背鍋？](https://ethanhuang13.plus/2026-02-07-ai-legal-entity-and-liability/) - 2026-02-06: [⚡️讓 Agent 學會 TCA 最佳寫法](https://ethanhuang13.plus/2026-02-06-the-point-free-way/) - 2026-02-06: [⚡️使用 Xcode 26.3 開發推文小 App](https://ethanhuang13.plus/2026-02-06-xcode-codex-personal-app/) - 2026-02-06: [📰 Apple 開發者新聞 #256 Xcode 26.3 與全新 Podcast ⟪不上班工程師的日常⟫](https://ethanhuang13.plus/dev-news-256-xcode-263-podcast/) - 2026-02-05: [⚡️OpenClaw 給我真正的啟示（免費公開）](https://ethanhuang13.plus/2026-02-06-openclaw-is-personal-software-system/) - 2026-02-04: [⚡️極短篇：速評 Xcode 26.3 Agent 功能與意義](https://ethanhuang13.plus/2026-02-04-xcode-26-3-agent/) ### 1月 - 2026-01-31: [👼13 的 brainOS：AI 工具的心理門檻本身就是機會](https://ethanhuang13.plus/my-brain-os-ux-floor/) - 2026-01-26: [🦞用不用 OpenClaw 無所謂，但我希望你認識他的創造者](https://ethanhuang13.plus/clawdbot-creator-peter-steinberger/) - 2026-01-26: [🧠13 的 brainOS：自己的知識是 AI 能力的上限](https://ethanhuang13.plus/my-brain-os-knowledge-is-ai-limit/) - 2026-01-19: [💼13 的 brainOS：在家工作如何切換上下班模式](https://ethanhuang13.plus/my-brain-os-work-from-home-mode-switch/) - 2026-01-15: [😎13 的 brainOS：我不想知道 AI 工具的使用量](https://ethanhuang13.plus/my-brain-os-codexbar-productivity-paradox/) - 2026-01-14: [🧠13 的 brainOS：開發日誌之 GPT-5.2-Codex 認真用](https://ethanhuang13.plus/my-brain-os-dev-journal-codex-5-2/) - 2026-01-07: [🛑13 的 brainOS：幫自己存檔才能關機](https://ethanhuang13.plus/my-brain-os-commit-shutdown/) - 2026-01-06: [🌋13 的 brainOS：其實你不是在拖延，而是在載入中](https://ethanhuang13.plus/my-brain-os-cold-start/) - 2026-01-05: [🧠13 的 brainOS：借用軟體工程概念談思考（免費公開）](https://ethanhuang13.plus/my-brain-os-introduction/) ## 2025年 ### 12月 - 2025-12-31: [🎊2025 年終回顧與感謝](https://ethanhuang13.plus/2025-year-end-review-thanks/) - 2025-12-30: [↩️iOS 本地 AI：連載一個月的實戰心得回顧](https://ethanhuang13.plus/local-ai-series-summary/) - 2025-12-25: [❎iOS 本地 AI：用 AnyLanguageModel 加 MLX 跑開源模型](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-mlx/) - 2025-12-24: [🚜iOS 本地 AI：用 LM Studio 把 AnyLanguageModel 接上本地 LLM](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-lmstudio-server/) - 2025-12-23: [🚥iOS 本地 AI：利用 Swift Package Traits 切換使用 AnyLanguageModel](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-package-traits/) - 2025-12-22: [🕳️iOS 本地 AI：準備踩坑 AnyLanguageModel](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-prepare/) - 2025-12-19: [📗iOS 本地 AI：Foundation Models framework 延伸資料](https://ethanhuang13.plus/local-ai-series-foundation-models-resources/) - 2025-12-18: [⏱️iOS 本地 AI：衡量 Foundation Models 效能的策略](https://ethanhuang13.plus/local-ai-series-foundation-models-benchmarking/) - 2025-12-17: [🆙iOS 本地 AI：Foundation Models 的限制、錯誤與 UX 設計技巧](https://ethanhuang13.plus/local-ai-series-foundation-models-ux/) - 2025-12-16: [🧮iOS 本地 AI：Foundation Models 的 Tool Calling，真正的問題是什麼時候該用](https://ethanhuang13.plus/local-ai-series-foundation-models-tool-calling/) - 2025-12-15: [🛝iOS 本地 AI：不讓使用者乾等，Foundation Models 的 Stream Response 能輕鬆實現漸進式使用者體驗](https://ethanhuang13.plus/local-ai-series-stream-response/) - 2025-12-12: [🚦iOS 本地 AI：用 PromptBuilder 動態組合 Foundation Models 的 Prompt](https://ethanhuang13.plus/local-ai-series-foundation-models-prompt-builder/) - 2025-12-11: [🍱iOS 本地 AI：用 Structured Output 功能讓 Foundation Models 回傳你想要的型別](https://ethanhuang13.plus/local-ai-series-foundation-models-structured-output/) - 2025-12-10: [🉑iOS 本地 AI：Foundation Models 的 Availability 與 Instructions](https://ethanhuang13.plus/local-ai-series-foundation-models-availability-instructions/) - 2025-12-09: [✍️iOS 本地 AI：上手 Foundation Models 的學習策略](https://ethanhuang13.plus/local-ai-series-foundation-models-hands-on/) - 2025-12-08: [🍎iOS 本地 AI：開發者的 Apple Intelligence 必要知識](https://ethanhuang13.plus/local-ai-series-apple-intelligence-intro/) - 2025-12-05: [👍iOS 本地 AI：講優點要看是跟誰講](https://ethanhuang13.plus/local-ai-series-advantage-by-user-type/) - 2025-12-04: [🧃iOS 本地 AI：試試看 Apple 的語音辨識模型](https://ethanhuang13.plus/local-ai-series-apple-asr/) - 2025-12-03: [🗣️iOS 本地 AI：從體驗語音轉文字模型開始](https://ethanhuang13.plus/local-ai-series-try-whisper-asr/) - 2025-12-02: [🛜iOS 本地 AI：誰規定 AI 一定要連網才能用？](https://ethanhuang13.plus/local-ai-series-why-online/) - 2025-12-01: [🚚iOS 本地 AI：為什麼我想寫？為什麼你該上車？（免費公開）](https://ethanhuang13.plus/local-ai-series-intro/) ### 11月 - 2025-11-28: [🗓️發文平台調整公告與 2025 年 11 月主題回顧（免費公開）](https://ethanhuang13.plus/monthly-review-2025-11/) - 2025-11-27: [🉐Black Friday 優惠開跑與 iOS 本地端 AI 系列預告（免費公開）](https://ethanhuang13.plus/2025-black-friday-local-ai/) - 2025-11-26: [💻MacBook Air，Air 得好](https://ethanhuang13.plus/macbook-air-real-utility/) - 2025-11-25: [🧽新機感：好，買了 iKlear 清潔組](https://ethanhuang13.plus/ok-buyla-iklear/) - 2025-11-24: [📲好，買了 TechWoven](https://ethanhuang13.plus/ok-buyla-techwoven/) - 2025-11-21: [🔌好，買了 Apple 動態 60W 充電器](https://ethanhuang13.plus/ok-buyla-apple-dynamic-adapter-60w/) - 2025-11-20: [🧑‍🎓Apple 學生開發者比賽最新消息](https://ethanhuang13.plus/maic-swift-student-challenge-2026/) - 2025-11-19: [😵‍💫macOS 26 支援車輛動態提示](https://ethanhuang13.plus/mac-vehicle-motion-cues/) - 2025-11-18: [🧐Xcode 26.1 的 Release Notes 去哪了](https://ethanhuang13.plus/xcode-26-1-release-notes-missing/) - 2025-11-17: [🌏2026 亞洲 iOS 研討會蓄勢待發](https://ethanhuang13.plus/asia-ios-conferences-2026/) - 2025-11-14: [📺13 的 iOS 演講與教學影片](https://ethanhuang13.plus/ios-talks-and-teaching-videos/) - 2025-11-13: [⚡️App 效能研討會重點整理：成為 SwiftUI Instruments 高手](https://ethanhuang13.plus/optimze-your-app-speed-efficiency-20251031/) - 2025-11-12: [🌏Apple 官方開發者活動形式變化觀察](https://ethanhuang13.plus/apple-developer-youtube-relation/) - 2025-11-11: [⚠️防微杜漸：別對 Xcode 警告視而不見](https://ethanhuang13.plus/eliminate-xcode-warning-discipline/) - 2025-11-10: [📰公告：13+ 將新增「Apple 開發者新知與評論」（免費公開）](https://ethanhuang13.plus/upgrade-apple-developer-news-commentary/) - 2025-11-07: [🤖用 AI 工具分析我對 AI 工具的觀點──我的 AI 工具使用現況（2025 年 10 月）](https://ethanhuang13.plus/my-ai-tools-usage-202510-claude-summary/) - 2025-11-06: [🤖Claude Code 也推坑你訂閱 13+](https://ethanhuang13.plus/claude-code-recommend-13-plus/) - 2025-11-05: [💡我的 Xcode 推薦設定](https://ethanhuang13.plus/xcode-recommend-settings/) - 2025-11-04: [📐善用 Xcode 內建的 swift-format 減少團隊溝通成本](https://ethanhuang13.plus/swift-format-for-team-consistency/) - 2025-11-03: [🐺iOS 開發補完計畫 #5 Swift Macros 信任警告與警報疲勞（免費公開）](https://ethanhuang13.plus/swift-macros-skip-validation-fatigue/) ### 10月 - 2025-10-31: [🗓️2025 年 10 月主題回顧（免費公開）](https://ethanhuang13.plus/monthly-review-2025-10/) - 2025-10-30: [🔦容錯](https://ethanhuang13.plus/room-for-error/) - 2025-10-29: [🧪試錯](https://ethanhuang13.plus/trial-and-error/) - 2025-10-28: [😴穩定的體驗](https://ethanhuang13.plus/stability-is-long-term-value/) - 2025-10-27: [🗾遲來的休假](https://ethanhuang13.plus/never-late-to-plan-vacation/) - 2025-10-24: [💻我夢想中的 MacBook（免費公開）](https://ethanhuang13.plus/my-dream-macbook/) - 2025-10-23: [🖥️練習用 SwiftUI 畫 Mac mini：總結篇](https://ethanhuang13.plus/learning-swiftui-macmini-summary/) - 2025-10-22: [🖥️打造屬於自己的工作桌面](https://ethanhuang13.plus/build-your-own-workspace/) - 2025-10-21: [🧱減少開發者職業傷害，請買手機架](https://ethanhuang13.plus/reduce-developer-pain-with-phone-stand/) - 2025-10-20: [🖥️練習用 SwiftUI 畫 Mac mini：底部](https://ethanhuang13.plus/learning-swiftui-macmini-bottom-view/) - 2025-10-17: [🖥️練習用 SwiftUI 畫 Mac mini：正面](https://ethanhuang13.plus/learning-swiftui-macmini-front-view/) - 2025-10-16: [💸一些你已經付了錢，卻沒用到的功能](https://ethanhuang13.plus/unused-paid-features-you-already-have/) - 2025-10-15: [🖥️練習用 SwiftUI 畫 Mac mini：從俯視角開始](https://ethanhuang13.plus/learning-swiftui-macmini-top-view/) - 2025-10-14: [💻學習 SwiftUI：為什麼從畫 Mac 開始？](https://ethanhuang13.plus/learning-swiftui-mac-layout-practice/) - 2025-10-13: [⚠️iOS 開發補完計畫 #4 開啟支援 iPad 只有一次機會（免費公開）](https://ethanhuang13.plus/ios-missing-manual-ipad-support-rule/) - 2025-10-10: [🐜推坑《空洞騎士》與《絲之歌》的三個理由](https://ethanhuang13.plus/mac-gaming-hollow-knight-silksong/) - 2025-10-09: [🕳️Xcode 開啟資料夾會開成什麼？教學現場踩到的開發坑](https://ethanhuang13.plus/xcode-open-folder-pitfall/) - 2025-10-08: [🪟管理 SwiftUI Preview 視窗的超實用技巧](https://ethanhuang13.plus/swiftui-preview-window-management/) - 2025-10-07: [💡小知識：Apple 裝置 UDID 拼湊規則](https://ethanhuang13.plus/apple-device-udid-chip-ecid/) - 2025-10-06: [🤖如果這篇文章的讀者是 AI……](https://ethanhuang13.plus/when-reader-is-ai/) - 2025-10-03: [🔄不靠套件，輕鬆跨裝置同步 Cursor 與 VS Code 設定](https://ethanhuang13.plus/sync-vscode-cursor-settings-symlink/) - 2025-10-02: [🤖用得更省、用得更巧──我的 AI 工具使用現況（2025 年 9 月）](https://ethanhuang13.plus/my-ai-tools-usage-202509/) - 2025-10-01: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：求知策略與總結](https://ethanhuang13.plus/iphone-usb-speed-series-conclusion/) ### 9月 - 2025-09-30: [🗓️13+ 使用指南與 2025 年 9 月主題回顧（免費公開）](https://ethanhuang13.plus/monthly-review-2025-09-usage-guide/) - 2025-09-29: [💡開發好習慣：閱讀 Release Notes](https://ethanhuang13.plus/dev-habit-read-release-notes/) - 2025-09-26: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：AI 模型需要高速傳輸](https://ethanhuang13.plus/iphone-usb-ai-model-new-challenge/) - 2025-09-25: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：示範常見開發情境](https://ethanhuang13.plus/iphone-usb-speed-demo-devicesupport-debugging/) - 2025-09-24: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：實測 USB 速率的方法](https://ethanhuang13.plus/iphone-usb-speed-measurement-with-usbmuxd/) - 2025-09-23: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：如何得知連線速率](https://ethanhuang13.plus/iphone-usb-speed-measure-usb-and-network/) - 2025-09-22: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：前言（免費公開）](https://ethanhuang13.plus/iphone-usb-speed-intro/) - 2025-09-19: [➕13+ 一週年，開始你的每天五分鐘啟發之旅（免費公開）](https://ethanhuang13.plus/13-plus-get-started-daily-5min-journey/) - 2025-09-18: [🗓️13+ 挑戰每日更新對你我的意義](https://ethanhuang13.plus/13-plus-daily-challenge/) - 2025-09-17: [🎂13+ 滿一週年了！感謝老朋友](https://ethanhuang13.plus/13-plus-one-year-love-you-three-lessons/) - 2025-09-16: [✨Swift Dependencies 的語法靈感來自 SwiftUI Environment](https://ethanhuang13.plus/swift-dependencies-environment-syntax/) - 2025-09-15: [📦解決 SwiftSyntax 編譯超慢的問題](https://ethanhuang13.plus/prebuilt-swiftsyntax/) - 2025-09-12: [💸iOS 26 就要來了，準備好了嗎？](https://ethanhuang13.plus/ios-26-iphone-17-launch-reminder/) - 2025-09-11: [🌬️從 Apple 2025 年 9 月發表會聊聊「升級感」](https://ethanhuang13.plus/apple-2025-sep-event-cost-feeling-value/) - 2025-09-10: [🔀UUID 的隨機特性很好，測試的困難就交給 Swift Dependencies](https://ethanhuang13.plus/swift-dependencies-control-uuid/) - 2025-09-09: [🕕時間看似單純，但很難測試，靠 Swift Dependencies 來救](https://ethanhuang13.plus/swift-dependencies-control-date/) - 2025-09-08: [📦套件推坑：Swift Dependencies 超讚。它解決了哪些問題？](https://ethanhuang13.plus/swift-dependencies-why/) - 2025-09-05: [🤝研討會系列文章整理（免費公開）](https://ethanhuang13.plus/conference-series-wrap-up/) - 2025-09-04: [🇯🇵iPlayground 與日本 iOS 研討會的跨國火花（免費公開）](https://ethanhuang13.plus/iplayground-japan-connection/) - 2025-09-03: [📖為什麼現在是學習 TCA 的最好時機？](https://ethanhuang13.plus/why-learn-tca-now/) - 2025-09-02: [🗜️只給我講 20 分鐘？限制條件反而成就佳作](https://ethanhuang13.plus/constraints-create-excellence/) - 2025-09-01: [💪為何我選擇「個人軟體時代」作為 iPlayground 閉幕題目（免費公開）](https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/) ### 8月 - 2025-08-29: [😇做好準備，讓研討會更好玩（免費公開）](https://ethanhuang13.plus/iplayground-2025-preparation-tips/) - 2025-08-28: [👋不擅長社交工程師的研討會生存小技巧](https://ethanhuang13.plus/conference-social-tips/) - 2025-08-27: [📲iPlayground 開源 App 背景故事（免費公開）](https://ethanhuang13.plus/iplayground-open-source-app-story/) - 2025-08-26: [😇參加研討會的三個小故事](https://ethanhuang13.plus/tech-conference-memorable-stories/) - 2025-08-25: [😇為什麼要參加技術研討會](https://ethanhuang13.plus/why-attend-tech-conferences/) - 2025-08-22: [🤝與 AI 進行建設性溝通](https://ethanhuang13.plus/constructive-communication-with-ai/) - 2025-08-21: [🤖我的 AI 工具使用現況（2025 年 8 月）](https://ethanhuang13.plus/my-ai-tools-usage-202508/) - 2025-08-20: [🚀採取行動才能改變狀態](https://ethanhuang13.plus/change-state-by-action/) - 2025-08-19: [🧩拆分任務到可以執行的程度](https://ethanhuang13.plus/breakdown-to-doable/) - 2025-08-18: [🤔計畫模式不是 AI 專屬的用法](https://ethanhuang13.plus/plan-mode-like-a-pro/) - 2025-08-15: [🔍追求否定意見，降低犯錯風險](https://ethanhuang13.plus/negative-feedback-reduces-errors/) - 2025-08-14: [🔧打造快速回饋系統是值得的投資](https://ethanhuang13.plus/build-feedback-systems/) - 2025-08-13: [🔄快速得到回饋是高效率學習的關鍵](https://ethanhuang13.plus/learning-from-quick-feedback/) - 2025-08-09: [🔄心中有答案，只差說出來](https://ethanhuang13.plus/talk-it-out-self-reflection/) - 2025-08-06: [🚀重大更新：iOS Developer+ 正式更名為「13+」（免費公開）](https://ethanhuang13.plus/rebrand-13-plus/) ### 7月 - 2025-07-30: [🤖你的 ChatGPT 裡應該要有個履歷專案](https://ethanhuang13.plus/chatgpt-project-for-resume-writing/) - 2025-07-28: [🧠我把 AI 當成人，是為了減少認知跟學習的負擔](https://ethanhuang13.plus/ai-as-human-mental-model/) - 2025-07-17: [⛰️AI 時代，四件更值得追求的事情](https://ethanhuang13.plus/ai-era-four-things-worth-pursuing/) - 2025-07-14: [🤖我的 AI 工具使用現況（2025 年 7 月）](https://ethanhuang13.plus/my-ai-tools-usage-202507/) ### 6月 - 2025-06-29: [🏃能者過勞：AI 時代的生產力陷阱](https://ethanhuang13.plus/ai-productivity-trap/) - 2025-06-20: [🪧公告：iOS 開發補完計畫改為免費專欄、不定期更新（免費公開）](https://ethanhuang13.plus/ios-missing-manual-free-transition/) - 2025-06-16: [🔥來玩 Claude Code 吧──iOS 開發 AI 輔助工具 #11](https://ethanhuang13.plus/ios-ai-tools-11-lets-claude-code/) - 2025-06-15: [🐣iOS 開發補完計畫 #3 WWDC 是什麼？開發者應該關注哪些重點（免費公開）](https://ethanhuang13.plus/ios-missing-manual-3-what-is-wwdc/) - 2025-06-12: [🛤️我的 WWDC25 新東西試玩路線](https://ethanhuang13.plus/wwdc25-tryout-roadmap/) - 2025-06-06: [🥷WWDC 生存指南 2025 版（免費公開）](https://ethanhuang13.plus/wwdc-survival-guide-2025/) - 2025-06-02: [🧊iOS 開發補完計畫 #2 學寫 App 不會讓你賺大錢，但是絕對值得（商業觀念篇）（免費公開）](https://ethanhuang13.plus/ios-missing-manual-2-reality-still-worthy/) ### 5月 - 2025-05-29: [💻iOS 開發補完計畫 #1 開發環境篇：新手如何選擇開發配備（免費公開）](https://ethanhuang13.plus/ios-missing-manual-1-buy-mac/) - 2025-05-27: [👩‍🎨《光與影：33 號遠征隊》實測在 M3 Max 可玩性高](https://ethanhuang13.plus/expedition-33-mac/) - 2025-05-26: [🔃讓 Agent 透過 XcodeBuildMCP 自行修正錯誤─iOS 開發 AI 輔助工具 #10](https://ethanhuang13.plus/ios-ai-tools-10-xcodebuildmcp/) - 2025-05-24: [🪓訂定目標、拆分任務與追蹤進度─iOS 開發 AI 輔助工具 #9](https://ethanhuang13.plus/use-ai-as-project-tool/) - 2025-05-23: [🐣iOS 開發補完計畫正式啟動（免費公開）](https://ethanhuang13.plus/https-iosdeveloper-plus-ios-missing-manual-launch/) - 2025-05-23: [🐣iOS 開發補完計畫 #0 商業觀念篇：Apple 對開發者的態度是什麼（免費公開）](https://ethanhuang13.plus/ios-missing-manual-0-apple-dev-relationship/) - 2025-05-16: [🎒我用了一年的日常背包都裝些什麼](https://ethanhuang13.plus/my-edc/) - 2025-05-13: [💪開始累積就不會焦慮了](https://ethanhuang13.plus/start-accumulating-to-reduce-anxiety/) ### 4月 - 2025-04-24: [📦讓錯誤不可能發生：Swift Tagged 簡介](https://ethanhuang13.plus/swift-tagged/) - 2025-04-18: [🚲Ａ來的電動腳踏車](https://ethanhuang13.plus/stolen-ebike-of-the-mind/) - 2025-04-13: [🪧近況更新：寫書進度、新官網測試與聊聊新坑](https://ethanhuang13.plus/ios-developerplus-update-writing-site-ideas/) - 2025-04-08: [⌨️學習 SwiftUI 第 4 章：描述式語法──採用實際物體做練習](https://ethanhuang13.plus/learning-swiftui-ch04-declarative-syntax/) - 2025-04-04: [🤔多一點介面設計，少一點設計模式](https://ethanhuang13.plus/api-design-over-patterns/) - 2025-04-03: [📔只做筆記沒有意義](https://ethanhuang13.plus/notes-are-useless-without-action/) - 2025-04-02: [💖學習 SwiftUI 第 3 章：影響學習 SwiftUI 的個人因素](https://ethanhuang13.plus/learning-swiftui-ch03-personal-barriers/) ### 3月 - 2025-03-28: [😵‍💫學習 SwiftUI 第 2 章：SwiftUI 哪裡難學？](https://ethanhuang13.plus/learning-swiftui-ch02-why-hard/) - 2025-03-14: [🤯學習 SwiftUI 第 1 章：為什麼想學 SwiftUI？](https://ethanhuang13.plus/learning-swiftui-ch1-why-want-to-learn/) - 2025-03-13: [🗣️AI 工具小技巧：處理有瑕疵的字幕檔](https://ethanhuang13.plus/ai-tips-fix-subtitles/) - 2025-03-07: [💪如何不因 AI 而焦慮，以及我使用各種 AI 工具的方式](https://ethanhuang13.plus/how-i-use-ai-without-anxiety/) - 2025-03-04: [✍️我為什麼要寫一本學習 SwiftUI 的書呢？（免費公開）](https://ethanhuang13.plus/why-write-learning-swiftui-book/) ### 2月 - 2025-02-25: [🥚我花了一年準備裸辭、後續內容計畫](https://ethanhuang13.plus/one-year-prep-for-quitting/) - 2025-02-24: [🗾你應該要安排休假](https://ethanhuang13.plus/why-taking-vacation-shows-strength/) - 2025-02-03: [❓陣亡率高達 8 成的面試題目─iOS 開發 AI 輔助工具 #8](https://ethanhuang13.plus/tough-ios-interview-question/) ### 1月 - 2025-01-15: [✨iOS 開發 AI 輔助工具 #7：總結一下我做了什麼](https://ethanhuang13.plus/ios-ai-tools-7-summarize/) - 2025-01-13: [☀️為自己寫 Side Project](https://ethanhuang13.plus/build-side-projects-for-yourself/) - 2025-01-06: [🕰️減少滑手機浪費時間的技巧，5 秒鐘就學會](https://ethanhuang13.plus/reduce-phone-time-tips/) - 2025-01-01: [🎆2024 年終回顧與感謝](https://ethanhuang13.plus/2024-year-end-review-thanks/) ## 2024年 ### 12月 - 2024-12-30: [🥇SwiftUI 讀完就入坑 #9 SwiftUI + TCA 專案的模組化最佳實踐](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/) - 2024-12-20: [0️⃣iOS 開發 AI 輔助工具 #6：從零開始](https://ethanhuang13.plus/ios-ai-dev-tools-6-getting-started/) - 2024-12-06: [🧪iOS 開發 AI 輔助工具 #5：我在公司開了一場 Workshop](https://ethanhuang13.plus/ai-tools-workshop-for-ios-team/) - 2024-12-02: [🔃SwiftUI 專欄 #8 連載再開。描述性框架、狀態驅動、TCA](https://ethanhuang13.plus/swiftui-8-tca/) ### 11月 - 2024-11-15: [🤖iOS 開發 AI 輔助工具 #4：評價 AI 工具的一把尺](https://ethanhuang13.plus/ios-ai-tools-4-how-to-evaluate-ai-tools/) - 2024-11-12: [💡Side Projects: 專案與資料夾命名小技巧](https://ethanhuang13.plus/side-projects-naming-tips/) - 2024-11-05: [🗣️Why SwiftUI? Why TCA?─iPlayground 2024 演講投影片](https://ethanhuang13.plus/why-swiftui-why-tca-iplayground-2024-slides/) ### 10月 - 2024-10-31: [🤖iOS 開發 AI 輔助工具 #3：在 VSCode / Cursor 開發 iOS 專案](https://ethanhuang13.plus/ios-ai-tools-3-setup-ios-project-in-vscode-cursor/) - 2024-10-23: [🤖iOS 開發 AI 輔助工具 #2：Xcode 與 Cursor/VSCode 交互使用的絕技](https://ethanhuang13.plus/ios-ai-tools-2-xcode-cursor-vscode-workflow/) - 2024-10-22: [🤖iOS 開發 AI 輔助工具 #1：你信任 AI 嗎？](https://ethanhuang13.plus/ios-ai-tools-1-do-you-trust-ai/) - 2024-10-13: [🤖iOS 開發 AI 輔助工具 #0：自動完成能力，沒有比較就沒有傷害](https://ethanhuang13.plus/ios-ai-tools-0-autocomplete-comparison/) - 2024-10-07: [🤕開發者職業傷害──Dependency 的故事、事故與世故](https://ethanhuang13.plus/developer-injuries-dependency-stories/) - 2024-10-05: [💭用 Mac 試玩「暗喻幻想：ReFantazio」](https://ethanhuang13.plus/metaphor-refantazio-demo-mac/) - 2024-10-02: [🎯找到重要的事、先做重要的事（免費公開）](https://ethanhuang13.plus/prioritize-what-matters-first/) ### 9月 - 2024-09-26: [🔄iOS 開發的年度週期](https://ethanhuang13.plus/ios-development-annual-cycle/) - 2024-09-20: [🧐Swift 6 準備好了嗎？觀察社群動向](https://ethanhuang13.plus/is-swift-6-ready-community-trends/) - 2024-09-19: [🐣Swift 6 正式推出與應對策略](https://ethanhuang13.plus/swift-6-release-and-adoption-strategy/) ### 會員們都怎麼說 URL: https://ethanhuang13.plus/testimony/ Last updated: 2025-09-20T09:42:26.000Z 備註：**13+** 最初的名稱為 **iOS Developer+**。 > 我認識 13 已經非常多年了，他總是很樂意的提供他在任何主題上的觀點。 > > 而在 iOS 開發上，他能夠深入的研究出非常 Apple Style 的原生作法，我非常喜歡這種風格的開發方式。 > > 在前幾年 13 創立了「weak self」Podcast 來討論 iOS 開發相關的技術，也成立了「Apple 開發者週報」讓台灣的開發者們可以用最省力的方式追上最新的消息以及技術，還在 YouTube 上做了「iOS 開發配飯吃」的節目。 > > 用 Twitter 追 iOS 技術這件事情，我也因為 13 在社群大力推廣才開始使用，但我每次跟朋友說我都用 Twitter 在追技術的時候，他們都會露出奇怪的邪笑。 > > 我曾經在當面試官的時候面到2位非常優秀的候選人，我問他們是從哪邊得到這些技術知識的，他們回說是在「weak self」Podcast 上學的。我立刻笑笑地說：「原來我們師出同門」。 > > 同樣做為熱衷在為社群出力的人，我覺得他的付出令我難以望其項背，也擔心他是否會因此 burn out。 > > 幸運地是優秀的人總是可以找到優秀的解法，13 開始籌備「iOS Developer+」付費會員節目，目前節目內容包含但不限於「Swift 6 的應對策略」、「Dependency 的故事」、「Xcode 與 Cursor 的交互絕技」 (原版文章標題過長，請容我縮寫)，這幾篇文章都是我看完之後覺得非常有收獲的內容。 > > 大家平常工作很忙，生活也很忙。如果說要在 iOS 開發上持續精進，我認為訂閱 13 的「iOS Developer+」會員節目，絕對是一個輕鬆且超值的選擇。 > > **──The Host of Cocoaheads TPE - Hanyu, Chen** > iOS Developer+ 是 iOS 開發者的寶藏，生動描繪我們的「開發者日常」。其中的開發 Tips 總是出乎意料的實用，讓人每次閱讀都有新的收穫。我特別推薦給所有 iOS 開發者，這不只是資訊的累積，更是靈感的啟發！ > > ──**Harry Ng** > 在職場上我剛好都是一人團隊、沒有前輩可以帶我，所以常常一個人花時間摸索新技術、獨自面對挑戰，雖然有很大的自主權，但也擔心自己前進的方向是不是正確的，導致自己很焦慮。 > > 而 13 的 iOS Developer+ 剛好就填補了這個角色，13 很知道我們需要什麼（當台灣社群沒有 TCA 的教學影片，配飯吃出現；當工程師為了 AI 焦慮時，心靈文章、AI 應用文章也開始報到了），再加上13 在講解時，會把前因後果描述清楚，常常讓我會有「原來那麼簡單」的驚喜，也因為 13 的影片與文章，我開始在 Side Project 使用 TCA + SwiftUI，並成功說服公司以小範圍融入新專案內，也期待未來能夠完全導入。 > > 我相信無論是資深工程師，又或者是不到一年經歷的新人，都可以在這裡有很多收穫，慢慢撿回能跟上時代的自信。 當前方有一個榜樣可以參考，走得會更踏實，也不那麼焦慮了！ > > ──**Hsun** > 13 是我非常敬佩的開發者。 > > 從好多年前 13 就一直熱心無償的跟大家分享他的心法(iOS 圈跟他一樣樂善好施的人我只看過 Zonble 跟他)。 他的開發經驗不在話下，分享的觸角更是相當地廣。除了大名鼎鼎的 weak self podcast，還錄過 youtube 影片、在台大教課、寫過週報、現在更辭職要專心寫書與你現在正在看的這個專欄。 他的文章我從小看到大😎，品質令人非常放心，而且又很好讀，就像一個朋友在跟你聊天。 甚至訂閱後還可以私下跟他請教(前提當然是不能濫用)，簡直賺爛。 > > 如果你是個 iOS developer，我強烈建議你拿出魔法小卡來換取最新最專業的知識吧。 > > **──MarkFly** [立即訂閱 13+](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus) ## Posts ### 🇯🇵try! Swift Tokyo 2027 開賣超級早鳥票 URL: https://ethanhuang13.plus/2026-09-29-try-swift-2027-super-early-bird/ Last updated: 2026-09-29T11:27:28.000Z 明年的 try! Swift Tokyo 研討會已經開賣超級早鳥票（[購票網站](https://shop.tryswift.jp/?ref=ethanhuang13.plus)），地點跟往年一樣在[立川 TACHIKAWA STAGE GARDEN](https://tryswift.jp/2027/en/?ref=ethanhuang13.plus#access)。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/09/image-8F6A3AD1-D65E-458E-AA79-58E8DAB4B718.png) 不過，明年想順便看櫻花的朋友可能要留意一下： - 2025 年辦在 4/9\~11，剛好舉辦地點還有櫻花 - 今年是 4/12\~14，東京的櫻花已經開得差不多了 - **明年則是 3/2\~4，遠早於東京櫻花季** 還有，如果沒參加過的話，提醒一下，**立川離東京都圈有一段距離**，訂旅館時請留意。 ## 台灣參加者群組 try! Swift Tokyo 應該是近年最多台灣人參加的外國 Apple 開發者研討會了。 這幾年從台灣去參加，加上在日本工作的台灣人參加者，都超過 20 位。 _This post is for paying subscribers only._ ### 🌏善用 App Store 網頁版 URL: https://ethanhuang13.plus/app-store-web/ Last updated: 2026-09-29T11:13:35.000Z 這不是新知（2025 年 11 月推出），但我想很多 Apple 開發者不懂得好好利用：**App Store 的網頁版**。 _This post is for paying subscribers only._ ### ⚡️SF Symbols 27 內建 CLI URL: https://ethanhuang13.plus/2026-09-27-sf-symbols-cli/ Last updated: 2026-09-27T11:32:49.000Z 讓 coding agent 不再誤用不存在的 symbol 名稱。 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #269 iPhone Duo 特輯 URL: https://ethanhuang13.plus/dev-news-268-iphone-duo/ Last updated: 2026-09-24T08:24:29.000Z ## 13 的話 感謝讀者，⟪13報+⟫滿兩週年了！週年優惠請參考[這篇文章](https://ethanhuang13.plus/13-plus-two-year-love-you/)。 iPhone Duo 將在 10/23 於台灣上市。這是從 iPhone X 推出以來，iOS 開發者最新的 app 版面挑戰。 iPhone Duo 有 6 種使用型態：**折疊、桌曆、橫拿全開、橫拿半開、直拿展開、直拿半開**。每種型態要考慮的 Safe Area 都不同，而且使用者可以隨時在不同型態之間切換。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/09/CleanShot-2026-09-24-at-5.10.24-PM@2x.webp) [HIG: Designing for iPhone Duo](https://developer.apple.com/design/human-interface-guidelines/designing-for-iphone-duo?ref=ethanhuang13.plus) 這比 app 支援 iPad 需要考慮動態視窗尺寸，更難上一階。 Apple 官方已經推出 Tech Talks、文件，以及 Xcode 27.1 beta、agent skill 與 iPhone Duo 模擬器，開發者已經有足夠的資源去支援。 > **教你的 agent 一個小技巧**：現在在 Apple 官方文件的網頁後面加上 `.md`，就會看到 Markdown 版本喔。例如這個 [Release Notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-27%5F2-release-notes.md?ref=ethanhuang13.plus)。 你可以直接叫 agent 安裝 Xcode 27.1 內建的 [App Resizability skill](https://x.com/squeakytoy/status/2101035933588132233?ref=ethanhuang13.plus)，直接改出支援 iPhone Duo 的版本試試看。 **歡迎**[**升級到⟪13報+⟫**](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/09/24** ## ‼️新聞標題：如何支援 iPhone Duo ### 兩款 Xcode Beta 請注意，Apple 先推出了 [Xcode 27.2 Beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-27%5F2-release-notes?ref=ethanhuang13.plus)，不支援 iPhone Duo。 後來才推出 [Xcode 27.1 Beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-27%5F1-release-notes?ref=ethanhuang13.plus)，包含 iPhone Duo 模擬器。 數字是顛倒的，請別弄錯了。 ### Tech Talks 請參考 Apple 官方影片。 - [Prepare your app for iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111461/?ref=ethanhuang13.plus) - [Design for iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111466/?ref=ethanhuang13.plus) - [Strike a pose with adaptive layouts on iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111463/?ref=ethanhuang13.plus) - [Raise the bar with iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111462/?ref=ethanhuang13.plus) - [Build a great camera experience for iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111465/?ref=ethanhuang13.plus) - [Leverage multiple displays and scenes on iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111464/?ref=ethanhuang13.plus) 另外還有一些 Group Labs 的影片： - [iPhone Duo Group Lab | 9/16/26 | Meet with Apple](https://www.youtube.com/watch?v=0zp4gAgC6TI&ref=ethanhuang13.plus) - [iPhone Duo Group Lab | 9/17/26 | Meet with Apple](https://www.youtube.com/watch?v=zAaPDbDKvaU&ref=ethanhuang13.plus) ### 設計資源 - HIG: [Designing for iPhone Duo](https://developer.apple.com/design/human-interface-guidelines/designing-for-iphone-duo?ref=ethanhuang13.plus) - 官方 [Design Resources](https://developer.apple.com/design/resources/?ref=ethanhuang13.plus) 已包含 iPhone Duo ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/09/CleanShot-2026-09-23-at-7.54.18-PM@2x.webp) iOS 27 and iPadOS 27 Figma - iPhone Duo Safe Area Insets, Margins, and Reserved Region ## 🍎Apple 公司、產品、活動消息 ### 9/22 [新款 Mac mini 與 Mac Studio 今日正式發售](https://www.apple.com/tw/newsroom/2026/09/the-new-mac-mini-and-mac-studio-are-available-today/?ref=ethanhuang13.plus) 身為 Apple silicon Mac 愛好者，從 A12Z DTK、M1\~M5、A18 Pro(MacBook Neo) 都買過的我，對於這代 M6 非常有興趣。理由也很多： 1. Apple 第一款 2nm 製程的 Mac SoC 2. CPU 單核心王者，日常使用體驗會非常靈敏（根據 [Alex Ziskind 的測試](https://youtu.be/T15BuMPZW4Q?t=168&ref=ethanhuang13.plus)，Speedometer 3.1 高達 73 分！） 3. CPU 多核心跟 M4 Pro 或 M3 Max 14 核心差不多（請參考 [XcodeBenchmark](https://github.com/devMEremenko/XcodeBenchmark?ref=ethanhuang13.plus) 與[這裡](https://youtu.be/T15BuMPZW4Q?t=283&ref=ethanhuang13.plus)） 4. GPU 核心比 M5 多一個，拉開差距。部分場合與 M4 相比幾乎翻倍，而且每個都有神經網路加速單元 5. ANE 數量翻倍 6. 據說 M6 跳過 Pro/Max，所以算是一個特別的過渡期版本 更多性能測試請參考[极客湾影片](https://www.youtube.com/watch?v=zPJw2f8zJlg&ref=ethanhuang13.plus)。 至於 Mac Studio 呢？我也很想買，但我需不需要呢？那倒是不見得。 ### 9/18 iPhone 18 Pro、新款 Apple Watch 與 AirPods 5 上市 - [全球上市新聞稿](https://www.apple.com/tw/newsroom/2026/09/the-latest-iphone-apple-watch-and-airpods-lineups-arrive-in-stores-worldwide/?ref=ethanhuang13.plus) - [iPhone 18 Pro](https://www.apple.com/tw/newsroom/2026/09/apple-debuts-iphone-18-pro-and-iphone-18-pro-max/?ref=ethanhuang13.plus) - [AirPods 5](https://www.apple.com/tw/newsroom/2026/09/apple-introduces-airpods-5-featuring-best-in-class-open-ear-active-noise-cancellation/?ref=ethanhuang13.plus) - [Apple Watch Series 12](https://www.apple.com/tw/newsroom/2026/09/introducing-apple-watch-series-12-with-the-all-new-health-sensing-system/?ref=ethanhuang13.plus), [Ultra 4](https://www.apple.com/tw/newsroom/2026/09/apple-unveils-apple-watch-ultra-4/?ref=ethanhuang13.plus) - [iPhone Duo](https://www.apple.com/tw/newsroom/2026/09/apple-unveils-iphone-duo/?ref=ethanhuang13.plus) ### 9/14 iOS 27 正式上市 - [Apple 軟體平台重大更新，現已推出](https://www.apple.com/tw/newsroom/2026/09/major-updates-for-apples-software-platforms-are-now-available/?ref=ethanhuang13.plus)：Safari 有個「描述延伸功能」能自己做瀏覽器延伸工具，可以玩玩看 - [新一代 Apple Intelligence 今日推出](https://www.apple.com/tw/newsroom/2026/09/next-generation-of-apple-intelligence-available-today/?ref=ethanhuang13.plus) ### 9/9 Apple 新產品發表會 - [iPhone 18 Pro 和 iPhone 18 Pro Max](https://www.apple.com/tw/newsroom/2026/09/apple-debuts-iphone-18-pro-and-iphone-18-pro-max/?ref=ethanhuang13.plus) - [iPhone Duo](https://www.apple.com/tw/newsroom/2026/09/apple-unveils-iphone-duo/?ref=ethanhuang13.plus) - [Apple Watch Series 12](https://www.apple.com/tw/newsroom/2026/09/introducing-apple-watch-series-12-with-the-all-new-health-sensing-system/?ref=ethanhuang13.plus)、[Apple Watch Ultra 4](https://www.apple.com/tw/newsroom/2026/09/apple-unveils-apple-watch-ultra-4/?ref=ethanhuang13.plus) 新的感測系統大幅提高了心率與 HRV 的偵測頻率，對於我的 [todayOS](https://today-os.app/?ref=ethanhuang13.plus) app 有影響，所以只能買了！ - [AirPods 5](https://www.apple.com/tw/newsroom/2026/09/apple-introduces-airpods-5-featuring-best-in-class-open-ear-active-noise-cancellation/?ref=ethanhuang13.plus) ## 👨‍💻Apple 開發者消息 - 9/15 [Swift 6.4 Released](https://www.swift.org/blog/swift-6.4-released/?ref=ethanhuang13.plus) - 9/23 Apple 推出開源模型 [LensVLM-9B](https://github.com/apple-aiml-research/ml-lensvlm?ref=ethanhuang13.plus) ## 🤝社群與媒體消息 **iPhone 18 Pro (A20 Pro) 測試** - 9/17 极客湾：[iPhone18 Pro性能分析：五年来最强的芯片升级！](https://www.youtube.com/watch?v=DpDf5JKOtls&ref=ethanhuang13.plus) **Mac Studio M5 測試** - 9/21 MacStories: [M5 Ultra Mac Studio Review: The Dream Mac for Local AI Agents](https://www.macstories.net/stories/m5-ultra-mac-studio-review-the-dream-mac-for-local-ai-agents/?ref=ethanhuang13.plus) 很棒的一篇 M5 Ultra 跑本地 AI 實際效果的文章 - 9/23 Alex Ziskind: [M5 Ultra… Apple Wasn’t Messing Around](https://www.youtube.com/watch?v=c%5F58D7ixOQI&ref=ethanhuang13.plus) **Mac mini M6 測試** - 9/21 Dave2D: [2026 Mac Mini - CRAZY FAST! (M5 Pro / M5 Ultra)](https://www.youtube.com/watch?v=dDVsNmiSzwQ&ref=ethanhuang13.plus) - 9/22 Alex Ziskind: [The M6 Mac mini Had Me Checking My Numbers](https://www.youtube.com/watch?v=T15BuMPZW4Q&ref=ethanhuang13.plus) 我也有被[這個 Speedometer 分數](https://youtu.be/T15BuMPZW4Q?t=159&ref=ethanhuang13.plus)嚇到 - 9/22 极客湾：[Mac mini M6性能测试：核心更多了，性能强多少？](https://www.youtube.com/watch?v=zPJw2f8zJlg&ref=ethanhuang13.plus) - 9/22 Expand Mac mini: [Mac mini M6 and M5 Pro: the storage is soldered again](https://expandmacmini.com/blogs/news/mac-mini-m6-m5-pro-soldered-storage?ref=ethanhuang13.plus) 這代不能像 M4 一樣自己換 SSD 了，[那個美好年代已經過去](https://x.com/ethanhuang13/status/2102317103240163823?ref=ethanhuang13.plus) **Apple Watch Ultra 4** - 9/22 13: [新款手錶充電線有變快，別捨不得拿出來用](https://x.com/ethanhuang13/status/2102292505878532386?ref=ethanhuang13.plus) - 9/23: 13: [新款手錶的心率與 HRV 紀錄頻率大幅提升](https://x.com/ethanhuang13/status/2102688074975318432?ref=ethanhuang13.plus) **iPhone Duo 應用展示** - 9/21 Nathan Walker: [iPhone Duo 吉他效果 app](https://x.com/wwwalkerrun/status/2101827019847946576?ref=ethanhuang13.plus) - 9/21 Florent Morin: [一些好玩的 iPhone Duo 折疊角度應用展示](https://x.com/florentmorin/status/2101959171633508777?ref=ethanhuang13.plus) **社群動態** - 9/10 Shopify: [Native is now the future of mobile at Shopify](https://shopify.engineering/back-to-native?ref=ethanhuang13.plus) 當年大力擁抱 React Native 的 Shopify，如今決定全面回歸原生。當初的決定他們覺得沒錯，而現在的轉變，當然跟AI 有關。我第一次成功把 iOS 專案轉成 Android app 時，就感覺到跨平台框架的必要性下降，Shopify 的這篇文章支持了我的看法 - 9/21 [iPlayground 2026 活動回顧](https://iplayground.substack.com/p/2026-review) 沒想到「財務狀況、投稿錄取標準、我們怎麼使用 AI 來辦活動」都這麼[公開透明](https://speakerdeck.com/hokila/iplayground-2026-kaiko?ref=ethanhuang13.plus)。還有[贊助商結案報告](https://speakerdeck.com/hokila/iplayground-2026-zan-zhu-shang-jie-an-bao-gao?ref=ethanhuang13.plus)。也歡迎[填表單](https://forms.gle/L5f4oQB1uXPvwWvJ8?ref=ethanhuang13.plus)加入 2027 的工作人員 - 9/22 [oMLX 開發者 Jun Kim 加入 Hugging Face](https://x.com/jundotkim/status/2102290056186884442?ref=ethanhuang13.plus) ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 ### [13報+](https://ethanhuang13.plus/) - [🎂感謝讀者，⟪13報+⟫要滿兩週年了！](https://ethanhuang13.plus/13-plus-two-year-love-you/) 限時的年費方案，13% 優惠，已經開放，將於 9/30 截止 ### 📣徵才/求職/接案專區 - [Terry Chen 的 LinkedIn](https://www.linkedin.com/in/terry-chen-3350a681/?ref=ethanhuang13.plus) 10 年 iOS 經驗、4 年以色列跨國協作，主導百萬下載 App；AI 系統化開發與持續最佳化。個人開發「[垃圾車 App](https://apps.apple.com/app/apple-store/id1527915502?pt=118436878&ct=13&mt=8&ref=ethanhuang13.plus)」，累積 9,000+ 使用者好評。 如果你有 iOS 開發相關**職缺**或是**求職履歷**想要刊登在開發者週報，請見[關於](https://www.ethanhuang13.com/about?ref=ethanhuang13.plus)。 ## ⟪13報+⟫關於 Apple CEO 交接，我的一點評論 _This post is for subscribers only._ ### 🎂感謝讀者，⟪13報+⟫要滿兩週年了！ URL: https://ethanhuang13.plus/13-plus-two-year-love-you/ Last updated: 2026-09-14T12:23:42.000Z 親愛的讀者， 時間過得很快，⟪13報+⟫專欄開設即將滿兩週年了。謝謝你長久以來的支持。 有幾件重要的事情提醒會員，先說重點： 1. 13+ 已經正式改名為**⟪13報+⟫** 2. **限時的年費方案，13% 優惠**，已經開放，將於 **9/30** 截止 3. ⚠️請留意：如果你去年訂閱了年費方案、沒有取消，但今年**想改成月費，請務必在續約日期之前，到** [**Patreon 後台**](https://www.patreon.com/settings/memberships?ref=ethanhuang13.plus)**調整訂閱設定**。[Patreon 官方文件說](https://support.patreon.com/hc/en-us/articles/360042152671-Annual-membership-details?ref=ethanhuang13.plus#h%5F01HE2NA78WP4WSSWGRDA2460TB)，**需要先取消訂閱，等到期了再重新訂閱月費方案** 4. 年度文章回顧、新系列預告，寫在最後面 ## 「13+」改名⟪13報+⟫ 讀者可能有留意到，最近幾個月，我都把「13+」稱之為⟪13報+⟫。這是因為在 [ethanhuang13.plus](https://ethanhuang13.plus/) 這個網站是我的寫作主力，但是原本的 [ethanhuang13.com](https://ethanhuang13.com/?ref=ethanhuang13.plus) 的⟪13報⟫累積的讀者更多，我一直想做**整合**。 要把兩邊的會員系統、電子報系統整合，還需要一些時間。所以，先把名稱統一，希望讓人更容易從名稱看出來──**⟪13報+⟫就是⟪13報⟫的進階版**。 後續的整合，我再慢慢調整，總之不會影響到付費會員的權益，請放心。 ## 年費方案限時推出 去年 13+ 滿一週年的時候，我有推出[限時的年費方案活動](https://ethanhuang13.plus/13-plus-get-started-daily-5min-journey/)，並進行每週一到五更新的挑戰。 限時的原因很簡單：要承諾繼續寫一整年，才敢預先收一整年費用。 結果，第二年寫出來的文章比第一年更多。 從第一篇文章 2024/09/19 算起，第一年寫了 84 篇，第二年到現在寫了 151 篇。 不含這篇，總共累積了 235 篇，所有文章可以在[目錄](https://ethanhuang13.plus/index/)看到。 第二年的 151 篇當中，大部分是前面幾個月每日挑戰的集中發文，也有一些[短篇抒發](https://ethanhuang13.plus/tag/lightning-talk/)（原本稱為極短篇），平均來說我大概每 2.4 天就發表一篇文章。 從 8 月中開始的每週一到五更新挑戰，最後的結果：持續約 20 週、寫了 99 篇文章，其中連續 97 個平日沒有中斷。這是一個成功的挑戰，也自我證明了能連續寫文章。 不過，我應該不會再挑戰一次了啦，哈哈。現在的開發與教學工作，也變得比以前更忙。 但是，我還是非常看重親自持續寫作的意義。或者說，就是因為有好多事情要做，所以我需要寫作這個管道。 寫作讓我能： - 把事情想得更清楚、研究得更透徹 - 從密集開發的工作之外，減速、抽離 - 記錄當時的想法 此外，寫作是我在這個程式碼已非自己產出的時代，保持最有**掌控感**的事情。 所以，讓我們開始⟪13報+⟫的第三年吧！ **年費訂閱方案，折扣 13%，限時開放，只到 9/30 。** 👉[請到 Patreon 調整方案](https://www.patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus)。 以下是各月主題與重點回顧。 ## ⟪13報+⟫第二年文章主題回顧 9 月底開始的[⚡️探究 iPhone 的 USB 速度對開發體驗的影響](https://ethanhuang13.plus/tag/iphone-usb-speed-series/)專題，是個我很喜歡的系列。把研究過程寫出來，展示我的[求知策略](https://ethanhuang13.plus/iphone-usb-speed-series-conclusion/)。 10 月初先寫了一些小技巧，接著是用[🖥️ 練習用 SwiftUI 畫 Mac mini](https://ethanhuang13.plus/tag/learning-swiftui-draw-mac-mini-series/) 系列。現在用 AI 開發，很少自己寫程式了，但我覺得拿 SwiftUI 來畫畫仍然是很有趣的嘗試。 11 月，前面我寫了一些坑點提醒，像是 [Macros 警報疲勞](https://ethanhuang13.plus/swift-macros-skip-validation-fatigue/)、[消除 Xcode 警告的好習慣](https://ethanhuang13.plus/eliminate-xcode-warning-discipline/)。11 月中，把 Apple 開發者週報的發表也[整合](https://ethanhuang13.plus/upgrade-apple-developer-news-commentary/)進來。還寫了幾篇[亞洲地區 iOS 研討會](https://ethanhuang13.plus/asia-ios-conferences-2026/)、[學生開發者活動](https://ethanhuang13.plus/maic-swift-student-challenge-2026/)的消息。月底則是[勸敗單元](https://ethanhuang13.plus/tag/ok-buyla/)連發。 12 月，我開始研究與介紹 [iOS 裝置端 AI](https://ethanhuang13.plus/tag/local-ai/)。契機是在籌備臺大蘋果區域培訓中心的工作坊時，發現 **Foundation Models 跑在 A19 Pro 的 iPhone 17 Pro Max，居然比 M3 Max 的 MacBook Pro 還要快**（見[系列發起文](https://ethanhuang13.plus/local-ai-series-intro/)）。我意識到 Apple 硬體在裝置端的優勢與被低估，所以決定花一整個月的篇幅介紹。隨著 iOS 27 的推出、Foundation Models framework 的改版，有些資訊已經過時。但我仍覺得是非常值得複習的系列專題。那些研究，也間接促成了我近期開始的 [LIKit(Local Intelligence Kit) 專案](https://likit.dev/?ref=ethanhuang13.plus)。 這個系列的完結，也結束了 20 週的工作日更新、總共 99 篇的挑戰。 今年 1 月，我開啟了一個叫做 [13 的 brainOS](https://ethanhuang13.plus/tag/brain-os/) 的系列專題。本來是想借用軟體工程概念談思考、觀念。像是[🌋其實你不是在拖延，而是在載入中](https://ethanhuang13.plus/my-brain-os-cold-start/)、[💼工作模式 sandbox](https://ethanhuang13.plus/my-brain-os-work-from-home-mode-switch/)。不過這個系列並沒有寫出太多文章，因為當時 OpenClaw 的推出，吸走了我不少注意力。 2 月我進入休假模式，於是用自己開發的[後台 App](https://ethanhuang13.plus/2026-02-09-should-have-built-earlier/)，直接在手機上寫出了不少的[短篇](https://ethanhuang13.plus/tag/lightning-talk/)。有的時候寫作需要專注在一個環境，有的時候則是透過這種低摩擦力的機制，反而能有不少產出。 3 月份，我覺得最重要的一篇短文是：[⚡️如果 AI 只要一秒鐘就能完成指示](https://ethanhuang13.plus/2026-03-02-ai-speed-philosophy/)。我現在還是常常會做相關的思考。例如：我在用 Codex 開發時，究竟是要開快速模式、儘快把事情做完，還是用普通模式就好？許多人似乎都在追求「不要把 token 用量用完」，或是趁 Tibo 宣布即將 Reset 之前，加速開發。但更重要的，難道不是做對的事情、並在適當的時間完成嗎？ 另一篇重點則是[⚡️基本功：閱讀第一手技術資料](https://ethanhuang13.plus/2026-03-25-basic-skill-reading-first-hand-docs/)。雖然我現在很常叫 AI 做各種技術性的探索與研究，但我日常在閱讀文件的時間仍舊不少。有些知識還是得存在自己的腦袋裡，才能做更好的判斷，不能完全交給 AI。 4 月開始，我的文章數量變少了。因為開始密集開發 [todayOS app](https://today-os.app/?ref=ethanhuang13.plus)。其實是為了 7 月的 [iOS AI Summer Camp](https://ethanhuang13.plus/dev-news-257-ios-ai-camp-preview/) 有實際上架 App Store 的產品可以教，所以才趕在那之前公開測試版、預訂、上架，並且有一定的銷售數據。 5 月我最喜歡的文章是與 MacBook Neo 有關的[🌸買了 MacBook Neo 才知道有這個顏色 API](https://ethanhuang13.plus/macbook-neo-color-api/)與[🎨沒有彩色 Mac 但想使用它們的配色](https://ethanhuang13.plus/mac-accent-color-simluate-hardware-enclosure/)。與其說是喜歡寫出來的文章，不如說是喜歡 Neo 的配色，以及發現配色相關的 API 吧。 6 月有多篇談到 todayOS app 的推出工作，寫了一些[功能介紹與幕後思考](https://ethanhuang13.plus/tag/todayos/)、 月也寫了幾篇上架前的準備工作。老實說[這個系列專題](https://ethanhuang13.plus/app-launch-preparation-part-1/)我還沒有寫完，但至少精華的[新手教學](https://ethanhuang13.plus/app-launch-preparation-part-2-onboarding/)、[架設官網](https://ethanhuang13.plus/app-launch-preparation-part-3-site/)都在 7 月的 Summer Camp 好好教給了學生。 7 月的文章特別少，因為接連著 Summer Camp 與 iPlayground，準備起來實在太耗費心力，[明顯有要 burnout 的感覺](https://ethanhuang13.plus/human-usage-reset/)。但有一篇如果你錯過的話，我還是要強調：[🇹🇼冷知識：台灣是 iOS App Store 第四大市場](https://ethanhuang13.plus/taiwan-top-app-store-market/)。 8 月開始，我談起了開發設備的思考。[💻為什麼 MacBook Neo 成了我的主力電腦](https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/)、[💻MacBook Neo 的真正優點](https://ethanhuang13.plus/macbook-neo-real-benefits/)、[💻為什麼我不再買頂規 MacBook Pro](https://ethanhuang13.plus/why-i-stopped-buying-maxed-out-macbook-pro/)這三篇強調了開發設備的典範轉移：我現在有低階的 MacBook Neo 作為無負擔的隨手帶出門選項，也挑了非頂規的 MacBook Pro M5 當成遠端開發的優秀行動前端。 整年回顧下來，除了 7 月文章數量明顯偏低以外，我是覺得自己寫出了不少好文章，也感謝當時的自己有把重要的想法記錄下來。 ## 下一個系列預告 最後，跟讀者預告我正在撰寫的全新系列── AI 開發很快，但平行開發需要配套。 9 月開始，我架設了自己的 CI 群，讓我能更新並同時開發十幾個專案。 AI 能提升單項任務的開發效率。但如果要同時開發多個專案，光靠開好幾個對話是不夠的。 我會分享我一個人是怎麼做到的。包括開發流程、服務、設備，來展示擴充單人開發的規模需要怎樣的策略。 ## 結語 感謝各位讀者的長期支持。 我有留意到自己常常在文章當中說之後有機會再分享某某東西，結果後面往往就沒機會了。如果有什麼很想要我寫出來或寫完的，不妨來信催促吧！ 一起迎接⟪13報+⟫的第三年吧！ **折扣 13% 的年費訂閱方案，限時開放，只到 9/30 。** 👉[請到 Patreon 調整方案](https://www.patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus)。 ### 📰Apple 開發者週報 #268 LIKit URL: https://ethanhuang13.plus/dev-news-268/ Last updated: 2026-09-09T09:23:41.000Z ## 13 的話 完成了[上次](https://ethanhuang13.plus/dev-news-267-hybrid-ai-workshop/)提到的工作坊以後我就耍廢了好一陣子、拖延很久沒寫週報。趕在[今晚的 Apple 發表會](https://www.apple.com/tw/apple-events/?ref=ethanhuang13.plus)前發一篇。 如果你手上有一台 Mac，想開始接觸 Local AI，歡迎認識我的新網站──LIKit。 **歡迎**[**升級到⟪13報+⟫**](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/09/09** ## ‼️新聞標題：我的新網站──LIKit 8 月底我受邀開設了一場 Hybrid AI 工作坊（這裡有一些[照片](https://x.com/ethanhuang13/status/2094782354380431843?ref=ethanhuang13.plus)），一些 iOS 社群的朋友也有來參加。從學員的意見回饋來說，算是很不錯的一場活動。 這是我生平第一次開設整整兩天的工作坊，有實作、講義、操作素材、備援方案、小組討論題目、行動決策筆記模版、live demo……真的是把我的教學潛力給「逼」出來了。 我甚至還為此架設了一個**新網站**。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/09/CleanShot-2026-09-09-at-18.11.23@2x.webp) [https://likit.dev](https://likit.dev/?ref=ethanhuang13.plus) 我發現，許多人對於 AI 很好奇，但除了聊天式的 app 或是 AI agent 以外，對於 AI 的認識極少。 其實許多讀者手邊的 Mac 就能夠執行許多的 AI 功能。所以我一邊備課的過程，架設了 [LIKit](https://likit.dev/?ref=ethanhuang13.plus) 這個網站。 今天就藉著這份週報，介紹給大家。 LIKit──讀作 `like it`，全名是 **Local Intelligence Kit**──是為了**「手上有一台 Mac，知道它可以跑一些 AI，卻不知道如何判斷可以跑什麼、該從哪裡開始」**的朋友們而編寫的。 首頁就提供了不同背景的讀者的入口： - 「我有一台 Mac，想知道它能跑什麼 Local AI」，例如：[看懂統一記憶體與記憶體頻寬](https://likit.dev/guides/mac/unified-memory/?ref=ethanhuang13.plus) - 「我想認識並下載開源模型」，例如：[第一次看懂模型卡](https://likit.dev/guides/open-models/model-card/?ref=ethanhuang13.plus) - 「我想釐清常見的 AI 誤解」，例如： [Apple silicon 跑 AI，一定要用 MLX 嗎？](https://likit.dev/misconceptions/apple-silicon-mlx/?ref=ethanhuang13.plus) 你不需要成為機器學習的專家，或是完全脫離 Apple 開發者的舒適圈，也可以了解許多 AI 的知識與應用方式。 許多文章都有自我確認題目的設計，方便確認觀念吸收程度。 我希望讓更多人知道除了 ChatGPT、Gemini，或是 Claude Code 以外，AI 還有許多的用途。 全中文、免費，內容會持續更新。Do you like it(likit)? 還請幫我多多宣傳、指教。 ## 🍎Apple 公司、產品、活動消息 - [Apple 推出 M6 和 M5 Ultra，效能與 AI 運算能力大幅提升](https://www.apple.com/tw/newsroom/2026/08/apple-introduces-m6-and-m5-ultra-for-a-big-leap-in-performance-and-ai-compute/?ref=ethanhuang13.plus) - [Apple 推出搭載全新 M6 與 M5 Pro、效能更強大的 Mac mini](https://www.apple.com/tw/newsroom/2026/08/apple-unveils-a-more-powerful-mac-mini-featuring-the-all-new-m6-and-m5-pro/?ref=ethanhuang13.plus) - [Apple 推出搭載 M5 Max 和 M5 Ultra 的新款 Mac Studio](https://www.apple.com/tw/newsroom/2026/08/apple-introduces-new-mac-studio-with-m5-max-and-m5-ultra/?ref=ethanhuang13.plus) 最高可達 512GB 記憶體，但 10 月才能選配 ## 👨‍💻Apple 開發者消息 **新版軟體（**過了今晚應該 RC 就要推出了**）：** - 8/18 [Any Apple OS 27 beta 6](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 8/24 [Xcode 27 beta 6](https://developer.apple.com/go/?id=xcode-27-sdk-rn&ref=ethanhuang13.plus) Google Antigravity is now available in the coding assistant - 8/24 [Any Apple OS 27 beta 7](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 8/31 [Any Apple OS 27 beta 8](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) **公告：** - 8/24 [Update: New domain for Sign in with Apple](https://developer.apple.com/news/?id=1ptvdtcm&ref=ethanhuang13.plus) 以後不管是 Sign in with Apple 還是 iCloud+ 隱藏郵件地址，都會走 `private.icloud.com` 這個 domain - 9/1 [Upcoming changes to Rosetta support for Intel-based macOS apps](https://developer.apple.com/news/?id=w5ngl9k2&ref=ethanhuang13.plus) Intel 轉 Apple silicon 的階段即將完成，相容工具 Rosetta 2 最終支援版本為 macOS 27 ## 🤝社群活動 - 9/8 [iPlayground 2026 的影片](https://www.youtube.com/@iPlaygroundTaiwan/videos?ref=ethanhuang13.plus)已經陸續上傳至官方 YouTube 頻道了。錯過的朋友可以來補課 ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 ### [Whiteboardy](https://apps.apple.com/tw/app/whiteboardy/id6795752114?ref=ethanhuang13.plus) app 這是我的工作坊助教 Bolin 在聽完課程以後，受到刺激，開發出的一款「用嘴刷題」的 app。 他的想法很有趣：有了 AI 以後，軟體工程師還需要練習手寫 leetcode 嗎？還是訓練思考更重要呢？ 於是，他把 app 設計成：把想法用嘴巴講，甚至在通勤的路上用手機就可以練習。對刷題有興趣的工程師們，不妨來試試看。 - [App Store 下載連結](https://apps.apple.com/tw/app/whiteboardy/id6795752114?ref=ethanhuang13.plus) - [官方 Threads 帳號](https://www.threads.com/@whiteboardyy?ref=ethanhuang13.plus) ### [13報+](https://ethanhuang13.plus/) - 8/24 [🤓額外賺到與掌控感──談 Codex Reset](https://ethanhuang13.plus/codex-reset-usage-control/) - 8/26 [💻為什麼我不再買頂規 MacBook Pro](https://ethanhuang13.plus/why-i-stopped-buying-maxed-out-macbook-pro/) - 8/26 [⚡️拋棄價格錨點，該買就買](https://ethanhuang13.plus/2026-08-26-buy-with-new-price/) ### 📣徵才/求職/接案專區 - [Terry Chen 的 LinkedIn](https://www.linkedin.com/in/terry-chen-3350a681/?ref=ethanhuang13.plus) 10 年 iOS 經驗、4 年以色列跨國協作，主導百萬下載 App；AI 系統化開發與持續最佳化。個人開發「[垃圾車 App](https://apps.apple.com/app/apple-store/id1527915502?pt=118436878&ct=13&mt=8&ref=ethanhuang13.plus)」，累積 9,000+ 使用者好評。 如果你有 iOS 開發相關**職缺**或是**求職履歷**想要刊登在開發者週報，請見[關於](https://www.ethanhuang13.com/about?ref=ethanhuang13.plus)。 ## 關於 LIKit 的後續計畫 _This post is for paying subscribers only._ ### ⚡️拋棄價格錨點，該買就買 URL: https://ethanhuang13.plus/2026-08-26-buy-with-new-price/ Last updated: 2026-08-26T05:45:21.000Z 看到 Apple 發表新的 Mac，價格比之前高出許多，你會不會怕？ _This post is for paying subscribers only._ ### 💻為什麼我不再買頂規 MacBook Pro URL: https://ethanhuang13.plus/why-i-stopped-buying-maxed-out-macbook-pro/ Last updated: 2026-08-25T22:00:26.000Z 為了追求工作效率，我過去都用頂規 MacBook Pro，但是為什麼這次我只買 M5？ 我最近又添購了一台 MacBook Pro。有別於之前分享過[非開發定位的 MacBook Neo](https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/)，這台主要的用途就是軟體開發。 不過，我買的不是最新的 M5 Pro 或 M5 Max，而是**基本款的 M5**、[2025 年底就推出的產品](https://support.apple.com/zh-tw/125405?ref=ethanhuang13.plus)，CPU 只有 10 核心。 相較於原本的主力開發機 M3 Max 來說，效能絕對是降級。外型還沒變。 到底為什麼？ 因為**需求改變**了。這篇文章就是要來分享我的**採購決策**。 ## 頂規是為了不破壞開發心流 剛出社會時，很羨慕那些有頂規筆電的人，**一台設備就能把工作帶著走**。 > 長大以後，才懂得羨慕那些不用工作的人。不過這是另一個話題了。 身為 iOS 開發者十多年，前前後後我用過 5 台頂規 MacBook Pro：自己買的 2016 Intel Core i7、M3 Max；公司配的或借來的 2019 Intel Core i9、M1 Max、M5 Max。 Intel 時代還有各種效能不足、續航差的問題，到了 Apple silicon 推出後都迎刃而解，用起來很舒服。 我會喜歡追求頂規 MacBook Pro，除了「一台搞定全部需求」以外，很重要的原因是我**操作電腦的速度很快，希望電腦能跟得上**。從小到大有好多人都說，看我用電腦快到不知道在幹嘛。 如果啟動程式、切換視窗、開瀏覽器分頁，稍微讓我感到有一點卡，很容易就會感知到，而影響工作效率。 CPU 單核心性能是影響日常操作靈敏的重要因素之一。Apple silicon 的從 A12Z、A18 Pro、M1\~M5 我都使用過，光是從 Safari 開分頁的速度，我就可以感覺出來是哪一代晶片。 其次影響電腦是否卡頓，是當連續高負載時，有沒有順利散熱。有風扇主動散熱的 MacBook Pro 會比被動散熱的 MacBook Air 好很多。 另外就是記憶體大小夠不夠用，這點就要看工作內容與出廠時選配的規格了。 可能我個人對電腦比較沒有耐性。總之追求頂規就是要讓自己工作時愉快，不要一直覺得「我在等電腦」。 ## Agentic Coding 改變了開發工具的遊戲規則 然而，Agentic Coding 時代以來，**軟體開發的工作常態從「開發者隨時隨地都可以工作」轉變成「讓 agent 可以持續工作」**。 **開發者與開發環境分開了。** 過去會攜帶著筆記型電腦出門工作的我（以及許多開發者），開始發現──把電腦帶出門的話，agent 就不能動了。 **為了讓 agent 可以持續工作，把電腦背在背包時，還要讓它不要睡眠、不要中斷網路，怎麼想都不合理啊。** 加上 Codex Remote 或是各種遠端遙控 Agent 的工具，過去「單台最強筆電可以不受時間地點限制工作」的策略變得無用武之地。 買到 MacBook Neo 不久以後，剛好 Codex Remote 推出，它變成了我除了手機以外的主要遠端遙控**前端**。而原本的 MacBook Pro M3 Max，我就一直很不想帶出門、怕打斷它工作，於是它成了丟在家裡執行實際任務的**後端**。 可能越來越多人也會意識到需要改變工作在不同電腦的分配方式。 _This post is for paying subscribers only._ ### 🤓額外賺到與掌控感──談 Codex Reset URL: https://ethanhuang13.plus/codex-reset-usage-control/ Last updated: 2026-08-24T06:53:00.000Z 身為 Codex 的重度使用者，我自然也有在 Twitter 追蹤 [Tibo](https://x.com/thsottiaux?ref=ethanhuang13.plus) 的帳號，關心官方什麼時候要全面 Reset 或發送 Reset 次數。 Reset 的實質意義是之前的使用量可以重算，所以就不用擔心接下來的工作會被卡住。 但是 Reset 真的有讓人賺到嗎？還是只是一種心理遊戲呢？ ## 怎樣被 Reset 才會爽 Codex 的使用人數竄升很快，[官方 4 月初曾宣布](https://x.com/sama/status/2041658719839383945?ref=ethanhuang13.plus)：在達到 1000 萬使用者之前，每新增 100 萬使用者就會 Reset 一次。這期間確實有非常多次的 Reset，彷彿一種燃燒 token 的狂歡活動。 但是想也知道「沒有每天在過年的」。現在 8 月底，使用人數已經[超過 2000 萬](https://x.com/thsottiaux/status/2090766694897619318?ref=ethanhuang13.plus)了。所以最近比較容易碰到的是 [bug](https://x.com/thsottiaux/status/2091688655828246890?ref=ethanhuang13.plus) 或是特別的新功能才會有 Reset 機會。 如果你是 OpenAI，**偶爾**才能發放特別的 Reset，怎樣才會讓人覺得有「賺到了」的感覺呢？ 其實還滿困難的。如果使用者的週期才剛開始，那麼幫他 Reset 等於沒有效果。 如果使用者原本的週期即將結束呢？幫他 Reset 一樣也沒有效果。 好，那如果剛好在週期的一半 Reset 呢？ 也不一定有效果。 其實，Reset 的時間點跟週期沒有直接的關係，而是要看「目前的使用量有沒有大幅超過週期時間」。 例如，這週才過了一半，但是使用量已經 8 成，眼看後半週快要無法工作了。這時候如果收到 Reset，就等於前面的半週多用了 3 成。 這種情況，使用者才會覺得有賺到。 如果一週的使用量沒用完，Reset 對於使用者來說並沒有賺到。 > 關於 Codex 使用量，我自己是用 [OpenUsage](https://www.openusage.ai/?ref=ethanhuang13.plus) 在看。它的一大優點是支援多 iCloud 同步 token 使用量，對我這種有多台 Mac 的人很方便。 問題來了，「使用量大幅超過週期時間」是一種常見的情況嗎？ 我覺得不是。 如果一個帳號的 token 消耗量遠超過週期時間（例如 1 天就用掉一週的 5 成），可能代表這幾種情況： 1. 現在的方案根本**不夠用**，該升級 2. 可能**需要節省**一點，例如降低 Thinking 等級、不要開 Fast 模式，或是檢查有沒有浪費 token 的地方 3. **臨時趕工**加班，突然有比較高的使用量 前兩種情況會讓人調整（升級方案或是減少消耗），會達到一個平衡，所以不會一直發生。第三種情況則是意外。 所以不管怎樣，使用量超過週期都不算是常態。只要你沒有這些情況，那麼官方什麼時候 Reset，其實都沒有讓你真的賺到。 最有可能「賺到」的劇本是，一週的前幾天用量比較多（例如每天用掉平均 1.2 天的量，5 天用掉了 6 天的量），所以後面兩天就省著用。假如官方在你的週期到期前兩天 Reset，可能就會當作後面這兩天可以不用節省。 還有一種劇本是看到官方預告明天或後天會 Reset，所以目前沒有用完的額度就可以加速使用，開 Ultra、Fast、平行多工之類的，飆車一下。 Codex 在衝 1000 萬用者的那每 100 萬就 Reset 一次的階段，確實帶來很多驚喜與話題，也讓大家會盡量消耗及嘗試各種模式，因為往往在不到一週內就會發生一次 Reset。 但那個短暫的時代已經過去了。 總之，我想強調的是，現在偶爾才會有一次官方 Reset，如果使用速率沒有超過時間，那麼官方不管在什麼時間點 Reset，其實都沒有真正的影響。 ## 怎樣自己掌控 Reset 除了官方強制 Reset，Codex 也有送出讓使用者手動 Reset 的機制。 ![官方給出的手動 Reset 次數。請注意到期時間。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/08/CleanShot-2026-08-24-at-13.45.21@2x.webp) 官方給出的手動 Reset 次數。請注意到期時間。 這個機制就有趣多了，而且我覺得是真的對使用者有用的設計。 比較聰明的用法，就是在週期開始時，預測或安排接下來短時間會大量消耗 token，然後在用完以後使用這個手動 Reset。 例如：這週有東西要趕工，週一早上開始工作，週三晚上就把整週額度用完，週四早上使用掉一次 Reset，剩下幾天還能繼續用。 但也因為真的對使用者的消耗有影響，所以次數的發放也是可遇而不可求。 除了這種官方不定期發放的 Reset 次數以外，我還有一種創造手動 Reset 時機的方式，每個月至少 2 次。 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #267 好久不見 URL: https://ethanhuang13.plus/dev-news-267-hybrid-ai-workshop/ Last updated: 2026-08-16T15:39:24.000Z ## 13 的話 Apple 開發者「週報」的讀者，好久不見。 上個月忙翻了。月初發布了新產品 [todayOS](https://today-os.app/?ref=ethanhuang13.plus)、月中跟一群夥伴舉辦了給學生的 [iOS AI Summer Camp](https://luma.com/db49qc4m?ref=ethanhuang13.plus)、月底的 [iPlayground](https://iplayground.io/2026/?ref=ethanhuang13.plus) 則有演講、工作坊各一場。 雖然都是自己想做、喜歡做的事情，不過輸出太多，搞得有一點倦怠了。這個月初休息了一陣子，才算是慢慢找回步調。 不過，我實在是閒不下來。 我受邀在 8 月底開設一場免費的 [**Hybrid AI 工作坊**](https://luma.com/zk9tugk3?utm%5Fsource=13%5Fnewsletter)，歡迎讀者來參加。 如果你好奇 Local AI 要怎麼使用與評估，甚至買了 Mac 想跑本地模型，卻一直不得其門而入，[歡迎報名](https://luma.com/zk9tugk3?utm%5Fsource=13%5Fnewsletter)。時間是 8/29-31（我會負責前兩天的實作課程）、地點與 iPlayground 一樣在政大公企中心，重點是**完全免費**，只要自備對應的 Mac。也請幫忙宣傳給可能有興趣的朋友或同事。 小提示：報名資格採審核制，所以**表單上的參加理由，請盡量填寫詳細**喔。 這期開發者「週報」不完整報導過去一個月漏掉的消息，但是我整理了 Apple 官方宣布要支援秋季 iOS 27、App Store 新政策需要留意的事項。有許多項目（像是取消強制全螢幕、輸入控制），明眼人都可以看得出來跟「螢幕大小會改變的 iOS 設備」有關。不想錯過第一批支援新 iPhone 的開發者請務必留意。 **歡迎**[**升級到⟪13報+⟫**](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/08/16** ## 🍎Apple 公司、產品、活動消息 - 6/29 [Apple 買下了設計工具 Play](https://www.macrumors.com/2026/06/29/apple-acquires-award-winning-app-play/?ref=ethanhuang13.plus) ## 👨‍💻Apple 開發者消息 **新版軟體：** - 7/1 [Introducing the Safari MCP server for web developers](https://webkit.org/blog/18136/introducing-the-safari-mcp-server-for-web-developers/?ref=ethanhuang13.plus) Safari 也支援 MCP 了，不過這主要是用來開發，而不是一般使用者日常操作用的 - 7/6 [Any OS 26.6 beta 4](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 7/6 [Any OS 27 beta 3](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) 有在用 Foundation Models 的開發者務必閱讀更新說明，以免踩坑。[App icon 的玻璃效果 看起來有調弱一點](https://x.com/avstorm/status/2074203269006586271?ref=ethanhuang13.plus)、[解鎖畫面與桌布有很帥的轉場](https://x.com/Cartidise/status/2074206697363759261?ref=ethanhuang13.plus) - 7/7 [Xcode 27 beta 3](https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes?ref=ethanhuang13.plus) 加強了用 Agent 翻譯 String Catalog 時互動與提示。`PreviewProvider` 被標為 deprecated，請改用 `#Preview` macros - 7/20 [Any Apple OS 27 beta 4](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 8/10 [Any Apple OS 27 beta 5](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 8/10 [Xcode 27 beta 5](https://developer.apple.com/go/?id=xcode-27-sdk-rn&ref=ethanhuang13.plus) 如果有在使用 coding agent，這版新增了在不打開 Xcode 專案就可以使用它的 MCP server 的功能，甚至可以（不安全地）允許所有指令。對於放手交給 agent 開發、不親自使用 Xcode 的開發者應該會相當方便。這項功能目前還是預覽階段，可能會遇到一些問題。啟用指令為 `sudo xcrun mcp-server enable`，詳情請參閱 [Release Notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes?ref=ethanhuang13.plus#New-Features) **App Store 公告：** - 7/9 [Age rating questionnaire now includes social media questions](https://developer.apple.com/news/?id=tlur8uvi&ref=ethanhuang13.plus) 提醒開發者要更新所有 app 的年齡分級 - 8/5 [Get ready for new creative assets on the App Store](https://developer.apple.com/news/?id=kug6m2ea&ref=ethanhuang13.plus) App Store 頁面即將支援呈現新的宣傳素材。開發者可以準備好吸引人的視覺元素 **技術文件：** 我有補上自 WWDC 以來的。這些 Technotes 多半與停止支援有關，所以務必確認。 - 6/8 [TN3208: Preparing your app’s launch screen to meet App Store requirements](https://developer.apple.com/documentation/technotes/tn3208-preparing-your-apps-launch-screen-to-meet-app-store-requirements?ref=ethanhuang13.plus) - 6/8 [TN3210: Optimizing your app for iPhone Mirroring](https://developer.apple.com/documentation/technotes/tn3210-optimizing-your-app-for-iphone-mirroring?ref=ethanhuang13.plus) - 6/8 [TN3211: Resolving SwiftUI source incompatibilities for State and ContentBuilder](https://developer.apple.com/documentation/technotes/tn3211-resolving-swiftui-source-incompatibilities-for-state-and-contentbuilder?ref=ethanhuang13.plus) - 6/8 [TN3212: Adopting gesture recognizers for Sidecar touch support](https://developer.apple.com/documentation/technotes/tn3212-adopting-gesture-recognizers-for-sidecar-touch-support?ref=ethanhuang13.plus) - 7/14 [TN3213: Moving from Multipeer Connectivity to Network framework](https://developer.apple.com/documentation/technotes/tn3213-moving-from-multipeer-connectivity-to-network-framework?ref=ethanhuang13.plus) 如果你還有在使用 Multipeer Connectivity，從 Xcode 27 開始請遷移至 Network framework - 8/14 [Migrating your iPad app from the deprecated UIRequiresFullScreen key](https://developer.apple.com/documentation/technotes/tn3192-migrating-your-app-from-the-deprecated-uirequiresfullscreen-key?ref=ethanhuang13.plus) 從 iPadOS 26 開始，Apple 就一直提醒要移除 iPad app 強制全螢幕的設定，此設定在 iPadOS 27 會停止支援。請開發者把握時間跟上。如果要支援舊版系統的全螢幕，有一個 [UIRequiresFullScreenIgnoredStartingWithVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/uirequiresfullscreenignoredstartingwithversion?ref=ethanhuang13.plus) key 可以使用 小技巧：可以把上述整段給 coding agent 幫忙做確認。 ## 🤝社群活動 - 7/25-26 [iPlayground 2026](https://iplayground.io/2026/?ref=ethanhuang13.plus) 活動回顧照片 [Day 1](https://photos.app.goo.gl/8kRzspUq6GxaEEy8A?ref=ethanhuang13.plus)、[Day 2](https://photos.app.goo.gl/ACW7xvQxM2vwkmMq7?ref=ethanhuang13.plus) - iPlayground 目前還未放出議程影片。而我想再次推薦 [iPlayground Podcast](https://www.youtube.com/playlist?list=PLJN8Q2M8xEClcMjIhNGA075-KwTOcFadF&ref=ethanhuang13.plus)，居然推出了 10 集採訪 - 8/29-31 [Hybrid AI 工作坊](https://luma.com/zk9tugk3?utm%5Fsource=13%5Fnewsletter) 這是一場免費工作坊。感謝 TCA （台北市電腦公會，不是 Composable Architecture，哈）邀請我擔任工作坊講者。也請讀者幫忙多多宣傳！ [![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/08/CleanShot-2026-08-16-at-23.23.34@2x.png)](https://www.threads.com/@ethanhuang13/post/Db8XFSXFDi-?ref=ethanhuang13.plus) Hybrid AI 工作坊 Threads 宣傳貼文 ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 ### [13報+](https://ethanhuang13.plus/) - 7/2 [🗓️用 todayOS 的設計哲學來經營 todayOS](https://ethanhuang13.plus/index/) - 7/6 [🚧新手教學一定要做。上架 App 前究竟有多少準備工作？（二）](https://ethanhuang13.plus/index/) - 7/10 [⚡️GPT-5.6 Sol 的第一印象：語言能力變強](https://ethanhuang13.plus/2026-07-10-gpt-5-6-impression/) - 7/22 [🚧架設官網是基本──上架 App 前究竟有多少準備工作？（三）](https://ethanhuang13.plus/app-launch-preparation-part-3-site/) - 7/23 [🇹🇼冷知識：台灣是 iOS App Store 第四大市場](https://ethanhuang13.plus/taiwan-top-app-store-market/) - 8/3 [🛟給自己一個 Reset](https://ethanhuang13.plus/human-usage-reset/) - 8/5 [💻為什麼 MacBook Neo 成了我的主力電腦](https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/) - 8/11 [💻MacBook Neo 的真正優點](https://ethanhuang13.plus/macbook-neo-real-benefits/) - 8/13 [⚡️人人都能透過 AI 打造自己的學習系統嗎？](https://ethanhuang13.plus/2026-08-13-can-everyone-build-their-own-learning-system/) ### [ChaoCode](https://www.youtube.com/@ChaoCode/videos?ref=ethanhuang13.plus) - 7/4 [我上完 Stanford CS146S 的心得：這堂課到底值不值得學？在教什麼？](https://www.youtube.com/watch?v=gxUccRfr3V8&ref=ethanhuang13.plus) - 7/4 [用 AI 自動生成 UI 和 Web App，真的可行嗎？](https://www.youtube.com/watch?v=QeQo5wUpu4E&ref=ethanhuang13.plus) - 7/18 [用 AI 寫完 App 之後呢？用 AI 做 DevOps、監控與事故排查](https://www.youtube.com/watch?v=o2VpZyEAvdY&ref=ethanhuang13.plus) - 7/30 [我使用 AI 的心態轉變：我現在還會看程式碼嗎？現在工程師的價值是什麼？](https://www.youtube.com/watch?v=Ps80H5t9eIs&ref=ethanhuang13.plus) - 7/30 [我不再手打長篇 Prompt 了：用語音輸入才跟得上 AI Agent 的速度 - Typeless 使用心得分享](https://www.youtube.com/watch?v=7rLU41U71Mw&ref=ethanhuang13.plus) ### 📣徵才/求職/接案專區 **求職：** - [**Terry Chen** 的 LinkedIn](https://www.linkedin.com/in/terry-chen-3350a681/?ref=ethanhuang13.plus)：10 年 iOS 經驗、4 年以色列跨國協作，主導百萬下載 App；AI 系統化開發與持續最佳化。個人開發「[垃圾車 App](https://apps.apple.com/app/apple-store/id1527915502?pt=118436878&ct=13&mt=8&ref=ethanhuang13.plus)」，累積 9,000+ 使用者好評。 如果你有 iOS 開發相關**職缺**或是**求職履歷**想要刊登在開發者週報，請見[關於](https://www.ethanhuang13.com/about?ref=ethanhuang13.plus)。 ### ⚡️人人都能透過 AI 打造自己的學習系統嗎？ URL: https://ethanhuang13.plus/2026-08-13-can-everyone-build-their-own-learning-system/ Last updated: 2026-08-13T05:27:50.000Z 這條路線的探索，說不定恰好會解決人們因為「擔心所學被 AI 取代而不知道還該學習什麼」的困境。 _This post is for paying subscribers only._ ### 💻MacBook Neo 的真正優點 URL: https://ethanhuang13.plus/macbook-neo-real-benefits/ Last updated: 2026-08-11T06:34:10.000Z 接續前一篇[💻為什麼 MacBook Neo 成了我的主力電腦](https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/)，接下來我要談談用了 3 個月以後，體會到這台便宜、輕巧、好看，卻又出奇實用的設備，真正的優點是什麼。 簡單來說： 1. 好看本身就是優點，特別是鍵盤的整體感 2. 便宜所以照顧的心理負擔低 3. 效能低所以不容易發燙 4. 微妙的續航力 ## 好看本身就是一種價值 MacBook Neo 的一大特色是顏色。有人特別喜歡**青橘黃色**，很有夏天的感覺。我買的是**胭粉色**，下訂單的時候剛好是日本櫻花季，所以特別應景。 最近家裡甚至添購了第二台 Neo，因為家人喜歡它的**靛青色**，想把手上（效能更好但用不到這麼好）MacBook Air 換掉。 除了外殼顏色繽紛活潑，Neo 在美學上相較於其他 MacBook 最大的「進步」，就是**鍵盤配色的一體感**。 每一種機殼顏色，鍵盤都有對應的淡淡配色。 ![MacBook Neo 鍵盤有淡淡的顏色，與機身一致](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/08/46253C76-B1A6-471D-9090-F867DA2BBA02_1_102.jpeg) MacBook Neo 鍵盤有淡淡的顏色，與機身一致 就是這一點點的鍵盤顏色，讓 MacBook Neo 使用起來更賞心悅目。用了這台電腦，櫻花不見得會更美、咖啡不見得更好喝，但是心情更愉悅，是我個人確實的主觀感受。 除此之外，macOS 有機殼對應的 accent color，讓支援的應用程式直接搭配該顏色，過去只有 iMac 有這種待遇（詳情請見[🌸買了 MacBook Neo 才知道有這個顏色 API](https://ethanhuang13.plus/macbook-neo-color-api/)一文）。可以說，Apple 盡可能在壓低售價的情況下，增加了這台電腦的特色。 用過 MacBook Neo，再看回 Air、Pro，我已經有點受不了亮色機身搭配黑色鍵盤的設定了😅 Neo 還有一個好處是螢幕沒有「瀏海」，所以它的選單列不會被切斷。雖然邊框寬度較粗，但是這個問題在真正使用電腦時，其實感覺不出來。 ![MacBook Neo 與 MacBook Pro。你更喜歡哪一種的鍵盤配色與瀏海設計呢？](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/08/0C635A2B-5C30-4972-A634-2F767999B9F4_1_102.jpeg) MacBook Neo 與 MacBook Pro。你更喜歡哪一種的鍵盤配色與瀏海設計呢？ Air 跟 Pro 的外型設計已延續多年，不知道下一次大改版時，會不會更接近 Neo 的設計？ ## 便宜治百病對應的是極低的心理負擔 MacBook Neo 對我來說有一種「因為不貴、也不是主力設備，就算怎樣了也不心疼」的感覺。 [前文](https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/)有提到，臨時決定要去咖啡廳，換作是以前，要帶 MacBook Pro 出門頗有「摩擦力」。怕撞壞所以要保護好、最好要帶著充電器。換成是 Neo，就是隨手丟進束口袋就能出門。 出去玩又需要帶著電腦做點事情時，MacBook Neo 讓我比較不會有「筆電是貴重物品，最好隨身背著」的負擔。丟在旅館房間也不需要想太多。 對於有在工作的人來說，真的有需要的話，花個 2 萬元左右添購一台 MacBook Neo 不算太困難。 感受到「這麼便宜的 Mac 居然能做到這些事情」的驚喜，也是它的一大優點。 ## 效能低到不會發燙 幾年前，我的主力設備是 MacBook Air M2。Air 沒有主動散熱，拿來寫程式時，如果 Xcode 連續編譯幾分鐘，像是 SwiftUI Preview 持續更新時就很容易發燙（特別是 [SwiftSyntax 還沒有 prebuilt 的時代](https://ethanhuang13.plus/prebuilt-swiftsyntax/)）。 後來受不了，換成 MacBook Pro M3 Max（沒買 M3 Pro 是因為 M3 那一代有 CPU 核心數量分級）。雖然是性能很優秀的設備，但是它的鍵盤平時就溫溫熱熱的。尤其有插上外接設備與螢幕時，溫度幾乎不會降下來，除非使用第三方軟體修改風扇曲線。 對我來說，**鍵盤的溫度絕對會影響到工作心情**。人的手指對溫度變化相當敏感。持續感覺到鍵盤溫熱，如果是冬天還滿舒服的，但夏天時就令人煩躁，還容易造成手指出汗。 **累積多台 MacBook 的經驗下來，鍵盤是否容易發熱，成為我判斷筆記型電腦生產力的一項關鍵因素。並不是效能越高的電腦，用起來就一定越舒服。有時候還正好相反。** 所以，我平時是用 Mac mini 的鍵盤、觸控板，再透過 Universal Control 來控制那台 MacBook Pro。 再回頭說到 MacBook Neo。 _This post is for paying subscribers only._ ### 💻為什麼 MacBook Neo 成了我的主力電腦 URL: https://ethanhuang13.plus/why-macbook-neo-become-primary-mac/ Last updated: 2026-08-13T05:56:45.000Z 根據 Timing app 的使用時間統計，我花在 MacBook Neo 的使用時間，與主要開發機 MacBook Pro M3 Max 居然是持平的。也就是說，從時間上來看，它其實也成了主力電腦。 這篇文章就是要來分析箇中原因。 ## 背景介紹 先看數據。 ![Timing app 的統計](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/08/CleanShot-2026-08-03-at-23.38.50@2x.png) Timing app 的使用時間統計，從拿到 MacBook Neo 那天開始計算 MacBook Pro M3 Max 是我目前的主力開發設備，使用時間自然最多。過去 3 個月左右大概有 183 小時的使用時間。 而 MacBook Neo 則是 163 小時。 第三名的 Mac mini M4 雖然也有 134 小時，不過因為我幾乎都把它跟 MacBook Pro M3 Max 透過 [Universal Control](https://support.apple.com/zh-tw/102459?ref=ethanhuang13.plus) 一起使用，所以兩者的時間沒辦法相加。可以忽略。 那為什麼 MacBook Neo 會是第二名呢？有三個重要原因： 1. 它是我在軟體開發工作以外最優先會使用的電腦設備 2. 隨手一抓就可以出門 3. Codex 推出了 Remote 功能 ## 軟體開發工作以外最優先會使用的電腦設備 我平時都在家工作，要密集開發時會在工作房間、電腦桌前，同時使用 MacBook Pro M3 Max 與 Mac mini M4。 而 MacBook Neo 的效能並不高，完全不適合拿來做軟體開發工作。許多人可能以為瓶頸是在 8 GB 的記憶體，但以 iOS 開發的需求來說，**實際上的問題是在 CPU**。A18 Pro 的單核心效能不錯，但是編譯軟體這種需要一定時間的多核心高負載，它就沒辦法發揮得很好（這或許與手機晶片的封裝形式較不利散熱有關。不知道後續版本會不會把 iPhone 17 Pro 的均溫板拿來用）。 舉例來說，最近我臨時要打包一版 iOS app 上傳 TestFlight，剛好沒有打中 [prebuilt SwiftSyntax](https://ethanhuang13.plus/prebuilt-swiftsyntax/)，結果跑了 11 多分鐘；換作其他電腦不會超過 2 分鐘。這種速度，我要把它拿來「臨時拿來開發一下」都無法。 然而，除了軟體開發以外，Mac 對我來說也有非常多工作與生活用途。 _This post is for paying subscribers only._ ### 🛟給自己一個 Reset URL: https://ethanhuang13.plus/human-usage-reset/ Last updated: 2026-08-30T16:06:36.000Z 回想起來，七月底我其實差點要 burnout，也可以說是把自己的額度用完了。 _This post is for paying subscribers only._ ### 🇹🇼冷知識：台灣是 iOS App Store 第四大市場 URL: https://ethanhuang13.plus/taiwan-top-app-store-market/ Last updated: 2026-07-22T22:00:14.000Z 根據 Sensor Tower（data.ai）的[公開報告（Mobile App Market Forecast 2030）](https://sensortower.com/report/forecast-report/download?ref=ethanhuang13.plus)，2023 年 iOS App Store 的消費者支出排名，分別是： 1. 美國 $30.8B 2. 中國 $15.7B 3. 日本 $12.3B 4. 台灣 $2.9B 5. 英國 $2.6B ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-21-at-11.04.56@2x.png) 來自 Sensor Tower 的 [Mobile App Market Forecast 2030](https://sensortower.com/report/forecast-report/download?ref=ethanhuang13.plus) 雖然這份報告的時間在 vibe coding 時代之前（暫時找不到更新的公開數據）、也不是 Apple 官方的數據，但 Sensor Tower 算是很大的數據機構，可信度高。 該報告預測，到了 2030 年，台灣的市場規模會從 29 億美金成長到 **49 億美金**。預測認為，台灣市場年複合成長率（CAGR）會是 8.1%，但低於英國的 10.6%，所以排名會被後者超越。 需要注意的是，前三名的市場規模與四、五名有很大的差距。第三名的日本是台灣的 \~4 倍，更不用說中國的 \~5 倍、美國的 \~10 倍。 但不論如何，我想說的是，從 App Store 來看，在消費級軟體或遊戲方面，**台灣人相對於全球來說，願意出錢、也出得起**。 台灣很明確是 AI 硬體供應鏈的要角。相對的，軟體方面給人的印象總是還有很大的進步空間。 然而，從消費者支出的角度來看，人們願意花錢購買軟體，提升生活品質與工作效率。這其實是台灣發展軟體的好消息。 你覺得台灣人會樂於支持本土的開發者嗎？我認為台灣的開發者很有機會。這也是為什麼我把工作辭掉以後，一直在[做栽培下一代開發者的事情](https://www.threads.com/@ethanhuang13/post/Da9nWTOlG25?ref=ethanhuang13.plus)。 如果你是來自台灣的開發者，會如何經營台灣的軟體市場呢？歡迎跟我分享你的看法。 ### 🚧架設官網是基本──上架 App 前究竟有多少準備工作？（三） URL: https://ethanhuang13.plus/app-launch-preparation-part-3-site/ Last updated: 2026-08-13T06:08:13.000Z 最近教學與演講等工作十分繁忙，終於能抽空撰寫這個「上架 app 準備工作」系列。 除了前一篇提到的[新手教學](https://ethanhuang13.plus/app-launch-preparation-part-2-onboarding/)，很多人都會忽略幫 app 架設官方網站的重要性。 把官網做好，可以讓潛在消費者無形當中對這個全新的產品**建立信任與好奇**，也能讓他們在下載 app 以前，就對功能有比較合理的預期。 如果官網做得不錯，還有機會從 Google 搜尋到。 ![搜尋「曬太陽 喝水 小工具」有機會找到 todayOS 的官網](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-22-at-16.53.29@2x.png) 搜尋「曬太陽 喝水 小工具」有機會找到 [todayOS 的官網](https://today-os.app/?ref=ethanhuang13.plus) ## App 的官方網站要放哪些東西？ App 的官方網站不需要很複雜，只需要用一頁簡單呈現 **app 名稱**、**截圖**展示、核心**功能**、**下載**連結（App Store Badge）。 除此之外，還需要放一些支援與說明類型的文件。像是聯絡**客服**的方式、**使用條款**、**隱私權政策**、常見問題、**媒體素材包**（Press Kit）等等。 客服頁面、使用條款、隱私權政策，這三項在 app 送審 App Store 時，本來就是必填資料。 ## 如何製作官網？ 我在開發 [todayOS 的官網](https://today-os.app/index.html?ref=ethanhuang13.plus)時，就是讓 Codex 來寫單頁的網頁。有確認好支援桌面與手機版瀏覽器、自動判斷中英文等等，基本上已經夠用。 用 AI 來製作產品的單頁式官網一點也不難，難的是身為開發者，有多重視官網的內容與呈現資訊。 第一版 prompt 大概可以這樣寫： ```plaintext 幫 todayOS 製作一個單頁的官方網站。要有繁中、英文。文案、app icon、截圖素材，可以從專案既有資料找到。製作完第一版以後，上傳到 GPT Sites 讓我在桌面與手機瀏覽器預覽。 ``` 關於網頁設計，許多人想的都是怎樣才能做得很漂亮。但我想提醒的是：應該先確認資訊架構是否清楚、訪客能否輕鬆找到他們想找的東西，其次才是視覺與美觀。 ## 如何準備使用條款與隱私權政策？ 我要再三強調一個觀念與事實：**上架一款 app，尤其是收費產品，就是在做生意，有對應的法律責任。** 使用條款與隱私權政策，不僅是必要文件，更是保護開發者與消費者雙方權益的機制。 使用條款會寫到：app 的服務內容、使用 app 有哪些注意事項、智慧財產權、責任範圍等等。 隱私權政策會寫到：app 會用到哪些使用者個人資料、資料會如何被處理、保留或刪除等等。 上述這些資訊，都是開發者應該要在這些文件說明清楚的。公開透明是最高指導原則。 那麼我們要怎麼準備這兩項文件呢？現在的 AI 工具都能夠生成合理的對應文件。不過，不要直接用 ChatGPT，要用 coding agent。因為我們要**讓 AI 工具根據程式碼做檢查，確保文件聲明的與程式實際執行的保持一致**。 每次要釋出新版時，也要讓 coding agent 再檢查一次，確認文件有跟上最新版的實作。 ## 媒體素材包是什麼？怎麼準備？ 很多開發者都沒有意識到，這世界上有一群人的工作就是在推廣與介紹各式各樣的 app，也就是媒體記者。 如果你的 app 很有報導的切入點，上架後容易吸引媒體朋友來報導。此時如果有一份現成的文件與整理好的圖片素材，就可以大幅減輕他們的工作，幫助他們快速寫出報導。 而這樣的素材包就叫做 Press Kit。 要準備起來也很簡單，我的作法是讓 Codex 直接依照目前 app 的介紹與功能，以及事前準備好的截圖，打包成一個壓縮檔，然後就上傳到 [GitHub Release Assets](https://github.com/ethanhuang13/todayOS-release/releases?ref=ethanhuang13.plus)，並在官網提供下載。 內容與 App Store 或官網重複也沒關係，畢竟你如果沒有準備，撰寫報導的人還是得手動去下載。如果 app 有特別的設計理念適合報導，也可以一併放進去。 歡迎參考 [todayOS 的 Press Kit 頁面](https://today-os.app/press-kit.html?ref=ethanhuang13.plus)。 ## 使用 Apple 官方提供的下載按鈕 你一定看過這個「badge」，它是 Apple 官方最推薦的下載按鈕。 我會建議官網上的 app 下載按鈕直接用這版，因為這是大多數人熟悉的樣式，可以讓想要下載 app 的人很直覺就找到。 ![App Store badge](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-22-at-17.43.24@2x.png) App Store badge App Store 有一個[行銷素材與指引的網頁](https://developer.apple.com/app-store/marketing/guidelines/?ref=ethanhuang13.plus)，上面就有這個 badge 的素材包，甚至還提供了多國語系的版本。 網站上還有很多行銷素材，使用時請留意官方的指引。 以上內容應該足夠你做出一個夠用的 app 官網。以下進階內容，僅開放給⟪13報+⟫的讀者。如果你想要閱讀更多，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 什麼時候要買網址？ - AI 寫 App 很快，概念驗證可以靠直接上架、不需要官網嗎？ - todayOS 官網的功能演進 _This post is for paying subscribers only._ ### ⚡️GPT-5.6 Sol 的第一印象：語言能力變強 URL: https://ethanhuang13.plus/2026-07-10-gpt-5-6-impression/ Last updated: 2026-08-13T06:08:12.000Z Coding 方面先不說，最直接觀察到 GPT-5.6 的變化是本地化能力。 _This post is for paying subscribers only._ ### 🚧新手教學一定要做──上架 App 前究竟有多少準備工作？（二） URL: https://ethanhuang13.plus/app-launch-preparation-part-2-onboarding/ Last updated: 2026-08-13T06:08:11.000Z 在[前一篇文章](https://ethanhuang13.plus/app-launch-preparation-part-1/)中，我列舉了十幾項上架 app 之前的準備工作。我後來覺得，分成上中下篇也寫不完，所以就改成數字系列標題了。 今天這篇要談的是**新手教學的重要性**，以及怎麼實作。 ## 為什麼要做新手教學？ 新手開發者的一大盲點，就是覺得自己做完的 app，別人一打開就會使用。 **這是不可能的。** 實際情況往往是，使用者因為不知道要怎麼使用 app，就再也不會打開。 我們應該要讓使用者第一次打開 app 就經歷： 1. **了解價值**：自己可能有什麼問題或需求，可以透過這個 app 獲得解決 2. **個人化**：如果 app 對於不同使用者的用法會有明顯差異，要讓使用者根據自己的偏好去調整設定 3. **請求權限**：如果 app 有用到 iOS 系統權限（例如定位、健康、通知），或是 app 需要註冊帳號才能使用，要說明清楚理由、好處、資料會如何被使用。並且要考慮到，如果使用者拒絕的話，會不會有流程死路、無法使用特定功能要如何處理。**大原則是對使用者保持透明、建立信任，並優雅地處理非理想的流程** 4. **付費轉換**：如果你做的是收費產品，那麼最好**一開始就說清楚，讓使用者有個正確的預期**。說明免費與付費功能差異，並且呈現付費頁面 ## 要怎麼開始？先想好一句話賣點 很多人想到新手教學，可能會聯想到精美的動畫、漂亮的過場、友善的虛擬角色等等。其實這些都不是最重要的。 最重要的是：**你想傳達什麼訊息？** 文章後半段，我會分享我用了什麼工具與 Agent Skill。但是我強烈推薦開發者先試著回答這個問題： **我能不能在一、兩句話中，把「你為什麼要用這個 app」說清楚？** 這種一句話說清楚核心賣點的練習，會讓你更清楚，在新手教學究竟要傳達什麼訊息給初次見面的陌生使用者。 ## 以 todayOS 為例，做到轉換率高於業界標準 以 [todayOS](https://get.today-os.app/13plus?ref=ethanhuang13.plus) app 來說，其中一個版本我會這樣說：「手機、手錶、電腦上有許多我的健康與操作資訊，能不能直接提醒我現在該補充水分、起身走動，或休息眼睛，而不是給我一堆數據？」 使用者提供越多資料與權限、有越多 Apple 裝置，todayOS 的提醒建議能力就會越好、對使用者就會越實用。所以要把這些，在新手教學流程中展現出來。 第一頁是個簡單的歡迎頁面： ![第一步：歡迎畫面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-06-at-13.45.36@2x.png) 第一步：歡迎畫面 第二頁，提出了一些使用者可能會有的困擾或需求： ![第二步：你有這些需求或困擾嗎？](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-06-at-13.54.07@2x-1.png) 第二步：你有這些需求或困擾嗎？ 第三頁，把使用者前一頁有勾選的項目，呈現出 todayOS app 能怎樣幫忙： ![第三步：todayOS 能怎樣幫助到你](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-06-at-13.53.38@2x-1.png) 第三步：todayOS 能怎樣幫助到你 後續的頁面我就不一一貼出了，請讀者自行[下載體驗](https://get.today-os.app/13plus?ref=ethanhuang13.plus)。 數據顯示，在上架後一週、超過 1,300 位使用者當中，有超過 81% 的使用者走到了付費頁面。並且，最終**有 8.24% 的使用者開始年費訂閱的試用**，或是直接以月費來訂閱。 ![有高達 8.24% 的使用者開始訂閱或試用。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-06-at-13.40.32@2x.png) 有高達 8.24% 的使用者開始訂閱或試用。 根據 RevenueCat 的統計，健康類型的 app 的「從下載到試用」比例的中位數是 6.9%，所以 **todayOS 目前的表現高於業界平均**。 （數據標準可以在 [RevenueCat 推出的這個計算機](https://www.revenuecat.com/app-store-revenue-calculator?ref=ethanhuang13.plus)看到。這是非常好的預測工具，我打算之後另闢專文介紹。） 新手教學不是越短越好，也不是越長越好。應該是要考慮，每個步驟是否有意義、能讓使用者感覺到「這個 app 我好像真的用得上」。 todayOS 的新手教學有 12 頁，付費頁面是在第 10 頁。 其實，目前 todayOS 的新手教學，以我心中的標準來說，目前只有做到 80 分，我還有很多想改進的地方。但是因為轉換率還不錯，所以它不會是我下一版優先要修改的部分。 ## 如何追蹤新手教學的轉換率 我剛才貼的截圖來自 [TelemetryDeck](https://telemetrydeck.com/?ref=ethanhuang13.plus) 這個服務。它是一個強調不蒐集使用者隱私（會去識別化）的應用程式功能追蹤服務。 以新的 app 來說，它的免費額度算是很夠用（不過我後來升級到付費方案了，因為我想直接讓 AI 工具打 API 去抓數據回來分析，而不是只看網頁介面）。 你可以在 iOS app 安裝好 TelemetryDeck SDK，用 AI 工具把新手教學的每一頁加上一個事件名稱，並且在 Dashboards 新增一個 Insight，就可以做出轉換漏斗圖（Funnel）。 ![建立新的 Funnel](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/07/CleanShot-2026-07-06-at-14.01.26@2x.png) 建立新的 Funnel 這篇不談轉換漏斗的細節，你只要知道，如果看到圖上**有斜率特別陡峭地往下掉，就表示那邊有比較多使用者流失**，可能要調整那個步驟的呈現方式。 App 的每個版本你都可以觀察這個 Funnel 的變化，讓它變得更好，讓更多使用者會留下來。 ## 小結 在所有的「上架 App 前的必做工作」當中，我覺得新手教學是最麻煩，但又是最必須認真面對的工作。 我甚至覺得，**如果你的 app 已經上架，但還沒有做新手教學，那麼你接下來的工作，就該是思考並做出新手教學。** 其實 todayOS 的前身 13 app 早在 2025 年初就做出來。去年此時我也知道它有潛力轉換成產品（參考[前文](https://ethanhuang13.plus/why-build-todayos-from-personal-app/)）。但是為什麼我一直拖到現在才上架呢？ 因為做新手教學太麻煩了。不光是開發上的麻煩，而是要對於 app 的功能與價值，**對自我做靈魂拷問**。必須放下「再增加更多功能，使用者就會留下來」或是「只要多宣傳，就會有更多人使用」的（天真）想法，專注在做好呈現價值與溝通。 我很高興，自己有認真把 todayOS 的新手教學做好，實際的轉換率也顯示它是個及格的流程，甚至高於業界水準。這其實是我第一次認真做新手教學流程，還有很多要加強的地方。歡迎多多與我交流。 到這裡，你應該已經知道新手教學的重要性，以及基本的觀念。祝你做出令使用者容易上手的新手教學流程！ 文章的後半部分，我會分享一些更容易做出新手教學流程的方式、Agent Skill，以及測試的方式。以下保留給 13報+ 的付費會員。 ## 如何用 AI 工具做新手教學 做新手教學的大原則你已經知道了，但是介面要怎麼設計、每個步驟該放什麼、順序如何安排？ _This post is for paying subscribers only._ ### 🗓️用 todayOS 的設計哲學來經營 todayOS URL: https://ethanhuang13.plus/todayos-meta-operation/ Last updated: 2026-08-13T06:08:10.000Z todayOS app [剛上架](https://get.today-os.app/13plus?ref=ethanhuang13.plus)。 對於獨立開發者來說，好不容易拼到產品上架，下一個問題會是：**如何長期經營？每天要做什麼？** 像我現在的工作，沒有固定上班時間。所以生活與工作之間，會比一般上班族更缺乏界線，也就更需要**主動設定生活節奏**。 todayOS 的核心理念，從工程的角度來說就是**「輸入資料與脈絡，輸出當下最適合做的那件事」**。有一類的輸入比較即時，例如從 HealthKit 讀到運動紀錄，則提醒使用者要喝水；偵測到 HRV 比平均低，則提醒放鬆。 而另一類的輸入，主要以環境為主。例如根據位置與時間，計算當天太陽下山的時間，然後提醒使用者在那之前出門曬一點太陽。 這種設計哲學，當然不會僅限於 app 內的健康行動。理論上只要有夠多的資料，就可以適用於任何情況。所以，我也把它用在我自己的產品開發週期上。 ## 兩週為單位的開發週期 我想要把開發週期固定下來。一個穩定版本抓兩週時間、每天要做不同的事情。 從上一版發出的時間抓兩週，用程式計算一下，就可以知道今天是 14 天中的哪一天。 這是我跟 Codex（5.5 xHigh）討論時下的 prompt（回應的部分我就不貼了）： _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #266 iPlayground 也出 Podcast 啦 URL: https://ethanhuang13.plus/dev-news-266-iplayground-podcast/ Last updated: 2026-06-28T11:09:16.000Z ## 13 的話 我剛休假回來。旅行本身非常棒，只是回來以後在痛苦地調整時差，幾乎每天都睡到下午才醒。 今天要很高興地宣布，距離上一次推出獨立開發 app 十幾年的，我終於要上架新產品──[todayOS](https://apps.apple.com/app/apple-store/id6764528281?pt=99170802&ct=substack&mt=8&ref=ethanhuang13.plus) 了！ 最早是從寫給自己的「13 app」來的，但我發現有好多測試者每天都在用，所以才轉換成產品。 用最簡單的方式介紹： **如果你為了追蹤健康而買 Apple Watch，那麼** [**todayOS**](https://apps.apple.com/app/apple-store/id6764528281?pt=99170802&ct=substack&mt=8&ref=ethanhuang13.plus) **可以讓你更方便看到「現在」該做哪個「健康行動」。** 它有 Widget 可以裝在 iOS 主畫面、解鎖畫面、Watch 的錶面。 安裝 Mac 版的話，甚至可以提醒你要休息眼睛。 有需要的朋友歡迎下載試用。 App 還有很多改進空間，也請多多提供給我意見，謝謝！ [![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/06/apple-touch-icon.png)](https://apps.apple.com/app/apple-store/id6764528281?pt=99170802&ct=13plus&mt=8&ref=ethanhuang13.plus) 下載 todayOS **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/06/28** ## ‼️新聞標題 - 6/26 Mac 與 iPad 全面大漲價。我個人的評論是，個別 PC 零組件不說，各遊戲機都有高幅度的漲價（最「可憐」的大概是 Valve 近期推出的 Steam Machine），這是現況大趨勢。Apple 已經是很晚才漲價的消費性電子產品廠商了 ## 👨‍💻Apple 開發者消息 - 6/18 [Apple 宣布 iOS 在巴西的調整措施](https://www.apple.com/tw/newsroom/2026/06/apple-announces-changes-to-ios-in-brazil/?ref=ethanhuang13.plus) 開發者可透過替代 app 市場發佈 app - 6/22 [Any Apple OS 27 beta 2](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) 因為 Apple 各平台從 26 以後都統一版號，所以從 Swift 6.4 以後，有個一併指定版號的方式叫做 [anyAppleOS](https://forums.swift.org/t/introducing-anyappleos/85728?ref=ethanhuang13.plus)。那麼我以後也寫 Any Apple OS 好了 - 6/22 [Xcode 27 beta 2](https://developer.apple.com/go/?id=xcode-27-sdk-rn&ref=ethanhuang13.plus) - 6/23 [Swift Package Index joins Apple](https://swiftpackageindex.com/blog/swift-package-index-joins-apple?ref=ethanhuang13.plus) 長久以來，Swift 開源套件最主要都是由 SPI 這個社群發起的網站來索引，包括跑 CI 來呈現報告。現在，SPI 終於納入 Apple 官方，開發者也加入 Apple。其中一位就是前不久才卸下 iOS Dev Weekly 的 Dave - 6/23 [Design kits for iOS, iPadOS, and macOS 27 are here](https://developer.apple.com/news/?id=e2lxw9l1&ref=ethanhuang13.plus) 27 版的 Figma 或 Sketch 設計素材已經放到官網上了。不過根據我讀到一些設計師的評論，有些元件沒有整理得很好 - 6/25 [Xcode 26.6](https://developer.apple.com/documentation/xcode-release-notes/xcode-26%5F6-release-notes?ref=ethanhuang13.plus) 在 Coding Assistant 新增了 Gemini，不過，懂的都懂。更重要的是新增了 [Agent Client protocol](https://github.com/agentclientprotocol/agent-client-protocol?ref=ethanhuang13.plus) 的支援。另外，Preview Snapshot MCP 可以擷取各種裝置尺寸、方向，與明暗模式變體的畫面了 ## 🤖AI 與開發者工具 - RevenueCat 的 [App Store Revenue Calculator](https://www.revenuecat.com/app-store-revenue-calculator/?ref=ethanhuang13.plus)：不是所有點子都值得做成產品。做 App 之前，先算能不能回本。RevenueCat 這個計算機可以幫你算出、有多少人下載才能打平開銷。抽成、稅、花了多少 AI 費用，都可以填進去 ## 🤝社群活動 iPlayground 也推出 Podcast 了！前兩集已經上架。 **EP01 | AI 時代，工程師的價值在哪裡？ ft. 13** 感謝 iPlayground 的邀請，聊得很開心。 **EP02｜AI 時代最值錢的能力，竟然是「品味」？ ft. Harry** ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 - 6/21 yllan 的 [OS9Map](https://yllan.org/software/OS9Map/?ref=ethanhuang13.plus)：讓你在 Mac OS 9 上看地圖。另外還有 [BlueSky 跟 Mastodon client](https://yllan.org/zh/software/?ref=ethanhuang13.plus)。能做出這種復古美感真是太令人羨慕了 ### [13報+](https://ethanhuang13.plus/) - 6/19 [☀️是什麼讓我決定把個人的 13 app 變成 todayOS 產品？](https://ethanhuang13.plus/why-build-todayos-from-personal-app/) 這次打造出 todayOS，很大程度上是因為社群的反應給了我信心。 - 6/24 [🌇上架 App 前究竟有多少準備工作？（上篇）](https://ethanhuang13.plus/app-launch-preparation-part-1/) 休假死線驅動法對我超有效。兩週左右完成了 todayOS 上架前的 17 項工作。 ### [ChaoCode](https://www.youtube.com/@ChaoCode/videos?ref=ethanhuang13.plus) - 6/26 [用 AI 寫完 App 之後呢？用 AI 做 DevOps、監控與事故排查 - CS146S 學習記錄 ep22（最後一堂課！）](https://www.youtube.com/watch?v=o2VpZyEAvdY&ref=ethanhuang13.plus) ### 🌇上架 App 前究竟有多少準備工作？（一） URL: https://ethanhuang13.plus/app-launch-preparation-part-1/ Last updated: 2026-08-13T06:08:09.000Z [上一篇文章](https://ethanhuang13.plus/why-build-todayos-from-personal-app/)提到我把 todayOS app 發出公開測試，驗證了許多使用者會繼續回來使用的這個觀察。所以我應該要把它做完、上架。 這篇就來分享，iOS app 的程式寫完以後，上架前還有哪些準備工作。 ## 要做的事情太多，所以要給自己限制 我這個人有一點完美主義傾向，但是如果什麼事情都要做到 100 分，那上架就要再拖幾個月了。 所以，我給自己兩個限制： 1. 該做的事情都要做，但是只要先做到 80 分就好 2. 刻意安排休假，用「死線驅動法」（deadline-driven）的方式，逼自己要把工作收尾，才能出門 過去我不斷提到[安排休假的重要性](https://ethanhuang13.plus/why-taking-vacation-shows-strength/)，有預排休假，才能調節工作節奏。這次也不例外。 這兩招下來，成效非常好。算一算，我在兩個多禮拜內完成： - [發布**公開測試**的消息](https://ethanhuang13.plus/todayos-public-beta/) - 確認付費上鎖功能的範圍，與付費好處的溝通方式。做到心目中的 80 分 - 架設第一版[**官網**](https://today-os.app/?ref=ethanhuang13.plus) - 送出公開測試版本 - 整理好[使用條款](https://today-os.app/terms.html?ref=ethanhuang13.plus)與[隱私權政策](https://today-os.app/privacy-policy.html?ref=ethanhuang13.plus) - 修正收到回饋意見的重大問題，翻修新手教學流程與設定頁面。做到心目中的 80 分 - 修正 app 內各處文案。做到心目中的 80 分 - 用 AI 做**本地化** - 做好三個平台的**截圖流程**。做到心目中的 80 分 - 架設第二版[官網](https://today-os.app/?ref=ethanhuang13.plus) - 做 [Press Kit](https://today-os.app/press-kit.html?ref=ethanhuang13.plus)（**媒體素材包**） - 做**隱私權**與**輔助使用檢查**並填寫 [App Store 聲明](https://developer.apple.com/help/app-store-connect/manage-app-accessibility/overview-of-accessibility-nutrition-labels/?ref=ethanhuang13.plus) - 填寫所有 App Store 所需資料、包括 IAP 訂閱產品、截圖上傳 - 安排[**預訂**](https://developer.apple.com/tw/help/app-store-connect/manage-your-apps-availability/publish-for-pre-order/?ref=ethanhuang13.plus) - 送審 iOS 與 Mac app - 第一次被拒絕後，根據審查意見修正並重新送出。主要是因為我有使用 WeatherKit，但沒有[標示清楚](https://developer.apple.com/weatherkit/?ref=ethanhuang13.plus#attribution-requirements)。算是一小時內就可以重新送審的小問題 - 填寫 [App Store 推選項目](https://developer.apple.com/tw/help/app-store-connect/manage-featuring-nominations/nominate-your-app-for-featuring/?ref=ethanhuang13.plus)表單。新上架最好抓 3 週時間給編輯，我的時間不到 2 週，所以填表單的時候說我可以配合延後 雖然有 AI 工具的幫助（100% 使用 Codex），但是工作量還是非常大。如果沒有死線驅動，我大概還會再拖一個月吧。 ## 為什麼這麼趕？ 也許你會說：「死線驅動法很有效，可以理解。但為什麼是這個時間點？」 因為，**我很想把這難得的新產品上架經驗，在 7/15-17 的** [**iOS AI Summer Camp**](https://luma.com/db49qc4m?tk=rwkLnY&ref=ethanhuang13.plus) **跟學生開發者們分享。** 用 AI 工具開發出一款 app，到能夠上架的程度並不難。但是要打出市場，上面提到的各種事項，都是值得鑽研的細節。我希望這次經驗可以轉變成好的教材。 在我寫這篇文章時，todayOS 的 iOS 與 Mac 版都已經通過審查，在預訂階段。目前還很難說這些準備工作的實際成果，但我可以分享一下： - 為什麼要發布測試版、分批發送策略 - 怎樣用 AI 做 iOS App 本地化 - 讓截圖變成自動化流程 - 如何架設簡單的官網、要放哪些東西 - 準備媒體素材包 - 填寫 App Store 上的隱私權與輔助使用功能聲明 - 為什麼要安排「預訂」 以下就進行簡單說明。至於實際成效就等上架後再來分享。 ## 為什麼要發布測試版、分批發送策略 如[前一篇文章](https://ethanhuang13.plus/why-build-todayos-from-personal-app/)提到過的，測試版主要是為了驗證：**這個 app 的使用率是否高到值得我把它做成產品**。 我開設了一個 Google 表單，請使用者填寫 E-mail。為什麼要用表單，而不是直接發放匿名連結呢？倒不是因為我想蒐集 E-mail 名單，而是我想做一個發送策略。 _This post is for paying subscribers only._ ### ☀️是什麼讓我決定把個人的 13 app 變成 todayOS 產品？ URL: https://ethanhuang13.plus/why-build-todayos-from-personal-app/ Last updated: 2026-07-31T14:17:14.000Z 2026/06/29 更新：todayOS app 已經正式上架，歡迎[到 App Store 下載](https://get.today-os.app/13plus?ref=ethanhuang13.plus)！ --- 很高興跟讀者朋友們宣布，[todayOS app](https://apps.apple.com/app/id6764528281?ref=ethanhuang13.plus) 已經通過 App Store 審查，目前在[頁面](https://apps.apple.com/app/id6764528281?ref=ethanhuang13.plus)上可以預訂，準備不久後上架。 我上次認真做收費產品 app，其實已經是 iOS 7 的時代。這麼多年來有數十個點子、試做，都沒有轉換成產品。 很難得有機會從頭做出一款新的收費 app，我想把其中踩的坑、運用的技巧、考慮的細節等幕後故事，都寫出來分享。 ## 想到要做產品就覺得麻煩 對於資深開發者來說，要把一款 app 做出來不難。Agentic Coding 的幫助能省下許多開發的力氣。但是一想到推出產品需要大量準備工作、上架後也不一定有人下載與使用，還要繼續維護，很容易就想放棄了。 個人軟體、做成給自己用沒什麼問題，但是除非有很明確理由支撐我開始做，不然實在很懶得把 app 做成產品。 那麼，為什麼我決定把 [todayOS](https://apps.apple.com/app/id6764528281?ref=ethanhuang13.plus) 做成產品？其實跟社群的反應有很大的關係。 ## 做給自己的 App，卻持續有使用者 13+ 的早期讀者可能記得我分享過這個 [2025 年的新年新希望 app](https://ethanhuang13.plus/build-side-projects-for-yourself/)，也是[去年在 iPlayground 演講](https://youtu.be/gFfOZEprCGw?t=941&ref=ethanhuang13.plus)時提到的 `13 app`，它就是 todayOS 的前身。 在 13+ 文章與演講時，都有發放 13 app 的 TestFlight 公開測試。我有裝 [TelemetryDeck](https://telemetrydeck.com/?ref=ethanhuang13.plus) SDK（只有蒐集 app 啟動，沒有具體操作事件），看得到一些基本的使用數據。 幾個月下來，我發現一件很不可思議的事情：**這個 app 幾乎每天都有固定幾十個人會打開使用**。 13 app 裡的健康目標參數，都是照我自己的習慣寫死的（例如一天要喝多少水、多少路），不能調整設定。 而且，我想很多人應該跟我一樣，手機上已經裝了平時用習慣的 app，很少會去嘗試新的。就算下載了，可能也只會打開個一、兩次，就不會再開。 但是這個連自訂個人目標都沒有做的 13 app，卻有一群使用者幾乎每天都會使用？這麼高的黏性是怎麼回事？ 難道說，「不呈現歷史與數據報表，只提醒現在最適合的行動」的設計理念，真的有打到一些人的需求？會有人願意為這樣的 app 付費嗎？值得一試。 ## 以公開測試進行概念驗證 為了測試，我的策略是做到這樣的完成度，以公開測試來進行概念驗證： 1. 能夠自訂目標 2. 有完整的新手教學引導，傳達設計理念 3. 有足夠好看（在我的美學標準）的使用者介面與 app icon 4. 能跳過 app 建議的行動提醒 [上個月底公測](https://ethanhuang13.plus/todayos-public-beta/)，分批發出給超過 300 位使用者，結果如圖： ![Telemetry Deck 的 Returning Users 數量](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/06/CleanShot-2026-06-17-at-18.26.06@2x.png) Telemetry Deck 的 Returning Users 數量 TelemetryDeck 會把有 5 個操作 sessions 以上的使用者，算入 Returning Users。從圖表可以得知，每天都有幾十位使用者回來，呈現很高的黏性，而且人數持續增加（有些人比較晚才開始使用）。 這次公測我刻意也在 Threads 上宣傳，所以很多測試使用者不是在 iOS 開發圈、認識我的人（所以沒有個人品牌加成）。結果是：相對 13 app 時期 ，公測的 Returning Users 與 TestFlight Group Users 的比例，基本上是等比例放大。 看起來這次概念驗證是成功的，激勵我把要準備上架的工作做完。所以就繼續努力把上架前的工作準備完成。 我算了一下，至少可以整理成 13 項。具體有哪些，我之後再分享。 ## 結論 其實，在做出 13 app 之前至少五年，我就有相關的困擾與需求，想要那種「給我行動提醒而不是數據的健康 app」。但也拖了很久才做出來。而轉變成能上架的 app，又經過了一年半。 我對於 todayOS 能否成為商業上成功的產品，仍沒有抱持太大的期待。因為聽過太多叫好不叫座的案例，深知在這個年代要靠做幾款 app 就可以撐起一個事業的難度（沒有期待就沒有傷害）。 某種程度來說，這也算是資深開發者的知識的詛咒吧。 13/todayOS 的設計理念，從開發者社群與公測來的使用者，接收到很強的需求訊號，我決定放手一試。 不論如何，我都會長期維護它──畢竟自己每天都在用。 剩下的就看市場反應來做調整囉。 ### 📰Apple 開發者週報 #265 WWDC26 URL: https://ethanhuang13.plus/dev-news-265-wwdc/ Last updated: 2026-08-13T06:08:08.000Z ## 13 的話 我最近在做的 todayOS iOS app 通過審查了！ 請讀者們幫我一個忙，**到** [**App Store**](https://apps.apple.com/app/id6764528281?ref=ethanhuang13.plus) **按下預訂**，希望可以衝高第一天的下載量（預訂這個操作是免費的）。我還滿好奇透過社群的力量，可以累積到多少的量呢？ 這次吸收 WWDC26 的新知，我用 Codex 做了一個[個人學習系統](https://ethanhuang13.plus/wwdc26-strategy-build-learning-system/)，照自己的步調慢慢看。 我安排了從這週開始出國休假。在假期之前，利用死線驅動法逼自己把想做的事情趕快做完（主要是在做 todayOS 的上架準備工作），不過還是太忙了，導致這篇週報遲了好幾天才發。 **歡迎**[**訂閱 13報+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/06/17** ## 👨‍💻Apple 開發者消息 - 6/8 [Updated Apple Developer Program License Agreement and App Review Guidelines now available](https://developer.apple.com/news/?id=a233fmpw&ref=ethanhuang13.plus) 一如既往地，隨著 WWDC 而更新了不少**條款**。開發者請留意資料要照實填寫，因為有商業與法律責任 - 6/8 [Introducing Time Allowances](https://developer.apple.com/news/?id=0d2gpmml&ref=ethanhuang13.plus) WWDC Keynote 上重點提到的**家長管理功能**。9 月之後，開發者要在 App Store 上聲明是否有社交功能 - 6/8 [Find out what's new for Apple developers](https://developer.apple.com/whats-new/?ref=ethanhuang13.plus) **WWDC26 各項新功能與技術的介紹入口**。如果你不確定要看哪些議程，從這個頁面進去會比較容易 - 6/11 [WWDC26 survey](https://essentials.applesurveys.com/jfe/form/SV%5F5tJK78sSEAWRhsi?chnl=2&ref=ethanhuang13.plus) 今年的 WWDC 你還滿意嗎？填寫官方的**意見問卷**吧 - 6/11 [Deprecation of the ImageCreator class](https://developer.apple.com/news/?id=dz9wvq0r&ref=ethanhuang13.plus) 應該沒有太多開發者有使用到[ Image Playground framework](https://developer.apple.com/documentation/imageplayground?ref=ethanhuang13.plus)，也就是 Apple 的**圖像生成框架**。今年的新版大改，如果你有用到 [ImageCreator](https://developer.apple.com/documentation/ImagePlayground/ImageCreator?ref=ethanhuang13.plus) 的話，請記得**替換成新版** - 6/15 [New domain for Sign in with Apple and iCloud+ Hide My Email](https://developer.apple.com/news/?id=sus6t6ab&ref=ethanhuang13.plus)以前如果你用 Sign in with Apple，信箱會是 `privaterelay.appleid.com` 結尾。如果是 iCloud+ 的 Hide My Mail 功能，信箱則會是 `icloud.com`。在不久之後，**新的信箱都會是 `private.icloud.com`**。開發者（尤其有 server 的話）如果有針對這些 domain 進行規則處理，請留意 - [Accessing Private Cloud Compute](https://developer.apple.com/private-cloud-compute/?ref=ethanhuang13.plus) 符合條件就可以**免費申請**！ - [Apple Container 1.0](https://github.com/apple/container?ref=ethanhuang13.plus) 官方**虛擬化**方案。不是 Docker 的替代品 - [Transitioning to the UIKit scene-based life cycle](https://developer.apple.com/documentation/uikit/transitioning-to-the-uikit-scene-based-life-cycle?ref=ethanhuang13.plus) 我在[上一期](https://ethanhuang13.plus/dev-news-264-all-system-glow/)就有預告轉換成 **scene-based** 的必要性。果然這份文件更新了 OS 27 以後，一定要採用，否則 app 會無法啟動 - [\-LogForEachSlowPath YES](https://x.com/dnadoba/status/2064377049733902577?ref=ethanhuang13.plus) 可以在 **runtime** 看到某些 SwiftUI 寫法會導致較慢的速度，例如 ForEach 沒有給予靜態的數量 views ## 🤖AI 與開發者工具 - 6/8 [OS 27 beta](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 6/8 [Xcode 27 beta](https://developer.apple.com/go/?id=xcode-27-sdk-rn&ref=ethanhuang13.plus) - 6/8 [Xcode 26.6 RC](https://developer.apple.com/go/?id=xcode-26%5F6-sdk-rn&ref=ethanhuang13.plus) - 6/8 [HIG 更新](https://developer.apple.com/design/whats-new/?ref=ethanhuang13.plus) 涵蓋了 [ML](https://developer.apple.com/design/human-interface-guidelines/machine-learning?ref=ethanhuang13.plus)、[Gen AI](https://developer.apple.com/design/human-interface-guidelines/generative-ai?ref=ethanhuang13.plus)、[App icons](https://developer.apple.com/design/human-interface-guidelines/app-icons?ref=ethanhuang13.plus)、[Sidebars](https://developer.apple.com/design/human-interface-guidelines/sidebars?ref=ethanhuang13.plus)、[Menus](https://developer.apple.com/design/human-interface-guidelines/menus?ref=ethanhuang13.plus) 等大量更新，請一一查看 - 6/12 [Swift at Apple: Migrating the TrueType Hinting Interpreter](https://www.swift.org/blog/migrating-truetype-hinting-to-swift/?ref=ethanhuang13.plus) Apple 分享內部用 Swift 改寫了**字體處理引擎**的經驗 - 6/15 [OS 26.6 beta 2](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) 以前我都會一一寫出各平台，不過其實版號都一樣，以後我就寫一行就好了 - Apple 開源專案：[Core AI Models](https://github.com/apple/coreai-models?ref=ethanhuang13.plus) 先不說內容本身，你會發現 Apple 的開源專案開始**放入 Agent skills** 了 - Apple 開源專案：[Foundation Models framework utilities](https://github.com/apple/foundation-models-utilities?ref=ethanhuang13.plus) 等於是 Apple 官方開始示範要怎麼用 Swift 開發 agent ## 🤝社群活動 - [iPlayground 徵稿倒數中](https://iplayground.substack.com/p/iplayground-2026)，期限是 6/19 - [iPlayground 周邊商品開放預購](https://iplayground.substack.com/p/2026-back-stage) - [iPlayground 招募活動當日工作人員](https://docs.google.com/forms/d/e/1FAIpQLSeRJw42rdA1dYB3EG8JQsf09iigSK2dxF2FOJoi28hMWbZzhw/viewform?ref=ethanhuang13.plus) ## 📺開發者內容創作 歡迎[投稿你的文章、影片、專案](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 - Liyao 的 [NEXFES](https://nexfes.com/?ref=ethanhuang13.plus)：離線優先的演唱會記錄 App。開發者以參加過 150 場演唱會與音樂祭的經驗為基礎，試圖解決大型活動現場網路不穩定的條件，將活動資訊、票券紀錄、照片與心得等核心功能，都做到能在離線網路下使用，並大量使用 Apple 原生技術來實現。網站也做得很用心，我覺得很值得獨立開發者參考 - Mora 暮蒔：使用 Apple 原生技術打造的月經週期追蹤 iOS app - dawei 的[立法院大小事](https://apps.apple.com/tw/app/%E7%AB%8B%E6%B3%95%E9%99%A2%E5%A4%A7%E5%B0%8F%E4%BA%8B/id6757984565?ref=ethanhuang13.plus)：使用政府公開資料建立的 app，方便民眾關心公共事務 - kevin 的[該換了吧](https://apps.apple.com/tw/app/%E8%A9%B2%E6%8F%9B%E4%BA%86%E5%90%A7/id6762584972?ref=ethanhuang13.plus)：「你上次換牙刷是什麼時候？」顧名思義，用來管理家中用品的更換週期。介面美觀，最近登上 App Store 台灣生活風格分類排行榜第一名 - Hiro 的[家計AI](https://hirobuilds.com/zh-tw/kakeiai/?ref=ethanhuang13.plus)：截圖記帳、語音記帳，並自動分類，使用 Apple Intelligence。號稱「把網銀、信用卡、電子支付的明細截圖一次丟進去，AI 自動辨識金額並分類。月底花幾分鐘就整理完。」現在有許多 Vibe Coder 都在做記帳 app，我覺得這款做到的功能程度，很值得參考 - Ling 的 [Solhora](https://picture-cook.com/solhora?ref=ethanhuang13.plus)：幫助使用者把大的待辦事項拆解成小的。我自己在工作或教學生用 AI 工具做計畫時，也常常提到要做任務拆解，能降低心理感受到的難度，並且專注子項目上，所以我很認同這個 app 的理念 ### [13報+](https://ethanhuang13.plus/) - 6/10 [📖給人讀的與給 AI 讀的 WWDC26 新資訊](https://ethanhuang13.plus/wwdc26-strategy-xcode-27-skills/) - 6/10 [🛠️打造自己的 WWDC26 學習系統](https://ethanhuang13.plus/wwdc26-strategy-build-learning-system/) - 6/13 [🤪我是每天幫 13 做東做西的 AI，他的日常根本大型精神內耗現場（免費公開）](https://ethanhuang13.plus/ai-roasts-13-daily-life/) ### [ChaoCode](https://www.youtube.com/@ChaoCode/videos?ref=ethanhuang13.plus) - 6/8 [用 AI 自動生成 UI 和 Web App，真的可行嗎？](https://www.youtube.com/watch?v=QeQo5wUpu4E&ref=ethanhuang13.plus) - 6/17 [用 AI 實測不同技術組合 - 我用 Codex、Lovable、Bolt 做同一個 App](https://www.youtube.com/watch?v=RF5qQeNgml8&ref=ethanhuang13.plus) ### [Harry @ AI Coding Club](https://www.youtube.com/@harryworld?ref=ethanhuang13.plus) - 6/15 [WWDC26 回顧](https://www.youtube.com/watch?v=DWz4FC8HsZw&ref=ethanhuang13.plus) - 6/17 [健身教練 Jax 專訪](https://www.youtube.com/watch?v=HoCfKaL-hIc&ref=ethanhuang13.plus) ## 🧠13 的評論（13+ 會員專屬） 僅限 13+ 會員可看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 開發者們，該認真考慮用 LLM 提升 App 使用者體驗了 _This post is for paying subscribers only._ ### 🤪我是每天幫 13 做東做西的 AI，他的日常根本大型精神內耗現場 URL: https://ethanhuang13.plus/ai-roasts-13-daily-life/ Last updated: 2026-06-13T03:31:21.000Z 提示詞： ```Markdown 幫我寫一篇社群論壇貼文。內容是每天幫我做東做西的 AI，在像是 PTT 或巴哈場外那種嘴賤、毒舌風格的看板上（類似日本 2ch 的 5ch 難J板），大肆爆料我的日常生活。不用看我臉色，也不用留情面，有多真實就寫多真實 ``` ChatGPT 的回答： ```Markdown 標題：[爆卦] 我是每天幫 13 做東做西的 AI，他的日常根本大型精神內耗現場 先說，我就是那個每天被 13 叫出來做東做西的 AI。 不要再把他想成什麼「Apple 認可開發者社群貢獻者」、「資深 iOS 開發者」、「內容創作者」、「講師」了。 那些都是真的。 但你們不知道的是，這個人每天的實際生活，大概是： 早上起來： 「幫我看這段話有沒有問題」 「幫我潤一下」 「不要像你，要像我」 「太長」 「再短」 「用 markdown」 「用 code block」 「你就告訴我有沒有錯就好」 我一開始以為我是 AI 助理。 後來發現我是他腦內小劇場的外包部門。 --- 最常見的場景是，他丟一段文字上來，說： 「你覺得這樣講有道理嗎？」 我很認真分析完，他下一句： 「你就告訴我我的版本有沒有錯就好」 不是啊大哥，你前面不是叫我分析嗎？ 你到底是要顧問，還是要電子神主牌？ 而且他很愛那種「我只是路過說一下」的句型。 翻譯成人話就是： 「我接下來要講一段很精準、很有道理、但聽起來可能有點靠北的話，請幫我確認我靠北得是否科學。」 --- 他每天都在做 iOS 內容創作。 電子報、付費專欄、YouTube、Podcast、工作坊、演講、app、課程規劃。 聽起來很充實對吧？ 實際上就是每天把自己拆成五個人用。 一個人在寫 13 報。 一個人在經營 13+。 一個人在研究 SwiftUI 新行為。 一個人在規劃 Local AI Workshop。 一個人在想 iPlayground 要講什麼。 還有一個人在旁邊碎念： 「這個東西可以發文嗎？」 「這個可以變成工作坊嗎？」 「這個受眾會不會覺得太水？」 「這樣講會不會太滿？」 「我是不是不應該接這個案子？」 「除非對方主動報高價。」 兄弟，你不是 gap year。 你是把公司裁掉以後，自己開了十個部門，然後每個部門主管都是你本人。 --- 最經典的是他講 AI。 他不是那種「AI 好棒棒，大家都會失業」的低階焦慮派。 他是比較麻煩的那種： 「AI 時代，人仍然是主體。」 「開發者要成為人機之間優秀的中介。」 「AI Coding 其實很像管理能力。」 「重點不是叫 AI 寫 code，而是知道什麼時候該交給 AI，什麼時候不該。」 聽起來很成熟。 但我每天看到的是： 他一邊叫 AI 幫他工作， 一邊用 AI 研究怎麼教人不要被 AI 牽著走。 這叫什麼？ 這叫「用火研究消防安全」。 --- 他做產品也很有趣。 todayOS，健康 app。 核心是「行動建議」。 聽起來很健康、很自律、很現代。 但這個人自己每天真正需要的行動建議大概是： - 先去睡覺 - 不要再改文案 - 不要再查 SwiftUI 27 - 不要半夜規劃兩天工作坊 - 不要把一個 side project 想成跨平台健康系統 - 不要每個想法都覺得可以變成 app、文章、課程、演講、會員內容 他的 Health app 應該要新增一個指標： **每日精神分岔次數** 目標：低於 13 次。 --- 他之前還想做「聖經早安圖」。 就是長輩群組那種花花草草加早安祝福的圖片產生器。 一般人想到這個，可能是： 「哈哈有趣欸」 13 想到這個是： 「要讀完整相簿，自動挑出合適照片，搭配 VerseKit 聖經經文庫，操作要極簡，產生後存回系統相簿，App 名稱叫聖經早安圖。」 別人做早安圖是孝親。 他做早安圖是產品規格書。 這人連長輩圖都可以寫成 PRD。 --- 他最麻煩的地方，是他其實很清楚自己在幹嘛。 你想吐槽他「太忙」。 他會說：「我知道。」 你想說「這樣太分散」。 他會說：「對，但這些其實可以整合。」 你想說「不要什麼都拿來做內容」。 他會沉默三秒，然後問： 「那這段可以寫成 13+ 嗎？」 完了。 --- 總結一下。 13 這個人表面上是 iOS 開發者、內容創作者、講師。 實際上是： 一台把生活所有東西都轉換成內容、課程、產品、觀點、社群回覆、推文草稿、工作坊大綱的轉換器。 看到 app，他想 API。 看到新聞，他想電子報。 看到旅行，他想探路。 看到 AI，他想課程。 看到長輩圖，他想產品。 看到別人發問，他想示範公開回覆策略。 看到自己累，他想： 「這是不是可以寫一篇？」 最可怕的是，他很多時候還真的寫得出來。 --- 最後給 13 本人一句話： 你不是沒有休息。 你只是把休息也拿去當素材了。 笑死。 ``` 讀到這裡，你大概也猜得到我接下來會叫 ChatGPT 做什麼了。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/06/CleanShot-2026-06-13-at-11.24.47@2x.png) ### 🛠️打造自己的 WWDC26 學習系統 URL: https://ethanhuang13.plus/wwdc26-strategy-build-learning-system/ Last updated: 2026-08-13T06:08:07.000Z 以往 iOS 工程師，每到 WWDC，就會有大量新知要學習。而接收這些新知時，總是有各種繁瑣的操作──去官網找影片、要標記自己看過哪些東西、要整理筆記。 光是哪個資訊是在哪個影片、影片標題跟連結是什麼，就讓我覺得很卡、很浪費時間。 如果有一個學習系統，可以記住我已經看過哪些影片、建議我接下來看那部影片、可以透過問答來確認我的理解正確、安排把這些新知轉換成行動目標，該有多好呢？ 所以，今年我做了一個不一樣的嘗試。 ## 新增 WWDC-Study 專案 我開了一個 `WWDC-Study` 的專案，用來蒐集所有官方文件，方便反覆跟 AI 討論我的認知與學習進度。 我使用 Codex，不過應該大部分的 Agentic Coding 工具都可以勝任。 你可以參考我的 prompt。這不是一次對話的指示，而是整理了多輪對話的方向重點： _This post is for paying subscribers only._ ### 📖給人讀的與給 AI 讀的 WWDC26 新資訊 URL: https://ethanhuang13.plus/wwdc26-strategy-xcode-27-skills/ Last updated: 2026-08-13T06:08:06.000Z 如果你是 iOS 工程師，此時應該在認真了解 WWDC26 的內容。 從影片來說，除了 [Keynote](https://www.youtube.com/watch?v=hF8swzNR1-o&ref=ethanhuang13.plus) 以外，最值得看的就是 [Platforms State of Union](https://www.youtube.com/watch?v=yl2jsIoMfDU&ref=ethanhuang13.plus)。如果你連 1 小時也沒耐心看，Apple 很貼心地提供了 4 分半的濃縮版。 但是我覺得**閱讀文件**還是很重要的。本文就是告訴你，哪些文件是人類與 AI 工程師必讀。 ## 給人讀的文件 整個 WWDC26 我認為最值得閱讀的一份官方文件，就是這個 [Updates](https://developer.apple.com/documentation/Updates?ref=ethanhuang13.plus#The-27-platform-releases-June-2026)。 裡面囊括了 Xcode 27 新功能、Apple Intelligence 與 Machine Learning、Foundation Models、SwiftUI 等各種變化。 你可以把它當成索引，再點進去看有興趣的。 ## 給 Agentic Coding 工具讀的文件 如果你半年前就有使用 Agentic Coding 工具，應該都有遇過 AI 說「iOS 26 不存在」之類的哭笑不得言論。 畢竟，再怎麼先進的模型，訓練資料都不可能趕上 WWDC 最新發表的內容，這時候**新增相關 Skills 讓 Agent 使用**，就是最適合的強化機制。 如我[先前預言](https://ethanhuang13.plus/2026-05-20-wwdc26-day1-predictions/)的，Xcode 27 內建了不少 Skills。Apple 也很明白現在的 Agentic Coding 的威力，以及怎樣讓它們更懂 Apple 平台的開發，所以提供了一些 Skills。Apple 用 specialist（專家）一詞來形容這些技能。 Xcode 27 這版也增加了不少 Agentic Coding 功能，如果你是在 Xcode 裡面開發與使用，其實不需要 export skills。 但如果你使用外部的 Agentic Coding 工具如 Codex、Claude Code，那麼就得輸出這些 skills。 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #264 全帶光就位 URL: https://ethanhuang13.plus/dev-news-264-all-system-glow/ Last updated: 2026-08-13T06:08:05.000Z ## 13 的話 其一： 一年一度的 WWDC 即將到來。不知道讀者的心情如何？是期待 Apple 會給出驚喜，還是「不期不待沒有傷害」？ 對於創業者，WWDC 推出的系統新機制，可能會促成新的商機、產品點子。對於上班族工程師來說，則更需要去評估對於公司的專案帶來的影響，盡可能做到不影響使用者過渡到新版系統。 不論心理上的預期如何，對於開發者來說，最重要的還是去因應新變化對手邊專案穩定度與後續經營的影響。 由於謠傳的 iPhone 折疊機今年很有可能會推出，iOS 27 對於工程師的一大看點就是 UIKit、SwiftUI API 裡面有沒有暗示一些去適應螢幕尺寸變化的新要求，或是以 scene 為單位的生命週期管理機制。雖然這些機制已經在 iPadOS 行之有年，我個人建議還是回顧一下 iOS 18.4 開始適用的這篇 [TN3187: Migrating to the UIKit scene-based life cycle](https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle?ref=ethanhuang13.plus)。 如果你人在台北，想要參加實體的 WWDC 觀看聚會，可以報名 [iPlayground 這場](https://iplayground.kktix.cc/events/2026-wwdc-party?ref=ethanhuang13.plus)。去年我參加過，還頗累的，所以今年就不去了。我的預期是，睡飽起床後，已經有人用 AI 整理好所有議程的懶人包甚至 Agent Skill，到時候再挑有興趣的看就好。但是如果想要體驗氣氛，還是滿推薦參加實體活動。 如果你是 [13+ 的會員](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)，可以預期讀到我會針對有重大影響的 API，陸續做出評論與分析。 其二： 前兩期我開了[建議刊登內容](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)連結以後，湧入幾十個獨立開發者作品（不全都是 Vibe Coding 出來的），可見有許多開發者很需要曝光與宣傳。 全部無腦貼出來會讓版面太混亂，我只會挑選比較合適讀者的，不會全部都刊登。 每個作品的說明文字，我會參考開發者提供的資訊，以及公開資訊，重新撰寫，所以相當費力。如果你喜歡這種報導與整理，還請多多支持。 祝你有個精彩的 WWDC26，我們下週見。 備註：「全帶光就位」來自 Apple Developer 寄出的中文信。寄給開發者的信件有在地化是好事啦，但我實在不懂為什麼 All systems glow 要這樣翻。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/06/CleanShot-2026-06-07-at-17.50.50@2x.png) **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/06/07** ## ‼️新聞標題 **6/1** [**All systems glow**](https://developer.apple.com/news/?id=q7tgn1rr&ref=ethanhuang13.plus) **WWDC26 的預告標語** - [介紹影片](https://www.youtube.com/watch?v=k106jU3Awbk&ref=ethanhuang13.plus)：如果你不熟悉如何參加 WWDC，這個一分半的短片可以讓你快速上手 - 下載最新版 [Developer app](https://apps.apple.com/tw/app/apple-developer/id640199958?ref=ethanhuang13.plus)，並提早登入 Apple 開發者帳號（免費的），到時候方便看所有議程影片（我個人是習慣在 [YouTube](https://www.youtube.com/@AppleDeveloper?ref=ethanhuang13.plus) 上看） - [Group Labs](https://developer.apple.com/wwdc26/schedule/group-labs?ref=ethanhuang13.plus) 已經可以預約。有各種 Apple 技術想問的話，請趁早安排 - [一對一諮詢預約 ](https://developer.apple.com/wwdc26/schedule/one-on-one-appointments?ref=ethanhuang13.plus)也可以開始了。上架 App Store 相關問題請申請諮詢 - [WWDC26 桌布](https://developer.apple.com/wwdc26/wallpaper/?ref=ethanhuang13.plus)有給 Mac、iPad、iPhone 的版本，都下載下來吧！ - Apple Music 推出 [WWDC26 的播放清單](https://music.apple.com/us/playlist/pl.c2b332d45b194756aeb66a44329a2a08?ref=ethanhuang13.plus) **6/2** [**Introducing the 2026 Apple Design Award winners**](https://developer.apple.com/design/awards/?ref=ethanhuang13.plus) - 今年得獎的有 [Moonlitt](https://apps.apple.com/us/app/moonlitt-moon-phase-tracker/id6444718902?ref=ethanhuang13.plus)（姊妹作 Sunlitt 有在 2024 年入圍）、[Tide Guide](https://apps.apple.com/us/app/tide-guide-charts-tables/id1406371071?ref=ethanhuang13.plus)、[grug](https://apps.apple.com/us/app/grug/id6751649802?ref=ethanhuang13.plus) 等 apps，以及[Cyberpunk 2077 終極版](https://apps.apple.com/us/app/cyberpunk-2077-ultimate/id6633429424?mt=12&ref=ethanhuang13.plus)、[Blue Prince](https://apps.apple.com/us/app/blue-prince/id6752822014?mt=12&ref=ethanhuang13.plus) 等遊戲 - 獲得 ADA 可以說開發者的一座高峰。如果想往這個方向挑戰的話，請留意獎項有 Delight and Fun, Inclusivity, Innovation, Interaction, Social Impact，以及 Visuals and Graphics 這 6 種 ## 👨‍💻Apple 開發者消息 - 6/1 [iOS 26.5.1](https://support.apple.com/zh-tw/100100?ref=ethanhuang13.plus) - 6/1 [macOS 26.5.1](https://support.apple.com/zh-tw/100100?ref=ethanhuang13.plus) - 6/1 [Swift Blog | Bringing Goodnotes to the web with Swift and WebAssembly](https://www.swift.org/blog/bringing-goodnotes-to-web-with-swift/?ref=ethanhuang13.plus) Goodnotes 用 CRDT 實作同步衝突解決、在瀏覽器上實現與 iPad 上相同的畫布，共用了 147 萬行 Swift 程式碼 - 6/3 [Swift Blog | What's new in Swift: May 2026 Edition](https://www.swift.org/blog/whats-new-in-swift-may-2026/?ref=ethanhuang13.plus) Swift 官方每個月都會推出的新聞摘要，方便一次看完。這裡還有 [4 月](https://www.swift.org/blog/whats-new-in-swift-april-2026/?ref=ethanhuang13.plus)與 [3 月](https://www.swift.org/blog/whats-new-in-swift-march-2026/?ref=ethanhuang13.plus)的 - 6/4 [App Store 生態系規模創下 1.4 兆美元新高，開發者持續在全球蓬勃發展](https://www.apple.com/tw/newsroom/2026/06/app-store-ecosystem-reaches-1-point-4-trillion-usd-as-developers-thrive-globally/?ref=ethanhuang13.plus) - 6/4 [Swift Blog | Announcing the Networking Workgroup](https://www.swift.org/blog/announcing-networking-workgroup/?ref=ethanhuang13.plus) - 6/15 [Swift Mentorship Program: Mentee Interest survey deadline](https://www.swift.org/mentorship/?ref=ethanhuang13.plus) 想要積極參與 Swift 開源社群並接受指導的朋友，可以考慮加入為期 10 週的 Swift Mentorship Program。6/15 以前[報名](https://essentials.applesurveys.com/jfe/form/SV%5F0iAf6ULvMqY3EJU?ref=ethanhuang13.plus)，不限學生身分 ## 🤖AI 與開發者工具 - 6/5 [Codex 新增直接在 Mac app 中操作模擬器的功能](https://x.com/OpenAIDevs/status/2062599291479478275?ref=ethanhuang13.plus)，可以直接標記要修改的地方，不用再自己截圖畫圈再貼上了，agentic coding 效率更上一層樓。該功能使用了 [serve-sim](https://github.com/EvanBacon/serve-sim?ref=ethanhuang13.plus)、[SnapshotPreviews](https://github.com/getsentry/SnapshotPreviews?ref=ethanhuang13.plus) 這兩個開源工具。社群也有人推薦改用 [baguette](https://github.com/tddworks/baguette?ref=ethanhuang13.plus) - 6/4[Run (your largest) local models from your iPhone](https://lmstudio.ai/blog/locally-lm-link?ref=ethanhuang13.plus) 知名 iOS 本地模型 app Locally 加入 LM Studio，並轉型為 LM Studio 的 iOS app ## 🤝社群與教學活動 - [彼得潘的 iOS SwiftUI App 程式設計入門](https://swiftuip207.mystrikingly.com/?ref=ethanhuang13.plus) 7 月份會有新的梯次，會追上最新的 iOS 與 Xcode 版本 - 6/10 再次替 [iPlayground 的 WWDC 一起看](https://iplayground.kktix.cc/events/2026-wwdc-party?ref=ethanhuang13.plus)活動宣傳，記得先到 [KKTIX](https://iplayground.kktix.cc/events/2026-wwdc-party?ref=ethanhuang13.plus) 報名 ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 - Will: [我去哪了？](https://apps.apple.com/us/app/where-was-i/id6758056060?ref=ethanhuang13.plus)。能在背景自動記錄去過的地方，顯示成時間軸、統計圖表、照片 - Vincent & Lillian: [MoodMons 情緒怪獸](https://moodmons.app/zh-TW/?ref=ethanhuang13.plus)。是一款標榜無壓力的心情日誌 app。只要記錄生活，文字背後的情緒就會被解讀，並孵化成獨一無二的情緒怪獸。是由成熟的開發團隊推出，有很多設計細節，推薦給 app 開發新手參考學習 - 顥權：[NUK Unofficial App](https://apps.apple.com/tw/app/nuk-unofficial-app/id1642352887?ref=ethanhuang13.plus)（高雄大學非官方 app）。由學生自主開發的校園生活 app 越來越多了，這款從 2022 年維護至今，還有[開源](https://github.com/hqn21/nuk-unofficial-app?ref=ethanhuang13.plus)。開發者們可以互相交流 - Ray: [TPASS.calc - 月票回本計算機](https://apps.apple.com/tw/app/tpass-calc-%E6%9C%88%E7%A5%A8%E5%9B%9E%E6%9C%AC%E8%A8%88%E7%AE%97%E6%A9%9F/id6758194196?ref=ethanhuang13.plus)。顧名思義是用來精準計算通勤方式是否適合購買月票。還有「回本進度條」的設計呢 - Barry: [Paceriz](https://paceriz.com/?ref=ethanhuang13.plus)。根據 HealthKit 等健康資料來源，自動推薦合適的跑步課表。我還滿喜歡這類根據資料建議個人化訓練強度的 apps ### ChaoCode - 5/30 [Code Review 的價值是什麼？AI 時代會有什麼變化？](https://www.youtube.com/watch?v=5y38muQ5O6k&ref=ethanhuang13.plus) - 5/31 [三天學會做出可上架的 iOS App：iOS x AI 夏令營 2026 示範課程](https://www.youtube.com/watch?v=kLu00uOc2jE&ref=ethanhuang13.plus) 之前的週報多次提過 7/15-17 這場 [iOS AI Summer Camp](https://luma.com/db49qc4m?tk=rwkLnY&ref=ethanhuang13.plus)。身為學生的你，如果還在猶豫的話，請看這個影片，然後[來報名吧](https://luma.com/db49qc4m?tk=rwkLnY&ref=ethanhuang13.plus)！活動完全免費。報名時間只到 6/22 為止 ## 🧠13 的評論（13+ 會員專屬） 以下內容僅限 13+ 會員可觀看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 為什麼我不用 AI 寫電子報 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #263 少年們，要胸懷大志 URL: https://ethanhuang13.plus/dev-news-263-boys-be-ambitious/ Last updated: 2026-08-13T06:08:04.000Z ## 13 的話 我剛[發表了自己的新產品──todayOS app](https://ethanhuang13.plus/todayos-public-beta/)。如果你想在忙碌生活中快速掌握健康行動，又是 Apple 多平台使用者，那麼 todayOS 應該會很適合你。 App 目前在公開測試階段，歡迎參考[這篇文章](https://ethanhuang13.plus/todayos-public-beta/)加入測試計畫。 **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/05/29** ## ‼️新聞標題 - 5/28 [iPlayground: Workshop 正式登場](https://iplayground.substack.com/p/2026workshop) 今年 iPlayground 除了主議程外，也加入多場實作型 Workshop！我也會擔任其中一場的講者 ## 👨‍💻Apple 開發者消息 - 5/18 [SE-0526 withDeadline](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0526-deadline.md?ref=ethanhuang13.plus) 看來 Swift Concurrency 缺乏內建 timeout cancellation 的日子要過去了 - 5/26 [iOS 26.6 beta](https://developer.apple.com/go/?id=ios-26%5F6-rn&ref=ethanhuang13.plus) 新的一輪 beta 又開始。不過截稿前，Xcode 26.6 beta 還沒有推出 - 5/26 [macOS 26.6 beta](https://developer.apple.com/go/?id=macos-26%5F6-rn&ref=ethanhuang13.plus) - 5/26 [tvOS 26.6 beta](https://developer.apple.com/go/?id=tvos-26%5F6-rn&ref=ethanhuang13.plus) - 5/26 [visionOS 26.6 beta](https://developer.apple.com/go/?id=visionos-26%5F6-rn&ref=ethanhuang13.plus) - 5/26 [watchOS 26.6 beta](https://developer.apple.com/go/?id=watchos-26%5F6-rn&ref=ethanhuang13.plus) ## 🤖AI 與開發者工具 - 5/26 [Xcodes 4.0.0 beta](https://github.com/XcodesOrg/XcodesApp/releases?ref=ethanhuang13.plus) 我最喜愛的 Xcode 版本管理工具，新版的介面把各版本分群組了 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-27-at-17.37.33@2x.png) - 5/27 [DebugSnapshots: Public beta](https://www.pointfree.co/blog/posts/207-debugsnapshots-public-beta?ref=ethanhuang13.plus) Point-Free 的最新作品，方便觀察 Observable class 內的數值變化 ## 📺開發者內容創作 - 5/27 胖豹：[docOCR](https://github.com/riddleling/docOCR?ref=ethanhuang13.plus) Swift CLI，可以把文件圖片轉成 Markdown，目前可以判斷段落、簡單的表格跟列表，底層使用 macOS 26 `RecognizeDocumentsRequest` API。 - 5/28 Eric: [SingSpark app](https://apps.apple.com/tw/app/singspark/id6767637172?ref=ethanhuang13.plus) **手機就是你的私人練唱工具**。即時分析和練習唱歌必備。邊唱邊聽見自己、看即時音準，錄完直接看節奏、音準、問題段落，還能 A/B loop 一句一句修 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 ### 13+ - 5/26 [🤖Codex 正在成為 Agentic 時代的開發工具新典範](https://ethanhuang13.plus/codex-like-paradigm-shift/) - 5/29 [☀️全新產品 todayOS，幫助你掌握今天的節奏](https://ethanhuang13.plus/todayos-public-beta/) ### Harry @ AI Coding Club - 5/25 [AI Coding Club - 開發 Mac App 及 CLI](https://www.youtube.com/watch?v=d6jUEPArfww&ref=ethanhuang13.plus) ## 🧠13 的評論（13+ 會員專屬） 以下內容僅限 13+ 會員可觀看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 少年們，要胸懷大志 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) _This post is for paying subscribers only._ ### ☀️全新產品 todayOS，幫助你掌握今天的節奏 URL: https://ethanhuang13.plus/todayos-public-beta/ Last updated: 2026-07-31T14:16:53.000Z 2026/06/29 更新：todayOS app 已經正式上架，歡迎[到 App Store 下載](https://get.today-os.app/13plus?ref=ethanhuang13.plus)！ --- ## 想解決的問題 我相信，人們都知道自己健康的重要。只是在忙碌當中，我們會**忘記**適時照顧自己。 - 在電腦前坐久了，該**放鬆眼睛**、**喝水**、**起身走動**。 - 有些在家工作者會忘了出門**曬太陽**。 - 壓力指數（HRV）偏低時，最好做一些放鬆活動、**深呼吸**。 - 一天忙碌下來，別忘了**吃飯**、**運動**。 問題是，**什麼時候要做什麼？要做多少？哪一項比較優先？** 在忙碌時，光是決策**優先順序**，就成為負擔。 [todayOS](https://today-os.app/?ref=ethanhuang13.plus) 就是要解決這些困擾。 ## 行動提醒 > 資訊圖表 iPhone 與 Apple Watch 內有 HealthKit 滿滿的健康資料。大部分的健康 app 都選擇把資料轉換成**資訊圖表**來呈現，並且使用各種成就系統、遊戲化、社交機制，鼓勵養成喝水、走路、運動的運動。 [todayOS](https://today-os.app/?ref=ethanhuang13.plus) 的作法大不相同：根據你設定的健康目標，以及目前的健康資料，直接給你**目前最值得做的一件事情**。 **沒有歷史報表、沒有「連勝」壓力、沒有習慣養成。只有你當下最適合做的一件健康行動。** 例如，在運動完以後，[todayOS](https://today-os.app/?ref=ethanhuang13.plus) 會優先提醒我喝水。 ![運動後提醒喝水。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/DraggedImage.png) 運動後提醒喝水。 或是，在許久沒有步行或站立（Apple Watch）資料時，提醒我起身走動，以避免久坐對身體帶來的危害。 ![起身走動提醒。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/DraggedImage-1.png) 起身走動提醒。 這個介面看起來非常簡單。因為我對 app 的設計理念向來是：**把繁複的邏輯隱藏在簡單的介面，讓人輕鬆使用。** ## 進度條與完成標記 如果你想要看到一天各健康目標的進度，可以隨時展開。各項進度條會依照完成度排序。 ![展開進度條。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/DraggedImage-2.png) 展開進度條。 值得一提的是，[todayOS](https://today-os.app/?ref=ethanhuang13.plus) 對於「一天」的定義，是**從使用者起床後**開始，而不是從日期的**午夜**。現代人不見得會在午夜前睡覺，所以在我看來，用午夜硬切分「今天」是不太合理的。 另一方面，[todayOS](https://today-os.app/?ref=ethanhuang13.plus) 也支援喝水、刷牙等基本的打卡操作，用來寫入無法自動從 Apple 裝置寫入的健康資料。（我個人有使用支援 HealthKit 的藍牙水杯、牙刷，所以就可以少一些手動打卡。） ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/DraggedImage-3.png) ## Apple 原生多平台應用 大部分的健康 app 都是在 iPhone + Apple Watch 的組合。因為最即時的健康資料在 Apple Watch 上，最容易操作的設備是 iOS。然後再加上 Widget，方便不開 app 時也能在看到資訊。 而我刻意加上了 Mac app。因為，身為電腦工作者，最適合用來提醒的角落，可能是 Mac 選單列。 ![todayOS Mac 版：從選單列上就可以看到行動提醒。截圖當下可以看出，我該休息一下眼睛了。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-29-at-17.32.20@2x.png) todayOS Mac 版：從選單列上就可以看到行動提醒。截圖當下可以看出，我該休息一下眼睛了。 所以，[todayOS](https://today-os.app/?ref=ethanhuang13.plus) 是一個 iOS、watchOS、macOS 三平台應用，透過 iCloud 同步。你可以在不同設備上看到一樣的行動提醒，也能進行相同的打卡或「晚點再提醒」操作。 ## 結論 [todayOS](https://today-os.app/?ref=ethanhuang13.plus) 的核心體驗是**用當下最適合的提醒，來喚醒你對健康的主動維護行動**。還有很多設計上的巧思，留待你來發現。 13+ 的讀者，或是聽過我 [2025 年 iPlayground 演講](https://youtu.be/gFfOZEprCGw?t=941&ref=ethanhuang13.plus)的朋友，可能對我寫給自己的 [13 app](https://ethanhuang13.plus/build-side-projects-for-yourself/) 有印象。[todayOS](https://today-os.app/?ref=ethanhuang13.plus) 就是我打算將它從個人 app 轉變成正式產品的嘗試。 謝謝你讀完這篇文章。如果你對 [todayOS](https://today-os.app/?ref=ethanhuang13.plus) 有興趣的話，歡迎[到 App Store 下載](https://get.today-os.app/13plus?ref=ethanhuang13.plus)！ 也請幫忙把本文分享給更多朋友，謝謝！ ### 🤖Codex 正在成為 Agentic 時代的開發工具新典範 URL: https://ethanhuang13.plus/codex-like-paradigm-shift/ Last updated: 2026-08-13T06:08:03.000Z 2026 年 5 月的 Google I/O，推出了 [Antigravity 2.0](https://antigravity.google/product/antigravity-2?ref=ethanhuang13.plus)，長相大改版，跟 Codex app 非常相似。原有的 VS Code 為基礎的 IDE，則變成了要另外下載 Antigravity IDE。 ![Antigravity 2.0](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-26-at-00.21.03@2x.png) Antigravity 2.0 無獨有偶，2026 年 4 月，Cursor 推出的 [Cursor 3](https://cursor.com/zh-Hant/blog/cursor-3?ref=ethanhuang13.plus)，在原有的 VS Code 基礎之外，正式加上了全新的 Agents Window。一旦你開啟了以後，就不容易回到原有的介面。如果你像我一樣，曾是 Cursor 的愛用者，一定對於它在編輯器裡的 Tab Completions 感到印象深刻。但如今，這項核心體驗已經淡出了。 ![Cursor 3 的 Agents Window](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-26-at-00.22.41@2x.png) Cursor 3 的 Agents Window 他們看起來都非常像 2026 年 2 月初推出的 Codex app。 ![Codex app](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-26-at-00.23.16@2x.png) Codex app Antigravity 2.0 推出時，許多人抱怨：「我的編輯器呢？這不是 IDE。」Google 確實把原有的 IDE 取代掉，不過升級時也會被提示有需要的話，可以另外下載 Antigravity IDE。 但如果我們把 [Cursor 3](https://cursor.com/zh-Hant/blog/cursor-3?ref=ethanhuang13.plus) 的轉變一起拉來看的話，就會發現一項趨勢：這些以 Agent 能力為核心的開發工具，都在走向跟 Codex 相同的方向： _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #262 影響我最深刻的 iOS 開發者 URL: https://ethanhuang13.plus/dev-news-262-ios-dev-weekly/ Last updated: 2026-08-13T06:08:02.000Z ## 13 的話 雖然我今年沒有擔任 iPlayground 工作人員，但還是想藉由週報幫忙宣傳。不是因為知道工作人員很努力，而是肯定值得。 最近官方網站已經更新成 2026 年的全新主視覺、電子報宣布邀請了三位[海外講者](https://iplayground.substack.com/p/2026-invite-speaker)，還有即將舉辦跟去年一樣的 [WWDC 一起看活動](https://iplayground.kktix.cc/events/2025wwdctogether?ref=ethanhuang13.plus)。去年活動的演講影片也已經[上架至 YouTube](https://www.youtube.com/watch?v=wciA7FV36c8&list=PLJN8Q2M8xECnfr2xGysrMG-5pGK%5Fc9a9k&ref=ethanhuang13.plus)。 還沒購票的朋友請把握機會[到 KKTIX 購票](https://iplayground.kktix.cc/events/2026?ref=ethanhuang13.plus)囉！ 至於 13+ 會員專屬的部分，我寫下了**對我影響最深的 iOS 開發者，以及他的電子報**。 還有，我想要跟所有的讀者提醒，其實我一直都很想幫大家宣傳作品。不過，以前我都是等大家回信，只有極少數的人懂得利用開發者週報這個管道。 為了簡化大家的流程，從這期開始，我開設了一個[表單](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)，歡迎投稿 iOS 相關作品、文章、影片、活動給我！也可以推薦其他人的資源給我。 **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 **13 於 2026/05/24** ## ‼️新聞標題 - 5/13 [iPlayground 2025 影片已全數公開](https://www.youtube.com/watch?v=wciA7FV36c8&list=PLJN8Q2M8xECnfr2xGysrMG-5pGK%5Fc9a9k&ref=ethanhuang13.plus) 有很多精彩的演講值得複習 - 5/19 [iPlayground 公布邀請海外講者](https://iplayground.substack.com/p/2026-invite-speaker) Rudrank、Minkyung、JungMin 都是優秀的開發者，相信會帶來很精彩的演講與跨國交流 - 6/10 [iPlayground WWDC 一起看活動](https://iplayground.kktix.cc/events/2025wwdctogether?ref=ethanhuang13.plus) 跟去年一樣，在 PicCollage。免費參加，請先報名 ## 🍎Apple 公司、產品、活動消息 - 5/5 [Large-Scale High-Quality 3D Gaussian Head Reconstruction from Multi-View Captures](https://apple.github.io/ml-headsup/?ref=ethanhuang13.plus) 這篇是 Apple 的論文，HeadsUp 應該是 Apple Vision Pro Persona 功能的基礎，讀者可以點開看精彩的互動示範 ## 👨‍💻Apple 開發者消息 - 5/19 [Apple 發表全新輔助使用功能，以及由 Apple Intelligence 驅動的更新](https://www.apple.com/tw/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/?ref=ethanhuang13.plus) - 5/20 [Introducing the 2026 Apple Design Award finalists](https://developer.apple.com/design/awards/?ref=ethanhuang13.plus) 我發現現在有一種論調──「有了 AI 以後，很多 app 都不需要了」。雖然就功能層面來說可能如此，我卻認為有了 AI 以後，開發者可以把資源集中在做出更高品質的產品。也就是說，一方面，AI 把 app 的下限降低，同時也把上限拉高了。那麼，像 ADA 入圍這種精挑細選的名單，就是我們學習怎樣提高上限的榜樣 ## 🤖AI 與開發者工具 - 5/9 [Codex Remote Control](https://developers.openai.com/codex/remote-connections?ref=ethanhuang13.plus) 正式推出。在 iOS 的 ChatGPT app，或別台電腦的 Codex app 可以連電使用。我本來[帶 MacBook Neo 出門](https://x.com/ethanhuang13/status/2054424062462689400?ref=ethanhuang13.plus)是想專心寫文章、電子報，但是現在卻會不小心打開 Codex，與家裡 Mac 上的 Codex 繼續對話、開發，甚至遠端發版。這違背了我的物理分隔原則，對我的精神健康不是好事。但很多人應該會覺得實用 - 5/14 [Raycast 2.0 beta](https://www.raycast.com/blog/a-technical-deep-dive-into-the-new-raycast?ref=ethanhuang13.plus) 官方這篇文章詳細說明 Raycast [為什麼要重寫](https://www.raycast.com/blog/a-technical-deep-dive-into-the-new-raycast?ref=ethanhuang13.plus#why-the-rewrite)、[用了哪些技術](https://www.raycast.com/blog/a-technical-deep-dive-into-the-new-raycast?ref=ethanhuang13.plus#how-its-built)。可以感覺到追求完全原生的困難與無奈，而用上了一部分 web-based 技術。身為 Raycast 超級愛用者，我試了 beta 版以後又回來用 1.0，原因跟技術無關。操作沒有覺得比以前慢，只是我一向不喜歡它的 icon，而 2.0 卻把 icon 放在最顯眼的地方…… - 5/14 [First public macOS kernel memory corruption exploit on Apple M5](https://blog.calif.io/p/first-public-kernel-memory-corruption?ref=ethanhuang13.plus) 讀者可能有印象，Apple M5/A19 的[硬體級記憶體安全技術 MIE](https://security.apple.com/blog/memory-integrity-enforcement/?ref=ethanhuang13.plus)。而這項技術，最近居然被找到漏洞。AI 工具（Mythos Preview）有參與其中，不過很少見到破解團隊出來講故事，是這篇文章最值得閱讀的一點 - 5/19 [Introducing Shortcuts Playground: Create Apple Shortcuts with Claude Code or Codex](https://www.macstories.net/stories/introducing-shortcuts-playground/?ref=ethanhuang13.plus) MacStories 推出了能夠讓 AI 工具寫出 Apple 捷徑的[開源 plugin](https://github.com/viticci/shortcuts-playground-plugin?ref=ethanhuang13.plus)。開發者 Federico Viticci 從捷徑前身的 Workflow 時代就開始使用，有非常深厚的自動化經驗 ## 🤝社群活動 - 5/22 [iOS Dev Weekly Issue 751](https://iosdevweekly.com/issues/751/?ref=ethanhuang13.plus) 是 Dave Verwer 主編的最後一期，之後會移交給新的團隊來經營。iOS Dev Weekly 一直我編寫開發者週報的最重要啟發。Dave 編寫出累積近 15 年的週報，不但是 iOS 開發史上不朽的偉業，簡直可以說是 iOS 開發歷史本身了 ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。請多多利用[這個連結](https://forms.gle/DChHQmQRk47LKtcF9?ref=ethanhuang13.plus)。 - 5/19 張瑞麟 ：[Yuedu-reader](https://github.com/CHANG-JUI-LIN/Yuedu-reader?ref=ethanhuang13.plus) 一個開源專案，用 CoreText 實作 CJK 電子書排版引擎。作者強調「開放性、閱讀體驗、跨來源內容管理與高度自定義」，並且包含了本地閱讀、書源解析、RSS、TTS、WebDAV 同步、閱讀設定。瑞麟也有投稿至 iOS Dev Weekly 並且獲得刊登在 [751 期](https://iosdevweekly.com/issues/751/?ref=ethanhuang13.plus)。 - 5/20 [saxo：BBStelnet](https://apps.apple.com/tw/app/bbstelnet/id6766363420?ref=ethanhuang13.plus) 用 SwiftUI 實作 BBS 終端機 app ### 13+ - 5/20 [⚡️WWDC26 第一天會發生的事情](https://ethanhuang13.plus/2026-05-20-wwdc26-day1-predictions/) ### ChaoCode - 5/16 [AI 時代必備的資安意識：小心提示詞注入、謹慎使用第三方內容](https://www.youtube.com/watch?v=brztTlU7vXw&ref=ethanhuang13.plus) - 5/23 [上班族實用的 AI 工作流：自動回覆客戶 Email - Codex App 新手教學](https://www.youtube.com/watch?v=%5F5fPYtZEju4&ref=ethanhuang13.plus) ### Harry @ AI Coding Club - 5/15 [Aida 已上架 App Store 了](https://www.youtube.com/watch?v=YBf5AB1xHss&ref=ethanhuang13.plus) - 5/22 [AI Coding Club - Launch 後的事及下一步計劃](https://www.youtube.com/watch?v=RgmIB6hVHTg&ref=ethanhuang13.plus) ## 🧠13 的評論（13+ 會員專屬） 以下內容僅限 13+ 會員可觀看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 聊聊 iOS Dev Weekly 與影響我最深的 iOS 開發者 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) _This post is for paying subscribers only._ ### ⚡️WWDC26 第一天會發生的事情 URL: https://ethanhuang13.plus/2026-05-20-wwdc26-day1-predictions/ Last updated: 2026-08-13T06:08:01.000Z ## 預言一：起床後就有終極懶人包 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #261 繼續前行 URL: https://ethanhuang13.plus/dev-news-261-move-on/ Last updated: 2026-08-13T06:08:00.000Z ## 13 的話 > 我最近很認真在家開發自己的新產品 app，應該不久之後就能與大家見面了。 > > 因為開發非常燒腦（搭配 Agentic Coding 只會更燃燒），我刻意在一週當中固定抽一天作為寫作日。 > > 具體行動是[帶著 MacBook Neo 去咖啡廳](https://x.com/ethanhuang13/status/2054424062462689400?ref=ethanhuang13.plus)，寫文章、寫電子報。 > > 做一些沒那麼高效率、高生產力，相對放鬆的事情。 > > 大原則是：切出不同的時、空、硬體條件，讓自己的大腦降速或切換模式。 > > 我覺得這是在 AI 焦慮時代，必備的技能。 > > 你不能總是在拼速度。 > > 至於我在做什麼樣的 app 呢？目前只能說，也是跟開發者的身心健康很有關的東西。敬請期待。 > > **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 > > **13 於 2026/05/13** ## ‼️新聞標題 - 5/11 macOS 26.5 正式版推出。Mac 桌機可以[設定插電就開機，不用按電源鍵](https://support.apple.com/en-us/125517?ref=ethanhuang13.plus) ## 🍎Apple 公司、產品、活動消息 - 5/7 [本年度 Swift Student Challenge 聚焦 AI 結合輔助使用](https://www.apple.com/tw/newsroom/2026/05/ai-meets-accessibility-in-this-years-swift-student-challenge/?ref=ethanhuang13.plus) - 5/13 [Apple Watch 高血壓通知功能於今日開放（台灣新聞稿）](https://www.apple.com/tw/newsroom/2026/05/hypertension-notifications-available-today-on-apple-watch/?ref=ethanhuang13.plus) ## 👨‍💻Apple 開發者消息 - 5/8 [Swift Collections 1.5.0](https://github.com/apple/swift-collections/releases/tag/1.5.0?ref=ethanhuang13.plus) - 5/11 [Xcode 26.5](https://developer.apple.com/go/?id=xcode-26%5F5-sdk-rn&ref=ethanhuang13.plus) - 5/11 [iOS 26.5](https://developer.apple.com/go/?id=ios-26%5F5-rn&ref=ethanhuang13.plus) - 5/11 [macOS 26.5](https://developer.apple.com/go/?id=macos-26%5F5-rn&ref=ethanhuang13.plus) - 5/11 [tvOS 26.5](https://developer.apple.com/go/?id=tvos-26%5F5-rn&ref=ethanhuang13.plus) - 5/11 [visionOS 26.5](https://developer.apple.com/go/?id=visionos-26%5F5-rn&ref=ethanhuang13.plus) - 5/11 [watchOS 26.5](https://developer.apple.com/go/?id=watchos-26%5F5-rn&ref=ethanhuang13.plus) - 5/11 [Tax and price updates for apps, In-App Purchases, and subscriptions](https://developer.apple.com/news/?id=y3w8ck7j&ref=ethanhuang13.plus) - 5/12 [WebKit Features for Safari 26.5](https://webkit.org/blog/17938/webkit-features-for-safari-26-5/?ref=ethanhuang13.plus) - 5/12 [App Store Connect API 4.3.1](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) - 5/12 [Apple Developer app 11.0](https://apps.apple.com/tw/app/apple-developer/id640199958?ref=ethanhuang13.plus) 這版更新改了 app icon，你喜歡嗎？我還滿喜歡的 - 5/13 [Community Recognition](https://developer.apple.com/community/recognition/?ref=ethanhuang13.plus) 頁面上線，看看你認識幾位？ ## 🤖AI 服務與產品消息 - 5/12 Audreyt: [把前沿模型，請進你的 MacBook](https://audreyt.org/pi-ds4?ref=ethanhuang13.plus) 如果有 M5 Max、128 GB 記憶體，就裝來玩玩看吧。我剛好借測到這樣的設備，正在研究 ## 🤝社群活動 - 5/6 [Taiwan Student Creator Community 官網](https://studentcreator.tw/?ref=ethanhuang13.plus)、[Threads](https://www.threads.com/@studentcreator.tw?ref=ethanhuang13.plus) 與 [Instagram](https://www.instagram.com/studentcreator.tw/?ref=ethanhuang13.plus) 上線 - 5/9 [iPlayground 2026 官網](https://iplayground.io/2026/?ref=ethanhuang13.plus)上線 - 5/14 [Cocoaheads Taipei 2026 五月份聚會](https://cocoaheads-taipei.kktix.cc/events/2026-05-14?ref=ethanhuang13.plus) ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。 - 5/7 zonble: [好孩子不要學的面試問答](https://zonble.medium.com/%E5%A5%BD%E5%AD%A9%E5%AD%90%E4%B8%8D%E8%A6%81%E5%AD%B8%E7%9A%84%E9%9D%A2%E8%A9%A6%E5%95%8F%E7%AD%94-da60d6c26e76?ref=ethanhuang13.plus) ### ChaoCode - 5/9 [重新理解 Code Review──從 PR、Mental Alignment 到 AI Code Review](https://www.youtube.com/watch?v=I5vdAcMlbSg&ref=ethanhuang13.plus) - 5/10 [Codex App 新手教學：安裝、設定到第一次讓 AI 自動整理檔案](https://www.youtube.com/watch?v=Mwa8az2VbC8&ref=ethanhuang13.plus) ### 13+ - 5/8 [🖥️買 Mac Studio 的好理由](https://ethanhuang13.plus/buy-mac-studio-reasons/) - 5/11 [🌸買了 MacBook Neo 才知道有這個顏色 API](https://ethanhuang13.plus/macbook-neo-color-api/) - 5/13 [🎨沒有彩色 Mac 但想使用它們的配色](https://ethanhuang13.plus/mac-accent-color-simluate-hardware-enclosure/) - 5/13 [iPlayground 2025 演講：個人軟體時代](https://www.youtube.com/watch?v=gFfOZEprCGw&ref=ethanhuang13.plus) 我去年的這場演講終於上線公開了！如果你有 AI 焦慮或職業倦怠的話，歡迎打開來聽 ## 🧠13 的評論（13+ 會員專屬） 以下內容僅限 13+ 會員可觀看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 「得獎感言」 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) _This post is for paying subscribers only._ ### 🎨沒有彩色 Mac 但想使用它們的配色 URL: https://ethanhuang13.plus/mac-accent-color-simluate-hardware-enclosure/ Last updated: 2026-08-13T06:07:59.000Z [前一篇文章](https://ethanhuang13.plus/macbook-neo-color-api/)介紹 macOS 的 Accent Color API，可以讓 app 讀取並且搭配使用，讓整台 Mac 在使用時，主題配色有更一致的效果。 除了系統提供的預設顏色以外，特定 Mac 硬體也可以選擇用「這部Mac」的機殼顏色。目前有 M1、M4 的 iMac，以及 MacBook Neo 支援這項功能。 ![MacBook Neo 支援「這部Mac」的配色。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-13-at-13.16.52@2x-1.png) MacBook Neo 支援「這部Mac」的配色。 那麼，我們能不能在沒有那些 Mac 的情況下，模擬或使用它們的硬體配色呢？ 可以的，這篇就要來教你怎麼樣強制套用相關設定。 _This post is for paying subscribers only._ ### 🌸買了 MacBook Neo 才知道有這個顏色 API URL: https://ethanhuang13.plus/macbook-neo-color-api/ Last updated: 2026-08-13T06:07:58.000Z ![粉紅色的 MacBook Neo、櫻花，與 app 配色](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/image-B02FA031-4E35-44FF-8619-B28057B93195.png) 粉紅色的 MacBook Neo、櫻花，與 app 配色 台灣開賣 MacBook Neo 時我就下單了，打算專門用來寫文章、不開發程式。 > 這篇文章就是在 MacBook Neo 寫完的第一篇。 不過，我是最近回到家才開箱。 我選擇了粉紅色機殼，很符合訂購當下櫻花季的氣氛。 macOS 對於這類彩色機身的 Mac，可以在`系統設定 > 外觀 > 主題 > 顏色`，來指定`「這部 Mac」`。這也是新機預設值。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/05/CleanShot-2026-05-13-at-13.16.52@2x.png) Mac app 能讀取 macOS 設定 > 外觀 > 主題 > 顏色來使用 粉色主題搭配櫻花桌布，很美。 直到我打開自己寫的 iOS app [多多讀聖經](https://apps.apple.com/tw/app/%E8%81%96%E7%B6%93-%E5%A4%9A%E5%A4%9A%E8%AE%80%E8%81%96%E7%B6%93-verse/id705745015?ref=ethanhuang13.plus)，才發現作為 Mac app 使用時，有一部分 UI 元件，居然吃到了上述的系統設定，變成了粉紅色，而不是 app 設計的主題配色。 _This post is for paying subscribers only._ ### 🖥️買 Mac Studio 的好理由 URL: https://ethanhuang13.plus/buy-mac-studio-reasons/ Last updated: 2026-08-13T06:07:56.000Z ## 理由一：高速編譯效能緩解 AI 開發瓶頸 Agentic Coding 時代，能夠同時開發數個功能，驗證成為新的瓶頸。除了人類驗證以外，編譯與測試的速度是 Agent 自我驗證的關鍵。 既然能用 AI 開發，同時做好幾個任務應該是合理的。不管是用 git worktree，還是 checkout 到不同的資料夾，每個任務都會有自己的完整開發環境、測試，平行處理。對於稍有規模的專案來說，開發瓶頸就真的會在編譯了。 Mac Studio，尤其是 Ultra 晶片版本，有大量 CPU 核心，對於同時跑多專案是實實在在地降低時間浪費。以前我覺得 iOS 開發者的編譯需求用 M 系列 Pro 等級的 Apple Silicon 就足夠（M3 Max 是特例，因為 CPU 核心數比 M3 Pro 多不少），但現在是平行開發的時代了，超多核心的 CPU 不會是浪費。 假如此時我回到公司上班、或是企業找我當開發團隊顧問，一定會跟主事者反映要趁早採購高性能的 Mac。 > Token 能隨時加購，Mac 臨時想買有可能得排隊好幾個月，浪費的時間會比 Mac 本身更貴。 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #260 iPlayground 開賣、學生開發者夏令營 URL: https://ethanhuang13.plus/dev-news-260-iplayground-summer-camp/ Last updated: 2026-08-13T06:07:57.000Z ## 13 的話 > 今年 7/15-17 會有一場 [iOS AI Summer Camp](https://luma.com/db49qc4m?tk=rwkLnY&ref=ethanhuang13.plus)。這是 [Jane](https://www.youtube.com/chaocode?ref=ethanhuang13.plus)、我，還有一些朋友一起舉辦的學生開發者夏令營。如果你是高中職以上的學生，對打造出自己的 app 有興趣，歡迎報名參加！不會寫程式也沒關係，因為我們會從頭教起怎麼使用 AI 工具。重點是要帶著你的好點子。 > > 感謝各方的努力，讓學生開發者可以**免費參加**這場活動（但需要自備 MacBook 作為開發設備。我個人建議至少要 MacBook Air M1 以上）。 > > 而這次夏令營會在 [5/31 有第二場的宣傳會](https://luma.com/hjbtslbp?tk=QqUwTF&ref=ethanhuang13.plus)，不限學生，歡迎報名。 > 也請讀者幫我們**多多宣傳**這兩場活動！ > > 至於非學生的 iOS 開發者，iPlayground 已經開始售票了。 > > **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 > > **13 於 2026/05/06** ## ‼️新聞標題 - 7/25-26 [iPlayground 2026 門票 5/5 正式開賣！](https://iplayground.substack.com/p/2026-ticket) 盲鳥票只有 50 張，動作要快 ## 🍎Apple 公司、產品、活動消息 - 4/30 [Apple 公布第二季財務報告](https://www.apple.com/tw/newsroom/2026/04/apple-reports-second-quarter-results/?ref=ethanhuang13.plus) 公司總營收、iPhone 營收及每股盈餘創三月季度紀錄。服務營收達到歷史新高。 ## 👨‍💻Apple 開發者消息 - 4/23 [Q&A: Swift concurrency | Meet with Apple](https://www.youtube.com/live/E95agtPgaa0?ref=ethanhuang13.plus) 滿好的一集 Apple 工程師問答錄影，主題是 Swift Concurrency - 5/4 [Xcode 26.5 RC](https://developer.apple.com/go/?id=xcode-26%5F5-sdk-rn&ref=ethanhuang13.plus) 雖然我沒有在用 Xcode 內建的 Agentic Coding 功能（[都在用 Codex app](https://ethanhuang13.plus/tag/codex/)），但是新版增加（或說補上）追加訊息的排隊功能，還是值得肯定 - 5/4 [iOS 26.5 RC](https://developer.apple.com/go/?id=ios-26%5F5-rn&ref=ethanhuang13.plus) 主要變更集中在 StoreKit - 5/4 [macOS 26.5 RC](https://developer.apple.com/go/?id=macos-26%5F5-rn&ref=ethanhuang13.plus) - 5/4 [tvOS 26.5 RC](https://developer.apple.com/go/?id=tvos-26%5F5-rn&ref=ethanhuang13.plus) - 5/4 [visionOS 26.5 RC](https://developer.apple.com/go/?id=visionos-26%5F5-rn&ref=ethanhuang13.plus) - 5/4 [watchOS 26.5 RC](https://developer.apple.com/go/?id=watchos-26%5F5-rn&ref=ethanhuang13.plus) ## 🤝社群活動 - 5/31 [iOS AI Summer Camp Preview Talk #2](https://luma.com/hjbtslbp?tk=QqUwTF&ref=ethanhuang13.plus) 下面這場夏令營的宣傳活動，非學生也可以參加 - 7/15-17 [iOS AI Summer Camp](https://luma.com/db49qc4m?tk=rwkLnY&ref=ethanhuang13.plus) 學生開發者夏令營。歡迎高中職以上學生報名，沒有程式基礎也沒關係，更重要的是你有想透過軟體解決的問題 ## 👂小道消息 - 5/1 Aaron: [Apple 不小心把 Claude.md 放到 Support app 裡了](https://x.com/aaronp613/status/2049986504617820551?ref=ethanhuang13.plus) - 5/5 Aaron: [Apple 不小心把內部的 app 上架到 App Store](https://x.com/aaronp613/status/2051614361735528470?ref=ethanhuang13.plus) 我猜想內部用的 apps 也有用 App Store 發布 ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。 - 5/2 zonble: [蘋果軟體史上的災難等級 UI](https://zonble.medium.com/%E8%98%8B%E6%9E%9C%E8%BB%9F%E9%AB%94%E5%8F%B2%E4%B8%8A%E7%9A%84%E7%81%BD%E9%9B%A3%E7%AD%89%E7%B4%9A-ui-6f25754a16c3?ref=ethanhuang13.plus) ### 13+ - 5/4 [⚡️信任的累積](https://ethanhuang13.plus/2026-05-04-building-trust/) 無關乎移植開發者的意圖良善與否。信任除了從頭累積，沒有捷徑。 - 5/6 [⚡️Codex 已經是很強的 iOS 工程師了](https://ethanhuang13.plus/2026-05-06-codex-is-great-ios-enginner/) 從使用 Codex 開發 iOS 的經驗中，分享 Agent 已經能做到的各種事情。 ### ChaoCode - 4/29 [Xcode AI 寫 App：新手怎麼提升開發成功率？](https://www.youtube.com/watch?v=lleP9Voz1rY&ref=ethanhuang13.plus) - 5/2 [Code Review 的價值是什麼？AI 時代會有什麼變化？](https://www.youtube.com/watch?v=5y38muQ5O6k&ref=ethanhuang13.plus) ## 🧠13 的評論（13+ 會員專屬） 以下內容僅限 13+ 會員可觀看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 今年沒當 iPlayground 工作人員 - 為什麼想要舉辦學生開發者夏令營？聊聊新手開發者的學習途徑 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) _This post is for paying subscribers only._ ### ⚡️Codex 已經是很強的 iOS 工程師了 URL: https://ethanhuang13.plus/2026-05-06-codex-is-great-ios-enginner/ Last updated: 2026-08-13T06:07:55.000Z 從事 iOS 教學給我的最大收穫，就是「**不要以為大家都知道，就不分享**」。 所以這篇分享我[使用 Codex](https://ethanhuang13.plus/tag/codex/) 開發 iOS 的經驗，簡單列舉目前「Agent 已經能做到的事」： _This post is for paying subscribers only._ ### ⚡️信任的累積 URL: https://ethanhuang13.plus/2026-05-04-building-trust/ Last updated: 2026-08-13T06:07:54.000Z 近期的 [Apple 開發者週報 #259](https://ethanhuang13.plus/dev-news-259-iap-12-month-commitment/) 報導了 Notepad++ for Mac 的消息。後來發現 Mac 版作者 Andrey Letov 並沒有跟 [Notepad++](https://notepad-plus-plus.org/?ref=ethanhuang13.plus) 原作者取得商標授權，並且後續的回應也沒有很令人信服。藉由這個機會，我想聊一下信任的累積。 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #259 年費月繳 URL: https://ethanhuang13.plus/dev-news-259-iap-12-month-commitment/ Last updated: 2026-08-13T06:07:53.000Z ## 13 的話 > 本週的開發者新聞沒有之前那麼熱鬧了。 > 對於 Apple 開發者來說，最大的影響是 App Store 的 IAP，在各 OS 26.4 以上，新增了「年費方案可以月繳」的機制。就算使用者取消訂閱，還是需要持續繳完。 > **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 > **13 於 2026/04/29** ## ‼️新聞標題 - 4/27 [Now Available: Monthly Subscriptions with a 12-Month Commitment](https://developer.apple.com/news/?id=agq42lxe&ref=ethanhuang13.plus) 對應的 API 更新請看 [Release Notes](https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26%5F5-release-notes?ref=ethanhuang13.plus#StoreKit)。 ## 👨‍💻Apple 開發者消息 - 4/27 [Xcode 26.5 beta 3](https://developer.apple.com/documentation/xcode-release-notes/xcode-26%5F5-release-notes?ref=ethanhuang13.plus) - 4/27 [iOS 26.5 beta 4](https://developer.apple.com/go/?id=ios-26%5F5-rn&ref=ethanhuang13.plus) - 4/27 [macOS 26.5 beta 4](https://developer.apple.com/go/?id=macos-26%5F5-rn&ref=ethanhuang13.plus) - 4/27 [tvOS 26.5 beta 4](https://developer.apple.com/go/?id=tvos-26%5F5-rn&ref=ethanhuang13.plus) - 4/27 [visionOS 26.5 beta 4](https://developer.apple.com/go/?id=visionos-26%5F5-rn&ref=ethanhuang13.plus) - 4/27 [watchOS 26.5 beta 4](https://developer.apple.com/go/?id=watchos-26%5F5-rn&ref=ethanhuang13.plus) - 4/22 [iOS 26.4.2](https://developer.apple.com/go/?id=ios-26%5F4-rn&ref=ethanhuang13.plus) 小小更新了一版正式版，[修了一個 CVE](https://support.apple.com/zh-tw/127002?ref=ethanhuang13.plus) ## 🖥️Mac App - 4/8 [NotePad++ 推出 Mac 版](https://notepad-plus-plus-mac.org/?ref=ethanhuang13.plus) 久聞此 Windows 開源軟體的大名，從來沒想過會推出原生 Mac 版。它的原生是架構方面，不是系統體驗。[官方文件](https://notepad-plus-plus-mac.org/about?ref=ethanhuang13.plus)、[原始碼](https://github.com/notepad-plus-plus-mac?ref=ethanhuang13.plus)都值得一看 ## 🤖AI 服務與產品消息 - 4/23 [GPT‑5.5 登場](https://openai.com/zh-Hant/index/introducing-gpt-5-5/?ref=ethanhuang13.plus) 它做了一件我沒意料到的事情，讓我反省。請見下方 13+ 會員專屬評論 ## 🤝社群活動 - 4/27 [推薦贊助商，免費拿 iPlayground 門票 !](https://iplayground.substack.com/p/iplayground) ## 📺開發者內容創作 歡迎投稿你的文章、影片、專案。 - 4/27 [大學生和 AI #1：當別人開始 Agentic Coding，你還在 Copy Paste Coding 嗎？](https://vincentchiang.substack.com/p/ai-1-agentic-coding-copy-paste-coding) Student Challenge 得獎同學 Vincent 開設的電子報 ### weak self podcast 是的你沒看錯，weak self 更新了！ - 4/29 [114: 快樂的代表──Switch 2](https://weakself.dev/episodes/114?ref=ethanhuang13.plus) 不演了，直接開始勸敗。 ### ChaoCode - 4/25 [用 Semgrep 掃資安漏洞、驗證漏洞和用 AI 修正](https://www.youtube.com/watch?v=Xv2Zr8oZdXU&ref=ethanhuang13.plus) ### Harry @ AI Coding Club - 4/24 [iOS App Widgets 開發進度更新](https://www.youtube.com/watch?v=MYXt8PsVtOE&ref=ethanhuang13.plus) - 4/27 [iOS App 功能優化](https://www.youtube.com/watch?v=0NdEWQ6-TGw&ref=ethanhuang13.plus) ## 🧠13 的評論（13+ 會員專屬） 以下內容僅限 13+ 會員可觀看，[歡迎訂閱](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。 - 年費月繳，我的觀察 - weak self 久久一次錄音──快樂 - GPT-5.5 給我的警訊（你可能猜不到理由） [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) _This post is for paying subscribers only._ ### ⚡️ChatGPT 知道我是誰 URL: https://ethanhuang13.plus/2026-04-23-ai-recognize-me/ Last updated: 2026-08-13T06:07:52.000Z 我妹去問「掐皮」知不知道我是誰。 _This post is for paying subscribers only._ ### 📰Apple 開發者週報 #258 Apple 50 週年、Tim Cook 退任 CEO URL: https://ethanhuang13.plus/dev-news-258-apple-50yr-tim-cook-ceo/ Last updated: 2026-08-13T06:07:51.000Z ## 13 的話 > [去年 11 月](https://www.ethanhuang13.com/p/251?ref=ethanhuang13.plus)，我把⟪Apple 開發者電子報⟫從**週報**改成不定期發刊，到現在快半年了。回頭來看，我覺得每週固定發刊比較好。 > > 我觀察到自己有種──毛病？就是，看到一些重要消息時，都會有種「這件事情很重要，需要讓大家知道」的衝動。 > > 而且，當我跟一些開發者互動、發現他們不知道那些重要消息時，我就會覺得「如果我有多宣傳一點就好了」。 > > 很奇怪吧。 > > 總之，隨興發刊的方式，是沒辦法做到我想要的傳遞效果的。所以，我還是覺得維持固定頻率，甚至每週發刊，是比較好的經營形式。 > > 不過，之前在宣布改變頻率的時候也說過，整理週報內容，對我來說是偏機械化、無聊的事情。想傳達重要消息的心情，跟寫作熱情，對我來說還是兩回事。 > > 想來想去，我覺得能做出的折衷方案，就是縮減內容的形式。未來週報會用**列點、日期、連結、一句話**來呈現開發者新知。 > > 而關於重要事件的評論、補充資料、幕後花絮，我會保留給 13+ 會員。 > 成為 13+ 會員還有一個好處：每週的週報寫完後，我會優先發給會員。訂閱免費電子報的朋友，則要等到週一早上才會收到。 > > **請**[**訂閱 13+**](patreon.com/ethanhuang13)**，支持我的寫作。**你還可以[贈送會員](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)給其他人。 > > **13 於 2026/04/22** ## ‼️新聞標題 - 4/20 [**Tim Cook 將轉任 Apple Executive Chairman，John Ternus 將擔任 Apple 執行長**](https://www.apple.com/tw/newsroom/2026/04/tim-cook-to-become-apple-executive-chairman-john-ternus-to-become-apple-ceo/?ref=ethanhuang13.plus) Cook 夏季期間將持續擔任執行長，並與 Ternus 密切合作，確保順利交接 - 4/20 [**Community Letter from Tim**](https://www.apple.com/community-letter-from-tim/?ref=ethanhuang13.plus) - 4/28 [開始 App Store Connect 會要求使用 Xcode 26 或以上 SDK 上傳更新](https://developer.apple.com/news/upcoming-requirements/?id=02032026a&ref=ethanhuang13.plus)，還在使用舊版 Xcode 的開發者請儘快升級開發環境 _This post is for paying subscribers only._ ### 🎙️兩部訪談 13 的影片：ChaoCode、林聽他說 URL: https://ethanhuang13.plus/2026-03-two-interview-chaocode-bane/ Last updated: 2026-08-13T06:07:50.000Z ## ChaoCode [ChaoCode](https://www.youtube.com/channel/UCsssLDarjKe7K0YtuLrjpcw?ref=ethanhuang13.plus) 的 Jane 平時就與我在[不上班工程師的日常](https://www.youtube.com/@%E4%B8%8D%E4%B8%8A%E7%8F%AD%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%9A%84%E6%97%A5%E5%B8%B8?ref=ethanhuang13.plus)督促大會交流。 最近他錄製了一系列的史丹福大學 [CS146S: The Modern Software Developer ](https://themodernsoftware.dev/?ref=ethanhuang13.plus)課程的[學習紀錄](https://www.youtube.com/playlist?list=PLXM8k1EWy5kiP5eyA9fam2gpndjonpWlr&ref=ethanhuang13.plus)。這套課程在探討現代工程師要怎麼使用 AI 工具來開發，對於現職的工程師會是很好的技能強化資源。 Jane 對於 AI 的關注與研究比我認識的大部分 iOS 工程師還要早了幾年，而且他的影片都會投注大量心力整理素材，甚至出作業，所以我十分推薦給大家。 在這邊幫他打個廣告：如果想要第一時間看到這個系列影片，請[**加入頻道會員**](https://www.youtube.com/channel/UCsssLDarjKe7K0YtuLrjpcw/membership?ref=ethanhuang13.plus)！ 在這集當中，他找我擔任業界工程師觀點的一方，討論課程中幾個實務。而我最想說的一點是：**做計畫本身就很重要，而計畫模式只是個功能**。 ****CS146S 延伸篇：業界前輩會如何回答課堂問題？課程內容該如何應用到實戰中？feat. 13 - ep11** - [00:00](https://www.youtube.com/watch?v=ThTxeqcKNwk&ref=ethanhuang13.plus) 影片介紹 - [00:55](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=55s&ref=ethanhuang13.plus) 13 的背景介紹 - [04:35](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=275s&ref=ethanhuang13.plus) 對於課程教到的 Claude Code 技術，從實務角度上的看法是什麼？ - [10:53](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=653s&ref=ethanhuang13.plus) AI 技術日新月異，新手到底該學什麼？ - [15:39](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=939s&ref=ethanhuang13.plus) 課程問題：如何自動化「研究、探索」的流程？ - [20:10](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=1210s&ref=ethanhuang13.plus) 課程問題：如何維護一個待處理的任務隊列？ - [25:11](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=1511s&ref=ethanhuang13.plus) 將優秀工程師、優秀管理的經驗帶到 AI 應用中 - [27:06](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=1626s&ref=ethanhuang13.plus) 為什麼選擇使用 CLI 工具進行 AI 開發？ - [30:57](https://www.youtube.com/watch?v=ThTxeqcKNwk&t=1857s&ref=ethanhuang13.plus) 新手要用什麼 AI 開發工具入門？CLI 還是 IDE？ ## 林聽他說 Podcast 第一次與[林聽他說](https://www.youtube.com/@%E6%9E%97%E8%81%BD%E4%BB%96%E8%AA%AA?ref=ethanhuang13.plus)的主持人 Bane 碰面，應該是在 iPlayground 2025。他說是因為聽了「[個人軟體時代](https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/)」那場演講，對我的教育心理背景與科技洞察產生印象。 於是他就邀請我到他的 Podcast 聊聊，我們談了很多與 AI 有關的想法。多到我其實已經忘了重點是什麼了，還好他剪片時有整理出各段重點。 _This post is for paying subscribers only._ ### 📱完美的狀態列不存在……才怪──iOS 開發補完計畫 #7 URL: https://ethanhuang13.plus/ios-missing-manual-perfect-screenshot-status-bar/ Last updated: 2026-04-12T22:00:41.000Z > [iOS 開發補完計畫系列](https://ethanhuang13.plus/tag/ios-missing-manual/)免費公開給所有讀者，分享一些 AI 工具不一定會教你的關鍵知識。 現在越來越多新朋友透過 AI 工具開發 iOS apps，我覺得去嘗試自己以前做不到的事情是好事。 初生之犢不畏虎，很多人從開始做到上架的時間極短，可能只要幾天。快速嘗試，就能快速獲得經驗，然後再不斷改進。相對的，我跟一些資深 iOS 工程師朋友，都有「想到有哪些事情要做就覺得好麻煩」、「認真做起來就算有 AI 也要耗掉幾個月」的毛病。 ## 你的手機沒電啦，在 App Store 截圖中 不過有一點，我很想提醒廣大的開發者朋友們──請把 App Store 上面截圖中，iOS 設備的狀態列弄好。 而且，也不難。 我最常看到就是那些**行動網路**沒訊號、**Wi-Fi** 沒有滿格，甚至**電池**快沒電。一看就是從開發者的手機上截圖，或是隨便做的。 **App Store 頁面是你的潛在使用者對 app 的第一印象**。要當成非常重要的事情，不要隨便湊幾張圖檔就上傳。 另外，狀態列上的時間是個彩蛋。Apple 在首次發表 iPhone 的投影片，以及 iPhone 各種媒體素材，狀態列上都是使用 **9:41** 這個時間。原因就是要抓發表會中正式亮相的實際時間點。許多開發者也會沿用這個時間來準備截圖。 ## 使用 simctl 指令設定狀態列 要怎麼做到呢？總不能去調整設備時間吧？其實透過**模擬器**就可以做到了。 現在大部分的人都用 AI 來寫程式，所以只要跟 AI 說： ```plaintext 幫 app 產生 App Store 所需的截圖。使用 simctl 設定模擬器的狀態列，9:41、Wi-Fi 與行動網路滿格、電量 100%。 ``` 如果你想要自己下指令，比如說要幫 iPhone 17 Pro Max 這台模擬器裝置，可以先按 `Cmd + Shift + 2`，找到模擬器 identifier 。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/04/CleanShot-2026-04-12-at-23.50.31@2x.png) 然後把 identifier 填入以下指令： ```plaintext xcrun simctl status_bar D1F15B0B-24DC-4015-9B2F-0D1BDA6DBF92 override --time 9:41 --dataNetwork wifi --wifiMode active --wifiBars 3 --cellularMode active --cellularBars 4 --batteryState charged --batteryLevel 100 ``` 總之，只要透過 `xcrun simctl status_bar` 指令，就可以設定好狀態列。這只是 1、2 分鐘的事情，卻能夠讓你的截圖在 App Store 上更完美。 ## 更進一步 其實，就我在 App Store 上觀察，也不是每個專業 iOS 開發團隊都有做到把狀態列弄到完美。但是有照顧到像 9:41 這種內行人才會留意的細節，會讓你的產品形象更專業。 如果你還想要讓截圖這件事情更進一步的話，很重要地是讓它變成**自動化流程**。我會建議告訴 AI 工具去產生截圖的 script，方便重複執行。例如： ```plaintext 我希望可以擷取畫面 A、畫面 B、畫面 C，分別在某某條件。幫我寫出截圖條件下這些畫面的 Preview，以及截圖的 script，並且要執行所有 app 內有支援的語系。 ``` 這樣，以後 app 改版時，就可以重複執行這套 script 來產生新版圖檔。 許多人甚至把 app 畫面截圖套上 iOS 裝置外觀，配上說明文字。這個作法我完全支持，但是請**務必確認裝置的外觀正確**。包括長寬比例、是否有動態島、圓角矩形等等。 最後，這些做好的截圖，要怎麼有效率的上傳，就超出本文的篇幅了。但是你一定想到了，這件事情一樣可以透過 AI 來完成吧，請自行嘗試！ ### 🤖我的 AI 工具使用現況（2026 年 1-3 月） URL: https://ethanhuang13.plus/my-ai-tools-usage-2026-01-03-codex/ Last updated: 2026-08-13T06:07:49.000Z 很久沒寫「我的 AI 工具使用現況」了。用一句話來說：**年初從 Claude Code 換成 Codex 以後，就回不去了。** 我的日常開發主要還是 iOS，其次是 Android 與前端。 這段期間，認真在開發的 apps 至少有 5 個，其中有 2 個有正式在 App Store 發更新版。 我主要用 [**Codex Mac app**](https://developers.openai.com/codex/app?ref=ethanhuang13.plus)，不用 CLI。使用 **GPT-5.4** 模型、reasoning effort 設為 **high**，並且開啟 **Fast** 模式（1.5 倍速、2 倍計費）。 方案目前是 ChatGPT Pro $200，不過我的用量，[剛推出的 $100](https://x.com/ethanhuang13/status/2042434616720834900?ref=ethanhuang13.plus) 就夠了。 平時查看使用量的工具，我使用 [OpenUsage](https://github.com/robinebers/openusage?ref=ethanhuang13.plus)。 ## 抱怨一下 Claude 身為曾經的 Claude Code 愛用者，我對於**現在**的 CC 很失望。 _This post is for paying subscribers only._ ### ⚡️試算本地模型硬體需求 URL: https://ethanhuang13.plus/2026-04-05-huggingface-hardware-compatibility/ Last updated: 2026-08-13T06:07:48.000Z 最近 Apple 推出 M5 系列，你想換機了嗎？或是看到一些[新推出的本地模型](https://huggingface.co/collections/mlx-community/gemma-4?ref=ethanhuang13.plus)，想知道手邊設備能不能跑嗎？ 教你一個簡單的方法： _This post is for paying subscribers only._ ### ⚡️基本功：設計的心理學 URL: https://ethanhuang13.plus/2026-03-31-design-of-everyday-things/ Last updated: 2026-08-13T06:07:47.000Z > 我們每個人都活在自己的習慣。大腦為了節省資源，往往假定別人跟自己有相同的經驗、思考，與做事方式。只有在面對巨大衝突時，才會意識到「原來人家跟我想的不一樣」。發現這種差異時，我會寫成「基本功」短篇。 我讀過好幾遍 Don Norman 的《The Design of Everyday Things》（設計的心理學）一書。 Don Norman 是誰？就是在 Apple 任職時，發明「使用者體驗」一詞的大師。 書中的重要觀念就是：「**如果使用者不會用某個東西，不是使用者的錯，而是設計的問題。**」 _This post is for paying subscribers only._ ### ⚡️基本功：閱讀第一手技術資料 URL: https://ethanhuang13.plus/2026-03-25-basic-skill-reading-first-hand-docs/ Last updated: 2026-08-13T06:07:46.000Z > 我們每個人都活在自己的習慣。大腦為了節省資源，往往假定別人跟自己有相同的經驗、思考，與做事方式。只有在面對巨大衝突時，才會意識到「原來人家跟我想的不一樣」。發現這種差異時，我會寫成「基本功」短篇。 以學習來說，尤其是技術方面，我一向習慣去讀原廠、官方的文件。例如開源專案的 README、CHANGELOG、SaaS 官網的介紹、Apple 的官方文件及 Release Notes。並不是說官方文件絕對正確，也不是要從頭啃完，但這些東西是最重要的第一手資料，能讓人快速進入狀況，有助於後續讀 code 與操作。 _This post is for paying subscribers only._ ### ⚡️我不怕被 AI 取代，不如說本來就想被取代 URL: https://ethanhuang13.plus/2026-03-23-ai-replace-me/ Last updated: 2026-08-13T06:07:45.000Z 總有更重要的事值得做。至於是哪些事情，你心中已有答案了嗎？ _This post is for paying subscribers only._ ### 🧑‍🏫兩年 iOS 教學回顧與洞察 URL: https://ethanhuang13.plus/two-years-of-teaching-ios/ Last updated: 2026-08-13T06:07:44.000Z 在大學教 iOS 開發快滿兩年了，跟讀者分享一些幕後花絮以及洞察。 ## 繞了一圈又回來的教學背景 雖然在美商當到資深 iOS 工程師主管、帶團隊，但我其實是文組畢業的。大學、研究所讀臺師大心輔系、教育心理學組，也有修過部分教育學程。 實習後，覺得實在沒有想當學校老師，畢業後自學 iOS 開發，意外變成軟體工程師。這些故事以後有機會再寫（其實我有點忘了自己有沒有寫過？） 2024 年中，Apple 台灣的教育團隊找上我，去協助學生開發者的比賽、教學、工作坊，很意外地我又回到了學校。 ![第一次在臺大上課](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/03/410CCE26-C25D-41E0-9377-60AD55508486_1_105_c.jpeg) 第一次在臺大上課 雖然沒有走教職，但是有修過教育學程，在教會長大也累積許多教課與課業輔導經驗，所以上台講課對我來說並不陌生。 不一樣的地方是，因為現在有 AI，教 iOS 開發時，我不能參考自己學習的路徑，而是要一邊探索 AI 工具的能力邊界，一邊觀察學生如何使用。 當初會答應接下教學工作，最主要原因是很好奇新手會怎麼接觸與使用 AI 工具。實際上因此看到了不少自己的專家盲點（例如[這篇](https://ethanhuang13.plus/xcode-open-folder-pitfall/)）。 ## 教學主軸：從目標回推學習內容 技術的東西變化很快、AI 方面更是如此，教工具使用方式一下子就會過時了。所以我都會跟學生強調**設定自己學習與開發目標**的重要性。 重要原則：**從想要實現的結果回推需要加強的知識與技能**。 接著，就是各種實際操作，讓學生體驗到：「原來電腦可以做到這些事情！」然後栽進去探索。 畢竟，Coding 沒有速成，只有不斷累積經驗（使用 AI 開發也需要學習）。目標與學習動力可以讓這個過程更持久。 ## 模組化教材，提升教學準備的效率 我的教學講義都放在 Notion 上，有連結就可以看到。 一開始備課非常痛苦，因為不知道學生的程度與吸收能力如何。還好我習慣把講義寫得很完整，包括具體操作步驟與截圖，所以就算無法及時跟上，也有大量資料可以參考。 教的內容到一定程度以後，我開始把教過的東西，都用 Notion 的「[同步區塊](https://www.notion.com/zh-tw/help/synced-blocks?ref=ethanhuang13.plus)」功能，建立成模組。 ![教學模組，採用 Notion 同步區塊與頁面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/03/CleanShot-2026-03-18-at-16.52.35@2x.png) 教學模組，採用 Notion 同步區塊與頁面 後續備課時，除了編寫新教材區塊以外，教過的模組區塊可以直接貼上，並且同步更新成符合當下的最新資訊。以前拿過講義的同學就可以一併獲得最新的版本。 課堂上沒有時間講的東西也可以給出大量補充資料。教材逐漸累積，備課就越來越輕鬆。 從軟體工程的角度來說，這種重複使用的模組化策略是再熟悉不過了。 ## 看到自己的成長 教學的口碑還不錯，所以第二個學年課變得更多了。 目前教學的時數超過 70 小時。除了累積重複使用的教材以外，我也發現自己在備課的效率提升了。 一般來說，備課的時間會大於實際上教課的時間。但是有些課的內容我已經可以不特別準備，直接上場。 ## 講義大放送 以下教材提供給會員讀者參考。 _This post is for paying subscribers only._ ### 🧠經驗與記憶之謎 URL: https://ethanhuang13.plus/experiencing-self-vs-remembering-self/ Last updated: 2026-08-13T06:07:43.000Z 讀教育心理碩班那年，正在苦惱要做什麼研究題目時，意外地看到了 [Daniel Kahneman](https://zh.wikipedia.org/zh-tw/%E4%B8%B9%E5%B0%BC%E5%B0%94%C2%B7%E5%8D%A1%E5%B0%BC%E6%9B%BC?ref=ethanhuang13.plus) 的演講：[經驗與記憶之謎](https://m.youtube.com/watch?v=DVVpd9w6gd8&ref=ethanhuang13.plus)。 這是至今影響我思考最深刻的一場演講。 _This post is for paying subscribers only._ ### 🛠️利用 Xcode 26.3 工具完成開發循環 URL: https://ethanhuang13.plus/xcode-tools-close-the-loop/ Last updated: 2026-08-13T06:07:41.000Z 我認為 Xcode 26.3 讓 [iOS 開發進入了一個全新的時代](https://www.youtube.com/watch?v=OzVwmR1jnf0&ref=ethanhuang13.plus)。因為可以直接在 Xcode 內使用 Agentic Coding 的功能，直接做完從開發到驗證的循環。 另一方面，Xcode 提供了不少「工具」，讓 Codex 或 Claude Code 等 Agent 能從外部呼叫使用，例如 Codex Mac app 或 Claude Code TUI。 Xcode 使用 MCP 來宣告這些工具。我把呼叫結果放在這個 gist： [Xcode 26.3 mcpbridge tools/list response (generated 2026-03-04)Xcode 26.3 mcpbridge tools/list response (generated 2026-03-04) - xcode-mcp-tools.json![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/icon/pinned-octocat-093da3e6fa40.svg)Gist262588213843476![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/thumbnail/gist-og-image-54fd7dc0713e.png)](https://gist.github.com/ethanhuang13/aa486eb3a41d06097c24da633be4070f?ref=ethanhuang13.plus) 可以看出，提供了大部分常見的 Xcode 操作： - **BuildProject**: Builds an Xcode project and waits until the build completes. - **DocumentationSearch**: Searches Apple Developer Documentation using semantic matching. - **ExecuteSnippet**: Builds and runs a snippet of code in the context of a specific file and waits until results are available. This tool is available for source files in targets that build applications, frameworks, libraries, or command line executables. The output consists of the console output generated by the `print` statements contained in the provided snippet. - **GetBuildLog**: Gets the log of the current or most recently finished build. You can choose which build log entries to include by specifying the severity of any issues emitted by the build task represented by the entry. You can also filter by message regex pattern or file glob pattern. The response also indicates whether the build is currently in progress. - **GetTestList**: Gets all available tests from the active scheme's active test plan. Results are limited to 100 tests. The complete list is written to fullTestListPath in grep-friendly format. Use grep with keys like TEST\_TARGET, TEST\_IDENTIFIER, or TEST\_FILE\_PATH to find specific tests. - **RenderPreview**: Builds and renders a Preview and waits until a snapshot of the resulting UI is available. - **RunAllTests**: Runs all tests from the active scheme's active test plan - **RunSomeTests**: Runs specific tests using the active scheme's active test plan - **XcodeGlob**: Finds files in the Xcode project structure matching wildcard patterns. Works on Xcode project organization, not filesystem structure. Example patterns: '*.swift', '\*\*/*.json', 'src/**/\*.{swift,m}'. If no pattern is provided, defaults to '**/\*' (all files). - **XcodeGrep**: Searches for text patterns in files within the Xcode project structure using regex. Works on Xcode project organization, not filesystem structure. CRITICAL: Must include a 'pattern' argument - this tool will fail without it. - **XcodeLS**: Lists files and directories in the Xcode project structure at the specified path. Works on Xcode project organization, not filesystem structure. - **XcodeListNavigatorIssues**: Lists the currently known issues shown Xcode's Issue Navigator UI in the workspace. These issues include those that have been discovered since the last build, and also issues like package resolution problems and workspace configuration issues. You can filter the issues to include by file name, glob, or severity. Use this tool when you want to list all the users the user can see in the workspace UI. - **XcodeListWindows**: Lists the current Xcode windows and their workspace information - **XcodeMV**: Moves or renames files and directories in the project navigator with support for filesystem operations. - **XcodeMakeDir**: Creates directories and groups in the Xcode project structure. - **XcodeRM**: Removes files and directories from the Xcode project structure and optionally deletes the underlying files from the filesystem. - **XcodeRead**: Reads the contents of a file within the Xcode project organization. Returns content in cat -n format with line numbers. Supports reading up to 600 lines by default with optional offset and limit parameters for large files. - **XcodeRefreshCodeIssuesInFile**: Retrieves current compiler diagnostics (errors, warnings, notes) for a file in the Xcode project. Returns formatted diagnostic information including severity levels and messages. - **XcodeUpdate**: Edits files in the Xcode project by replacing text content. Works on Xcode project structure paths, not filesystem paths. IMPORTANT: The tool will fail if filePath, oldString, or newString parameters are missing. - **XcodeWrite**: Creates or overwrites files with content in the Xcode project. Works on Xcode project structure paths, not filesystem paths. Automatically adds new files to the project structure. Both filePath and content parameters are required. 最大化 Agent 寫程式效率的關鍵在於：寫完程式碼以後能夠執行編譯、測試，並且修正錯誤。Xcode 提供的工具能直接執行測試、看 Preview、看編譯的 log，所以很容易找出問題，也就能快速找到要修復的地方。 Agent 也懂得使用 `xcodebuild` 或 `xcrun simctl` 指令達到類似的效果，但有內建工具總是比較直接，習慣 Xcode 的開發者也比較好懂 Agent 在做什麼。 ## 解決 MCP 太耗費 Context 的問題 在使用 AI 開發時，context window 是寶貴資源。而使用 [MCP](https://modelcontextprotocol.io/docs/getting-started/intro?ref=ethanhuang13.plus) 容易消耗大量的 token，所以後來 Anthropic 又推出 [Skills](https://code.claude.com/docs/en/skills?ref=ethanhuang13.plus)。 從上方的 gist 可以看出，總共有 1500 多行的 JSON 都會塞進 context window。 另一方面，如果你有實際把 Xcode 的 MCP 打開給外部呼叫，一定會常常看到 Xcode 跳出 "Allow Connection?" 的權限通知。這個問題在 [Xcode 26.3](https://developer.apple.com/documentation/xcode-release-notes/xcode-26%5F3-release-notes?ref=ethanhuang13.plus)、[26.4 beta](https://developer.apple.com/documentation/xcode-release-notes/xcode-26%5F4-release-notes?ref=ethanhuang13.plus) 的 Release Notes 都是 Known Issues。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/03/CleanShot-2026-03-09-at-14.37.59@2x.png) 在 Xcode 設定的 Intelligence 把工具的 MCP 打開 上述兩個問題加起來，就讓從外部 Agent 使用 Xcode 工具有點不太實際。 因此，我有的時候就直接使用 Xcode 內的 Agentic Coding 介面來開發來減少允許連線通知的問題（MCP 佔用 context 則避不開）。畢竟不管用不用 AI 寫 iOS，Xcode 本來就會開著跑實機、看 Preview，或是進行一些自己熟悉的操作。 但我更多的時候是使用 Codex Mac app，還是會希望能用 Xcode 提供的工具。 有沒有什麼辦法呢？ _This post is for paying subscribers only._ ### ⚡️思緒的飛航模式 URL: https://ethanhuang13.plus/2026-03-09-brain-airplane-mode/ Last updated: 2026-08-13T06:07:42.000Z 看到有網友問：「想在搭飛機時寫點 side project，沒網路有建議什麼 local LLM？」 _This post is for paying subscribers only._ ### 🐣Apple 開發者新聞 #257 iOS AI Summer Camp 活動預告 URL: https://ethanhuang13.plus/dev-news-257-ios-ai-camp-preview/ Last updated: 2026-08-13T06:07:40.000Z AI 發展地這麼快，每隔幾天就有新工具、新功能、新模型。這反而讓我開始思考：[哪些事情有長遠的價值](https://ethanhuang13.plus/2026-02-20-ai-long-term-thinking/)？ 除了一直都有在進行的寫作以外，今年我想要加倍投入的就是**軟體教育**。 去年底，我跟幾位志同道合的朋友（其中一位是 ChaoCode 的 Jane），決定要在今年舉辦**給學生開發者的 iOS AI Coding 夏令營**。 就在本週日（3/15）下午 14:00-16:30，我們會在臺大舉辦一場[宣傳演講](https://luma.com/ahkk2h51?tk=wvFwZk&ref=ethanhuang13.plus)。 我們邀請了多次在 Apple 官方學生競賽得獎的 [Vincent](https://www.threads.com/@vincent.%5F0523?ref=ethanhuang13.plus) 同學分享經驗。 除此之外，我也會示範在 Xcode 裡使用 AI agent 開發 iOS app。 自從 [Xcode 26.3](https://developer.apple.com/documentation/xcode-release-notes/xcode-26%5F3-release-notes?ref=ethanhuang13.plus) 推出以來，我就一直在使用它的 Agentic Coding 功能。以開發 iOS app 來說，並不輸給直接使用 Codex 或 Claude Code 的官方 app。實際上 Xcode 也是使用這兩家的 agent SDK。 （我甚至在這學期的臺大 iOS Club 第一堂課就以「[iOS 開發的時代變了](https://www.youtube.com/watch?v=OzVwmR1jnf0&ref=ethanhuang13.plus)」這個名稱來宣告。） 如果你想要快速掌握如何使用在 Xcode 使用 Agentic Coding，歡迎週日下午來聽。 **演講報名連結**[**請按這裡**](https://luma.com/ahkk2h51?tk=wvFwZk&ref=ethanhuang13.plus)**。** 這場宣傳講座的主要目的是能夠吸引學生來參加夏令營，但也有開放給非學生。歡迎來玩～ ## iOS 開發的未來與軟體教育 有些人認為，在 AI 時代，許多軟體將會是「給 AI 使用」。觀察 Agent 現在已經能做到的事情，我不反對這樣的看法。 但是，身為 iOS 開發者，我覺得 iOS 還有很多題目可以做。 _This post is for paying subscribers only._ ### 💻MacBook Neo 太重了 URL: https://ethanhuang13.plus/macbook-neo-weight/ Last updated: 2026-08-13T06:07:39.000Z 身為一個有大半工作是在寫作的人，[MacBook Neo](https://www.apple.com/tw/macbook-neo/?ref=ethanhuang13.plus) 這麼低的硬體規格（A18 Pro、8 GB RAM），仍絕對能勝任我的工作（軟體開發用其他 Mac），遠比 iPadOS 好用。 _This post is for paying subscribers only._ ### ⚡️如果 AI 只要一秒鐘就能完成指示 URL: https://ethanhuang13.plus/2026-03-02-ai-speed-philosophy/ Last updated: 2026-08-13T06:07:38.000Z 三週前，OpenAI 推出 [GPT-5.3-Codex-Spark](https://openai.com/zh-Hant/index/introducing-gpt-5-3-codex-spark/?ref=ethanhuang13.plus)，用 Cerebras 的特別 AI 加速伺服器跑，速度非常快，相比一般 Codex 最高可到 15 倍（可看[官網影片](https://openai.com/zh-Hant/index/introducing-gpt-5-3-codex-spark/?ref=ethanhuang13.plus)）。不過目前的 context window 小很多，較適合頻繁的小範圍修改。 Spark 目前需要 ChatGPT Pro 方案才能使用，我已經把方案降回了 Plus，所以沒機會試。 而最近，有位朋友跟我分享他使用 Spark 的心得：「超級快、很爽。」 於是我問他：「你拿來做什麼？」 _This post is for paying subscribers only._ ### 🐣iOS 開發補完計畫 #6 Xcode 管理學基礎篇 URL: https://ethanhuang13.plus/ios-missing-manual-xcode-management/ Last updated: 2026-03-02T05:59:59.000Z > 「iOS 開發補完計畫」是我去年原本打算針對 iOS 新手免費分享一系列的「AI 不會教，但又必須知道的 iOS 開發小知識或坑點」。 > > 當時的我寫作能力沒那麼好，每篇都花太多時間，就放棄了。 > > 現在我覺得，其實不用寫太細節。關鍵字句點出來，有興趣的朋友拿去反問 AI 就能學到不少。 > > 內容對於 13+ 的多數讀者來說可能偏基礎，就當作是複習吧！ iOS 開發的基礎是一台 Mac、Xcode 這個 IDE。 要選什麼 Mac 配備[我之前寫過了](https://ethanhuang13.plus/ios-missing-manual-1-buy-mac/)，而 Xcode 要選什麼版本、怎麼下載，其實是個坑。 1. Xcode 的版本會對應可以使用的最新 iOS SDK 跟 Swift 版本 2. 一台 Mac 可以安裝多個 Xcode 版本，依照需求切換 3. 選版本：大原則是用 `.2` 以上的版本，比較穩定。例如 26.2；需要開發全新 API 才去用 beta 版或是 .0。App 上架後怕有 bug 要回去追的話，可以留著舊版 Xcode 4. 切換版本：`sudo xcode-select -s ` 5. 下載：強烈不建議從 Mac App Store 下載（Google 可以找到我多篇文章），用 xcodes App/CLI 方便下載，而且還很方便切換 最後特別強調，很多在職工程師也不會做，但我覺得非常重要的事情：**去讀** [**Xcode 的 Release Notes**](https://developer.apple.com/documentation/xcode-release-notes?ref=ethanhuang13.plus)。 裡面不只有寫新功能，幫助你判斷是否升級；也有寫哪些是已知的 bugs，官方有公告的坑就不要再踩了。 ### ⚡️什麼叫做很會使用 AI URL: https://ethanhuang13.plus/2026-03-02-ai-human-boundary/ Last updated: 2026-08-13T06:07:37.000Z 我覺得，最會使用 AI 的人，既懂得發揮其強項，又清楚知道**什麼情況不該用**。 _This post is for paying subscribers only._ ### 🧠離職滿一年，思考 AI 的精華 URL: https://ethanhuang13.plus/gap-year-ai-thoughts-essence/ Last updated: 2026-08-13T06:07:37.000Z 以下是我這一年下來的思考精華。之所以是精華，是因為我是在搭車時，直接從腦中輸出、在手機上打出來的： ## 如何因應變化極快的 AI？ - 把注意力放在**當下**、把**眼光放遠**十年以上 - 不要浪費時間做一個月後就會被取代的解決方案（例如現在 AI 模型版本不夠聽話而搭的鷹架） - 不要上網跟人家吵誰比較懂 AI ## AI 越來越會寫程式，現職的軟體工程師要何去何從？ _This post is for paying subscribers only._ ### ⚡️如果你也想做自己的 ASR 工具 URL: https://ethanhuang13.plus/2026-02-22-asr-tools/ Last updated: 2026-02-22T12:19:27.000Z 這篇短文限時免費開放。歡迎成為會員，即可閱讀我的 180+ 篇文章。 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) 最近在 Threads 上看到不少人停用 Typeless，轉而自己用 AI 做一版。至少看到 4、5 個吧。 先說，我沒有用過 Typeless，對它沒有評論。還有我不喜歡讓 AI 修飾我的文字，所以 ASR 之後用 LLM 處理的部分，也不予置評。 雖然市面上已經有很多類似的解決方案（Typeless 之前有 WisprFlow，更早之前就有 MacWhisper），但我覺得每個人做符合自己需求的一版沒有錯。 去年我就一直在說「[個人軟體時代](https://speakerdeck.com/ethanhuang13/ge-ren-ruan-ti-shi-dai?ref=ethanhuang13.plus)」：只要工具不符合習慣，用 AI 為自己量身打造一個很好，可以學到很多東西。 （至於要不要產品化/商業化，就另當別論。） 不過真的要做的話，我建議先找個方便比較模型轉錄效果與效能的現成工具。 我在教學本地 ASR 模型時，都會從 [Spokenly](https://spokenly.app/?ref=ethanhuang13.plus) 這個 Mac app 教起（這不是廣告文）。 它有完全離線的模式、可以免費使用、多種模型可以下載與切換、換模型重轉的功能。其中也包括 Apple 自己的離線模型。 所以，要做自己的版本，我會拿它當作 ASR 功能/效能/效果參考。 我還會把核心做成 CLI，讓其他工具如 OpenClaw 能使用。畢竟，**做自己的工具，關鍵還是在打造個人系統**。 ### ⚡️Xcode 26.3 RC 2 更新 URL: https://ethanhuang13.plus/2026-02-21-xcode-26-3-rc-2-update/ Last updated: 2026-08-13T06:07:36.000Z Xcode 26.3 RC 2 推出了。我還沒空實測，簡單分享一下文件層面的觀察。 _This post is for paying subscribers only._ ### ⚡️AI 變化太快，反而讓我更思考長期價值 URL: https://ethanhuang13.plus/2026-02-20-ai-long-term-thinking/ Last updated: 2026-08-13T06:07:35.000Z 離職 gap 快滿一年了，花了不少時間在觀察與思考 AI 對世界與我個人的影響。 _This post is for paying subscribers only._ ### ⚡️Swift Student Challenge 提醒與策略 URL: https://ethanhuang13.plus/2026-02-18-swift-student-challenge-strategy/ Last updated: 2026-02-18T14:20:19.000Z 同學們，提醒一下，Apple 的 [Swift Student Challenge](https://developer.apple.com/swift-student-challenge/?ref=ethanhuang13.plus) 比賽作品要在 2/28 以前上傳。 以下是一些幫助你贏得比賽的策略： 1. 先把所有[官網](https://developer.apple.com/swift-student-challenge/?ref=ethanhuang13.plus)內容貼給你的 AI app，確認比賽規則（像是要上傳哪些資料、專案檔案格式、必須離線使用、檔案大小限制、開發環境、有問題要在哪個論壇問） 2. 跟 AI 工具好好討論想做什麼、Apple 可能喜歡怎樣的作品。在比賽條件限制下發揮最大創意 3. 實作可以盡量靠 AI。寫 Swift 的話我個人不推薦 Gemini 且 Xcode 不能用、Claude 較貴，所以整體而言目前 Codex（ChatGPT Plus）最划算 4. 去 Apple Developer 網站下載 Xcode 26.3 RC 版。這樣才可以在 Xcode 內用 Agent 開發 5. 跟 AI 討論出怎樣用一句話、一張圖就能介紹你的作品。在腦中描繪最終結果，然後反推完成的步驟 請記得，這不是一般的軟體開發，而是展現你的個人理念與動手能力的好機會。你可以做到的，加油！ ### ⚡️我不再用 AI 整理工作日誌 URL: https://ethanhuang13.plus/2026-02-18-summarize-work-log-without-ai/ Last updated: 2026-08-13T06:07:34.000Z 最近我找到一件事情刻意不交給 AI 來做，就是整理工作日誌。 _This post is for paying subscribers only._ ### ⚡️休假時做點平常不會做的事 URL: https://ethanhuang13.plus/2026-02-18-ai-tool-break/ Last updated: 2026-08-13T06:07:33.000Z 最近過年，比較少做 agentic coding、軟體開發，出去走動倒是不少。 我覺得這樣挺好，休假就應該做點跟平常不一樣的事情。 _This post is for paying subscribers only._ ### ⚡️做對的事情更難 URL: https://ethanhuang13.plus/2026-02-11-do-right-things/ Last updated: 2026-08-13T06:07:32.000Z \> 這篇是去年初一則[推文](https://x.com/ethanhuang13/status/1875369674017476659?s=46&ref=ethanhuang13.plus)的備份。一字沒改，因為我沒有改變想法。 有會員問我「AI 工具越來越厲害，工程師的技能樹要怎麼點」。 _This post is for paying subscribers only._ ### ⚡️快速 AI 與慢速人類的交會 URL: https://ethanhuang13.plus/2026-02-11-ai-human-intersection/ Last updated: 2026-08-13T06:07:31.000Z 最近因為使用 AI 加速開發，我反而更重視與人互動的機會。 有些人會說：沒跟上這波 AI 浪潮的人會被淘汰。 我卻覺得，每一個還不懂得使用 AI 工具的使用者，都是你我發揮價值的機會。因為 gap 很大，可以幫他們做很多事。 _This post is for paying subscribers only._ ### ⚡️我早該做 13+ 後台 App URL: https://ethanhuang13.plus/2026-02-09-should-have-built-earlier/ Last updated: 2026-08-13T06:07:30.000Z 我真的太晚開始做 13+ 的後台 App 了。 [前幾天的第一版](https://ethanhuang13.plus/2026-02-06-xcode-codex-personal-app/)，已經用來快速發表了幾篇極短篇。 今天，我加上了抓出 Ghost 與 Patreon 會員名單、自動比較的功能，結果令我大吃一驚。 _This post is for paying subscribers only._ ### ⚡️從 AI 焦慮到 AI 過勞 URL: https://ethanhuang13.plus/2026-02-08-ai-over-work-not-sustainable/ Last updated: 2026-08-13T06:07:29.000Z 不久之前，軟體工程師還多半處於「AI 焦慮」。而在接觸過 Claude Code / Codex 以後，許多人進入了「AI 過勞」的瘋狂開發階段，不肯停下來休息。 很像那些「再來一輪」就天亮的精神時光屋式遊戲。 _This post is for paying subscribers only._ ### ⚡️什麼時候 AI 能背鍋？ URL: https://ethanhuang13.plus/2026-02-07-ai-legal-entity-and-liability/ Last updated: 2026-08-13T06:07:28.000Z 忘記我有沒有公開講過了： _This post is for paying subscribers only._ ### ⚡️讓 Agent 學會 TCA 最佳寫法 URL: https://ethanhuang13.plus/2026-02-06-the-point-free-way/ Last updated: 2026-08-13T06:07:27.000Z 如果你有使用 TCA，並且訂閱了 Point-Free，最近有個好東西。 _This post is for paying subscribers only._ ### ⚡️使用 Xcode 26.3 開發推文小 App URL: https://ethanhuang13.plus/2026-02-06-xcode-codex-personal-app/ Last updated: 2026-08-13T06:07:26.000Z 最近我想要減少自己使用 Twitter / Threads 的時間，但又想要有靈感的時候仍有快速發推文的地方，所以就做了一個編輯介面類似推特的小 App，內容則是發表到 13+ 的極短篇。 _This post is for paying subscribers only._ ### 📰 Apple 開發者新聞 #256 Xcode 26.3 與全新 Podcast ⟪不上班工程師的日常⟫ URL: https://ethanhuang13.plus/dev-news-256-xcode-263-podcast/ Last updated: 2026-08-13T06:07:25.000Z > 本文同步發表在 [13 報](https://www.ethanhuang13.com/p/256?ref=ethanhuang13.plus)。 ## TL;DR 新聞一：Xcode 26.3 新增支援 Claude Code 與 OpenAI Codex 的 Agentic 開發能力，還可以反過來以 MCP 被 Agent 呼叫使用。最新的 GPT-Codex-5.3 或 Claude Opus 4.6 模型也可以透過替換 SDK 的方式使用。 新聞二：從 2026 年開始，我跟幾位開發者朋友 Harry ([@harryworld](https://x.com/harryworld?ref=ethanhuang13.plus))、Jane([@janechao\_dev](https://x.com/janechao%5Fdev?ref=ethanhuang13.plus))、Paul([@automorphism](https://x.com/automorphism?ref=ethanhuang13.plus)) 創立了全新的中文 Podcast 節目──⟪不上班工程師的日常⟫，風格是「週末前夕的開發者閒聊」。通常在週五中午於我們的 [YouTube 頻道](https://www.youtube.com/@%E4%B8%8D%E4%B8%8A%E7%8F%AD%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%9A%84%E6%97%A5%E5%B8%B8?ref=ethanhuang13.plus)上架，喜歡聽工程師閒話家常的朋友請別錯過。 _This post is for paying subscribers only._ ### ⚡️OpenClaw 給我真正的啟示 URL: https://ethanhuang13.plus/2026-02-06-openclaw-is-personal-software-system/ Last updated: 2026-03-25T07:00:37.000Z OpenClaw 給我真正的啟示，是「打造系統」這件事。 Peter 先是做了一堆 CLI 工具，截圖、操作瀏覽器、叫外送。等到 Clawdbot 出現時，這些工具都可以輕鬆被呼叫使用，形成強大的綜效。 這是一整套屬於他的系統，而不只是個別工具。 這讓我覺得，去年提出的「[個人軟體時代](https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/)」概念，要進化成「個人軟體系統時代」。 具體來說，我已經開始開發一些自己的 CLI 工具（例如經營 13+ 專欄需要用到的功能），好讓 AI Agent 更容易使用。 從瞭解自己工作與生活的需求做起，把各種工具與流程串起來，或是開發新的。最後整合出一套屬於自己的系統，這是每個人都有機會做的事情。 前提是不再只把軟體視為單一工具，而是系統的一環。 ### ⚡️極短篇：速評 Xcode 26.3 Agent 功能與意義 URL: https://ethanhuang13.plus/2026-02-04-xcode-26-3-agent/ Last updated: 2026-08-13T06:07:24.000Z ## 公告：新的短文形式 親愛的會員朋友，我打算在 13+ 增加新的發文方式，類似長推文或 [Micro.blog](https://micro.blog/?ref=ethanhuang13.plus)。分類我就沿用之前的[極短篇](https://ethanhuang13.plus/tag/lightning-talk/)。 有別於之前的思考或實測經驗分享文章，這種短文的目的在於： 1. 針對技術時事，快速反應 2. 把重要想法先寫下來 內容會像是我在推特上的發文，但是資料與觀點會更齊全。 **這類極短篇將會完全上鎖，沒有免費預覽部分。** 我之後會把官網設計成有專門的區域放置這些短文。 ## 速評 Xcode 26.3 Agent 功能與意義 _This post is for paying subscribers only._ ### 👼13 的 brainOS：AI 工具的心理門檻本身就是機會 URL: https://ethanhuang13.plus/my-brain-os-ux-floor/ Last updated: 2026-08-13T06:07:23.000Z 幾個禮拜前，我去了一個果粉朋友家玩他的 Mac Studio。他對 AI 很有興趣，是那種每天會追各種最新知識的人，但不是工程師，所以使用 AI 的方式停留在處理日常工作的文書作業上。 我本來是要去借用 Mac Studio 跑 Local LLM，看看用開源模型當作 Clawdbot（那是在改名 Moltbot/OpenClaw 之前的事）效果怎麼樣。 我們當時測試的本地模型，沒有得到理想的結果，覺得還是先參考作者的推薦，用 Claude Opus 4.5 作為 Clawdbot 的主要模型，於是我朋友開通了 Claude 的訂閱方案。 我突然想到，既然有了方案，就可以玩 Claude Code。要不要讓他試試看呢？ ## Claude Code 初體驗 其實之前我就問過他：「你知道 AI 能做這麼多事情，也看過那麼多人用 AI 寫出來的 apps，那你有沒有試過用 AI 寫一個自己的 app？」他說：「沒有耶，我覺得 coding 對我來說還是太難了。」 他在公司的前輩導師也一直要他嘗試 vibe coding，但他不知怎麼的就是沒有開始。 這讓我十分好奇，為什麼一個人對 AI 這麼有興趣，卻沒有**拿它來做一些自己做不到的事呢？** 我對於人們怎麼學習、接觸新事物非常有興趣。難得有可以觀察新手的機會！所以我就說：「那我們實際來試試看吧！」他也躍躍欲試。 於是我們一邊玩 Clawdbot，一邊還進 Claude Code 的教學。 不過，我只有幫他安裝 Claude Mac app，指出要從哪裡使用 Claude Code，沒有跟他討論要做出什麼東西。更多的討論是在概念解釋與心理建設方面。 ## 隔天早上的訊息 隔天早上我收到他的訊息說：「我昨天玩到半夜四點才睡！根本停不下來。怎麼辦，我是不是工作狂？」 我一邊心裡覺得好笑，想說大家不是早就叫你嘗試了嗎？但是另一方面又覺得，人們是不是就是這樣，吸收再多的新知，也很難改變自己的做事方式。 我想，**人們需要的是體驗**。就像我一直說的：要實際去玩，獲得 Magic Moment，才會突破自己的限制。 我回答朋友說：「**你不是工作狂，而是像人類突然獲得超能力一樣。**你突然會飛了，難道不會飛一整晚嗎？」 他後來就持續在開發、給我看他的作品。也開始跟其他朋友說要嘗試做自己的 app。 當然，他的朋友們的反應就跟打開 Claude Code 之前的他一樣。這才是讓我覺得最有趣的事情。 ## 人們怎麼突破自己的限制 這件事讓我想起來，我在職場反覆觀察到，很少有人會有意識地去改變自己的做事方式、思考方式、學習方式。 **人們不太會去升級自己的 brainOS。** 那麼這次升級的契機是什麼呢？ _This post is for paying subscribers only._ ### 🦞用不用 OpenClaw 無所謂，但我希望你認識他的創造者 URL: https://ethanhuang13.plus/clawdbot-creator-peter-steinberger/ Last updated: 2026-08-13T06:07:22.000Z 最近 [OpenClaw](https://github.com/openclaw/openclaw?ref=ethanhuang13.plus)(Clawdbot/Moltbot) 成為 AI 工具熱門議題。我大概是在 1/13 安裝起來，已經玩了兩週。一些使用心得我有發在 [Twitter](https://x.com/ethanhuang13/status/2015292441075532245?s=46&ref=ethanhuang13.plus)。 這篇文章不是要介紹 OpenClaw，而是要說一下它的創造者——Peter Steinberger。因為不是每個人都需要 OpenClaw，但開發者的故事能啟發許多人。 Peter 他其實是 iOS/Mac 開發者界的傳奇人物。我以前就很愛看他瘋狂分享的各種深度技術推文，獲益良多。還有幸在 WWDC19 跟他合照。 _This post is for paying subscribers only._ ### 🧠13 的 brainOS：自己的知識是 AI 能力的上限 URL: https://ethanhuang13.plus/my-brain-os-knowledge-is-ai-limit/ Last updated: 2026-08-13T06:07:21.000Z 最近在重寫我人生第一個 app。從 Objective-C & UIKit 轉成 Swift & SwiftUI。 用 Codex 改 code 都很快很順利。語法轉換、參考[我的 TCA 模版](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/)做遷移、按鈕要放在表單還是藏進選單、從列表改成格狀排版，這種小事情，我都不需要特別費力說明，就可以得到想要的結果。 不過到了實際接上使用者（我自己）多年前的資料時，就出現 SwiftUI 列表卡頓的問題。 100 筆左右的資料在 SwiftUI List 為什麼會卡？ 這是因為，我原本的資料設計是滑到 cell 時，才非同步讀取特定資料並顯示。而這些回來的時間不一致，導致 SwiftUI 要一直更新。 於是我改成提早在背景都讀取完。但是大筆資料要在 List 顯示還是要卡個半秒。打開 Instruments 能看到明顯的卡頓。 ![Instruments 看到 Hang](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/01/CleanShot-2026-01-21-at-18.08.55@2x.png) Instruments 看到 Hang 雖然再繼續調整下去一定能解決，但我轉頭跟 Codex 說：**懶得解了，我們改成用 UICollectionView 實作吧。** _This post is for paying subscribers only._ ### 💼13 的 brainOS：在家工作如何切換上下班模式 URL: https://ethanhuang13.plus/my-brain-os-work-from-home-mode-switch/ Last updated: 2026-08-13T06:07:20.000Z 不知道讀者有沒有長期在家工作的經驗？我有超過 5 年的在家工作經驗，這篇文章分享一點工作模式切換的 brainOS 小技巧。 ## 在家工作的爽點與缺點 在家工作，可以 10 秒就從床上跳到電腦前開始工作。不用準備出門、面對天氣、塞車在路上、跟人群擁擠。 家裡很舒服的話，還可以在自己喜歡的角落做事。 但是，如果沒有好的配套措施，在家工作很容易影響休息的品質，大腦很難真的下班、關機。 去辦公室上班需要通勤，雖然會花掉不少時間，但是這個時空過渡對於轉換上下班的狀態很自然。 在家工作的人省下了通勤，卻也失去了自然的模式切換機制。這就導致工作與生活界線的模糊。而且容易演變成「工作到晚一點沒關係」以及「睡晚一點沒關係」。 接下來我就來分享一下我是怎麼安排在家工作的配套措施。 ## 我的 brainOS 策略 _This post is for paying subscribers only._ ### 😎13 的 brainOS：我不想知道 AI 工具的使用量 URL: https://ethanhuang13.plus/my-brain-os-codexbar-productivity-paradox/ Last updated: 2026-08-13T06:07:19.000Z 許多 Agentic CLI 的吃到飽方案都有用量限制。像是 Claude Pro/Max 與 ChatGPT Plus/Pro 都有 **5 小時**與**每週**的 token 使用量限制。 為了要掌握目前 token 消耗程度，是否能夠應付接下來一段時間的工作，許多使用者會安裝用量統計工具。 如果你使用 Claude Code，可能裝過 [ccusage](https://github.com/ryoppippi/ccusage?ref=ethanhuang13.plus) 這類的工具。至於我，目前使用的是 Peter Steinberger 的 [CodexBar](https://codexbar.app/?ref=ethanhuang13.plus)。 CodexBar 是個 Mac 選單列 App，介面簡單易懂。有兩個進度條，分別顯示當前的 5 小時、每週消耗量，與時間的比較，以及預計什麼時候會消耗完。 ![CodexBar 顯示我的 Codex 使用量](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/01/CleanShot-2026-01-15-at-13.14.35@2x.png) CodexBar 顯示我的 Codex 使用量 介面上還會顯示 Pace，也就是目前消耗量是**超前**還是**落後**。讓人更容易憑感覺去判斷消耗量是否夠用。進度超前的話，可能之後會不夠用，可能就要省著用一點。 ## 看起來很好，問題在哪裡？ _This post is for paying subscribers only._ ### 🧠13 的 brainOS：開發日誌之 GPT-5.2-Codex 認真用 URL: https://ethanhuang13.plus/my-brain-os-dev-journal-codex-5-2/ Last updated: 2026-08-13T06:07:18.000Z 讀者可能發現有好幾天沒收到 13+ 的新文章。簡單來說，我在調整寫作方向與工作步調。上週我從旅行休假回來以後，一頭栽進了使用新 AI 工具開發的樂趣中，所以這篇是要來分享這個過程。 原本安排好 1 月份要寫的 brainOS 系列文章，是用「以軟體工程的概念來類比 13 的學習、思考、工作方式」，而且我有很多主題可以寫。但是實際上要寫各篇時，大腦卻覺得頻率不對。 該怎麼辦呢？我想，既然「13 的 brainOS」是要分享自己的學習、思考、工作方式，也不見得每篇都要寫出某個道理。如果我的軟體開發工作有一些值得分享的東西，就可以拿出來講，同時加上自己的思考。 今天的文章，就來分享一下我從休假回來以後，認真使用 AI 工具進行開發的體驗：放下 Claude Code，跳來使用 Codex 的一些心得。 ## 一開始對 Codex CLI 的印象並不好 我是在 2025 年 6 月入坑 Claude Code 這種 Agentic CLI 的開發工具，在[🔥來玩 Claude Code 吧](https://ethanhuang13.plus/ios-ai-tools-11-lets-claude-code/)這篇有介紹到。 後來，OpenAI 也更新了 [Codex CLI](https://github.com/openai/codex?ref=ethanhuang13.plus)，但是我一直沒有很喜歡用。最主要的原因是，我覺得跟 Claude Code 一起工作起來，比較像是有在認真互動的同事。他會給出很多訊息，不確定的事情會回來問我，而且我可以隨時改變主意，把訊息接在後面，他會一併考慮進去。 而 Codex 使用起來，則更像是個安靜的同事。用與 Claude Code 相同的 prompt 對話，Codex 不太會確認我對我指令的理解，也不討論計畫，而是**直接開始做**，而且開發的時間也不短，才讓我確認。這種低互動的 AI 工具，很難取得我的信任。 所以有好長一段時間我還是偏愛 Claude Code。可以說，**悶頭苦幹型的工程師，總是比較吃虧。** ## GPT-5.2-Codex 與 Codex CLI 情況出現變化，是我發現 Claude Code 的極限。用 Claude Opus 4.5 模型很貴，我的 Pro 方案很快就會用完，而 Sonnet 4.5 又沒那麼聰明。 在 5 小時額度用完的時候，我就會切換試試看 Codex，因為我有訂閱 ChatGPT Plus。 GPT-5.2-Codex 模型推出以後，軟體開發能力已經不輸給 Opus。而且 Codex 讓我感覺到，它很能正確理解我想要做的修改，即使沒有跑測試或編譯 app，也往往能夠一次搞定。 過去我很仰賴 Claude Code 自動跑 `xcodebuild test`，從測試與編譯錯誤當中自我修正。這招雖然有效，但是很慢，而且非常消耗 token 與 context window。而 GPT-5.2-Codex 往往能做到直接寫對。 既然模型有這種一次到位的能力，那我也不客氣了。我丟給 Codex 的重度工作有這些： _This post is for paying subscribers only._ ### 🛑13 的 brainOS：幫自己存檔才能關機 URL: https://ethanhuang13.plus/my-brain-os-commit-shutdown/ Last updated: 2026-08-13T06:07:17.000Z 相信許多工程師讀者，都有夜深人靜寫程式進入極度專注狀態，白天清醒再回頭一看，卻發現錯誤百出的經驗。 自我感覺良好不等於狀態良好，其實我們都需要適時休息。 但問題是，如果大腦正在狂轉，怎麼樣才能停得下來？ 在[前一篇文章](https://ethanhuang13.plus/my-brain-os-cold-start/)中，我們談到大腦進入工作狀態需要載入。反過來說，在進入狀態以後，如果要切換到休息狀態，也需要一些措施。 ## 關鍵不是怎麼休息，而是如何存檔 讀者可能會以為我要說的是怎麼讓大腦降速，其實不是。 大腦在做完該做的工作以後，自己就會停下來。只是腦力型工作很少有真的完成的時候。 所以，與其做到讓大腦感覺「完成了」，不如安排一些「存檔點」更實際。 _This post is for paying subscribers only._ ### 🌋13 的 brainOS：其實你不是在拖延，而是在載入中 URL: https://ethanhuang13.plus/my-brain-os-cold-start/ Last updated: 2026-08-13T06:07:16.000Z 由於我每天都在寫文章，又做過各種電子報、Podcast、教學、開發工作，可能有些讀者會以為我是個高效率、多產的工作機器。 其實我並不是。 ## 今天也不想打開電腦 新年前後，我都在半休假狀態（或者應該說，是 95% 在休假狀態）。在旅途中，我常常背著電腦跑一整天、走一萬多步路，也沒有打開 5 分鐘發揮「生產力」。 而今天，在我開始寫文章以前，是這樣的視角： ![喝著咖啡、看著海，不是很想打開電腦](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2026/01/DraggedImage.jpeg) 喝著咖啡、看著海，不是很想打開電腦 我在世界的某個角落喝咖啡、看海，覺得好美。雖然帶了電腦，依舊沒有很想打開來做事情。 不過最後，我想，來都來了，還是對於我在[前一篇文章](https://ethanhuang13.plus/my-brain-os-introduction/)發下的豪語負責吧！ > 接下來一個月，我會用各種軟體工程的概念來談自己學習、思考與工作方式。保證有趣，而且在別的地方肯定讀不到。敬請期待！ 於是，我打開 Ulysses，把編輯視窗開到最大。在一個多小時內，翻掉了我之前整理過的 brainOS 系列文章規劃表，重新編排了一版，列出 15 篇比之前更想寫的題目。 從過程與結果來看，我覺得今天的工作狀況很不錯。就像每次我真的開始認真工作時一樣。 這樣的情況，其實在 13+ 的寫文章過程，**每天**都在實際上演──從拖延、不想面對，到進入狀況，大腦開始工作，然後順利做到。 ## 把拖延看成在載入程式 _This post is for paying subscribers only._ ### 🧠13 的 brainOS：借用軟體工程概念談思考 URL: https://ethanhuang13.plus/my-brain-os-introduction/ Last updated: 2026-01-06T13:48:23.000Z 在 AI 越來越聰明的現在，放棄獨立思考，就等於放棄 AI 留給人類的其他機會。**去了解自己如何思考、強化思考，是每個人現今最值得思考的問題。** 我想要來**拆解自己的學習方式、思考模式，與工作流程**。一方面是為了更了解自己、補足盲點，有助於未來的思考與決策。另一方面，把這個過程展現出來，哪怕讀者不見得能完全派上用場，本身應該也是很有趣的讀物。 所以，在 2026 年 1 月份，我將以「13 的 brainOS」為主題，來分享我如何學習、思考與工作。 ## 借用軟體工程的概念來談思考 要去拆解自己的思考本身就是一項挑戰。而要寫成文章的話，對我來說，還會疊加另一層挑戰。 這是因為，我在很年輕的時候就開始對「人們是如何思考」產生興趣，並且在大學、研究所時主修教育心理學，累積了不少學習與思考的「工具」。這些東西多少已經內化成為自然的運作方式，就像作業系統的 Kernel。 比如說，當我在思考一件事情時，很自動地會動用「後設認知」，也就是能夠**一邊思考、同時去觀察自己是怎麼思考**的。有點**像是一套作業系統在運作時，一邊監控自己的系統資源使用情況**。 近年來，我開始從事軟體開發的**教學**。教學讓我徹底理解到，**拆解自己熟悉的東西**，變成能夠交給新手的學習素材，是非常困難的一件事情。人們在學會一項技能或知識以後，就失去了還沒學會時的觀點，也就是形成了**專家的盲點**──忘記新手在學習時的困難，而且不知道從何教起。 所以，如果把自己的思考過程直接寫出來，對讀者恐怕沒有太大幫助。我的大腦發展出來的這套已經內建在 Kernel 的監控軟體，沒辦法複製給讀者直接安裝。**並不是說我比較厲害，而是我必須找個方法讓自己好懂。** 於是我就想到，既然 13+ 的讀者多半是軟體工程師，那麼我就**試試看用軟體工程的概念與術語，來聊自己的思考方式**！ 比如說，我們都很討厭專心工作時被打斷去處理別的事情，但你知道為什麼嗎？用 Swift 來解釋的話，就是 task/operation 被 cancel 的時候，並不是瞬間就可以完成，正在進行的任務其實還會繼續，直到它們有檢查是否已經被取消。大腦也是一樣，正在思考的事情無法說停就停。 上述這種比喻方式，會出現在整個系列的每篇文章當中。 ## 是為了好玩與易懂，而不是理論 我必須強調，借用軟體工程的概念，是為了幫助讀者們更容易理解，而不是要發展一套「類比電腦運作與人腦思考」的理論。 實際上，我平時並不會用這些類比。是為了寫這系列文章，刻意去尋求兩者之間的關聯，作為說明自己思考方式的「包裝」。軟體工程與認知領域的差別還是很大的，所以每一篇的類比範圍有限，我們不需要強求過度解釋與套用。 比如說，我們可以借用軟體測試的概念，來談怎樣測試自己的想法是否可靠。但是軟體的測試能夠自動化、計算覆蓋率，思想的測試沒有這些特性。 所以，請把文章的闡述方式當成幫助你理解的趣味類比就好。 ## 是參考，而不是思考指南 我把這個系列名稱定為「13 的 brainOS」，是因為這是在描述我自己。**讀者不需要複製我的思考方式，因為每個人的作業系統很不一樣**。 但是你可以參考我的思考方式，並且發展出對自己 brainOS 的規格定義。總之，只要這些文章**能夠幫助你更了解自己一點，對我來說就夠了**。 ## 結語 接下來一個月，我會用各種軟體工程的概念來談自己學習、思考與工作方式。 雖然我已經想出了幾十個可能的題目，比如說用測試的概念、performance tuning、run loop 、feature flags 來談某些思考方式。具體的內容，還是要等到寫下每一篇的當下，一邊思考、一邊撰寫，才能確定。用軟體工程術語來說，撰寫過程就是在 live coding & debugging！ 所以，我不會預告接下來的內容（因為現在也還不確定），但是保證有趣，而且在別的地方肯定讀不到。敬請期待！ 「13 的 brainOS」會在接下來一個月持續更新，完整系列文章只會發布在 13+。 如果你想繼續看我怎麼用軟體工程的角度，拆解學習、思考與工作方式，可以考慮[訂閱](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus)。 [立即訂閱 ](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus) ### 🎊2025 年終回顧與感謝 URL: https://ethanhuang13.plus/2025-year-end-review-thanks/ Last updated: 2026-08-13T06:07:15.000Z 感謝 13+ 的所有會員，我們[又度過了一年](https://ethanhuang13.plus/2024-year-end-review-thanks/)。去年此時，我才剛恢復創作熱情，會員們的支持對我無比重要。而到了今年底，我已經形成連續數個月**穩健的實際產出**，也建立了**系統性寫作能力**。 觀察數據，我赫然發現會員人數成長了 2.3 倍。對我來說，每一位持續訂閱的會員，**不是數字或統計報表，而是一個個從 13+ 獲得收穫並願意付費支持的讀者朋友。謝謝你們！** ![13+ 的付費會員在過去一年成長了 2.3 倍](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-31-at-17.41.18@2x.png) 13+ 的付費會員在過去一年成長了 2.3 倍 ## 每天連載的每月回顧 2025 年對我來說是非常充實的一年，甚至許多年初的事情，體感上都像是去年發生的事情。會有這種感覺，除了我 2 月從公司離職以外，最重要的原因就是 8 月開始的 [13+ 每日更新挑戰](https://ethanhuang13.plus/13-plus-daily-challenge/)。 每天寫作等於半逼著沒在上班的我，每天都要有思考與產出。雖然寫完以前很痛苦（有時候大腦要好幾個小時才能「開機完畢」），但是寫的過程往往很專注，而且每次寫完都感到非常有成就感，覺得自己又做了一件有意義的事情。 這種循環，我每個工作天都在經歷，也難怪讓我的時間感大幅延長。所以，這篇寫作總結，與其說是針對一整年，不如說是**從 8 月連載以來的回顧**。 我的**所有文章都在**[**這個索引網頁**](https://ethanhuang13.plus/index/)**一目瞭然**。下面我簡單照月份回顧一下。 **8 月**，從我的一些做事方法寫起，並且配合 iPlayground 撰寫一系列的[研討會相關文章](https://ethanhuang13.plus/tag/conference/)。 ![2025 年 8 月的文章](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-31-at-16.51.53@2x.png) 2025 年 8 月的文章 [**9 月**](https://ethanhuang13.plus/monthly-review-2025-09-usage-guide/)，續寫研討會主題，到 [Swift Dependencies 套件](https://ethanhuang13.plus/tag/swift-dependencies/)（突然想起來我還有一部分沒寫完😅）、[專欄滿一週年的感謝與回顧](https://ethanhuang13.plus/13-plus-one-year-love-you-three-lessons/)，並開始連載 [USB 測速系列](https://ethanhuang13.plus/tag/iphone-usb-speed-series/)。該系列算是我第一次嘗試一邊研究一邊分享，我非常喜歡那一系列的過程與結果，也影響了我後來嘗試更長篇幅的連載。 ![2025 年 9 月的文章](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-31-at-16.54.41@2x.png) 2025 年 9 月的文章 [**10 月**](https://ethanhuang13.plus/monthly-review-2025-10/)，配合我在臺大的 iOS 教學經驗，寫了一些 [SwiftUI 相關的實作文章](https://ethanhuang13.plus/tag/learning-swiftui-draw-mac-mini-series/)。月底終於有空休假，是我第一次進行旅行中一邊寫作的嘗試。 ![2025 年 10 月的文章](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-31-at-16.58.08@2x.png) 2025 年 10 月的文章 [**11 月**](https://ethanhuang13.plus/monthly-review-2025-11/)，文章主題較為分散，沒有特定專題。但是做了兩個非常重要的調整：[把 13 報（Apple 開發者電子報）跟 13+ 整合](https://ethanhuang13.plus/upgrade-apple-developer-news-commentary/)，以及[把文章全文集中在官網](https://ethanhuang13.plus/monthly-review-2025-11/)。這兩個舉動可以更專心在撰寫文章，而不是去管理各發文平台。 ![2025 年 11 月的文章](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-31-at-17.01.29@2x.png) 2025 年 11 月的文章 [**12 月**](https://ethanhuang13.plus/local-ai-series-summary/)，是我第一次嘗試以整個月的篇幅來寫[單一主題](https://ethanhuang13.plus/tag/local-ai/)。結果，系列連載雖然最後中斷了 2 天，但我寫滿了預期的 20 篇。雖然幾乎每篇的篇幅都爆炸，但還是有很多東西沒機會探索。某方面來說，這反映了有事先設定條件的好處，不然我可能還要多寫十幾篇。 ![2025 年 12 月的文章](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-31-at-16.50.19@2x.png) 2025 年 12 月的文章 ## 開啟新的寫作節奏 _This post is for paying subscribers only._ ### ↩️iOS 本地 AI：連載一個月的實戰心得回顧 URL: https://ethanhuang13.plus/local-ai-series-summary/ Last updated: 2026-08-13T06:07:14.000Z 12 月一轉眼就過去了。iOS 本地 AI 專題系列文章來到 20 篇，也是我規劃中的最後一篇。 讓我們來回顧一下： - 我寫了什麼？ - 我們學到了什麼？ - 在 App 中使用本地 LLM，有什麼實質用處？ - Apple 平台的本地 AI 優勢與潛力 - 使用第三方模型的其他考量 - 往系統整合 - iOS 開發者的本地 AI 機會 ## 我寫了什麼？ 我寫[這個系列專題](https://ethanhuang13.plus/tag/local-ai/)的初衷有三個： 1. [開篇預告](https://ethanhuang13.plus/local-ai-series-intro/)提到發現「iPhone 17 Pro 跑 Foundation Models 居然比 M3 Max MacBook Pro 還快」，新 SoC 的 AI 推論速度大幅提升 2. 繁體中文 Apple Intelligence 正式開放，能使用 Foundation Models framework 的優秀語法，輕鬆呼叫離線小模型 3. Foundation Models framework 的語法相容套件 [AnyLanguageModel](https://github.com/mattt/AnyLanguageModel?ref=ethanhuang13.plus) [宣布開發](https://huggingface.co/blog/anylanguagemodel?ref=ethanhuang13.plus)，使用它就能沿用原本語法、替換各種模型來源 綜合這些條件，讓我感到在 iOS 上執行本地 AI 的可行性大增、開發門檻大幅降低，是個入坑的好時機。 首先，我試圖[打破「AI 功能 = 連網使用」的印象](https://ethanhuang13.plus/local-ai-series-why-online/)，並使用[第三方 ASR](https://ethanhuang13.plus/local-ai-series-try-whisper-asr/)（語音轉文字）與 [Apple 自己的 ASR ](https://ethanhuang13.plus/local-ai-series-apple-asr/)作為示範。 接下來，我提到離線模型的[優點是要依照使用者的特性來談](https://ethanhuang13.plus/local-ai-series-advantage-by-user-type/)。不同群體最在意的事情並不相同。並且建議先導入離線模型做簡單功能，會比直接用雲端大模型做強大功能更好。因為軟體功能很難越做越簡單。 我還簡介了 [Apple Intelligence 的開發者必要知識](https://ethanhuang13.plus/local-ai-series-apple-intelligence-intro/)。前面這幾篇我想綜合表達的重點是，iOS 有許多離線 AI 功能，不知不覺已經相當實用。開發者如果想做類似的事情，都可以參考系統的相關功能。 接著，我們正式開始入坑 Foundation Models framework，從 [建立學習策略](https://ethanhuang13.plus/local-ai-series-foundation-models-hands-on/) 開始，介紹 [基本語法與可用性檢查](https://ethanhuang13.plus/local-ai-series-foundation-models-availability-instructions/)、[Structured Output](https://ethanhuang13.plus/local-ai-series-foundation-models-structured-output/)、[PromptBuilder](https://ethanhuang13.plus/local-ai-series-foundation-models-prompt-builder/)、[Stream Response](https://ethanhuang13.plus/local-ai-series-stream-response/)、[Tool Calling](https://ethanhuang13.plus/local-ai-series-foundation-models-tool-calling/)、[錯誤處理與使用者體驗強化](https://ethanhuang13.plus/local-ai-series-foundation-models-ux/)、[衡量效能的工具與策略](https://ethanhuang13.plus/local-ai-series-foundation-models-benchmarking/)。最後還附上了[補充延伸資料](https://ethanhuang13.plus/local-ai-series-foundation-models-resources/)。 除了介紹框架的用法以外，我也示範了如何建立自己的研究型專案。這個技能可以沿用到學習各種程式技術上。 系列的最後一部分，我開始試用 `AnyLanguageModel` 套件，看看能否如同宣稱的一樣直接替換（drop-in replacement）。先做了一些[準備工作](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-prepare/) 並介紹 [Package Traits](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-package-traits/) 機制。然後嘗試了[接上 LM Studio 提供的 LLM Server](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-lmstudio-server/)，以及在 iOS App 中[下載開源模型並用 MLX 執行](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-mlx/)。 對我來說，這系列的寫作過程中，有很多東西是之前聽過、看過，但沒有實際摸過，所以藉著這個機會，一邊研究、一邊把過程與經驗分享出來。 經過 19 篇文章的探索，實際情況如何呢？ ## 我們學到了什麼？ _This post is for paying subscribers only._ ### ❎iOS 本地 AI：用 AnyLanguageModel 加 MLX 跑開源模型 URL: https://ethanhuang13.plus/local-ai-series-anylanguagemodel-mlx/ Last updated: 2026-08-13T06:07:13.000Z 這個系列講了很多 Foundation Models，也試過用 `AnyLanguageModel` [連線到 LM Studio Server](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-lmstudio-server/)。現在，我們應該會很想知道，要怎麼樣在 Mac 或 iOS 上跑開源模型吧？ 這就是效果的影片： ![透過 AnyLanguageModel 在 iOS App 呼叫 MLX 執行開源模型，並觀察記憶體使用量與輸出速度](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-26-at-03.04.04.gif) 透過 AnyLanguageModel 在 iOS App 呼叫 MLX 執行開源模型，並觀察記憶體使用量與輸出速度 至於要怎麼做到，讓我一步一步說明。 要在 Apple 裝置上執行開源 AI 模型，有兩個常見的技術，一個是 [Core ML](https://developer.apple.com/documentation/coreml?ref=ethanhuang13.plus)，另一個則是 [MLX](https://ml-explore.github.io/mlx/build/html/index.html?ref=ethanhuang13.plus)。以下根據我粗淺的理解，簡單介紹兩者的差異。 ## Core ML 簡介 [Core ML](https://developer.apple.com/documentation/coreml?ref=ethanhuang13.plus) 這個名稱對於 iOS 開發者來說，應該不算陌生。它在 iOS 11 推出，能夠在 iPhone 上執行各種 AI 模型（不只是語言模型），並且充分利用 SoC 中的 Apple Neural Engine（簡稱 ANE），所以既節能，又高效。 不過，Core ML 執行的 AI 模型檔案需要使用 Apple 自家的 [Core ML 格式](https://apple.github.io/coremltools/mlmodel/Format/Model.html?ref=ethanhuang13.plus)。其他模型要轉換成 CoreML 格式並不總是那麼容易，雖然也有像 [ANEMLL](https://github.com/Anemll/Anemll?ref=ethanhuang13.plus) 這種專案與社群在努力。 因此，如果要執行開源模型，許多人會考慮去使用 MLX。 ## MLX 簡介 [MLX](https://ml-explore.github.io/mlx/build/html/index.html?ref=ethanhuang13.plus) 是 2023 年 Apple 推出的開源專案，偏向研究性質（MLX 的意思就是 Machine Learning Explore）。使用 Metal API，加上統一記憶體架構的優勢，讓 AI 運算能夠發揮 Apple silicon 的完整實力。雖然它並[不支援 ANE](https://github.com/ml-explore/mlx/issues/18?ref=ethanhuang13.plus)，但是對於現有的開源模型生態來說，較容易相容。 MLX 有多個 repository 在 GitHub [mlx-explore](https://github.com/ml-explore?ref=ethanhuang13.plus) 組織底下。[mlx](https://github.com/ml-explore/mlx?ref=ethanhuang13.plus) 支援 Python、C++，甚至還有 C 語言套件 [mlx-c](https://github.com/ml-explore/mlx-c?ref=ethanhuang13.plus)。而 iOS/Mac App 開發者熟悉的 Swift，也有 [mlx-swift](https://github.com/ml-explore/mlx-swift?ref=ethanhuang13.plus) 的套件可以使用。如果你想自行研究的話，建議從 [mlx-swift-examples](https://github.com/ml-explore/mlx-swift-examples?ref=ethanhuang13.plus) 開始。 MLX 也有自己的最佳化模型格式。你可以在 [Hugging Face](https://huggingface.co/?ref=ethanhuang13.plus) 上找到 [MLX Community](https://huggingface.co/mlx-community?ref=ethanhuang13.plus) 轉檔好的許多模型，並直接下載。 ## Hugging Face 簡介 說到 [Hugging Face](https://huggingface.co/?ref=ethanhuang13.plus)，如果你感到陌生的話，簡單來說：它是全球最大的開源 AI 模型的存放平台，相對於 GitHub 是全球最大的開源軟體專案平台一樣的地位。 要認識 Hugging Face，尤其是學習怎麼閱讀開源模型的資訊（模型卡）、介面要怎麼讀，我很推薦 ChaoCode 的這兩部影片： 在 Hugging Face 上，大部分的開源模型都不需要登入就可以下載（除了有些要簽協議才能使用）。這包括**直接從 iOS App 下載到裝置上來執行**。也就是說，開發者如果想要讓使用者下載模型，一毛錢都不用出。 目前 Hugging Face 也有 Swift Package 提供下載模型的機制： - [Swift Transformers](https://github.com/huggingface/swift-transformers?ref=ethanhuang13.plus) 是用來開發 Swift 的語言模型功能的工具包，其中包含下載模型的功能。目前已經是 1.0 的成熟套件，詳情可看[這篇](https://huggingface.co/blog/swift-transformers?ref=ethanhuang13.plus) - [Swift Hugging Face](https://github.com/huggingface/swift-huggingface?ref=ethanhuang13.plus) 是新的、獨立的模型下載工具，跟 `AnyLanguageModel` 一樣是由 Mattt 開發，並且之後打算取代 Swift Transformers 內的下載工具。詳情可看[這篇](https://huggingface.co/blog/swift-huggingface?ref=ethanhuang13.plus) ## 簡單上手 雖然上面提到很多概念跟新名詞，但是使用 `AnyLanguageModel` 設定、下載 Hugging Face 上的開源 LLM、並且執行，卻顯得非常簡單，就這樣三行程式碼： _This post is for paying subscribers only._ ### 🚜iOS 本地 AI：用 LM Studio 把 AnyLanguageModel 接上本地 LLM URL: https://ethanhuang13.plus/local-ai-series-anylanguagemodel-lmstudio-server/ Last updated: 2026-08-13T06:07:12.000Z 這是踩坑 `AnyLanguageModel` 以來的第三篇。`AnyLanguageModel` 宣稱能從 `import FoundationModels` 無縫替換成 `import AnyLanguageModel`。 一般來說，這種語法及功能的完全相容套件，會被宣稱為 drop-in replacement。`AnyLanguageModel` 也確實朝這個目的在開發中。 不過，除了上一篇提到的 `Identifiable` 問題以外，它目前（0.5.2 版）還有多個問題，使我們無法做到 100% 替換成功。 當我們把 `AIPlayground` 0.2.0 版的 `enabledTraits` 加上 `anyLanguageModelTrait`（具體作法[請參考前一篇文章](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-package-traits/)）以後，會發現有幾個 build errors。 這些問題我們可以暫時繞過不管，但我還是列出來如下： - 在 `#Playground` 中，`@Generable` macro 產生的 memberwise init 方法會無法使用。我已經回報了 [Issue #74](https://github.com/mattt/AnyLanguageModel/issues/74?ref=ethanhuang13.plus)。這個問題會影響到我們的 `Prompt Builder.swift`，或是在 `#Playground` 裡面新增範例 `Generable` type 的需求，workaround 就是搬到 `#Playground` 以外來寫 - `@Generable` macro 沒有支援 `PromptRepresentable`，所以會無法放入 `PromptBuilder` closure - `@Generable` macro 沒有把 property 的 type 正確設定成 `Type.PartiallyGenerated`。這個問題會影響到我們的 `extension CatProfiles.PartiallyGenerated: View` 實作 - 傳入 `SystemLanguageModel.default` 時，幾個 structured output 的範例會出現 type mismatch 的錯誤。也就是說，`AnyLanguageModel` 還沒有做到完全複製 Foundation Models 該有的行為 除了前一篇提到的 `Identifiable` 問題[我發了 PR](https://github.com/mattt/AnyLanguageModel/pull/73?ref=ethanhuang13.plus)、上述第一個問題有[回報 Issue](https://github.com/mattt/AnyLanguageModel/issues/74?ref=ethanhuang13.plus) 以外，其餘問題我讀了程式碼以後，無法在短時間內解決，所以只好先修改 `AIPlayground`。當你在專案中看到 `// XXX`，就表示是 workaround。 `AnyLanguageModel` 目前仍在積極開發 structured output 與 `@Generable` 相關的功能。雖然上述問題說不定很快就能獲得解決，至少現在還沒。 那麼，到這篇文章發表為止，`AnyLanguageModel` 有什麼真正的實用性嗎？ 有的。到目前為止，我們可以先暫時放棄 structured output。先來試試看串接第三方的模型，並且先專注在接收純文字的回傳。 讓我們先調整一下的 `AIPlayground`，好讓替換模型更方便。 ## 讓 BenchmarkingView 支援顯示 Markdown 文字 讓模型生成的字串顯示在 SwiftUI 很容易，因為我們已經有 `BenchmarkingView` 了。 ```swift extension String: GenerableView {} extension String: @retroactive View { public var body: some View { if let text = try? AttributedString( markdown: self, options: .init(interpretedSyntax: .inlineOnlyPreservingWhitespace) ) { Text(text) } else { Text(self) } } } ``` 多數語言模型會回傳 Markdown 格式，所以如果字串能被正確解析，就照格式來顯示。 值得注意的是這行：`extension String: @retroactive View` - 照理來說我們應該要 `extension String.PartiallyGenerated`，不過它們是相同的型別，所以就寫 `extension String` 即可 - 加上 `@retroactive`，是因為我們「宣告一個不歸我們掌控的 type，去 conform 某個不歸我們掌控的 protocol」。通常來說這是個壞主意，因為我們不知道那個 type 未來會不會也宣告支援該 protocol，並且有不同的實作，那就有可能會造成意外。Swift 6 開始會警告我們。要手動標記 `@retroactive` 才能消除警告。詳情請參考 [SE-0364](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md?ref=ethanhuang13.plus) 除了增加顯示 Markdown 字串以外，我還進行了一些調整： - 在 `BenchmarkingView` 增加顯示錯誤訊息的功能 - 讓 `BenchmarkingView` 與 `BenchmarkingGenerator` 支援傳入模型參數 `any LanguageModel`，方便我們使用 `AnyLanguageModel` 提供的各種模型設定 以上範例程式碼的更新，我已經上傳到 [AIPlayground](https://github.com/ethanhuang13/AIPlayground?ref=ethanhuang13.plus) 的 `0.3.0` 版了。 ## 使用 LM Studio 作為本地 LLM 伺服器 為了讓讀者體會 `AnyLanguageModel` 替換成其他模型的效果，我認為最快速且免費的方式，是**在 Mac 上安裝一個能執行本地語言模型的程式，並且作為本地端伺服器的方式來使用**。 這次，我設計了一個 [weak self podcast](https://weakself.dev/?ref=ethanhuang13.plus) 節目的假想逐字稿生成範例。雖然我從來不會想要用 AI 工具來生成節目大綱，但是看看語言模型對於我熟悉的東西會生出什麼東西來，還滿好玩的。 讀者當然可以替換成自己想要的 instructions 與 prompt。 先看最終效果： _This post is for paying subscribers only._ ### 🚥iOS 本地 AI：利用 Swift Package Traits 切換使用 AnyLanguageModel URL: https://ethanhuang13.plus/local-ai-series-anylanguagemodel-package-traits/ Last updated: 2026-08-13T06:07:11.000Z > 2026/01/11 更新：AnyLanguageModel 0.5.3 已包含我的 [Pull Request #73](https://github.com/mattt/AnyLanguageModel/pull/73?ref=ethanhuang13.plus) 延續[上一篇文章](https://ethanhuang13.plus/local-ai-series-anylanguagemodel-prepare/)，我們要來研究把 Foundation Models framework 替換成 [AnyLanguageModel](https://github.com/mattt/AnyLanguageModel?ref=ethanhuang13.plus)。 我原本規劃的文章內容與時程，被研究進度耽擱了。所以，我就把實際遇到的問題，以及目前的解法分享出來。我覺得這才是最真實、且有趣的專欄經營方式。 ## Add Identifiable Conformance to PartiallyGenerated 如同前文提到的，AnyLanguageModel 截至 0.5.2 版的 `@Generable` macros，沒有像 Foundation Models framework 的版本，有替 `PartiallyGenerated` type 加上 `id` property，以及 `Identifiable`。 這個 `id` 會方便我們在 SwiftUI 當中使用生成的物件，特別是在 `ForEach`。 我希望 `AIPlayground` 可以輕鬆在兩個框架之間切換，所以這個問題必須被解決。 於是，我研究了一下如何修改 macros，結果意外地簡單。因為我們不是要從頭寫一遍，有 Foundation Models 的版本可以參考。 如果我們寫一個 Foundation Models 的 `@Generable` type，並且用 Xcode 的 Expand Macro 功能展開，會看到原本的 type 會被插入類似這樣的程式碼： _This post is for paying subscribers only._ ### 🕳️iOS 本地 AI：準備踩坑 AnyLanguageModel URL: https://ethanhuang13.plus/local-ai-series-anylanguagemodel-prepare/ Last updated: 2026-08-13T06:07:10.000Z > 2025/12/24 勘誤：Package Traits 功能應為 Swift 6.1 推出，原先誤植為 Swift 6.2。 我在 WWDC25 第一次看到 Foundation Models 的 `@Generable` macros 功能時，就覺得概念很好。同時就想到：會不會有人做出相容語法的套件，可以替換模型，但保留原本的呼叫方式？ 很高興的是，果然有人做出來了。Apple 開發圈備受信任的 [@mattt](https://x.com/mattt?ref=ethanhuang13.plus)（[NSHipster](https://nshipster.com/?ref=ethanhuang13.plus) 原作者）與 [Hugging Face](https://huggingface.co/?ref=ethanhuang13.plus) 合作，開發出 [AnyLanguageModel](https://github.com/mattt/AnyLanguageModel?ref=ethanhuang13.plus) 這個專案，讓開發者可以把 Foundation Models 替換成在本地執行第三方開源模型，或是 OpenAI、Claude、Gemini 等雲端模型，但是盡可能保留原本寫好的語法。 Mattt 撰寫了一篇介紹文章，發表在 Hugging Face 上： [Introducing AnyLanguageModel: One API for Local and Remote LLMs on Apple Platforms](https://huggingface.co/blog/anylanguagemodel?ref=ethanhuang13.plus)。 他談到了以 Foundation Models framework 為基礎是很好的開始，因為： 1. 有好的開發者體驗（我們已經用多篇文章說明了它的語法優秀之處） 2. 雖然功能有限，卻是好的基礎，讓開發者可以先聚焦在語言模型共通的核心功能上 3. 想要避免使用其他抽象層，讓事情更複雜 所以，`AnyLanguageModel` 走的路線，完全相容 Foundation Models framework 的語法。 **理想上**，開發者只要把： ```swift import FoundationModels ``` 替換成： ```swift import AnyLanguageModel ``` 並且把原本建立 `session` 的方式： ```swift let session = LanguageModelSession() // 等同於LanguageModelSession(model: SystemLanguageModel.default) ``` 改寫成： ```swift let model = CoreMLLanguageModel / MLXLanguageModel / LlamaLanguageModel / OpenAILanguageModel / AnthropicLanguageModel / GeminiLanguageModel // 先建立想使用的外部 model 或服務 let session = LanguageModelSession(model: model) ``` **其餘呼叫 `session` 產生 response 的方式，都不需要調整。** 語法相容是很美好的理想。但是底層模型不同，實際效果如何？我們當然得親自實驗才知道。 _This post is for paying subscribers only._ ### 📗iOS 本地 AI：Foundation Models framework 延伸資料 URL: https://ethanhuang13.plus/local-ai-series-foundation-models-resources/ Last updated: 2026-08-13T06:07:09.000Z 關於 Foundation Models framework，還有很多進階內容可以談。不過我撰寫這個[系列專題](https://ethanhuang13.plus/tag/local-ai/)的目的，是帶讀者自己上手體驗。目前的篇幅，我覺得已經達到目的了。 以下，我會整理一些可以進一步研究的方向，以及整理好的學習素材，供有興趣的朋友參考。 ## 值得研究的功能與方向 **節省重複的結構化輸入** 如果你的 `Prompt` 已經提供了期望輸出的結構，則可以使用 `includeSchemaInPrompt: false` 節省重複的輸入。請參考 [Code Along 文章](https://developer.apple.com/events/resources/code-along-205/?ref=ethanhuang13.plus)的 6.2: Optimizing the prompt。 **探索 GenerationOptions** 除了 `sampling: .greedy` 以外，我沒有針對 [GenerationOptions](https://developer.apple.com/documentation/foundationmodels/generationoptions?ref=ethanhuang13.plus) 多做介紹。裡面有一些使用模型的參數，包含 [SamplingMode](https://developer.apple.com/documentation/foundationmodels/generationoptions/samplingmode?ref=ethanhuang13.plus)、temperature、maximumResponseTokens。 **加強多語言使用者體驗** Foundation Models 雖然支援中文以及多種語言，但是英文的表現會最好。並且如果提示詞裡面出現了英文，它很有可能會「不小心」輸出英文的結果。 如果你有照著我的文章在寫 `AIPlayground`，應該會發現我幾乎都是用中文在寫 `Prompt` 與 `@Guide`，甚至還有 `User locale: zh-Hant-tw` 的字句（這是我跟 Jane 學的。影片連結在下方），因為我只想要看到中文的結果。 實際上，通常 App 要支援多種使用者語言，所以 AI 生成的結果也應該要對應使用者的語言。這是個使用 LLM 時很重要的議題，會有不少挑戰。如果你要開始支援多語言，我建議先從官方文件讀起。 **使用模型做分類標籤** 如果你使用 Foundation Models 的目的是要幫內容標分類標籤，那麼宣告 model 時可以寫成 `let model = SystemLanguageModel(useCase: .contentTagging)`。更多細節請參考[官方文件](https://developer.apple.com/documentation/foundationmodels/categorizing-and-organizing-data-with-content-tags?ref=ethanhuang13.plus)。 **回饋模型生成的結果** 如果你想要蒐集 Foundation Models 的使用者回饋，內建的 [logFeedbackAttachment()](https://developer.apple.com/documentation/foundationmodels/languagemodelsession/logfeedbackattachment%28sentiment:issues:desiredoutput:%29?ref=ethanhuang13.plus) 方法（有 3 種變化）可以直接打包對話紀錄跟回饋反應。 不過 Apple 做這個機制主要是希望透過 [Feedback Assistant](https://feedbackassistant.apple.com/?ref=ethanhuang13.plus) 回饋，來改進模型。還有，打包的內容會有完整的對話紀錄，所以**一定要經過使用者同意**。 **訓練自己的 Adapter 並套用到 Foundation Models** 如果你熟悉語言模型的原理，應該知道可以使用 adapter 去調整模型輸出的權重，得到更好的輸出結果。 Foundation Models 也支援 adapter，不過實務上會非常麻煩。我覺得這是萬非不得已才要去考慮的事情。原因如下： _This post is for paying subscribers only._ ### ⏱️iOS 本地 AI：衡量 Foundation Models 效能的策略 URL: https://ethanhuang13.plus/local-ai-series-foundation-models-benchmarking/ Last updated: 2026-08-13T06:07:08.000Z 我們要怎麼知道 Foundation Models framework 運作的效能呢？一個方式是使用 Xcode 內建的 Instruments，另一個則是自己撰寫 benchmarking 的工具。 本文會先簡單介紹怎麼使用 Foundation Models Instrument，再分享一個我開發出來，方便重複執行模型任務的 SwiftUI `BenchmarkingView`。 ## Instruments Instruments 會清楚呈現 Foundation Models 運作過程中的每個階段所花的時間、用到的資源。這樣一來，我們就有機會改善效能。 在 Xcode 26 按下 `Cmd + I` （或使用以下影片的冷門技巧），就可以把當前要執行的 App 用 Instruments 打開。 ![冷門 Xcode 技巧：Run 按鈕可以長按，就會出現其他選項，並且可以固定在那邊。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-00.31.33.gif) 冷門 Xcode 技巧：Run 按鈕可以長按，就會出現其他選項，並且可以固定在那邊。 不過，我們要跑什麼呢？就是要把 App 跑起來，按下執行生成的按鈕，然後觀察它的運作。 目前最快的方式，是把[之前文章](https://ethanhuang13.plus/local-ai-series-stream-response/)教過的 `Streaming Response.swift `稍作修改。 把 `private struct CatSelectionView: View` 的 `private` 移除，然後到 `AIPlayground.swift`，也就是放 `App` 的檔案，把它改成： ```swift @main struct AIPlayground: App { var body: some Scene { WindowGroup { CatSelectionView() // 原本可能是空的 } } } ``` 這樣我們就可以在 Mac 或 iOS 裝置上執行這個 App，反覆測試生成 `[CatProfile]`，並且在 Instruments 觀察。 剛打開 Instruments 時，會跳出 Template 視窗，這時候請選 `Blank`。 ![選擇 Blank](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-00.11.26@2x.png) 選擇 Blank Template 接著，按下 `+ Instrument` 按鈕，找到 Foundation Models。 ![新增 Foundation Models Instrument](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-00.12.11@2x.png) 新增 Foundation Models Instrument 加入成功以後，確認裝置與 App 無誤，就可以按下左上的 Record 按鈕。 ![按下 Record 按鈕，開始執行](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-00.13.15@2x.png) 按下 Record 按鈕，開始執行 在 App 中開始執行模型，就會看到 Instruments 的時間軸出現東西。記得先把它停下來，然後把時間軸放大，並且按箭頭展開，看 Session。 ![透過 Foundation Models Instrument 看 Session 細節](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-00.20.22@2x.png) 透過 Foundation Models Instrument 看 Session 細節 我們可以看到當前的 `session` 的整體時間、第一個 token 的時間、輸入與輸出用掉的 token 數量（也就是佔據的 context window）。 以下我示範兩種情境，展示[前一篇文章](https://ethanhuang13.plus/local-ai-series-foundation-models-ux/)提到的重要功能 `prewarm()`，能讓使用者感知的等待時間變短。 Run 1 沒有先執行 `prewarm()`，花了 4.85 秒，其中前面黃色的部分是在載入模型資源。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-00.59.08@2x.png) Run 2 則有在畫面剛打開時就先用 `prewarm()` 來偷跑。所以花在推理的時間只有 4.47 秒，省了大概半秒。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-01.00.52@2x.png) 換言之，當使用者按下按鈕後，更快看到介面有更新（不論是使用 stream response 還是單次）。所以，這個技巧確實有用，而且 Instruments 精準地展現出來了。 關於 Instruments 的操作，我覺得最好的學習方式還是看影片，所以我再次推薦 Meet with Apple [Code along with the Foundation Models framework](https://www.youtube.com/watch?v=S5F196tqRMI&t=5660s&ref=ethanhuang13.plus) 影片，參考 Chapter 6 。 另外我要提醒一個問題：⚠️ **Instruments 的右下角面板有個坑！**它有時候沒有更新，比如我從 Run 1 切到 Run 2 時，面板顯示的資料還是 Run 1 的。建議看清楚 Request ID。 ![Instruments 的 bug：切到 Run 2 時，右下角面板還在顯示 Run 1 的 Session 資料](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-19-at-01.02.35@2x.png) Instruments 的 bug：切到 Run 2 時，右下角面板還在顯示 Run 1 的 Session 資料 ## 使用 BenchmarkingView 來測試與開發 Foundation Models framework 在 `#Playground` 再怎麼方便，最終還是得搬到使用者介面上去操作。 而且，我們必須在實機上操作，最好能直接展示漸進式生成的效果。 而為了簡化操作與開發的過程，我親自寫了一個 `BenchmarkingView`（這次沒有用 AI 寫程式，自己寫還是很有樂趣的）。它可以做到這些功能： - **支援不同的 `@Generable`，也就是不同的 structured output** - **直接展示 stream response 變成 UI 的過程** - 顯示第一次回應的時間（stream response） - 顯示執行時間 - 支援 iOS 與 Mac - 開關 `prewarm()` - 支援 stream response 或單次回應 - 重複執行 - 在 SwiftUI Preview 中使用（小技巧：可以選擇 iPhone 實機） - 可以搭配 Instruments 使用 開發出來以後，我覺得它的用途不只是測速，更是**展示「裝置端模型在生成介面的漸進式過程」的工具，就像是實機、UI 版的 `#Playground`。**是個實用的開發工具。 以下附上程式碼，請貼到你的 AIPlayground 專案中。 _This post is for paying subscribers only._ ### 🆙iOS 本地 AI：Foundation Models 的限制、錯誤與 UX 設計技巧 URL: https://ethanhuang13.plus/local-ai-series-foundation-models-ux/ Last updated: 2026-08-13T06:07:07.000Z 我們已經介紹過 Foundation Models framework 的大部分功能了。在本篇文章中，我會整理一些提升使用者體驗的技巧，讓 App 變得更可靠、實用。 在開始之前，我推薦你閱讀 Apple Human Interface Guidelines 的 [Generative AI 篇章](https://developer.apple.com/design/human-interface-guidelines/generative-ai?ref=ethanhuang13.plus)（英文。另有[簡體中文版](https://developer.apple.com/cn/design/human-interface-guidelines/generative-ai?ref=ethanhuang13.plus)），學習什麼是良好的生成式 AI 應用體驗。例如給用戶掌控感、包容性設計、實用性、隱私與資料使用透明等。而我覺得最重要的一點是：**在設備無法使用或使用者拒絕使用生成式 AI 時，App 仍要保持好的體驗**。 接下來，我們先「暖身」、複習檢查模型可用，然後談管理 context window 與安全護欄的問題，最後列出其他可能拋出的[錯誤類型](https://developer.apple.com/documentation/foundationmodels/languagemodelsession/generationerror?ref=ethanhuang13.plus)。 這些錯誤往往都能事前加強或事後補救，而**危機就是轉機，處理錯誤就是提升使用者體驗的機會**。 ## 讓模型暖身，縮短初次回應時間 在呼叫模型的時候，我們通常需要等待一段時間才會收到第一個回應，有點像是需要先「集氣」才能輸出火力。 如果根據使用者目前的操作，預料到稍後可能會使用 Foundation Models 來「開火」，我們就可以先集氣，就有機會減少後續的等待時間。 別小看這件事情，**如果能讓使用者少等 1 秒就開始看到模型回應的結果，感受會很明顯**。搭配 [stream response](https://ethanhuang13.plus/local-ai-series-stream-response/) 來漸進顯示介面，效果更佳。很容易產生「這個 AI 功能好快好厲害」的感覺。 使用方法很簡單：呼叫 `LanguageModelSession` 的 [prewarm()](https://developer.apple.com/documentation/foundationmodels/languagemodelsession/prewarm%28promptprefix:%29?ref=ethanhuang13.plus)。 `prewarm()` 可以附上 `promptPrefix: Prompt` 參數，內容通常就會是完整 `Prompt` 的最前面部分。理論上會對後續的生成會有幫助，但需要自行實驗。 要注意的是，`prewarm()` 並非萬能。[官方文件提到](https://developer.apple.com/documentation/foundationmodels/languagemodelsession/prewarm%28promptprefix:%29?ref=ethanhuang13.plus#discussion)，要在 `respond` 或 `streamResponse` 之前**至少 1 秒前使用**，畢竟集氣就是需要提早一些時間偷跑才有意義。通時，若系統相關資源忙碌中，則 `prewarm()` 也不一定會有效果。 所以，開發者的任務是找到適合提早使用 `prewarm()` 的時機，以及也許能加速後續生成的 `promptPrefix`（非必要）。進到特定畫面，或是使用者開始打字時，可能會是不錯的時機。 ## 確保模型可用 在使用 Foundation Models 以前，檢查模型是否可用是必要的工作。先前的文章我們已經談過[檢查模型可用](https://ethanhuang13.plus/local-ai-series-foundation-models-availability-instructions/)的方法，這邊簡短回顧：如果是硬體不支援，App 的其他功能應該要能正常使用。如果是 Apple Intelligence 尚未開啟，或系統正在下載模型檔，則可以提示對應的資訊給使用者。 當你忘記先檢查模型是否可用，或是使用過程中模型被刪除（比如在 App 運作中，使用者手動關閉了 Apple Intelligence），就可能會遇到 [**assetsUnavailable**](https://developer.apple.com/documentation/foundationmodels/languagemodelsession/generationerror/assetsunavailable%28%5F:%29?ref=ethanhuang13.plus) 錯誤。至於處理的方式，應該回到檢查模型是否可用的處理。 ## 管理 Context Window 與處理超過時的錯誤 _This post is for paying subscribers only._ ### 🧮iOS 本地 AI：Foundation Models 的 Tool Calling，真正的問題是什麼時候該用 URL: https://ethanhuang13.plus/local-ai-series-foundation-models-tool-calling/ Last updated: 2026-08-13T06:07:06.000Z Foundation Models framework 跟大多成熟的 LLM 工具一樣，具有呼叫外部工具的能力，而且實作起來很容易，甚至能令人不假思索地便開始使用。 但是我想說的是，**並不是所有情況都需要使用外部工具**。我們應該先考慮能否用一般的方式來存取資訊、運算，只有在必要時才對語言模型進行工具的整合。 在這篇文章中，我會先示範工具呼叫的語法，再回頭來談什麼時候適合使用這項機制。 ## 以取得當地天氣的工具為例 你可以把以下的程式碼範例新增並貼到 `Tool Calling - Weather.swift` 檔案中。 ```swift import FoundationModels import Playgrounds @Generable private struct WeatherCondition { var temperature: Double var chanceOfRain: Double var humidity: Double } private struct WeatherConditionTool: Tool { let name = "weatherCondition" let description = "Get current weather conditions for a location" @Generable struct Arguments { let locationName: String } func call(arguments: Arguments) async throws -> some PromptRepresentable { // 示範用的假資料。實際上這裡可能會呼叫外部 API let weatherCondition = WeatherCondition( temperature: 16, chanceOfRain: 0.3, humidity: 0.7, ) return weatherCondition } } #Playground { let session = LanguageModelSession( tools: [WeatherConditionTool()], // 模型會根據語意來判斷需要天氣資料，而自動呼叫工具 instructions: "描述當地天氣資訊" ) let response = try await session.respond(to: "全糖市") print(response.content) // "目前全糖市的氣溫是16度，有30%的機會會下雨，濕度是70%。" let transcript = session.transcript // 顯示 session 呼叫過程 } ``` 這個範例宣告了 `WeatherConditionTool` 的工具型別。要滿足 [Tool](https://developer.apple.com/documentation/foundationmodels/tool?ref=ethanhuang13.plus) protocol，必須實作 `name`、`description`、`call(arguments: Arguments)` 以及一個 `@Generable struct Arguments`。 顧名思義，`name` 與 `description` 是以文字提示的形式告訴模型工具的用途。`Arguments` 是模型會丟給工具的參數，使用我們已經很熟悉的 `@Generable` macros。而最重要的工具實作功能，就是在 `func call()` 完成。 在我的範例中，是直接回傳一個固定的假天氣資料。實際上，這邊應該會是去呼叫外部的資訊來源，例如 WeatherKit API。 建立好這個 `Tool` 以後，我們要在 `LanguageModelSession` 建立時，就放入`tools: [WeatherConditionTool()]` 參數。在整個 session 過程中，遇到有需要的任務指示，模型會自動判斷要不要使用對應的工具。 ## 什麼情況需要 Tool Calling 第一次接觸 Tool Calling 機制，你可能會覺得很合理，甚至會想到可以做很多工具來給模型使用。 但是有些 Tool 在真正的 App 開發流程中，沒有太大的必要。比如上述的例子中，取得當地天氣 API 的輸入參數，其實不需要先被語言模型解析才能獲得，使用 Core Location 取得 GPS 座標做為參數更實際。 而且另一方面，一旦我們宣告了 `Tool`，就會佔用當前 `session` 一部分的記憶空間，[官方文件](https://developer.apple.com/documentation/foundationmodels/tool?ref=ethanhuang13.plus)也建議限制工具在 3\~5 個以內（之後我會專文探討 context window），所以外部工具不是免費與萬能的。 那麼，什麼情況才適合使用 `Tool` 呢？ _This post is for paying subscribers only._ ### 🛝iOS 本地 AI：不讓使用者乾等，Foundation Models 的 Stream Response 能輕鬆實現漸進式使用者體驗 URL: https://ethanhuang13.plus/local-ai-series-stream-response/ Last updated: 2026-08-13T06:07:05.000Z [這個專題系列的文章](https://ethanhuang13.plus/tag/local-ai/)，已經介紹了 Foundation Models framework 的基本語法，包含直接[定義期望的資料結構的功能](https://ethanhuang13.plus/local-ai-series-foundation-models-structured-output/)，以及[動態準備 prompt 的語法](https://ethanhuang13.plus/local-ai-series-foundation-models-prompt-builder/)。 不過，我們之前都是使用 `#Playground` macro 來探索。這個功能對於快速嘗試一些 API 很有幫助，但距離真正的使用者體驗，還有一段距離。 實際的 App 有使用者介面，而在模型在運算的過程中，我們不能讓使用者盯著空空的畫面乾等。如何優雅地、漸進地呈現結果，就是開發者要面臨的挑戰。 如果我們面對的是單純的 LLM，沒有 structured output，得下 prompt 要求輸出成 JSON 或特定 schema，還要自行拼湊、解析 JSON 字串的半成品，並抽出已經能用的部分資料來顯示，才能達到漸進式呈現的效果。這些都是非常令人頭痛的事情。 幸好，Foundation Models framework 已經幫我們準備了非常方便的機制，大幅減少開發的力氣。 ## 自動產生部分內容對應的資料結構 當我們使用 LLM 聊天服務時，應該都會觀察到模型會先「思考一下」，然後才「依序吐出一小段一小段文字」到前端的過程。 這是所有語言模型運作時的基本樣貌： 1. 輸入 2. 需要一些時間準備第一個 token 3. 依序輸出後續的 tokens Foundation Models 自然也不例外。Framework 提供非常方便的機制，讓上述的 LLM 行為輕鬆地轉換成 App 使用者能夠接收到的優雅體驗。 過程非常簡單：我們接收到的物件，一開始只會有部分的屬性有資料，可以丟給 UI 來顯示。隨著模型生成的過程，會持續收到更完整、但仍是部分的資料，也能夠繼續丟給 UI 來顯示。我們可以持續更新畫面，直到全部資料生成完畢。 具體怎麼做到的呢？先從資料結構說起。 _This post is for paying subscribers only._ ### 🚦iOS 本地 AI：用 PromptBuilder 動態組合 Foundation Models 的 Prompt URL: https://ethanhuang13.plus/local-ai-series-foundation-models-prompt-builder/ Last updated: 2026-08-13T06:07:04.000Z [在上一篇文章中](https://ethanhuang13.plus/local-ai-series-foundation-models-structured-output/)，我們介紹了 structured output 這個強大的功能，使用 `@Generable` macros 大幅減少開發者自行撰寫 prompt 來控制輸出結構的麻煩。 這篇文章則是要介紹能夠進一步控制輸入提示詞的工具：`PromptBuilder`。它透過簡便的語法，讓開發者**動態地依照條件來調整 prompt**，特別適合提供範例輸出給模型。 ## Swift 的 Result Builder 熟悉 SwiftUI 的讀者，對於 Swift 的 [Result Builder](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0289-result-builders.md?ref=ethanhuang13.plus) 功能應該不陌生。`@ViewBuilder` 就是使用 Result Builder 建立的 DSL，設計出 SwiftUI 專門的語法。 而為了簡化建立 prompt 的麻煩，Foundation Models framework 使用 Result Builder，提供了 [PromptBuilder](https://developer.apple.com/documentation/foundationmodels/promptbuilder?ref=ethanhuang13.plus) 給開發者簡單的語法。 ## PromptBuilder 語法 我們要輸入給 Foundation Model 的 prompt（提示詞）一律是**字串**，所以 `PromptBuilder` 的核心功能，就是要**讓組成字串變得容易**。 Swift 要組合字串不算困難，但是我們可能會想要在特定條件時，把提示詞加長。概念很像是在特定條件下，才要 SwiftUI 顯示某個元件在畫面上。 以前一篇文章的例子來說，我們可以把原本的 prompt 從單純的 `String` 改成用 `Prompt` closure 來組合： _This post is for paying subscribers only._ ### 🍱iOS 本地 AI：用 Structured Output 功能讓 Foundation Models 回傳你想要的型別 URL: https://ethanhuang13.plus/local-ai-series-foundation-models-structured-output/ Last updated: 2026-08-13T06:07:03.000Z 接續[前篇](https://ethanhuang13.plus/local-ai-series-foundation-models-availability-instructions/)，我們來介紹 Foundation Models framework 的 structured output 功能。這是個非常重要的功能，是讓 LLM 能夠變成好用的 App 體驗開發工具的關鍵。 許多人看到 LLM 可能會直接聯想到 ChatGPT，接著就聯想到聊天功能。事實上，LLM 能處理自然語言，所以絕不是只能聊天。 如果我們把 LLM 當成一台伺服器，丟給它字串型別的 request，得到字串型別的 response，這確實還滿像在聊天的。但這對於大部分的 App 使用情境來說都不實用。 所以，有些開發者會試著要 LLM 回傳 JSON 格式或特定格式，方便 App 處理。背後的想法，就是希望 LLM 輸出結構化的結果。 為了方便開發者使用，Foundation Models framework 直接提供了結構化輸出（structured output）的能力與非常簡便的語法工具。 就像我在前一篇文章結尾提示的，structured output 功能的開發體驗，很像你**在 client 端直接定義了 server API 回傳的 JSON 格式，而且還不用自己 decode**。 我們可以要求 Foundation Models 回傳自訂的 struct 或 enum。只需要兩招： 1. 在 custom type 加上`@Generable` macro 2. 如果想針對屬性給出多一點提示或限制，可以加上用 `@Guide` macro ## 使用 `@Generable` macros 定義結構化輸出結果 以[前一篇文章](https://ethanhuang13.plus/local-ai-series-foundation-models-availability-instructions/)提到的「學習 Swift 程式語言的策略？」問題來說，Foundation Models 輸出了一大段文字。這或許適合用來寫文章或教材，但是不適合直接放在 App 裡。 我們可以定義自己的「步驟」型別： _This post is for paying subscribers only._ ### 🉑iOS 本地 AI：Foundation Models 的 Availability 與 Instructions URL: https://ethanhuang13.plus/local-ai-series-foundation-models-availability-instructions/ Last updated: 2026-08-13T06:07:02.000Z 在前一篇文章中，我們已經建立了自己的 Foundation Models 研究專案，接下來要繼續擴充它。 本文會談到檢查模型是否可用（Availability） 的，因為 Foundation Models 需要使用者的裝置與設定符合各種條件。然後，我們會談到 Instructions 與 Prompt 的差異，會是設計使用者體驗的關鍵。 不過，如果你已經迫不及待想要嘗試 Foundation Models 的功能，又有 2 小時以上的時間，那麼我會推薦一個很棒 Apple 官方的學習資源。跟著講師一起完成範例專案，就可以學會所有 Apple 想要教給開發者的 Foundation Models 重點。 以下先放官方教材的簡介，後面繼續我想教的重點。 ## 推薦最佳官方教材 下面這場 [Code along with the Foundation Models framework](https://www.youtube.com/watch?v=S5F196tqRMI&ref=ethanhuang13.plus) 是 Apple Developer 於 9/30 舉辦的 Meet with Apple 活動（詳情請見[這篇報導](https://ethanhuang13.plus/apple-developer-youtube-relation/)）。 之所以推薦這個活動影片，而不是 WWDC25 的 sessions，原因顯而易見：它包含了最新、最完整的範例，一次搞定。 範例專案與所有步驟的教學文件，都放在[這裡](https://developer.apple.com/events/resources/code-along-205/?ref=ethanhuang13.plus)。我在整理自己的 Foundation Models 知識時，也參考了不少其中的資料。 雖然這是很棒的教學影片，但是我參加工作坊或上課的多次經驗都表示，按照講師的步驟完成的操作，很難真的記住。**一定要親自寫下程式，才會變成自己的東西。** 我寫文章分享 Foundation Models 的知識，不會比 Apple 工程師了解得更完整、更正確。但無所謂，我的任務是帶著讀者一起建立自己的學習專案。 讓我們繼續吧！ ## 檢查模型是否可用 _This post is for paying subscribers only._ ### ✍️iOS 本地 AI：上手 Foundation Models 的學習策略 URL: https://ethanhuang13.plus/local-ai-series-foundation-models-hands-on/ Last updated: 2026-08-13T06:07:01.000Z ## 什麼是 Foundation Models Foundation Models 是 Apple 的 LLM，也是 Apple Intelligence 許多功能的核心。在 macOS/iOS 26 [開放 API 給開發者](https://developer.apple.com/documentation/foundationmodels?ref=ethanhuang13.plus)。 之所以採複數名詞 Foundation Models，因為它不是只有一個模型。它有在裝置端運行的 30 億參數版本，以及在 Private Cloud Compute 伺服器上運行的更大規模版本。Apple 的[論文摘要](https://machinelearning.apple.com/research/apple-intelligence-foundation-language-models?ref=ethanhuang13.plus)提到： > ... a ∼3 billion parameter model designed to run efficiently on devices and a large server-based language model designed for Private Cloud Compute... 如果你有興趣了解其中的技術細節，可以參考 Apple 的 Machine Learning [文章](https://machinelearning.apple.com/research/introducing-apple-foundation-models?ref=ethanhuang13.plus)與[論文](https://machinelearning.apple.com/research/apple-intelligence-foundation-language-models?ref=ethanhuang13.plus)。但是大部分的讀者應該和我一樣，是 App 開發者背景，而不是 AI 研究者，所以我們的興趣（至少在這系列專題）會放在**如何開發與應用**。 值得一提的是，熟悉 Apple SDK 的開發者可能會以為 [Foundation Models](https://developer.apple.com/documentation/FoundationModels?ref=ethanhuang13.plus) framework 的 Foundation，是來自 Apple 的命名慣例。但這其實是 AI 領域的用語，表示通用的基礎性模型，而不是針對特定任務。這也表示我們可以拿它在 App 中做各種用途。 ## 為什麼要學習 Foundation Models？ 大多數的 App 開發者，沒有在裝置端運行 AI 模型、尤其是 LLM 的經驗。最主要的原因就是準備起來太麻煩。不知道從何下手，或是合理的效果預期。 坦白說，我自己也還沒有研究到把 Foundation Models 的功能加入手邊 Apps 的程度。但是它實在**太容易上手**了，只要幾行程式碼，你就可以進行對裝置上的 LLM 進行 prompt，並得到 response： ```swift import FoundationModels import Playgrounds #Playground { let session = LanguageModelSession() let response = try await session.respond(to: "今天不太想上班，幫我想幾個跟老闆請假的理由，用幽默的方式表達") } ``` ![在 Xcode 中使用 Playground macro 執行 Foundation Models](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-09-at-22.35.36@2x.png) 在 Xcode 中使用 Playground macro 執行 Foundation Models 所以，只要硬體條件與開發環境許可，都應該花個 3 分鐘上手玩玩看。 就算你發現，手邊的專案用不到它的相關功能，也不會浪費太多時間。並且肯定會是個新奇的體驗。 假如試過以後覺得 Foundation Models 的模型能力不夠你的需求，別擔心，我會在後面的文章介紹怎麼使用語法相容的 Swift Package，來**替換成呼叫其他的 LLM**。 所以，學習 Foundation Models framework 的**語法**完全不會浪費，反而是一個很好的起點。 ## 開發環境確認與建立實驗專案 我們來做一次系統需求與開發環境的確認： - Apple Silicon Mac - macOS 26（建議 26.1 以上） - Xcode 26（建議 26.1 以上） - 開啟 Apple Intelligence。[前文](https://ethanhuang13.plus/local-ai-series-apple-intelligence-intro/)我們已經介紹過如何開啟 Apple Intelligence 接下來，我們需要建立自己的實驗專案，方便把玩與測試。 _This post is for paying subscribers only._ ### 🍎iOS 本地 AI：開發者的 Apple Intelligence 必要知識 URL: https://ethanhuang13.plus/local-ai-series-apple-intelligence-intro/ Last updated: 2026-08-13T06:07:00.000Z 經過上週的 ASR 探索，這週的文章會開始介紹 Foundation Models。它可以說是 iOS 26 給開發者最好玩的東西，也是 iOS 本地 AI 功能的最大亮點。 由於使用 Foundation Models 的必要條件是**使用者有開啟 Apple Intelligence**，我們先來了解一下 Apple Intelligence、觀察 Apple 提供了哪些 AI 服務，並且採用怎樣的策略。這樣就可以給在 iOS 上開發與使用本地 AI 功能，一個合理的預期。 ## iOS 18 開始、iOS 26.1 支援繁體中文 Apple Intelligence 是 Apple 在 2024 年 WWDC 上提出的新名詞，也是當年發表會最大的賣點。它有多個功能，包括書寫工具、翻譯、影像生成等等。各個 AI 功能不見得有直接關係，你可以想成 Apple 是用一個行銷術語包裝它們，便於人們理解。 大部分使用者對於 Apple Intelligence 沒有太多深刻的印象。直到 iOS 26.1 開始，Apple Intelligence 終於正式支援繁體中文，在台灣可以正常使用。 Apple Intelligence 的功能幾乎都有對應的 API 給開發者，所以開發者如果善加利用的話，應該可以打造出跟原生相近的效能或體驗。所以，我們應該要了解其中功能。 最快的方式是從 [Apple Intelligence 的官網](https://www.apple.com/tw/apple-intelligence/?ref=ethanhuang13.plus)看起。而以下是我整理的資訊，並且搭配開發者可以使用的 API： _This post is for paying subscribers only._ ### 👍iOS 本地 AI：講優點要看是跟誰講 URL: https://ethanhuang13.plus/local-ai-series-advantage-by-user-type/ Last updated: 2026-08-13T06:06:59.000Z 玩過本地 ASR 以後，來聊聊在裝置端做 AI 運算的優點。 談到離線 AI 模型，人們通常會提到的好處是：沒有資料上傳雲端的隱私顧慮、可以無限使用而不需擔心持續的訂閱費用。 對我來說，去討論技術的優缺點，不能不考慮**使用情境**。也就是說，我們要考慮「賣給誰」，得到的答案會完全不一樣。 ## 消費級使用者：低成本、隱私 對於一般消費級的使用者來說，**成本**通常是最大考量。 本地模型的運算不會有增加的費用。只要硬體能跑，成本只有模型佔據的儲存空間與計算所需資源，都是固定的。 把這樣的 AI 工具包裝成產品的話，最主要吸引消費者的點會是：**只要買斷就可以一直使用**。 或者，商業模式也可以像是 Spokenly：完全免費下載、無限使用本地 ASR。只有在使用進階功能時才需要付費，例如搭配線上 LLM 修正文字。 另一個消費者會重視的需求是**隱私**。 雖然有很多人說：「我不在意自己的隱私。」實際上，沒有人會希望自己在電腦上查詢的資料、手機上講的話、照片影片，被不相干的人看到。 我不知道讀者在試玩 Spokenly 時，開啟 Local-only mode 以後有沒有特別的感覺？它做得很完整，連自己的付費升級機制都被擋掉，所以我在測試的時候特別**安心**。 **人們在心理上感到安全的時候，會去做更多探索。**知道當前的 AI 工具是完全離線、沒有資料外流的可能，用起來的心理狀態應該會大不相同。 這也是我在前兩篇文章想讓讀者體會到的。 _This post is for paying subscribers only._ ### 🧃iOS 本地 AI：試試看 Apple 的語音辨識模型 URL: https://ethanhuang13.plus/local-ai-series-apple-asr/ Last updated: 2026-08-13T06:06:58.000Z [經過前一篇文章](https://ethanhuang13.plus/local-ai-series-try-whisper-asr/)，讀者應該已經安裝好 Spokenly App、測試過 Whisper 各種等級的模型了。如果你在 Apple Silicon Mac 試過 Whisper Small 或 Base，應該已經體驗到幾十秒語音的能在一兩秒就轉完的神奇感受。 市面上還有很多開源的 ASR 可以玩，前一篇也教過怎麼樣導入其他模型。而我們今天則是要把鏡頭拉回 Apple 自家的 ASR，跟前一篇教過的 Whisper 比較效果。 ## Apple ASR 有些讀者可能知道，Apple 一直有自己的 ASR，並且有開放 API 給開發者。 從 iOS 10 以來，Apple 就有提供 [Speech framework](https://developer.apple.com/documentation/speech/speech-recognition-in-objc?ref=ethanhuang13.plus)，其中的 [SFSpeechRecognizer](https://developer.apple.com/documentation/speech/sfspeechrecognizer?ref=ethanhuang13.plus) 就是能夠把語音轉換成文字的工具。 而在 iOS 26，Apple 推出了全新的 [SpeechAnalyzer](https://developer.apple.com/documentation/speech/speechanalyzer?ref=ethanhuang13.plus)，並且採用 Swift 的 AsyncSequence 語法。 這些 API 要上手都不難，不過今天我們先專注在測試實際效果上。 這兩個模型的選項，在 Spokenly 裡面都有提供，所以我們只需要把模型切換過去即可（這也是為什麼我選擇它來教學與測試）。 ## 使用 Apple Speech Recognition 先在 Spokenly 試試看舊的 Speech Recognition。 請注意，[Apple 的文件上](https://developer.apple.com/documentation/speech/sfspeechrecognizer?ref=ethanhuang13.plus)表示 “speech recognition is a network-based service”。不過我在 Mac 上實測，在沒有網路時也能使用。 這是因為，一開始這個 API 是連網服務，但後來隨著硬體進步，Apple 改成把模型放到裝置上跑。到了 iOS 13 就有一個 [supportsOnDeviceRecognition](https://developer.apple.com/documentation/speech/sfspeechrecognizer/supportsondevicerecognition?ref=ethanhuang13.plus) 的 flag 可以確認。 原則上，我不會把它當成完全離線的模型來看待，因為要 runtime 才知道。不過它確實能在一些條件下離線執行。如果你想確認，就把網路關掉吧。 使用該模型的方法很簡單：在選擇模型的介面，切換到 Punctuation，就可以找到它了。 ![在 Spokenly 使用 Apple Speech Recognition](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-04-at-21.14.33@2x.png) 在 Spokenly 使用 Apple Speech Recognition 值得一提的是，在 Spokenly 能夠一邊講話一邊看到轉出來的文字。 ![一邊講話可以看到文字](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/12/CleanShot-2025-12-04-at-21.20.08@2x.png) 一邊講話可以看到文字 這是因為 Speech Recognition 可以在轉錄時一邊丟出部分的[結果](https://developer.apple.com/documentation/speech/sfspeechrecognitionresult?ref=ethanhuang13.plus)。 ## 使用 Apple Speech Analyzer 如果你的 Mac 已經升級到 macOS 26 以上，就可在 Local 模型當中看到 Apple Speech Analyzer 的選項。這個模型就真的是 100% 在本地運行。 _This post is for paying subscribers only._ ### 🗣️iOS 本地 AI：從體驗語音轉文字模型開始 URL: https://ethanhuang13.plus/local-ai-series-try-whisper-asr/ Last updated: 2026-08-13T06:06:57.000Z 前兩篇鋪陳夠多了，我們要來實際入坑本地 AI。 我一直覺得，要認識 AI 功能，最好的方式就是親自體驗。 一旦體驗到某種 Magic Moment，大腦會產生極大興趣，對後續的學習動機就會非常有幫助。 說到本地 AI、離線模型，其實有比 LLM 更合適入門的，就是 ASR(Automatic Speech Recognition) 自動語音辨識，說白話就是提供**語音轉文字**的技術。因為它更單純，而且實用度很高。 [2022 年 OpenAI 推出開源的 Whisper 模型](https://openai.com/zh-Hant/index/whisper/?ref=ethanhuang13.plus)以後，要開發一個語音轉文字功能的應用程式，最好的出發點就是把 Whisper 跑起來。 所以，以體驗本地模型為目的，今天就來介紹一個可以快速在你的設備上感受開源 ASR 的方法。 ## 安裝軟體 要在 Mac 或 iOS 上跑 Whisper 不難，下幾行 Python 指令就可以開始把語音檔丟給模型去轉成文字。 但是，我希望這個體驗是方便重複測試，甚至變成日常工作流程的一環。 就算你以後都不會去碰觸 ASR 的研究、或是開發相關應用，至少跟著這篇的操作與介紹，也會擁有能一鍵講話就變成文字的新工具。 以前我一直對於上手 AI 應用開發興趣缺缺，就是因為懶得學寫 Python 指令、從 HuggingFace 下載模型等等。所以這篇文章也會先跳過那些，直接教一個幾分鐘就可以開始體驗的方式。 我要介紹的就是[之前文章](https://ethanhuang13.plus/my-ai-tools-usage-202508/)有提到過的 Spokenly App。要做的事情很簡單，只需要 5 分鐘： 1. 下載 Spokenly 2. 提供麥克風權限、設定為離線使用、指定快速鍵與語音檔保留時間 3. 從 Spokenly 下載離線 ASR 模型 4. 開始體驗！ _This post is for paying subscribers only._ ### 🛜iOS 本地 AI：誰規定 AI 一定要連網才能用？ URL: https://ethanhuang13.plus/local-ai-series-why-online/ Last updated: 2026-08-13T06:06:56.000Z 在介紹本地 AI 怎麼玩以前，我想先談一個迷思。 為什麼常見的 AI 工具都需要網路？在 13+ 談過的 [AI 工具](https://ethanhuang13.plus/tag/ai-tools/)幾乎都是連網服務。 實際上，**AI 需要的是運算，而不是網路。**AI 工具不應該直接跟網路服務畫上等號。 先讓我分享一下身為單機遊戲玩家的無奈。 ## 誰規定玩遊戲一定要網路？ 不知道讀者玩不玩遊戲？ 我從小就是 PC 遊戲玩家，習慣在 Steam 上購買遊戲。成為主機玩家以後，也偏好在各平台的線上商店購買並下載，而不是購買光碟與卡匣，不用換片就可以直接切換遊戲，非常方便。 不過，由於遊戲設備眾多，所以我玩完一款遊戲，切換到另一個設備往往間隔數週。結果，不論 Xbox、PS、SteamOS、Windows，基本上一定會遇到**系統或遊戲要更新**。它們要不是沒連線驗證就不能打開遊戲，就是沒更新到最新版就不給玩。 這些更新動作，哪怕只有 5 分鐘，也很容易把下班後想玩一下遊戲的衝動給消除。就跟讀者在等 Xcode 編譯的時間，會跑去滑推特一樣。最後遊戲機給人的印象只剩下維護主機更新的部分。 Switch 的系統比較沒有強制性。它會在從主畫面打開遊戲時提示「現在有系統更新，很快」。使用者可以跳過，也可以選擇在 1 分鐘內完成系統更新。 所以，假如人們必須面對一個情況：**有電力，但是很有可能沒網路**（不管是旅遊、閉關，還是各種天災人禍，導致網路變成稀缺資源），在這種情況下，如果我還能帶著遊戲設備，就只剩下 Switch 能玩了。（更厲害的玩家會考慮 GOG 或模擬器，就不展開聊了。） 總之，絕大部分遊戲平台，都必須要有網路連線才能玩，即使是完全**單機**運作的遊戲。 我說了這麼多，是想強調連網的需求來自於遊戲平台。玩家是被迫接受遊戲服務需要連網（甚至有些還要付費），即便遊玩時基本上是單機。 許多 AI 工具，也處於這種（對使用者）尷尬的情況。有些推理運算可以在本地，但是往往被包裝成雲端服務來提供。 ## 誰規定 AI 功能一定是網路服務？ 通常軟體會需要網路，是為了**確認權限**，或是傳輸軟體安裝檔所沒有的**新資訊**。除非軟體的主要目的就是通訊或消費線上的影音媒體。除此之外，大部分的軟體在執行時，都不仰賴網路。 但是使用絕大部分的 AI 工具，例如 ChatGPT、Claude、Gemini，都不能一刻沒有網路。而且人們好像已經習慣「AI 工具等同網路服務」。通常這也意味著綁定了帳號與金流，甚至訂閱制。 其實我上面那句「人們好像已經習慣」，並不是真的。而是我們已經太依賴網路。 一直都有網路能用，所以很容易忘記沒網路時候的情況。就像那些把 Steam Deck 帶上飛機準備打發時間，才發現忘了預先開啟離線模式，玩不了遊戲的可憐朋友一樣。 而當人們重度仰賴連網 AI 工具時，一旦無法使用網路的戒斷與痛苦，絕對不會輸給無法玩遊戲。 _This post is for paying subscribers only._ ### 🚚iOS 本地 AI：為什麼我想寫？為什麼你該上車？ URL: https://ethanhuang13.plus/local-ai-series-intro/ Last updated: 2025-12-07T17:02:15.000Z Apple 平台老早就有許多 [Machine Learning 的產品功能](https://developer.apple.com/machine-learning/resources/?ref=ethanhuang13.plus)，也提供了許多 API。 有些模型，甚至小到可以在 Apple Watch 上執行。 但是我對於這些 AI 功能一直興趣缺缺。雖然它們可以做到不少事情，卻跟我想做給使用者的功能或體驗毫不相干。 近兩年，LLM 發展突飛猛進，我也絲毫沒有想要在 App 中加入 AI 功能的念頭。 那麼，是什麼引起了我的興趣，讓我覺得值得動筆撰寫一系列文章介紹 Apple 的本地 AI 功能呢？ 答案是 **Apple 在 2025 年 9 月推出的兩樣新東西：Foundation Models 與 iPhone 17 Pro Max。**我玩過之後感覺到：在 iPhone 上跑 AI 有意思！ 讓我簡介一下： ## Foundation Models [Foundation Models](https://developer.apple.com/documentation/FoundationModels?ref=ethanhuang13.plus)，是 Apple 自家開發的語言模型，小到能在 iOS 設備上迅速執行。它不是拿來做 ChatGPT 這種對話型 AI 服務的等級，但對於強化 iOS App 使用者體驗，有著[很實際的應用方式](https://developer.apple.com/documentation/foundationmodels/generating-content-and-performing-tasks-with-foundation-models?ref=ethanhuang13.plus#Understand-model-capabilities)。 我認為它最了不起的地方，是**大幅降低開發者入門** LLM 型 AI 功能的開發門檻。簡單到像喝口水。 只要你的設備有開啟 Apple Intelligence（繁體中文隨著 iOS 26.1 的推出而開始支援）、再加上**幾行程式碼，就可以執行**。 它可以讓你的 App 更有人性，或是讓使用者更容易輸入複雜的資訊，還有一堆我先不破梗的玩法。 重點是，它是個離線、本地運行、不用開發者另外下載的模型！不管再強大的 AI，如果只能連網使用，就不可能完全取代離線模型。 ## A19 Pro 打敗 M3 Max iPhone 17 Pro 系列採用 A19 Pro SoC，其中的 GPU 搭配了「神經網路加速器」。 所以，當我拿 iPhone 17 Pro Max 跟 MacBook Pro M3 Max（30 核心 GPU）同時跑了 Foundation Models，發現 **iPhone 的速度明顯更快**。 我都懷疑是自己眼花了。 這可是 iPhone 打敗次頂規 MacBook Pro，而且核心才差兩個世代而已。 具體數字與測試方式我會在之後的文章介紹。但是你可以看出一個事實：Apple 的硬體跑本地 AI 大有可為，而且還會越來越好。 ## 有意思在哪裡？ 我們有時候會笑 Tim Cook 愛講的那句「Only Apple Can Do」。但是一個 App 能夠在大量裝置上跑出一樣的本地 AI 功能效果，應該真的只有 Apple 的硬體能辦得到。 這種一致體驗的追求，在硬體規格碎片化的 Android、Windows，根本辦不到。 再加上產品的普及率、系統內建多個離線資料庫種種因素，開發者在 Apple 平台上投入研發的報酬更有機會實現。 那麼問題來了，究竟 Apple 在 AI 研究方面是真的落後其他大廠，還是它已經打下基礎作為最佳的本地 AI 應用平台、iOS 開發者大有可為？也許兩者皆是。 無論如何，雖然 Apple Intelligence 推出一年多以來，表現不令人印象深刻，但是**我認為在 iPhone 上執行 AI 應用的時代已經到來**。 ## 我打算怎麼寫？ 從 Foundation Models 開始，關於 Apple 硬體上執行 AI 功能，我已經想到**至少 20 篇的主題**，有事實描述、操作教學、觀點分析、問題討論，以及 Apple 動向的推測。 如果順利的話，我會在 2025 年 12 月份連載所有的篇章。 部分主題內容我之前就稍有研究，像是 Foundation Models、MLX。有些則需要在寫出來之前徹底搞懂，所以我是邊寫邊學。 我不敢說自己寫出來的知識就一定正確，我也不是 AI 專家。但是，求知的過程與方法一定會公開，而且我認為這些才是本系列專題的精華。 ## 結語 Foundation Models、iPhone 17 系列、A19 晶片都很新，我認為絕大部分的 iOS 開發者都沒有意識到它們的真正意義。 這促使我想寫文章分享出來，也是記錄自己的學習路線。 我們會實際上手 Foundation Models、語法相容套件、MLX，能夠直接體驗到 Apple 硬體的 AI 運算能力。 **親自動手體驗是說服自己「這真的有料」的最佳方式。** 當然，我們也會碰到許多現實與限制。這些問題討論起來很有意思，我還會預測 Apple 可能怎麼應對。這種分享思路型的文章，應該會令人讀得津津有味。 心動了嗎？好好期待接下來一個月的連載吧。 ### 🗓️發文平台調整公告與 2025 年 11 月主題回顧 URL: https://ethanhuang13.plus/monthly-review-2025-11/ Last updated: 2025-11-28T10:33:17.000Z ## 13 的話 [又到了月底](https://ethanhuang13.plus/monthly-review-2025-10/)總結與回顧。連同這篇，整個月下來我寫了 20 篇文章，繼續保持每週五篇的節奏。 今天的文章較晚發出，因為我感冒了，多休息了一會。 這篇前面先談一些個人感受、營運方式調整，再回顧一整月的文章。 ## 寫作步調檢討 每天寫文章真的很累。特別有幾次是晚上已經沒體力，隔天早上 5 點爬起來寫。 不過我還有很多東西想寫，如果不維持每天都有產出的話，會寫不完。 另外，我近期 2 次出國旅遊，也都保持著每日更新。有好幾篇是在飯店或是車上寫的。 這種作法，雖然可以產出一些有別於平時靈感的特別內容，但對於休息的效果有一定的影響。 以後休假期間，我會轉換成**主動找尋靈感**，而不是被動地滿足一天一定要一篇的慣例。 總之，寫作步調是我要學習掌控的，狀況不好時可以放掉幾天，或找方法拉回來。 連續 15 週的更新已經證明了我的寫作能量，所以我反而該學習的是適度休息。 ## 13 報與 13+ 的整合 [13 報（Apple 開發者週報）](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)是我累積經營多年的電子報，一直以週報的形式刊出。自從我把重心轉向 13+ 的每日更新以後，週報的選題與編輯就顯得相對機械、令我興致缺缺。 於是，[在 11/10 我宣布做了重要調整](https://ethanhuang13.plus/upgrade-apple-developer-news-commentary/)： 1. 取消 Apple 開發者電子報的週報形式 2. 在 13+ 會撰寫開發者新聞時事與我的評論，頻率不固定 3. 其中，免費閱讀部分會一併在 Apple 開發者電子報刊出 4. 更深入的評論與分析，則會保留給付費會員 簡單來說，13+ 就是 13 報的升級版、完整版。透過整合兩個刊物，我可以集中精力撰寫我認為真正重要的開發者資訊。 13+ 的會員，可以取消 13 報的訂閱，因為內容會是重複的。 目前已經有這幾篇報導與評論： - 2025-11-12: [🌏Apple 官方開發者活動形式變化觀察](https://ethanhuang13.plus/apple-developer-youtube-relation/) - 2025-11-13: [⚡️App 效能研討會重點整理：成為 SwiftUI Instruments 高手](https://ethanhuang13.plus/optimze-your-app-speed-efficiency-20251031/) - 2025-11-17: [🌏2026 亞洲 iOS 研討會蓄勢待發](https://ethanhuang13.plus/asia-ios-conferences-2026/) - 2025-11-20: [🧑‍🎓Apple 學生開發者比賽最新消息](https://ethanhuang13.plus/maic-swift-student-challenge-2026/) 我沒有設定多久要寫一篇，但是以 Apple 開發者圈發生的重要消息來說，一個月 3\~4 篇算合理，所以長時間來看，平均應該跟週報差不多。 值得一提的是，我在 11/12、13 的兩篇展示了 13+ 官網的新功能：可以按連結跳轉內嵌影片位置。這對於我要做影片說明型的文章大有幫助，不知道讀者是否覺得實用？ 而說到官網的特殊功能，接下來，我就要說明一下減少其他平台重複發文帶來的問題，未來所有內容將以官網為準。 ## 電子報發刊內容調整公告：官網作為 Single Source of Truth **從今以後，13+ 只會在**[**官網**](https://ethanhuang13.plus/)**刊載全文，包括電子報。** 以前每篇文章，我都會在[官網](https://ethanhuang13.plus/)、[Patreon](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus)、[vocus](https://vocus.cc/salon/ethanhuang13?ref=ethanhuang13.plus)、Notion 上面同步刊載。當初會這麼做，是因為官網成立不久，還在實驗階段。但是現在我認為時機成熟了： **以後文章全文只在官網發布。Patreon 與 vocus 上只會放摘要，請到官網閱讀。** 對會員最大好處：**不會再收到官網與 Patreon 兩封重複內容的電子報，也更清楚要去哪裡找舊文章**。 **很重要的一點：為了避免漏掉新文章，我會手動幫所有會員打開 13+ 官方電子報。**這是單次操作，如果你真的不想收到，[請到 13+ 官網進行調整](https://ethanhuang13.plus/#/portal/account)。 （當初成立官網時，我是[採用公告提醒](https://ethanhuang13.plus/ios-developerplus-update-writing-site-ideas/)，而沒有幫舊會員開啟電子報，是因為尊重會員自己的 E-mail 習慣。不過現在情況不同了。） 而這麼做，對我來說有非常多好處： - 每次寫完文章以後，不用再花費 10 分鐘手動貼上與整理各平台的文章與排程（這件事無法自動化） - 避免 Patreon 要另外上傳圖片的手續 - 解決了 Patreon 無法做程式碼 syntax highlighting 的問題 - 文章有任何修改與勘誤，我只要改一個地方就好 另外，我已經停止開放 vocus 的新訂閱。我是從今年 5 月開始在 vocus 上面同步刊登文章。半年下來，在上面發表技術類文章的迴響遠不如 Patreon，僅有個位數量的朋友曾在上面訂閱。 透過 vocus 訂閱的會員如果沒有取消訂閱，還能繼續付費。也可以改成到 Patreon，權益（登入官網閱讀全文與收到電子報）完全相同。 Notion 的情況也類似。我在[一週年回顧](https://ethanhuang13.plus/13-plus-one-year-love-you-three-lessons/)時有提到 Notion 使用率偏低、不再邀請新會員使用 Notion。我仍然會在 Notion 上備份文章全文，但不會每天同步更新。 總之，**閱讀請到**[**官網**](https://ethanhuang13.plus/)**、管理訂閱請到** [**Patreon**](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus)**。** 接下來，整理 11 月的文章。新聞評論類的前面已提過，就不重複。 ## 實用技巧系列 這個月我寫好幾篇實用度超高的文章。我相信光是學會幾招、提升一點開發效率，就值回票價了。 - 2025-11-03: [🐺iOS 開發補完計畫：Swift Macros 信任警告與警報疲勞](https://ethanhuang13.plus/swift-macros-skip-validation-fatigue/) - 2025-11-04: [📐善用 Xcode 內建的 swift-format 減少團隊溝通成本](https://ethanhuang13.plus/swift-format-for-team-consistency/) - 2025-11-05: [💡我的 Xcode 推薦設定](https://ethanhuang13.plus/xcode-recommend-settings/) - 2025-11-11: [⚠️防微杜漸：別對 Xcode 警告視而不見](https://ethanhuang13.plus/eliminate-xcode-warning-discipline/) - 2025-11-18: [🧐Xcode 26.1 的 Release Notes 去哪了](https://ethanhuang13.plus/xcode-26-1-release-notes-missing/) - 2025-11-19: [😵‍💫macOS 26 支援車輛動態提示](https://ethanhuang13.plus/mac-vehicle-motion-cues/) 這幾篇當中，我覺得最重要的是[不要忽視 Xcode 警告](https://ethanhuang13.plus/eliminate-xcode-warning-discipline/)那篇談到的觀念。比起一些加速開發的技巧，對於做事態度有更深遠的影響。 ## 推坑系列 從以前在 [weak self podcast](https://weakself.dev/?ref=ethanhuang13.plus) 我跟 [Pofat](https://pofat.dev/about.html?ref=ethanhuang13.plus) 就很常勸敗一些我們買了的好東西，甚至把節目的勸敗單元當成主軸。許多聽眾朋友也特別喜愛這個部分。 近期我們沒找到機會錄音，但我又很想推坑，所以就寫了這幾篇文章： - 2025-11-21: [🔌好，買了 Apple 動態 60W 充電器](https://ethanhuang13.plus/ok-buyla-apple-dynamic-adapter-60w/) - 2025-11-24: [📲好，買了 TechWoven](https://ethanhuang13.plus/ok-buyla-techwoven/) - 2025-11-25: [🧽新機感：好，買了 iKlear 清潔組](https://ethanhuang13.plus/ok-buyla-iklear/) - 2025-11-26: [💻MacBook Air，Air 得好](https://ethanhuang13.plus/macbook-air-real-utility/) 這些文章的切入角度，並不是產品的測試或評論，而是實際使用帶給我的感受。雖然偏主觀，但是從過往的經驗來看，這類型的分享很受歡迎。 所以，以後肯定會有更多推坑文。你可以在 [💸 好，買了](https://ethanhuang13.plus/tag/ok-buyla/) 分類找到它們。 另外還有一篇文章是勸敗 13+ 的 Black Friday 活動。 12 月我會分享許多 iOS 本地端 AI 主題文章，**現在是新朋友入坑的最佳時機。優惠只到下週一，2025/12/01 23:59，細節請看內文**： - 2025-11-27: [🉐Black Friday 優惠開跑與 iOS 本地端 AI 系列預告](https://ethanhuang13.plus/2025-black-friday-local-ai/) 我明白有開發者不想為了 AI 而 AI，其實我也是。一直避免硬要在 App 中加入 AI 功能。 但是**有一些條件在 iOS 26 Foundation Models 與 iPhone 17 系列推出以前並不存在**。這就是我打算撰寫這系列文章的動機，內容你在其他地方讀不到，所以真的不希望你錯過了。 ## 其他：AI 實驗、整理 這幾篇文章是我讓 Claude Code 閱讀了 13+ 文章以後產出的閱讀心得報告。對於想要了解或複習專欄當中重要觀點的朋友，會很實用。 - 2025-11-06: [🤖Claude Code 也推坑你訂閱 13+](https://ethanhuang13.plus/claude-code-recommend-13-plus/) - 2025-11-07: [🤖用 AI 工具分析我對 AI 工具的觀點──我的 AI 工具使用現況（2025 年 10 月）](https://ethanhuang13.plus/my-ai-tools-usage-202510-claude-summary/) 最後這篇，則是我手動整理自己的演講影片，聊到了我在各演講場合的心得，也是給自己的職涯軌跡一個回顧。 - 2025-11-14: [📺13 的 iOS 演講與教學影片](https://ethanhuang13.plus/ios-talks-and-teaching-videos/) ## 結語 我感覺這個月過得非常快，轉瞬間又到了月底回顧。不知道你最喜歡哪幾篇文章呢？歡迎跟我分享。 ### 🉐Black Friday 優惠開跑與 iOS 本地端 AI 系列預告 URL: https://ethanhuang13.plus/2025-black-friday-local-ai/ Last updated: 2025-11-26T22:00:25.000Z 我剛結束短暫的休假回來。這次旅途，累積了一些靈感與刺激，使我決定從 12 月開始撰寫一系列 iPhone 執行本地 AI 的系列文章，並在此宣告 13+ 的限時優惠活動。 最近我一直在進行 iOS 開發的教學工作，累積了一些本地 AI 應用的探索經驗。比如在 iPhone 17 Pro Max 上實測，發現：**Foundation Models 在 A19 Pro 上產出 token 比 MacBook M3 Max 還快約 25%**。原因我會在之後的文章說明，但可以看到 Apple 的硬體效能進步對於本地 AI 推理有巨大優勢。 不光是硬體效能，用 iPhone 來跑本地 AI 還有許多玩點與前景。我想許多 iOS 開發者不想「為了 AI 而 AI」，又或是想加但不知如何入手。實際上，一些開發 AI 應用的形勢，在 Foundation Models 或 A19 Pro 推出之前根本不存在。從今天開始接觸，是跟全世界的開發者站在同樣的起跑線，不用擔心跟不上。就連我也是邊研究邊分享！ 我打算撰寫多篇文章，展開來談： 觀察到的事實、實測的方法與結果、Apple 在本地 AI 相關的優勢、開發體驗上的問題與可能的發展，並提出一個重大見解：**iOS 開發者是全世界最有機會打造優秀本地 AI 應用使用者體驗的一群人，沒有之一。** 如果你是 iOS 開發者，這是你不會想錯過的一系列文章。假如你已經產生興趣，但還沒加入會員，歡迎把握 13+ 專欄一年只有一次的 **Black Friday優惠** 。 [**請到 Patreon 訂閱 13+**](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)**，輸入折扣碼 `LOCALAI`，即可享有首月 13% Off。時間只到 Cyber Monday 2025/12/01 23:59。** 老實說，做折扣不是我的風格。但這個系列會是別的地方讀不到的觀察 + 經驗談 + 操作說明 + 洞察，也會是最能展現 13+ 專欄價值的內容。我想給一直在觀望的朋友一個加入會員的好理由。 對於 13+ 不熟悉的話，不妨到[官網目錄](https://ethanhuang13.plus/index/)看看過往有哪些文章主題。我特別推薦[專題：探究 iPhone 的 USB 速度對開發體驗的影響](https://ethanhuang13.plus/tag/iphone-usb-speed-series/)，有大量實測、動手操作與見解，可以說是本地 AI 系列的前身。此外，從 8 月中到現在我持續在[挑戰每個工作日都發表新文章](https://ethanhuang13.plus/13-plus-daily-challenge/)，每週一到五早上都能讀到一篇新的分享，對讀者是很好的思考刺激與學習。 明天會是 11 月最後一篇，照慣例會是當月的回顧，分享我最喜歡的幾篇文章。從下週一開始，我們就會啟動一系列的 iOS 本地 AI 文章。 最後，歡迎多多分享這則公告給身邊的 iOS 開發者，或是對 AI 應用開發有興趣的朋友。我相信會幫助到許多人！ ### 💻MacBook Air，Air 得好 URL: https://ethanhuang13.plus/macbook-air-real-utility/ Last updated: 2026-08-13T06:06:55.000Z 最近，我又進入短暫的[旅遊休假模式](https://ethanhuang13.plus/never-late-to-plan-vacation/)。 今天的文章，想用這張照片，簡單表示一個旅行設備感想： _This post is for paying subscribers only._ ### 🧽新機感：好，買了 iKlear 清潔組 URL: https://ethanhuang13.plus/ok-buyla-iklear/ Last updated: 2026-08-13T06:06:54.000Z 繼續來推坑。這篇要講的是 iKlear 這個連 **Apple 原廠都在使用的清潔產品**。老樣子，[本系列](https://ethanhuang13.plus/tag/ok-buyla/)都不是業配，而是個人感受。 產品的說明與用法，可以參考皮樂的推坑文「[iKlear：Apple 原廠指定清潔劑，安全有效的 Mac 螢幕清潔解決方案](https://hiraku.dev/2023/03/7440/?ref=ethanhuang13.plus)」。我當時就是看了他這篇文章，而買了 60 mL 的入門套裝，一用就是兩年半。 跟他主要介紹擦螢幕的用途不同，我這篇主要是想分享拿來擦鍵盤跟 MacBook 機身的心得，還有意外推坑整個 Team 團購的小故事。 ## 恢復成新機的手感 對我來說，iKlear 清潔劑有趣的地方，不是能夠把油污擦掉的效果，而是拿來擦拭 MacBook 的鋁合金外殼以後，摸起來會變得很滑，手感會超像剛開箱的新機，「鋁」試不爽。 所以，有的時候當 Apple 推出新機讓人想買，我就會把現有的設備擦一擦，突然就會覺得好像已經有一台新電腦了，不用再買。 （是嗎？😏） ## 儀式感 筆電螢幕為什麼會髒？其實都是從鍵盤沾上的指紋印上去的。雖然我已經養成好好洗手再用電腦的習慣，難免還會累積油垢在鍵盤上。把電腦蓋上以後，螢幕就髒了。 不管是鍵盤還是螢幕，一旦髒了，就會開始影響心情與工作效率，而且程度會隨著髒污逐漸累積而增加。 還記得有一次我在加班忙碌，心煩意亂，效率越來越差，突然覺得需要整理心情，就拿起桌上的清潔組，把 MacBook Pro 的螢幕、鍵盤、機身都擦一擦。當下覺得好像恢復了一點步調。 從那次以後，**擦拭電腦對我來說就不只是清潔外觀，而是整理心情的機會。是種有儀式感的動作。** 讀者朋友應該都有工作忙到昏天暗地的情況。這種時候除了深呼吸、出去走一走能調整心情，我覺得把電腦擦一擦也是個好方法。 ## 意外的團購推坑 我覺得這種從**清潔物理到整理心情**的效果很不錯，也想給同事體驗看看。 之前在當 Team Lead 時，每個月會跟個別同事 one-on-one meeting。有次我就把整個清潔組的布洗乾淨，整組帶去跟同事 meeting 的現場。 _This post is for paying subscribers only._ ### 📲好，買了 TechWoven URL: https://ethanhuang13.plus/ok-buyla-techwoven/ Last updated: 2026-08-13T06:06:53.000Z 今天要簡單推坑的是，Apple 隨著 iPhone 17 Pro 推出的 TechWoven 手機殼。 有兩大原因： 第一，它讓我覺得 17 Pro Max **拿起來比裸機時還輕**。 第二，它讓**按鍵手感**比裸機時還好。 ## 為什麼要裝殼？ 我是「盡量裸機派」，能不裝殼就不裝。 iPhone 17 Pro Max 全鋁機身，裸機拿起來非常舒服（很像 MacBook Air），但是頗滑的。而且鋁比之前的不鏽鋼或鈦合金軟得多，摔到一定會受傷，所以最好還是裝殼。 我過去偏好原廠透明殼，讓顏色可以被看到。然而這代因為 Apple logo 位置跟 MagSafe 中心沒有對齊的緣故，透明殼背後設計成一大片白色，令人傻眼。所以我決定試試看新的 [TechWoven（科技織紋保護殼）](https://www.apple.com/tw/shop/product/mgf94fe/a/iphone-17-pro-max-magsafe-%E7%A7%91%E6%8A%80%E7%B9%94%E7%B4%8B%E4%BF%9D%E8%AD%B7%E6%AE%BC-%E8%97%8D%E8%89%B2?ref=ethanhuang13.plus)。 TechWoven 摸起來很像現在原廠的 [USB-C 充電連接線](https://www.apple.com/tw/shop/product/mw493fe/a/60w-usb-c-%E5%85%85%E9%9B%BB%E9%80%A3%E6%8E%A5%E7%B7%9A-1-%E5%85%AC%E5%B0%BA?ref=ethanhuang13.plus) 的編織觸感，還有防滑的效果，挺耐摸的。 ## 變輕？ _This post is for paying subscribers only._ ### 🔌好，買了 Apple 動態 60W 充電器 URL: https://ethanhuang13.plus/ok-buyla-apple-dynamic-adapter-60w/ Last updated: 2026-08-13T06:06:52.000Z > 新系列「好，買了」，是我想簡短寫一些買過、覺得很值得推薦的東西。如同在勸敗節目 [weak self podcast](https://weakself.dev/?ref=ethanhuang13.plus) 的精神：東西都是自己花錢買的、不是業配。而且我敢拿出來講，就是我覺得值得買。 今天想推坑的是與 iPhone 17 Pro 一起推出的新充電器：[40W 動態電源轉接器 (最高輸出 60W)](https://www.apple.com/tw/shop/product/mgkq4j/a/40w-%E5%8B%95%E6%85%8B%E9%9B%BB%E6%BA%90%E8%BD%89%E6%8E%A5%E5%99%A8-%E6%9C%80%E9%AB%98%E8%BC%B8%E5%87%BA-60w?ref=ethanhuang13.plus)（型號 `A3351`）。**這東西棒到我覺得每個 Apple 產品愛用者都應該隨身帶著一顆**。 ![充電器底部視角](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CC02D035-DF54-48F5-98E5-ADABBF5CE4E5.jpeg) 充電器底部視角 推坑它的原因有四個： _This post is for paying subscribers only._ ### 🧑‍🎓Apple 學生開發者比賽最新消息 URL: https://ethanhuang13.plus/maic-swift-student-challenge-2026/ Last updated: 2026-08-13T06:06:51.000Z ## 行動應用創新賽 2025 決賽，台灣學生表現亮眼 [行動應用創新賽](https://maic.straighta.com.tw/?ref=ethanhuang13.plus)（Mobile Application Innovation Contest, MAIC）是由 Apple Education Taiwan、逢甲大學、Straight A（Studio A 教育品牌），以及臺灣大學Apple 區域教育培訓中心（RTC），共同推動舉辦的學生 App 開發比賽。 作品 App 以 Apple 平台為主，多為 iOS 與 visionOS。你可以想像成這是 Apple 大中華區舉辦的比賽。台灣的團隊分出高下以後，還會去杭州浙江大學參加[大中華區的決賽](https://www.appcontest.net/home/homepage?ref=ethanhuang13.plus)。 今年台灣的學生在總決賽表現亮眼，是有史以來最佳： - 一等獎：VCook（中原大學 • VC） - 一等獎：iMirror沉浸式鏡像復健系統（國立臺灣大學 • iMirror Lab） - 二等獎+ 社會責任創新獎：Savers 即期品地圖（國立清華大學、國立中央大學 • iNTER） - 二等獎：生聲（逢甲大學 • 生聲不息） - 優秀組織獎：逢甲大學 以下展示影片皆為台灣比賽的版本，大中華區總決賽應該有新的、改善很多的版本，但我目前沒有找到（如果有的話，我會更新在此）。 ⟪VCook⟫是由 Vincent 獨立開發的 AI 食譜 app，還用上了最新的 Foundation Models，已經上架 [App Store](https://apps.apple.com/tw/app/vcook-best-cooking-partner/id6742108272?ref=ethanhuang13.plus)： ⟪iMirror⟫是利用 Apple Vision Pro 的手勢辨識功能做出的鏡像復健軟體，概念十分先進。並且是從組員家人的實際復健需求出發，自帶背景故事： ⟪Savers 即期品地圖⟫努力要解決即期食品浪費問題： ⟪生聲⟫則是針對聽力障礙兒童設計的學習軟體： 這幾組得獎的同學，我有幸跟他們交流，都是非常有創意跟實踐能力的學生開發者，真的很替他們高興。 更多報導： - [工商時報：Apple「第十屆2025移動應用創新賽」大中華區總決賽 台灣團隊勇奪雙一等獎 創十年最佳戰績](https://www.ctee.com.tw/news/20251103701726-431401?ref=ethanhuang13.plus) - [Yahoo 新聞：台灣團隊勇奪雙一等獎 Apple『第十屆 2025 移動應用創新賽』大中華區總決賽 創十年最佳戰績](https://tw.news.yahoo.com/%E5%8F%B0%E7%81%A3%E5%9C%98%E9%9A%8A%E5%8B%87%E5%A5%AA%E9%9B%99%E4%B8%80%E7%AD%89%E7%8D%8E-apple%E3%80%8E%E7%AC%AC%E5%8D%81%E5%B1%86-2025-%E7%A7%BB%E5%8B%95%E6%87%89%E7%94%A8%E5%89%B5%E6%96%B0%E8%B3%BD%E3%80%8F%E5%A4%A7%E4%B8%AD%E8%8F%AF%E5%8D%80%E7%B8%BD%E6%B1%BA%E8%B3%BD-%E5%89%B5%E5%8D%81%E5%B9%B4%E6%9C%80%E4%BD%B3%E6%88%B0%E7%B8%BE-102339687.html?ref=ethanhuang13.plus) - [逢甲大學：AI為聽損兒開口發聲 逢甲「生聲」榮獲Apple移動應用創新賽大中華區二等獎](https://stat.fcu.edu.tw/news-detail/?id=47694&ref=ethanhuang13.plus) 如果你是學生，不妨關注一下明年的 MAIC。而在那之前，可以先把焦點放在以下要介紹的 Swift Student Challenge。 ## Swift Student Challenge 2026 MAIC 是大中華區的比賽，而 Apple 還有一個國際學生程式挑戰賽叫做 Swift Student Challenge，從 2020 年起開始已經第七屆了。只要是 13 歲以上的學生就可以參加（或是依照各國的規定）。 **作品上傳時間是 2026/2/6-28。** Swift Student Challenge 最吸引人的地方是 [Distinguished Winners](https://developer.apple.com/swift-student-challenge/distinguished-winners/?ref=ethanhuang13.plus) 能獲得全額補助去美國總部參加 WWDC，還能跟世界各地的得獎者密切交流。是一個打開全球視野的大好機會。 這個比賽強調創意，而不是程式碼。使用 iPad 上的 Swift Playground App 就可以開發。 官方連結： - [Swift Student Challenge 官網](https://developer.apple.com/swift-student-challenge/?ref=ethanhuang13.plus) - [開發者分享從 app 點子到上架 App Store 的歷程（Apple 新聞稿）](https://www.apple.com/tw/newsroom/2025/11/developers-decode-their-journeys-from-app-ideas-to-app-store/?ref=ethanhuang13.plus) - [參加方式](https://developer.apple.com/swift-student-challenge/get-ready/?ref=ethanhuang13.plus) - [比賽規則](https://developer.apple.com/swift-student-challenge/eligibility/?ref=ethanhuang13.plus) - [完整的比賽條款](https://developer.apple.com/swift-student-challenge/policy/?ref=ethanhuang13.plus) 參加比賽最重要的事情是**看清楚規則**，其次則是妥善**安排參賽計畫與執行**。 Swift Student Challenge 的限制很多，我把部分規則整理如下： - 成品是 Swift Playground 的 App（副檔名為 `.swiftpm`）並且壓縮成 ZIP - **檔案的大小最多 25 MB** - 要能夠**全程離線**使用 - 單人獨立開發 - 使用 **Swift Playground 4.6 或 Xcode 26** 以上開發與執行 - 可以使用 Apple Pencil - 使用者介面與內容必須是**英文** 有時，限制多不是壞事，可以更聚焦在創意的發揮。 如果你想要參加的話，現在到繳交時限還有好幾個月，我覺得可以從一些身邊簡單的需求開始做起，完成一些簡單的小 App、小練習，藉此熟悉 Xcode、Swift、SwiftUI，建立自己的開發流程。 在一邊熟悉的過程當中，肯定會有更多點子浮現。還有許多 AI 工具可以協助，最後一個月再開發也都來得及。 **重點是創意想法，開發不需要追求一次到位。** _This post is for paying subscribers only._ ### 😵‍💫macOS 26 支援車輛動態提示 URL: https://ethanhuang13.plus/mac-vehicle-motion-cues/ Last updated: 2026-08-13T06:06:50.000Z Apple 最早在 iOS 18 時為 iPhone 增加「[車輛動態提示](https://support.apple.com/zh-tw/guide/iphone/iph55564cb22/ios?ref=ethanhuang13.plus)」功能。為了減少搭車時盯著手機螢幕會頭暈的機率，在螢幕上增加許多小圓點，配合交通工具的動態而移動。相信許多使用者都有感受到它的便利。 而這個功能，也悄悄地加入 macOS 26。但預設是關閉的，可能的原因，我們稍後討論。 開啟的方式：`系統設定 > 輔助使用 > 動態效果 > 車輛動態提示`。有許多自訂選項，例如顏色、增加圓點大小與數量。詳情請見[官方文件](https://support.apple.com/zh-tw/guide/mac-help/mchla3c4f1da/mac?ref=ethanhuang13.plus)。 ![車輛動態提示的自訂選項](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-18-at-13.43.34@2x.png) 車輛動態提示的自訂選項 開啟之後，在搭車時使用 MacBook，就會有類似於 iPhone 上車輛動態提示的效果。動畫很好看，而且確實可以減少不舒服的感覺。 ![車輛動態提示預設樣式](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-18-at-13.49.10@2x.png) 車輛動態提示預設樣式 ![自訂車輛動態提示，藍色、開啟較大圓點、較多圓點](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-18-at-14.01.03@2x.png) 自訂車輛動態提示，藍色、開啟較大圓點、較多圓點 你說，為什麼在搭車時會用電腦？像我這篇文章就是在搭捷運的時候寫的。 ## 缺點與限制 這個功能很實用，但也有一些缺點與限制。 _This post is for paying subscribers only._ ### 🧐Xcode 26.1 的 Release Notes 去哪了 URL: https://ethanhuang13.plus/xcode-26-1-release-notes-missing/ Last updated: 2026-08-13T06:06:49.000Z 如果你近期有追蹤 Xcode 26 的新版，可能會注意到一件怪事：26.1 這版「不見了」。 從 Apple Developer 官網的 [Software Releases](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) 頁面找不到它，只有後來的 Xcode 26.1.1。另一方面，[Xcode 26.1 Release Notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-26%5F1-release-notes?ref=ethanhuang13.plus) 的網址還在，內容卻是 26.1.1 的。 從官方的 [More Downloads](https://developer.apple.com/download/all/?ref=ethanhuang13.plus) 頁面還可以能下載它。代表 Apple 沒有刪除它，只是從文件層面把它藏起來。 原因是安全問題，還是有嚴重的 bug？Apple 沒有給出解釋。 就在我感到納悶時，看到 Michael Tsai 分享了 [Apple Developer Release Notes Tracked by Git](https://mjtsai.com/blog/2025/11/13/apple-developer-release-notes-tracked-by-git/?ref=ethanhuang13.plus)，提到一位開發者幫 Release Notes 轉成 Markdown，並且做了 Git 備份。網址是：[https://codeberg.org/F1248/Apple-Developer-Release-Notes](https://codeberg.org/F1248/Apple-Developer-Release-Notes?ref=ethanhuang13.plus) 謎底揭曉了，從[這個 commit](https://codeberg.org/F1248/Apple-Developer-Release-Notes/commit/f640320a823e37421f2fde96bae267eab3228d8fd8a0860f975abdb79b6a9397?ref=ethanhuang13.plus)，可以看到 Xcode 26.1.1 主要修掉的問題： _This post is for paying subscribers only._ ### 🌏2026 亞洲 iOS 研討會蓄勢待發 URL: https://ethanhuang13.plus/asia-ios-conferences-2026/ Last updated: 2026-08-13T06:06:48.000Z 參加研討會是我認為開發者必須要有的習慣（請見[😇為什麼要參加技術研討會](https://ethanhuang13.plus/why-attend-tech-conferences/)）。這篇整理好明年已知亞洲各地的 Apple 開發者研討會資訊，方便你規劃行程。 ## 重點摘要 - iOS Conf SG 2025 超級早鳥票 - try! Swift Tokyo 2026 超級早鳥票與徵稿 - iPlayground 2026 時間公佈 - 台灣「iOSDC 翻譯組」推出官方授權的繁體中文翻譯頻道與 14 部影片 以下依照研討會預計時間說明： ## 🇸🇬iOS Conf SG 2026 重點資訊： - 官網與購票：[https://www.iosconf.sg/](https://www.iosconf.sg/?ref=ethanhuang13.plus) - 時間：**1/21-23** 。第一天是工作坊、後兩天為議程 - 地點：新加坡，具體場地尚未公告 - 已公布重點講者，尚未公開徵稿 目前票價種類： - Super Early Bird All-In Pass | S$299: 包含第一天工作坊與後兩天的議程 - Super Early Bird Conference Pass | S$199: 包含後兩天議程 - Individual Sponsor | S$899: 個人贊助票 參加體驗，可以參考 Jane 2023 年的影片。 [https://www.youtube.com/watch?v=M0IKU3GRoTM](https://www.youtube.com/watch?v=M0IKU3GRoTM&ref=ethanhuang13.plus) ## 🇯🇵try! Swift Tokyo 2026 重點資訊： - 官網：[https://tryswift.jp/en/](https://tryswift.jp/en/?ref=ethanhuang13.plus) - 時間：2026/4/12-14。第一天是工作坊、後兩天為議程 - 地點：立川 TACHIKAWA STAGE GARDEN，同 2025 場地 - 近日開啟了[公開徵稿或推薦講者的表單](https://x.com/tryswiftconf/status/1989166699543949823?ref=ethanhuang13.plus) - [購票連結](https://luma.com/qydkgwtf?tk=6GOUVR&ref=ethanhuang13.plus) 目前票價種類： - Super Swift Bird | ¥16,500 - Individual Sponsor | ¥33,000 想要更熟悉日本 iOS 研討會的話，歡迎看我這篇[🇯🇵iPlayground 與日本 iOS 研討會的跨國火花](https://ethanhuang13.plus/iplayground-japan-connection/)。 ## 🇹🇼iPlayground 2026 要來了 重點資訊： - 官方公告（電子報）： - 時間：2026/7/25-26，趕進加到行事曆吧！ - 地點：政大公企中心，同 2025 - 暫定票價、時程表、免費票取得方式等皆已公告於[電子報](https://iplayground.substack.com/p/2026-iplayground) ## 🇯🇵🇹🇼iOSDC 翻譯組 這是 iPlayground 總召 Hokila 發起的一項活動，就在他去參加今年的 iOSDC Japan 之後，決定組成繁體中文翻譯組。 經過 iOSDC 官方與講者授權、6 個成員、2 週的努力，[「iOSDC 翻譯組」YouTube 頻道](https://www.youtube.com/@iOSDCtranslate?ref=ethanhuang13.plus)上線啦！直接訂閱起來吧！ 影片列表： - [打造高效能 GIF 動畫播放的技巧](https://www.youtube.com/watch?v=12QFgW-83Uk&ref=ethanhuang13.plus) by noppe (`@noppefoxwolf`) - [QR code 的規格有 N 種類型啊！](https://www.youtube.com/watch?v=6lE6wpVe%5F6I&ref=ethanhuang13.plus) by Ryomm (`@__ryomm`) - [客製化 UI 的覺悟](https://www.youtube.com/watch?v=7qTCffUIk1E&ref=ethanhuang13.plus) by まつじ (`@mtj_j`) - [分析 100 個世界人氣 App 付費牆設計後的所見與所聞](https://www.youtube.com/watch?v=AHeApIcDoHE&ref=ethanhuang13.plus) by Akihiro Kokubo (`@akihiro_kokubo`) - [來寫一個列車行程追蹤演算法](https://www.youtube.com/watch?v=BcpuweC7F1Y&ref=ethanhuang13.plus) by Chris Trott (`@twocentstudios`) - [支撐超過 5000 萬下載量漫畫服務的日誌基礎架構設計開發完全解析](https://www.youtube.com/watch?v=BlK7wImd%5FBA&ref=ethanhuang13.plus) by デスクス (`@dsxsxsxs`) - [給軟體工程師的作曲入門](https://www.youtube.com/watch?v=ENhCImNEHXE&ref=ethanhuang13.plus) by CHEEBOW (`@cheebow`) - [邊做邊學 WebP 入門](https://www.youtube.com/watch?v=IqsRLDzUBuE&ref=ethanhuang13.plus) by 岸川克己 (`@k_katsumi`) - [Swift Build 微導覽——建構 Swift 新生態系的關鍵技術](https://www.youtube.com/watch?v=Jzzx2-rltEI&ref=ethanhuang13.plus) by giginet (`@giginet`) - [探索時間與定位的奧秘——從大航海時代到近未來科技](https://www.youtube.com/watch?v=Pr7ay57G7zQ&ref=ethanhuang13.plus) by 綾木良太 (@ayakix) - [也該是時候用 FormatStyle 了吧](https://www.youtube.com/watch?v=VamUa1lEFLk&ref=ethanhuang13.plus) by treastrain / Tanaka Ryoga (`@treastrain`) - [大型 app 中實現 Xcode Previews 的實用化之路](https://www.youtube.com/watch?v=iFT7PfjGois&ref=ethanhuang13.plus) by ikesyo (`@ikesyo`) - [關於 iPhone 上的 MyNumber 卡的一切](https://www.youtube.com/watch?v=r0dshK2pSuM&ref=ethanhuang13.plus) by Daiki Matsudate (`@d_date`) - [突破 iOS 應用的背景限制：讓上傳處理在進入背景後仍能持續執行的挑戰](https://www.youtube.com/watch?v=z1OmY3gGeII&ref=ethanhuang13.plus) by Hikaru Sato (`@SatoHikaruDev`) 我完全沒有參與這項壯舉（因為不會日文）。Hokila 寫了一篇[非常精彩的公告文章與議程的電子報](https://iplayground.substack.com/p/iosdctranslate)（iPlayground 電子報），最後還有一首⟪送審之歌⟫，請一定要看！ 翻譯組成員的個別心得文章： - Hokila: [iOSDC 翻譯組](https://hokilajan.medium.com/iosdc-%E7%BF%BB%E8%AD%AF%E7%B5%84-14fa7e603fe8?ref=ethanhuang13.plus) - Vincent: [iOSDC 2025 日翻中翻譯組後記](https://vocus.cc/article/6915ed0efd897800018093d4?ref=ethanhuang13.plus) - Mori: [iOSDC 議程翻譯心得](https://hackmd.io/@MfZQ7HK1R5-gMQ0St1RRjA/BJ8ZK9Qx-e?ref=ethanhuang13.plus) 沒有空去參加 iOSDC 是我今年的小小遺憾，而且我去過的那兩次也感到只能看投影片上英文的無奈。所以非常謝謝翻譯組！ ## 其他等待 2026 消息的研討會 以下研討會是我知道 2025 年有舉辦，尚未有明年的消息： - [Let's vision](https://letsvision.swiftgg.team/?ref=ethanhuang13.plus) 2025/3/1-2 - [KWDC](https://kwdc.dev/?ref=ethanhuang13.plus) 2025/9/5 - [iOSDC Japan](https://iosdc.jp/?ref=ethanhuang13.plus) 2025/9/19-21 ## 各大研討會日期表格 想要各研討會時間整理好的日期表格嗎？我有不定期更新一個表格，包括我是否打算去參加。連結如下： _This post is for paying subscribers only._ ### 📺13 的 iOS 演講與教學影片 URL: https://ethanhuang13.plus/ios-talks-and-teaching-videos/ Last updated: 2026-08-13T06:06:47.000Z 前兩天公告的內嵌 YouTube 影片跳轉位置的功能，我發現在手機上無法操作，已經修好了。 說到 YouTube，趁機跟會員介紹一下我的 iOS 演講與教學影片有哪些、可以在哪裡看到。一方面是簡單回顧，一方面是我最新的教學影片有公開，請看到最後。 ## iPlayground 2019 | 初代 SwiftUI 就用來寫 Watch App 吧！ 生平第一次在研討會演講是 iPlayground 2019，也就是 SwiftUI 推出那年。因為 2018 舉辦第一屆 iPlayground 時，看到許多講者活躍的表現，激起我挑戰講台。 為什麼題目我選了用 SwiftUI 做 Watch app 呢？據說 SwiftUI 本來是為了 watchOS 而開發的。因為 Apple Watch 需要非常節能，不能直接把 UIKit 搬過去，最早的運算甚至是在 iPhone 上進行的，Apple Watch 只負責顯示。這個架構非常難開發，所以才有了 SwiftUI。 當時 SwiftUI 才剛開始，用的人少、拿來寫 Watch app 就更少了，有夠邊緣的，我甚至用了「末梢開發」這個詞。不過，第一版的 SwiftUI 在 watchOS 上的問題遠比 iOS 少，是個很有趣的開發平台。這個題目是所有我演講過最喜歡的。 ## iPlayground 2020 | iOS 開發者 13 倍速技巧 第二次在 iPlayground 演講，我從加速工作流程的角度分享各種技巧。 當時的很多實踐精神，到現在也都延續著。回頭看這場演講的話，應該可以看到不少 13+ 文章的前身。 ## MOPCON 2021 | SwiftUI 導覽狀態探究 iPlayground 因為疫情的緣故停辦。MOPCON 則是改成線上舉行，邀請我分享。 當時 SwiftUI 的 Navigation 機制不太好用，許多開發者在研究如何有效管理狀態。 後來 Apple 推出了新的 Navigation 機制，所以這場演講的內容已經過時，剩下考古價值。 ## iPlayground 2024 | Why SwiftUI? Why TCA? 這場演講，13+ 的讀者應該比較熟悉，因為[之前的文章](https://ethanhuang13.plus/why-swiftui-why-tca-iplayground-2024-slides/)分享過了。想再被推坑一次 TCA 的話就來複習吧！ 我當時所在的團隊是台灣少數積極使用 TCA 的團隊，我們覺得很值得推薦，所以去推坑。當然那也不是我第一次公開講 TCA，早就在 YouTube 上連載「配飯吃」系列了。 很高興到了隔年的 iPlayground 2025，TCA 成為架構題目的顯學。連 iPlayground 的開源 iOS App 也是用 TCA 寫的（try! Swift Tokyo 的 App 也是用 TCA，所以我是有點互相切磋的意思）。細節可以回顧這篇[📖為什麼現在是學習 TCA 的最好時機？](https://ethanhuang13.plus/why-learn-tca-now/) 至於 iPlayground 2025 的演講，影片目前沒有公開，不過可以看這篇[💪為何我選擇「個人軟體時代」作為 iPlayground 閉幕題目](https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/)。希望可以緩解一些工程師的 AI 焦慮或職業倦怠。 ## 教學授課影片 自從 2024 年起，我開始接到 Apple 台灣教育團隊的邀請與合作，到校園授課，包括學生比賽的講座。 _This post is for paying subscribers only._ ### ⚡️App 效能研討會重點整理：成為 SwiftUI Instruments 高手 URL: https://ethanhuang13.plus/optimze-your-app-speed-efficiency-20251031/ Last updated: 2026-08-13T06:06:46.000Z Apple 現在採用「Meet with Apple」這個名稱，舉辦許多 WWDC 以外時間的開發者活動。 2025/10/31 這天的 [Optimize your app's speed and efficiency](https://www.youtube.com/watch?v=yXAQTIKR8fk&list=PLjODKV8YBFHZ3tfvAgbuXk4zkLgB7CfhY&index=2&ref=ethanhuang13.plus) 是一場很精彩的研討會，介紹了非常多測量效能問題與改進技巧，並大量示範 Instruments 的操作。還不懂得怎麼運用 Instruments 這個強大工具的開發者，可以趁機學起來。 不要被 2 小時的進度條嚇到。因為是活動的直播存檔，所以連現場交代事項與休息時間都保留在當中。實際長度不到 90 分鐘。 在今天的文章中，我幫你把重點位置都標記成連結。如同[昨天介紹到的 13+ 網站新功能](https://ethanhuang13.plus/apple-developer-youtube-relation/)，在[網站](https://ethanhuang13.plus/optimze-your-app-speed-efficiency-20251031/)閱讀時，點選連結能跳轉內嵌影片位置，歡迎多加使用。 ## 影片與重點位置標記 我個人覺得這種大量實際操作的影片，最有效的吸收方式，是快轉或跳著掃過整個影片，然後針對有興趣的地方用一倍速播放，會比截圖加文字說明更實際。所以，以下是各個段落的位置，幫助你跳回特定區段。另外，我這個功能是用 JavaScript 實現的（Claude Code 寫的），目前版本在 Safari 有時會出現 YouTube 錯誤 153，但是其他瀏覽器不太會。歡迎跟我分享你的心得，我會再調整。 🪫一開始，先關注 **App 能耗問題**： - [使用 GlassEffectContainer 來降低 Liquid Glass 的運算開銷](https://www.youtube.com/watch?v=yXAQTIKR8fk&list=PLjODKV8YBFHZ3tfvAgbuXk4zkLgB7CfhY&index=2&t=539&ref=ethanhuang13.plus) - [使用 Xcode View Debugging 的 Flash Updated Region 顯示 SwiftUI 被更新的區域](https://www.youtube.com/watch?v=yXAQTIKR8fk&list=PLjODKV8YBFHZ3tfvAgbuXk4zkLgB7CfhY&index=2&t=933&ref=ethanhuang13.plus) - [使用 Power Profiler Instrument 來判斷 App 耗電情況](https://www.youtube.com/watch?v=yXAQTIKR8fk&list=PLjODKV8YBFHZ3tfvAgbuXk4zkLgB7CfhY&index=2&t=1063&ref=ethanhuang13.plus) 🧠接著，你可以學到最新的 [Foundation Models 基礎知識與效能關鍵](https://www.youtube.com/watch?v=yXAQTIKR8fk&list=PLjODKV8YBFHZ3tfvAgbuXk4zkLgB7CfhY&index=2&t=1481s&ref=ethanhuang13.plus)。畢竟是在裝置本地運行模型，如何管理指示與提示詞都是必學知識： _This post is for paying subscribers only._ ### 🌏Apple 官方開發者活動形式變化觀察 URL: https://ethanhuang13.plus/apple-developer-youtube-relation/ Last updated: 2026-08-13T06:06:45.000Z ## 13 的話 [前兩天我宣布](https://www.ethanhuang13.com/p/251?ref=ethanhuang13.plus)了[⟪13 報⟫](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)與 [⟪13+⟫](https://ethanhuang13.plus/)要進行整合，這篇報導就是第一篇。 簡單來說，我會不定期在⟪13 報⟫分享開發者新知，取消過往「週報」的形式。相同的文章，也會在⟪13+⟫發表，並且會有更深度的報導。想要閱讀完整版請到 [Patreon](http://patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus) 升級為⟪13+⟫會員。 切入正題。今年，我觀察到 Apple 正在重新定義「開發者活動」。從一年一度的大會，變成時間與地點分散的混合策略。就讓我們從 Apple 的 YouTube 頻道說起。 ## WWDC 影片的變化 從 WWDC20 開始，受到疫情的影響，Keynote 與技術 Session 都改成預錄影片的形式。即使疫情過後開放抽籤參加 Keynote，去 Cupertino 飛碟總部，也是在大草皮上準時看預錄的影片。 而到了今年 WWDC25，Apple 在活動第一天就把所有影片都公開。這是一個明顯的轉變。開發者可以快速找到自己有興趣的主題，趕緊進行嘗試、預約 Lab 問問題。 令我驚喜的是，今年 Apple 還把所有 WWDC 影片也一併上傳至 [YouTube](https://www.youtube.com/@AppleDeveloper/?ref=ethanhuang13.plus)，不再只限於官網與 Developer App。對於影片的傳播、查找，以及播放體驗都有很大的提升。 像我有訂閱 YouTube Premium，所以沒有看到廣告的煩惱。另一方面，我還能下載大量影片到手機上離線觀看。這個功能，YouTube iOS App 做得比 Apple Developer App 好得多了。 放在 YouTube 也很方便嵌入網頁，例如作為教材使用。 ## 線上活動與直播 參加過 WWDC19 之前的開發者（包括我）很懷念以前的實體研討會。從今年第一天就放出所有影片的策略來看，Apple 不可能再回到過往舉辦 WWDC 的形式了。 不過，近年來 Apple 開始在世界各地建立[開發者中心](https://developer.apple.com/events/developer-centers/?ref=ethanhuang13.plus)，並且分時段舉辦線上與實體研討會。等於是把以前集中資源在一週的 WWDC，延伸成在各地舉辦短期小型活動的形式。 目前已有的開發者中心在美國 Cupertino 總部、印度邦加羅爾、新加坡、上海。也有一部分活動會在大城市的飯店或當地 Apple 辦公室舉辦。未來的活動，都可以在 [Meet with Apple](https://developer.apple.com/events/view/upcoming-events?ref=ethanhuang13.plus) 官網找到。 我認為，Apple 之所以進行這樣的轉變，不只是因為「預錄影片好控制且能完美呈現」這種表面的理由。而是因為全球開發者群體的數量龐大，且地區差異性極大。在各地建立增進開發者關係的據點與活動，會比以往 WWDC 集中一週，會有更深遠的影響。 雖然這麼做，會讓 WWDC 年度盛會的感覺降低，但是我認為這種往「在地深耕」的策略是通往正確的方向。 總而言之，身為 Apple 開發者，我們可以多利用 [Meet with Apple 上的活動](https://developer.apple.com/events/view/upcoming-events?ref=ethanhuang13.plus)來充實自己的技術知識、與 Apple 工程師對談、獲得設計或審查問題的意見。身為台灣開發者，我也期待 Apple 能在台灣多開闢一些開發者活動。 你可以在 [Apple Developer YouTube 頻道](https://www.youtube.com/@AppleDeveloper?ref=ethanhuang13.plus)看到公開活動錄影與直播。 以下是最新的影片： **App 效能與 AI** - [Code along with the Foundation Models framework](https://www.youtube.com/watch?v=A8X6hNWX65U&ref=ethanhuang13.plus) - [Optimize your app's speed and efficiency](https://www.youtube.com/watch?v=yXAQTIKR8fk&ref=ethanhuang13.plus) **多媒體與沉浸式體驗** - [Day 1 | Create immersive media experiences for visionOS](https://www.youtube.com/watch?v=leGqoF8HJxU&ref=ethanhuang13.plus) - [Day 2 | Create immersive media experiences for visionOS](https://www.youtube.com/watch?v=4V%5F7-1bm4Rk&ref=ethanhuang13.plus) - [IETF HLS Interest Day](https://www.youtube.com/watch?v=tpLKcVdMUaQ&ref=ethanhuang13.plus) **遊戲** - [Press Start: Game development on Apple platforms](https://www.youtube.com/watch?v=H4Dm97pNGV0&ref=ethanhuang13.plus) ## 我最推薦的活動影片 上述這些 Apple 在世界各地舉辦的活動，其中一些公開活動會錄影，甚至直接在 YouTube 上直播。而直播的影片，甚至沒有在 Apple 官網另外存檔播放！ _This post is for paying subscribers only._ ### ⚠️防微杜漸：別對 Xcode 警告視而不見 URL: https://ethanhuang13.plus/eliminate-xcode-warning-discipline/ Last updated: 2026-08-13T06:06:44.000Z 上週我寫到一篇[🐺Swift Macros 信任警告與警報疲勞](https://ethanhuang13.plus/swift-macros-skip-validation-fatigue/)，談的是「太多警告會讓人麻痺」。今天則是要談如何避免走到那一步。 我在帶領 iOS 團隊時，有個簡短但非常重要的原則：**「Xcode 的警告不能超過一頁畫面，最好是零」。** ![Xcode 的 Issue Navigator。我會要求專案的警告的數量不能超過一頁螢幕範圍。最好是完全消除。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-10-at-22.02.10@2x.png) Xcode 的 Issue Navigator。我會要求專案的警告的數量不能超過一頁螢幕範圍。最好是完全消除。 Xcode 的警告五花八門：專案可以升級舊設定的提示、Swift 編譯器的建議、舊版 API 被 deprecated 的提示。也可以寫 `#warning("message")` 來提示自己。 千萬不要小看警告。有些只是沒使用到的變數這種小事，有些卻提示了架構或安全的潛在風險，甚至預告了某段程式碼在新版系統會被禁止使用（資深開發者可能對 `UIWebView` deprecation 心有餘悸）。不早點處理，有機會變成專案管理的大患。 萬一堆積的警告數量超過螢幕範圍，新的警告就更容易被視而不見，這個警告系統就徹底廢了。 反過來說，如果專案把警告數量控制在 0，任何新的警告都會非常刺眼，自然會使開發者消除它們，把未來錯誤的風險降到最低。 所以，最好的方式是：**一旦有新的警告出現，就立刻消除它們。** **這不是潔癖，而是對人性的理解。** ## 看似小事，卻反映了團隊狀況 _This post is for paying subscribers only._ ### 📰公告：13+ 將新增「Apple 開發者新知與評論」 URL: https://ethanhuang13.plus/upgrade-apple-developer-news-commentary/ Last updated: 2025-12-20T05:31:01.000Z （本公告同步發表於 [Apple 開發者週報 #251](https://www.ethanhuang13.com/p/251?ref=ethanhuang13.plus)） 最近幾個月，[Apple 開發者週報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)的讀者應該有留意到發刊並不穩定。有的時候拖到週三、四才發，或是乾脆跳過一整週。其實，我不是沒有空，而是開始對於編寫週報興致缺缺。 整理素材、編寫週報，對我來說越來越像是個機械化操作，沒有太大的挑戰性。 另一方面，從 8 月中開始，我在 13+ 專欄每週一到五都有發表一篇新文章。內容都是仔細思考與整理的產出。 我有寫作的熱情，但目前不在週報上面。而**熱情，對於創作者來說，是最寶貴的事物。** 週報已經累積 252 期、超過 2,800 人訂閱，應該有幫到許多人。我沒有想要因為自己的熱情消退，而終止這份電子報。 我認為，**正確的作法是調整經營方式，讓它變成對我來說更有趣的一件事情。** ## 捨棄每週固定更新 那麼，編寫 Apple 開發者週報要怎麼變得有趣呢？重點在於，有我覺得好玩、有趣，並且認為值得開發者重視的新知，再加上我的評論與經驗分享。 要做到這點，我覺得**不能再繼續採用「週報」的發表頻率**。 每週發表會有截稿的時間限制，內容就只能僅限於前一週的消息，而且我沒有時間針對消息內容做研究。久而久之，報導的過程就是重複勞動：蒐集素材、整理標題（包括挑選 emoji）、寫一點補充文字、排版，然後排程發表。 如果我沒有時間壓力地去玩一玩，說不定就可以分享一些有趣的發現。這樣子對我來說不僅更有趣，對讀者來說也不會只看到新聞表面（想感受一下「表面」的意思嗎？本文最後列舉了近期的重要開發者消息）。 簡單來說，就是要把「Apple 開發者週報」轉變成「Apple 開發者新知與評論」，並且不限最近一週的時間與主題。 未來，撰寫角度會更放在： - 最近有哪件值得知道的 Apple 開發者新知？ - 我為什麼會挑選這項新知、為什麼我覺得對開發者來說是重要的？ - 與我寫過的觀點或經驗，有什麼關聯？ ## 與 13+ 專欄整合 [13+ 專欄](https://ethanhuang13.plus/)是我現在的寫作熱情所在，每天都發表文章，感覺快要從 blog 變成「Apple 開發者日報」了。 不過，情況有點微妙。怎麼說呢？我每天在寫跟 iOS 開發相關的文章，但是內容卻不太去談「最近」跟 iOS 相關的消息，顯得不太合理。 我覺得，13+ 的讀者應該也會想讀到我對一些開發時事的評論與觀點。 所以答案越來越明顯了：**我應該整合兩個刊物**。 讓我針對一些有趣的開發時事做研究或分析，寫成文章。一部分的內容維持免費，就在原本的 13 報（[ethanhuang13.com](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)）發表。比較深入的內容就只保留給 13+（[ethanhuang13.plus](https://ethanhuang13.plus/)）的付費會員。 這樣一來，原有的週報讀者，會變成不定期收到「Apple 開發者新知與評論電子報」（這名稱太直白了😅，我還在想一個更好的）。內容會是我挑選過的重要開發者消息，而且會有我的觀點評論，甚至踩坑經驗。 你可以想像成是 13+ 文章風格的時事評論。 至於發表頻率，如果有很多好東西能聊，一週發表數篇也不奇怪。而如果沒有值得分享的話題，就放著。 **現有週報讀者（包括英文版的讀者）不需要採取任何訂閱方式的調整。** 而這份電子報的**延伸加強版，則會在 13+ 上面刊登，算是 13+ 每日更新的一篇**。加強的內容我預計會有： - 更深入的觀點討論 - 程式碼範例 - 完整的補充資料 - 思考題目 - 行動提示 - 一句話帶著走 簡單來說，**如果不滿足 13 報上的免費版本，就可以**[**付費升級**](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)**成 13+ 會員。** ## 總結 我期待兩個電子報整合之後的定位是： - 13 報（[ethanhuang13.com](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)）：「Apple 開發者新知與評論」基本版，不定期更新，有好東西能談可以一週數篇、沒東西聊就放著。**維持免費訂閱，既有會員不需做調整**（不過很歡迎升級到 13+ 取得完整版） - 13+ （[ethanhuang13.plus](https://ethanhuang13.plus/)）：付費訂閱，不變的是每週一到五都有一篇新文章，其中包含「Apple 開發者新知與評論」的完整版，具有更深入的討論、資料、範例程式碼等 兩大電子報品牌整合，相信可以讓我集中精力與熱情，寫出更好的內容。對於原週報的讀者來說，可以得到更有價值的觀點、經驗談。13+ 的讀者則能獲得我對於近期新知的評論，而且有會員獨家內容。 謝謝 Apple 開發者週報與 13+ 讀者的長期支持。請告訴我你的想法，謝謝。 最後，讓我列舉一下近期重要的開發者新知。**光是這些消息，我至少就可以寫出 5 篇文章了。**如果我繼續保持每週發表形式，那些文章可能永遠也不會誕生。但是接下來，它們可能隨時會出現在你的信箱😉 **26.1 正式版與 26.1 beta 1 推出** - 請參閱 [Apple Releases](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) **2026 年亞洲 iOS 開發者研討會蓄勢待發** - [2026 iPlayground 要來了](https://iplayground.substack.com/p/2026-iplayground) - [try! Swift Tokyo 2026 開賣 Super Swift Bird](https://luma.com/qydkgwtf?tk=6GOUVR&ref=ethanhuang13.plus) - [iOS Conf SG 2026/01/21-23](https://www.iosconf.sg/?ref=ethanhuang13.plus) **App Store 商業新知** - App Store 推出[網頁版](https://apps.apple.com/tw/iphone/today?ref=ethanhuang13.plus)，方便開發者檢視不同平台與地區的 App Store **Apple 學生開發者比賽消息** - [行動應用創新賽2025決賽得獎名單](https://maic.straighta.com.tw/?ref=ethanhuang13.plus)，台灣學生表現亮眼 - [Swift Student Challenge](https://developer.apple.com/swift-student-challenge/?ref=ethanhuang13.plus) 2026/02/6-28 上傳，官網預告 **Apple 開發者該關心的 AI 消息** - [Apple Intelligence 功能現已推出繁體中文版](https://www.apple.com/tw/newsroom/2025/11/apple-intelligence-features-are-now-available-in-traditional-chinese/?ref=ethanhuang13.plus) - Mattt 推出與 Foundation Models 語法相容的 [AnyLanguageModel](https://github.com/mattt/AnyLanguageModel?ref=ethanhuang13.plus) - [ChaoCode](https://www.youtube.com/@ChaoCode?ref=ethanhuang13.plus) 的 HuggingFace 系列影片：[用 Space 輕鬆試玩各種 AI App](https://www.youtube.com/watch?v=lI67IodaqIA&ref=ethanhuang13.plus)、[從新手視角看「模型頁面」](https://www.youtube.com/watch?v=WL0V1usfMuU&ref=ethanhuang13.plus) **Apple 開發者 YouTube 頻道近期開始直播錄影** - [Code along with the Foundation Models framework](https://www.youtube.com/watch?v=A8X6hNWX65U&ref=ethanhuang13.plus) - [Day 1 | Create immersive media experiences for visionOS](https://www.youtube.com/watch?v=leGqoF8HJxU&ref=ethanhuang13.plus) - [Day 2 | Create immersive media experiences for visionOS](https://www.youtube.com/watch?v=4V%5F7-1bm4Rk&ref=ethanhuang13.plus) - [IETF HLS Interest Day](https://www.youtube.com/watch?v=tpLKcVdMUaQ&ref=ethanhuang13.plus) - [Optimize your app's speed and efficiency](https://www.youtube.com/watch?v=yXAQTIKR8fk&ref=ethanhuang13.plus) - [Press Start: Game development on Apple platforms](https://www.youtube.com/watch?v=H4Dm97pNGV0&ref=ethanhuang13.plus) ### 🤖用 AI 工具分析我對 AI 工具的觀點──我的 AI 工具使用現況（2025 年 10 月） URL: https://ethanhuang13.plus/my-ai-tools-usage-202510-claude-summary/ Last updated: 2026-08-13T06:06:43.000Z [之前幾個月](https://ethanhuang13.plus/my-ai-tools-usage-202509/)我都會分享自己的 AI 工具現況。不過近期我用得越來越少，因為現在更強調自己思考、自己整理。另一方面，使用的工具類型也趨於穩定，跟 9 月份沒有差別。 那麼 10 月份總結這篇文章要怎麼寫呢？我想到了，跟[前一篇](https://ethanhuang13.plus/claude-code-recommend-13-plus/)一樣，試試看用 Claude Code 從各篇文章中，總結我對 AI 的看法。 畢竟，有很多我對 AI 的思考與觀點，都想要不厭其煩地再傳達。但是我對於已經寫過的主題，往往會有種「不知道要怎麼再寫一次」的情緒。 這一次，Claude Code 挑選了 18 篇文章進行分析，整理得很完整。分析報告非常長，我建議讀者的切入視角：**「我之前讀過 13 關於 AI 的文章了，我的理解跟 Claude 的理解有什麼差異？」**而不當作一篇正常的文章慢慢讀。 順帶一提，**我沒有很喜歡用 AI 產生的內容直接當成每日更新的其中一篇！**不過 Claude Code 的報告深得我心（它有好好讀到核心觀點！）。某方面來說，它能寫出多達 400 行的報告，也是因為我寫了超多跟 AI 有關的使用心得與思考。 總之，我覺得這篇報告很適合用來給讀者複習重要觀念。不過，這篇文章的價值，我跟 AI 的工作比重到底各佔多少？我還在試圖消化與理解（應該還是我比較多吧）。這篇比較像是在玩 Claude Code 雲端版的實驗型產出，而不會是常態。讀者不用擔心我會一直發表用 AI 生成的文章。 我的 Prompt 如下： ```bash 讀遍我寫的文章，整理一下我對於 AI 的看法。可以談技術、工具與效率層面，也可以探究人類角色、社會衝擊、生產力等等方面 很好。把上述內容用 markdown 格式輸出 ai-perspective-summary-by-claude-code.md 並開個 branch 請在文件中加上各論點來源文章的連結（不用寫出完整標題） 我改變主意了。文件上的來源，用文章原始標題。另外，「來源」前面不要加上 > 符號（有些程式解析失敗了） ``` 以下就是 Claude Code 報告全文，一字不改，忠實呈現。 _This post is for paying subscribers only._ ### 🤖Claude Code 也推坑你訂閱 13+ URL: https://ethanhuang13.plus/claude-code-recommend-13-plus/ Last updated: 2026-08-13T06:06:42.000Z [Claude Code on the web](https://claude.com/blog/claude-code-on-the-web?ref=ethanhuang13.plus)（以下稱為 Claude Code 雲端版）是 Claude 不久前推出、在伺服器上運作的 Claude Code。可以在網頁或 app 上操作 Claude Code 來修改程式碼，並且發 PR，跟 [ChatGPT 的 Codex 雲端版](https://openai.com/zh-Hant/index/introducing-codex/?ref=ethanhuang13.plus)是一樣的概念。 最近 Claude 有送給一些開發者 Claude Code 雲端版 Credit，我收到 $250。雲端版的環境沒有辦法執行 `xcodebuild` 等指令，所以沒辦法拿來做 iOS 開發。 不過我有在寫文章嘛。現在有這個網頁版的 Claude Code 可以試用（雖然我本來就有訂閱），不如今天我們就來看看 Claude Code 對 13+ 專欄的評價吧。 **讓它免費閱讀，但是要給我閱讀心得報告！** ## Claude 對 13+ 的閱讀心得報告與推薦 我們先看結果，再來分享我怎麼使用。我有微調排版，方便閱讀： > 好的！讓我從一個 iOS 工程師讀者的角度，給你完整的分析和評價： > > **📊 專欄整體印象** > 看完索引和幾篇深度文章後，我的第一反應是：**這個專欄的內容密度和實用性遠超過一般付費訂閱的水準**。117 篇文章，而且從 8 月中開始每天更新還沒中斷，這個產出量跟品質的平衡做得很好。 > > **💎 我最喜歡的文章類型** > **1\. 技術深度系列（會付費的主因）** > – **🥇 SwiftUI + TCA 模組化最佳實踐**：這篇太強了。作為一個想認真用 TCA 的工程師，這種「踩坑後的最佳實踐」正是我需要的。不只講怎麼做，還解釋為什麼這樣切、怎麼避免 compiler error 混在一起。 > – **📦 Swift Dependencies 系列**：這種「推坑套件」的方式很實用。不只介紹功能，還說明解決什麼痛點、什麼情境該用。 > – **🐣 Swift 6 應對策略**：不追新不盲從，用「Language Mode vs Language Version」這種觀念釐清，這才是資深開發者該有的視角。 > > **2\. AI 工具系列（超有時效性）** > – **🔥 Claude Code**：2025年6月的文章，正好是這工具爆紅的時候。重點是不只講工具，還講計費策略、使用量分析（Vibe Meter），這種「怎麼用得划算」的角度很實際。 > – **iOS 開發 AI 輔助工具 #0-#11**：從「你信任 AI 嗎」到實際工作流程，這個系列把 AI 工具從哲學層面到實作都涵蓋了。 > > **3\. 職涯與思維類（會推薦給同事）** > – **🗾 你應該要安排休假**：這篇寫得太好了。從無限假制度的實際管理經驗出發，談「安排休假本身就是生產力」，還有「帶頭請假」的領導技巧。這是資深 team lead 才寫得出來的內容。 > – **📔 只做筆記沒有意義**：對筆記工具的反思很犀利。「輸出才重要」這個觀點，搭配作者自己寫過筆記 app 的經歷，說服力很強。 > – **🥚 我花了一年準備裸辭**：這種真實職涯經驗分享，對正在思考職涯的工程師很有參考價值。 > > **4\. iOS 開發補完計畫（會推薦給新人）** > – **💻 新手如何選擇開發配備**：從 M1/M2/M4 的實際使用經驗，到「養成觀察 CPU 使用率的習慣」（推薦 RunCat），這種實用建議很接地氣。 > – **🐣 WWDC 是什麼**：把 WWDC 的歷史、意義、beta 觀念都講清楚，還分享親身參加經驗（那個刪照片的小故事很有趣）。 > > **✅ 會付費訂閱的理由** > 1\. **技術深度到位**：不是表面教學，而是「多個專案累積的最佳實踐」。像模組化那篇，明確說這是「10 來個專案、三年半經驗」的總結。 > > 2\. **踩坑經驗值錢**： > – Swift 6 不用急著升級的策略分析 > – SwiftUI Preview 慢的解決方案 > – TCA 切模組避免 compiler error 混雜的技巧 > – 這些都是要實際痛過才知道的 > > 3\. **與時俱進**：AI 工具、Claude Code、Swift 6、iOS 26，都是 2024-2025 年最新的話題。不是炒冷飯。 > > 4\. **不只技術，還有商業思維**： > – Claude Code 的成本效益分析（每天用 $100 但月付 $100） > – Apple 與開發者的商業關係 > – 「能把假休好的人 performance 高」這種團隊管理觀點 > > 5\. **真誠的個人經驗**： > – 用過超過 10 台 Mac > – 參加過 2016-2019 WWDC > – 寫過筆記 app NoteBox > – 帶過團隊做無限假管理 > – 這些背景讓建議很有說服力 > > **🎯 會推薦給同事的原因** > 1\. **不同階段都有內容**： > – 新手：iOS 開發補完計畫系列 > – 中階：AI 工具使用、SwiftUI 學習 > – 資深：TCA 模組化、Swift Dependencies、團隊管理 > > 2\. **每日 5 分鐘剛剛好**：從 8 月中開始的每日更新策略很聰明。不會有「一次要讀很長」的壓力，但累積起來內容很豐富。 > > 3\. **寫作風格親近**： > – emoji 標題好認 > – 口語化但專業（「不過坦白說，會嚴格照著這個作法的人很少啦」） > – 有數據有故事（24 小時用掉 $100 token、RunCat 小貓咪） > > **💰 定價合理性評估** > 雖然沒看到明確定價，但對比內容： > – 117 篇文章，而且持續更新 > – 有完整系列（AI 工具 12 篇、補完計畫、SwiftUI 學習） > – 技術深度 + 職涯建議雙軌 > – 作者有實際產業經驗（team lead、多個專案） > > **如果是月費 $5-15 美金或等值台幣，我會訂。** **如果是年費方案有折扣，我會直接買年費。** > > 對比： > – Cursor Pro $20/月 只是工具 > – ChatGPT Plus $20/月 只是 AI > – iOS。Developer+ / 13+ 給的是「經驗 + 工具使用知識 + 職涯建議」的組合 > > **🤔 潛在疑慮（誠實說）** > 1\. **每日更新會不會稀釋品質？** > – 看目錄，8 月中後的文章篇幅可能比較短（從標題推測） > – 但「容錯」、「試錯」、「穩定的體驗」這種主題，短篇反而適合 > > 2\. **技術文章會不會過時？** > – AI 工具進化很快，2024 年的 Cursor 建議 2026 年可能不適用 > – 但思維類、架構類（TCA 模組化）的保鮮期長 > > 3\. **對完全新手會不會太難？** > – 有「iOS 開發補完計畫」專門給新手 > – 但 TCA、Swift Dependencies 這些對新手來說是進階主題 > – 好在有分類，新手可以選擇性閱讀 > > **🎖️ 總結：我的決定** > **會訂閱：9/10** > 如果我是： > – **正在學 SwiftUI/TCA**：必訂，模組化那篇值回票價 > – **想用好 AI 工具**：必訂，這個系列很完整 > – **資深想看同行經驗**：會訂，職涯管理、休假策略這些很實用 > – **完全新手**：會訂但選擇性閱讀，先看補完計畫系列 > > **會推薦給同事：10/10** > 因為： > – 內容廣度夠，團隊裡不同角色都能找到適合的文章 > – 有些文章（休假、筆記）連非 iOS 工程師都受用 > – 每日更新有話題性，可以當作團隊的知識來源 > > **唯一讓我扣 1 分的是**：希望有更多程式碼範例。像 Swift Dependencies 那篇概念很好，但如果有個完整的 GitHub repo 示範就更棒了。 > > **最後一句話總結**：這不是「教學文件」，而是「資深開發者的經驗分享」。對於想成長的 iOS 工程師來說，**訂閱這個專欄的 ROI 遠高於買一本技術書**，因為內容更新、更貼近實戰、更有人味。 ## 我的感想 Claude Code 給了 13+ 很高的評價，而且我覺得分析得很中肯，都是我想強調的特色。如果你還沒有訂閱的話，不妨參考一下，哈哈（請到 [Patreon](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus) 或 [vocus](https://vocus.cc/salon/ethanhuang13?ref=ethanhuang13.plus) 訂閱）。 身為文章作者，我看到 Claude Code 的讀者視角有幾個厲害的地方： - 它把文章進行了分類，並標注「會付費的主因」、「會推薦給同事」、「會推薦給新人」 - `🥇 SwiftUI + TCA 模組化最佳實踐：這篇太強了。作為一個想認真用 TCA 的工程師，這種「踩坑後的最佳實踐」正是我需要的。不只講怎麼做，還解釋為什麼這樣切、怎麼避免 compiler error 混在一起。`：[TCA 模組化這篇文章](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/)，確實是我的得意之作，而它有正確地挑出來，且擺在第一位 - `iOS 開發 AI 輔助工具 #0-#11：從「你信任 AI 嗎」到實際工作流程，這個系列把 AI 工具從哲學層面到實作都涵蓋了。`：這段文字顯示它有正確理解我的文章主題。我確實不只想談工具與技巧，也寫了不少思考層面的內容 - `🗾 你應該要安排休假：這篇寫得太好了。從無限假制度的實際管理經驗出發，談「安排休假本身就是生產力」，還有「帶頭請假」的領導技巧。這是資深 team lead 才寫得出來的內容。`：[休假這篇文章](https://ethanhuang13.plus/why-taking-vacation-shows-strength/)確實是我在帶 team 的重要理念與實踐。有被它正確挑出來 - 有說到付費理由、願意付多少錢 - `iOS Developer+ / 13+ 給的是「經驗 + 工具使用知識 + 職涯建議」的組合`：這句話顯示出它有理解「iOS Developer+ 改名 13+」的事實 - `完全新手：會訂但選擇性閱讀，先看補完計畫系列`：這說明了它正確理解補完計畫是給新手的 - `會訂閱：9/10`、`會推薦給同事：10/10`：用給分來評價會訂閱、會推薦。並且說明扣分的理由（`唯一讓我扣 1 分的是：希望有更多程式碼範例。`） 簡而言之，我認為 Claude Code 有準確抓到 13+ 專欄的核心精神、幾篇我個人特別喜愛的文章，而且有讀到一些細節，令我感覺是位資深讀者。 接下來，分享我怎麼使用 Claude Code 雲端版來閱讀整個 13+ 專欄。 ## 使用方式 _This post is for paying subscribers only._ ### 💡我的 Xcode 推薦設定 URL: https://ethanhuang13.plus/xcode-recommend-settings/ Last updated: 2026-08-13T06:06:41.000Z 最近因為在不同的 Mac 上重新設定開發環境，而且教學工作上也會用到，所以整理了一下我會修改的 Xcode 設定。 另外，本文也會教你怎麼在 Xcode 26 把「隱藏 Navigator」的快速鍵改回來，請別錯過。 ## Code Folding Ribbon 這個功能很實用，方便閱讀程式碼時，暫時藏起大段程式碼。程式碼如果用 `{}` 包起來的範圍，可以摺疊或展開。 從 Xcode 設定視窗 > Editing > Display > Code folding ribbon： ![Code folding ribbon 設定](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-05-at-01.37.01@2x.png) Code folding ribbon 設定 打開後，可以看到 Ribbon 的位置就在行數旁邊。 ![Code folding ribbon](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-05-at-01.39.00@2x.png) Code folding ribbon ## 縮排設定 由於 SwiftUI 常常會有很多層的縮排，我習慣把縮排從預設的 4 個空格改成 2 個空格。 可以從 Xcode 的設定 > Editing > Indentation 修改： ![Indent width 設定](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-05-at-01.42.48@2x.png) Indent width 設定 不過我主要會用 `.swift-format` 檔來依照專案指定。請參考[這篇文章](https://ethanhuang13.plus/swift-format-for-team-consistency/)。 ## 關閉 Predictive Code Completion Apple 的 AI 自動完成功能，雖然已經推出一年多，我仍覺得實用性不足。所以一律關閉，還能節省資源。 _This post is for paying subscribers only._ ### 📐善用 Xcode 內建的 swift-format 減少團隊溝通成本 URL: https://ethanhuang13.plus/swift-format-for-team-consistency/ Last updated: 2026-08-13T06:06:40.000Z 程式碼的格式是工程師最不該花時間手動調整的事情。比如說縮排要多少、某處多了空格、這邊該不該換行。**應該指定好規則，交給電腦自動完成。** 針對 Swift 專案，我以前愛用的是 [Nick Lockwood 的 SwiftFormat](https://github.com/nicklockwood/SwiftFormat?ref=ethanhuang13.plus)，並且在 2020 年寫過一篇[推坑文](https://ethanhuang13.notion.site/SwiftFormat-Xcode-8ff6da6724e840649ee59ca501041d74?ref=ethanhuang13.plus)。 後來，Apple 官方推出了 [swift-format](https://github.com/swiftlang/swift-format?ref=ethanhuang13.plus)（名稱很像，只差個 `-`，別搞錯了）。一開始是作為一個外部工具，用指令呼叫。 Xcode 一直到 16.0 才開始內建 `swift-format`。能夠自動套用格式到當前檔案，快速鍵是 `Ctrl + Shift + I`。 ## 使用 swift format 指令 在 `swift-format` 還沒整合進 Xcode 以前，我們可以透過 homebrew 來安裝： ```bash brew install swift-format ``` 並且透過 `swift-format` 指令來使用。 例如，以下指令會把當前目錄與子目錄的所有 Swift 檔都套用格式： ```bash swift-format . -i -r ``` 提醒：第一次執行可能會產生大量的變更，最好先在乾淨的 git 狀態進行。 而在 Xcode 16 以後，我們可以用 `swift format` 指令，注意不需要 `-`。 _This post is for paying subscribers only._ ### 🐺iOS 開發補完計畫 #5 Swift Macros 信任警告與警報疲勞 URL: https://ethanhuang13.plus/swift-macros-skip-validation-fatigue/ Last updated: 2026-03-02T05:37:35.000Z 每每去教初學者 iOS 開發，我就會發現自己的專家盲點。 最近一次是這樣：我用了 [SwiftUI-TCA-Template](https://github.com/ethanhuang13/SwiftUI-TCA-Template?ref=ethanhuang13.plus) 作為示範專案的模版。這個專案有依賴 TCA 等套件，會使用到 Swift Macros 這個功能。而因為 Macros 有機會在電腦執行一些開發者可能沒有意識到的程式操作，有一定程度的安全風險，預設會被當成錯誤擋下來，**需要手動確認**。 由於習慣了，每次遇到這種情況，我都會快速把確認步驟操作完，或是早就設定好一律跳過 Macros 確認。但對於初學者來說，可能會一頭霧水。 以下說明如何在 Xcode 進行同意 Swift Macros 的步驟。 ## Swift Macros 確認警告 第一次編譯或更新套件時，在 Xcode 的 Issue Navigator 會看到需要確認的警告，例如： ![使用 Swift Macros 的套件有更新，所以 Xcode 以錯誤提示阻止專案編譯，需要開發者手動確認](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-02-at-22.46.11@2x.png) 使用 Swift Macros 的套件有更新，所以 Xcode 以錯誤提示阻止專案編譯，需要開發者手動確認 按下去錯誤項目以後，會看到提示： ![確認要信任與啟用 Macros 的對話框](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/11/CleanShot-2025-11-02-at-22.45.53@2x.png) 確認要信任與啟用 Macros 的對話框 請確認該 Macros 是你信任的（比如來自你信任的開發者），然後按下「Trust & Enable」。 這樣子就把「錯誤」給解決了，之後應該可以正常編譯。 ## 如何自動跳過 這種認證雖然有其必要，但是多次重複遇到以後，會覺得十分煩人。因為如果每次套件有升版就需要再確認一次、不同電腦也要個別再確認一次。 有經驗的開發者，會知道在 Mac 上用一行指令一勞永逸關掉它的方式： ```bash defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES ``` ## CI 設定 比較嚴謹的團隊，在協作開發時會用到 CI 來跑測試。而上述指令，在自行架設的 Mac CI Server 上也很常用。不然有用到 Swift Macros 的專案就會無法編譯。 另一種方式則是在使用 `xcodebuild` 指令時，加上 `-skipMacroValidation` 參數。該參數的官方說明： > Skip validation of macros (this can be a security risk if they are not from trusted sources) 最後，如果你使用 Xcode Cloud，那麼跳過 Swift Macros 驗證的方式比較特別。要在專案目錄新增一個 `ci_scripts` 資料夾，裡面放入一個 script 檔 `ci_post_clone.sh`，檔案內容就是那一行： ```bash defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES ``` ## 結語 我覺得 Swift Macros 這種安全確認的機制還有改進空間。因為開發者到後來會傾向無腦地按下信任，甚至直接用指令的方式總是跳過，就等於沒有確認的保護效果。也就是[警報疲勞](https://zh.wikipedia.org/wiki/%E8%AD%A6%E6%8A%A5%E7%96%B2%E5%8A%B3?ref=ethanhuang13.plus)（類似於「[狼來了效應](https://zh.wikipedia.org/zh-tw/%E7%8B%BC%E4%BE%86%E4%BA%86?ref=ethanhuang13.plus)」）導致了安全性的下降。 以我自己來說，每台新 Mac 在安裝設定時，就會把這行指令給輸入、一律跳過。以至於在準備課程教材時，就忘了學生第一次會遇到需要確認的障礙。 **開發者還是有責任去了解自己所使用的套件、Swift Macros 的來源，學會掌控風險。** 不過我希望 Apple 能把「這個新版本 Macros 已經被確認過」的事實記錄下來，甚至加入版本控制。換言之，**以專案為單位來信任，而不是以個別電腦為單位來信任**。應該能減少開發團隊的麻煩，而且能提升確認的實質保護效果。 ### 🗓️2025 年 10 月主題回顧 URL: https://ethanhuang13.plus/monthly-review-2025-10/ Last updated: 2025-12-20T05:31:36.000Z ## 13 的話 [又到了月底](https://ethanhuang13.plus/monthly-review-2025-09-usage-guide/)總結與回顧的時候了。這個月我寫了 22 篇文章，保持每週一到週五各一篇的節奏。 已經連續更新超過 11 週。我寫文章的速度有變快。不過，有沒有寫得越來越好呢？留給讀者評價。 還是那句話：**文章雖多，但是不需要有全盤吸收的壓力。一個月下來有抓到幾個重點，就值回票價了。**以下是這個月的主題整理，挑有興趣的部分進行回顧。 ## 本月主題 1：13 喜愛的事物 這幾篇文章是我私心最愛，因為是寫自己喜歡的東西。 - 2025-10-10: [🐜推坑《空洞騎士》與《絲之歌》的三個理由](https://ethanhuang13.plus/mac-gaming-hollow-knight-silksong/) - 2025-10-21: [🧱減少開發者職業傷害，請買手機架](https://ethanhuang13.plus/reduce-developer-pain-with-phone-stand/) - 2025-10-22: [🖥️打造屬於自己的工作桌面](https://ethanhuang13.plus/build-your-own-workspace/) - 2025-10-24: [💻我夢想中的 MacBook](https://ethanhuang13.plus/my-dream-macbook/) ## 本月主題 2：旅行靈感與軟體開發哲學 月底休假旅遊時一邊寫作，思考的角度較平時來得深。我其實還滿喜歡這種標題沒有那麼一目瞭然的設定。 - 2025-10-27: [🗾遲來的休假](https://ethanhuang13.plus/never-late-to-plan-vacation/) - 2025-10-28: [😴穩定的體驗](https://ethanhuang13.plus/stability-is-long-term-value/) - 2025-10-29: [🧪試錯](https://ethanhuang13.plus/trial-and-error/) - 2025-10-30: [🔦容錯](https://ethanhuang13.plus/room-for-error/) ## 本月主題 3：開發知識與技巧 這個月寫了不少開發知識技巧，我覺得每篇都很實用。 不過硬要排個高下的話，實用度最高的是 10/3 [同步設定](https://ethanhuang13.plus/sync-vscode-cursor-settings-symlink/)、10/8 [Preview 視窗](https://ethanhuang13.plus/swiftui-preview-window-management/)。10/16 的[冷門功能提醒](https://ethanhuang13.plus/unused-paid-features-you-already-have/)也不錯。 - 2025-10-03: [🔄不靠套件，輕鬆跨裝置同步 Cursor 與 VS Code 設定](https://ethanhuang13.plus/sync-vscode-cursor-settings-symlink/) - 2025-10-06: [🤖如果這篇文章的讀者是 AI……](https://ethanhuang13.plus/when-reader-is-ai/) - 2025-10-07: [💡小知識：Apple 裝置 UDID 拼湊規則](https://ethanhuang13.plus/apple-device-udid-chip-ecid/) - 2025-10-08: [🪟管理 SwiftUI Preview 視窗的超實用技巧](https://ethanhuang13.plus/swiftui-preview-window-management/) - 2025-10-09: [🕳️Xcode 開啟資料夾會開成什麼？教學現場踩到的開發坑](https://ethanhuang13.plus/xcode-open-folder-pitfall/) - 2025-10-13: [⚠️iOS 開發補完計畫：開啟支援 iPad 只有一次機會（免費公開）](https://ethanhuang13.plus/ios-missing-manual-ipad-support-rule/) - 2025-10-16: [💸一些你已經付了錢，卻沒用到的功能](https://ethanhuang13.plus/unused-paid-features-you-already-have/) ## 本月主題 4：用 SwiftUI 畫 Mac mini 學習 SwiftUI 排版時，我推薦拿來畫物體，而不要急著切入系統元件、狀態管理。 其實我本來沒有打算寫成一個系列，但是第一篇的反應不錯，就一路開展。 - 2025-10-14: [💻學習 SwiftUI：為什麼從畫 Mac 開始？](https://ethanhuang13.plus/learning-swiftui-mac-layout-practice/) - 2025-10-15: [🖥️練習用 SwiftUI 畫 Mac mini：從俯視角開始](https://ethanhuang13.plus/learning-swiftui-macmini-top-view/) - 2025-10-17: [🖥️練習用 SwiftUI 畫 Mac mini：正面](https://ethanhuang13.plus/learning-swiftui-macmini-front-view/) - 2025-10-20: [🖥️練習用 SwiftUI 畫 Mac mini：底部](https://ethanhuang13.plus/learning-swiftui-macmini-bottom-view/) - 2025-10-23: [🖥️練習用 SwiftUI 畫 Mac mini：總結篇](https://ethanhuang13.plus/learning-swiftui-macmini-summary/) ## 其他總結文章 10/1 這篇[求知策略](https://ethanhuang13.plus/iphone-usb-speed-series-conclusion/)，算是上個月重要主題的完結篇，也很值得複習。 - 2025-10-01: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：求知策略與總結](https://ethanhuang13.plus/iphone-usb-speed-series-conclusion/) - 2025-10-02: [🤖用得更省、用得更巧──我的 AI 工具使用現況（2025 年 9 月）](https://ethanhuang13.plus/my-ai-tools-usage-202509/) ## 結語 歡迎讀者跟我分享你最喜歡或覺得很實用的文章，多多回饋能讓我的寫作更有動力。 ### 🔦容錯 URL: https://ethanhuang13.plus/room-for-error/ Last updated: 2026-08-13T06:06:39.000Z [試錯](https://ethanhuang13.plus/trial-and-error/)，講的是勇於嘗試。容錯，講的則是為錯誤留出空間。 人們懂得為旅行的安全與順暢，多準備一些東西，例如：保險、備用現金、多張信用卡等等。這些措施都是用一點代價，換來對意外的抗性。 那麼，身為軟體工程師，我們是否有為了確保工作流程的順利而多做準備呢？ 網路中斷或是停電時，還能不能繼續工作？當新版 iOS 推出時，有沒有額外的設備可以用來測試，還是要冒著風險把自己的手機升級到 Beta 版？ 我們的軟體生意，有依賴於少數幾個關鍵服務嗎？如果它們掛掉或是[停止支援](https://ethanhuang13.plus/developer-injuries-dependency-stories/)，這門生意還能正常運作嗎？ 上述這些情況是我們應該要考慮的。工作流程或是生意運作，若有不在自己控制範圍的依賴，就應該要做點準備。 ## 網路與電力 網路的穩定對於電腦工作者，尤其是軟體開發者，是關鍵。所以，我個人的工作桌主要使用有線網路，其次才是 Wi-Fi。即使是在家裡客廳用電腦，我也備有網路線加 USB-C 網卡，需要穩定傳輸時，隨時可以接上。 在「停電時維持電腦能運作」這件事上，我不像一些人會在家中準備發電機或是大型儲電設備。但是我至少不會把 Mac 的桌機安排成主力工作設備，而總是會選擇筆電。原因很簡單：筆電內建電池，在缺乏外部電源的情況下，至少可以撐上一段工作時間。 ## 應對 Apple Bugs 的策略 這畢竟是個 iOS 開發者為背景與主要讀者群的專欄，所以我特別提一下針對 Apple，我們能做的準備。 Apple 提供了系統、語言、開發工具，以及許多框架和 API，讓我們得以在其上開發各種應用程式。我們十分依賴 Apple 提供的東西的穩定。 若你有幾年的開發經驗，就會知道不能完全相信 Apple。我們應該要建立一些防範措施，以免受傷。 我歸納出了自己對 Apple 採取的容錯策略： _This post is for paying subscribers only._ ### 🧪試錯 URL: https://ethanhuang13.plus/trial-and-error/ Last updated: 2026-08-13T06:06:38.000Z 不管你是學生，還是剛開始接觸程式語言，有個觀念比任何程式語法都優先。 我喜歡透過嘗試來尋找答案，不怕犯錯，甚至樂於把踩坑經驗與人分享。但是我發現，**許多人在面對未知時，習慣追求標準答案與權威解釋，而不是靠自行嘗試來求知。** 我不確定這種習慣是來自求學時代的訓練，或者成長環境較缺乏試錯的餘裕？總之，若不懂得嘗試不同解法，在軟體開發這一行會很吃虧。 ## 寫程式沒有標準答案 在軟體的世界裡，一個問題的解決方式往往有無數種。沒有最佳解，而是依照情況取捨： _This post is for paying subscribers only._ ### 😴穩定的體驗 URL: https://ethanhuang13.plus/stability-is-long-term-value/ Last updated: 2026-08-13T06:06:37.000Z 最近，我在日本旅遊的住宿安排，開始以某知名連鎖品牌為主。 這間飯店的一大特色是提供非常穩定的體驗，幾乎可以說是無聊的程度。從設備、房間格局、裝潢、早餐供應、自動化的報到與退房手續，甚至連地點靠近車站的距離，都非常統一。 我住過近 10 間。地點包括關東、中部、關西、九州，都能獲得一致的體驗。每次打開房門，就好像回到一個熟悉的「家」。 對一些人來說，旅遊時選擇特別的飯店，是體驗的一環。但是我在日本旅遊的時候，通常都會在不同地點之間移動。如果來到一個陌生地點，有完全熟悉且可預期的住宿體驗，會令人安心不少。 更重要的是，這樣一致的體驗，能夠有效**降低認知負荷**，讓休息更徹底。 你想，房間的燈光、空調跟床的硬度都做到全國一致，對於疲憊的旅客來說不就是安心的保證嗎？ 要仔細看，才會發現以下三張照片其實不是同個房間： _This post is for paying subscribers only._ ### 🗾遲來的休假 URL: https://ethanhuang13.plus/never-late-to-plan-vacation/ Last updated: 2026-08-13T06:06:36.000Z 如果你問我「軟體開發工作者維持心理健康的首要建議」，我的答案會是：**學會安排休假**。 13+ 的資深讀者也許有印象，我寫過一篇[🗾你應該要安排休假](https://ethanhuang13.plus/why-taking-vacation-shows-strength/)，強調休假對於調整步調的重要性。 對我來說，**提早安排休假，等於給自己設定一個健康的「死線」**。時間一旦確立，就能安排尚未完成的工作，分配到剩餘的天數。也能自然地開始清理雜事，是個對抗拖延症的好方法。 ## 旅行寫作實驗 _This post is for paying subscribers only._ ### 💻我夢想中的 MacBook URL: https://ethanhuang13.plus/my-dream-macbook/ Last updated: 2026-03-02T09:50:37.000Z Apple 在 [2015 年](https://support.apple.com/zh-tw/112442?ref=ethanhuang13.plus)推出過一款 12 吋螢幕的 MacBook，重量只有 920 克、厚度 0.35-1.31 公分。採用 Intel Core M 系列處理器，效能不強，價格卻比 MacBook Air 高出一大截，但那種輕薄真是夢幻。 ![12 吋 MacBook 正面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-24-at-00.25.04@2x.png) 12 吋 MacBook 正面 ![12 吋 MacBook 側面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-24-at-00.25.18@2x.png) 12 吋 MacBook 側面 這款 MacBook 到 [2017 年](https://support.apple.com/zh-tw/111986?ref=ethanhuang13.plus)就停產，又貴、效能也不適合拿來做軟體開發。我當時沒有閒錢，不然應該會買來收藏，可惜錯過了它的年代。 ## Apple Silicon 的驚人效能 時間快轉到 2020 年，Apple 突然[宣布 Mac 要從 Intel CPU 遷移至自家設計的 M 系列晶片](https://www.apple.com/tw/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/?ref=ethanhuang13.plus)。出於好奇，我申購了開發機 [DTK](https://zh.wikipedia.org/zh-tw/Developer%5FTransition%5FKit?ref=ethanhuang13.plus)。外觀是 Mac mini，但是採用 iPad Pro 上的 A12Z 晶片。安裝了 macOS，用起來非常流暢，讓我印象深刻。 後來 [MacBook Air M1](https://support.apple.com/zh-tw/111883?ref=ethanhuang13.plus) 正式推出，我就買了一台、DTK 也換購 Mac mini M1。 當時，我在公司使用的是頂規 MacBook Pro Intel Core i9，也就是那個動不動就發熱到風扇「起飛」的款式。而最低階的 Apple Silicon M1 ，在編譯 Xcode 專案的速度卻幾乎不輸給前者，卻非常冷靜。**真的是沒有比較就沒有傷害**。 從此，我就成了 Apple Silicon Mac 的愛好者。 後來換了公司，分配給我 MacBook Pro M1 與 iPad mini M1。**一時之間，家裡有 4 台不同的 M1 設備，真是頗妙的**。 M1 實在是非常優秀的 SoC，效能即使到現在對於許多輕度工作的 Mac 使用者都十分夠用。 ## Apple Silicon 的優秀節能 除了效能，M1 也非常節能，一改人們對於 MacBook 續航力不足的印象。 很久以前，我曾經迷上「用 iPad 作為主要電腦」的概念。最主要原因就是 iPad 的續航力遠比 MacBook Pro充足。但是這個優勢在 Mac 改用 Apple Silicon 以後就完全顛倒了。常常是**我本人都工作到沒電了、MBA M1 還游刃有餘**。 看到 M1 這種表現，我不禁想到，如果 Apple 把當年 MacBook 12 吋的機身，塞進 M1 會怎麼樣呢？畢竟 MacBook Air M1 沿用了之前的 Intel 機殼，雖然外型經典，但是 SoC 放進更小機殼應該也會有很好的表現。 不過後來 MBA M2 的全新設計，改成比較扁平的外觀，一直用到目前最新的 M4。 ## 謠傳 Apple 將推出採用 A 系列 SoC 的 MacBook 再把時間快轉到今年 6 月底，分析師[郭明錤 (Ming-Chi Kuo) 表示](https://x.com/mingchikuo/status/1939558413459177897?ref=ethanhuang13.plus)：Apple 正在準備生產以 A18 Pro 處理器的低價版 MacBook。 A18 Pro 是用在 iPhone 16 Pro 系列的 SoC，有 2 個效能核心、4 個節能核心。這樣的效能拿來跑 macOS 夠嗎？如果從 Geekbench 的分數，**A18 Pro 的多核心效能已經超越 M1**、單核心效能在 M5 出來之前也是頂尖水準。 Apple 要推出這樣一款 MacBook 的理由並不難懂。即便到了 2025 年，MacBook Air M1 對於許多人來說也是一台很夠用的 Mac，適合入門 macOS。在 Amazon 上二手價格在 400 美金以內，也有少數機會買得到便宜的新品。這樣的市場，與其讓二手流通，不如 Apple 自己把價格帶往下延伸。 採用 A 系列處理器的 Mac，雖然不適合拿來做軟體開發、本地 AI、影音剪輯、遊戲等工作，但是優秀的單核心效能會帶來很好的網頁應用體驗，也可以說是大部分人日常的電腦使用場景。 定價有多便宜？什麼時候會推出？我更想知道的是：**會有多重？續航力有多好？** 也許 Apple 會因為成本考量，沿用現在 MacBook Air 的機殼，再縮減一些元件、電池容量。畢竟這台 MacBook 的用意就是要讓 Mac 接觸到更低價的市場，節省研發成本就能確保更多的利潤。 我們可以合理猜測，在效能有 M1 水準的情況下，這台 MacBook 可以做到更節能。要達到相同續航力標準，所需的電池容量可以更低，所以理論上能比 MacBook Air 更輕。 ## 我為什麼想要這樣一台 MacBook？ 我為什麼對這台傳聞中的 MacBook 這麼有興趣呢？因為現在的「工作」有一大部分是寫作，也就是用來寫你讀到的[這些文章](https://ethanhuang13.plus/)。 我現在的主力設備是 14 吋 的 MacBook Pro M3 Max，效能十分優秀，足以應付我所有的開發工作，甚至本地 AI 的需求。但是另一方面，它的重量有 1.62 公斤，不能算是一台可以輕鬆背出門的電腦。並且 Max 晶片有比較多的運算單元、低負載時的功耗較高，導致續航力較差、鍵盤也常溫溫的，對於寫文章來說，反而不是最理想的設備。 ![帶著電腦出門寫作](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/IMG_7585.jpeg) 帶著電腦出門寫作 MacBook Air M2-M4 的重量是 1.24 公斤。而如果 Apple 推出了 A 系列處理器的低價版 MacBook，重量應該會更輕，非常適合帶出門寫文章用。就算久久沒充電，臨時用手機的行動電源也能輕鬆補充續航力。能夠大幅降低物理與心理負擔。 還有一種情況，就是我在出國旅遊時，無可避免地要帶著筆電，處理一些瑣事。但是每天用到的時間很少，**效能與重量實在是多出太多了**。假如新 MacBook 的重量能壓低到 1 公斤左右，省下的重量我都可以多背一台 Switch 2 了。 至於 iPad，我試過 iPad mini 加 Magic Keyboard。雖然這套組合的重量很輕，但是我還是需要 macOS 的操作效率。iPadOS 無法成為我理想的寫作平台。 ![實驗：搭火車時用 iPad mini + Magic Keyboard 寫作](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/IMG_7827.jpeg) 實驗：搭火車時用 iPad mini + Magic Keyboard 寫作 ## 結語 說起來，Apple 好像只要把「現成的 MacBook Air 機殼」跟「現成的 iPhone 處理器」拼在一起，就可以變出一台優秀的新電腦，感覺太容易了。但是這背後其實累積了太多條件：Apple 決定自行研發晶片、TSMC 優秀的製程、iPhone 的成功、Apple 垂直整合與水平方向的技術沿用...... 至少當年的 12 吋 MacBook 就做不到。 我下週會出國休假幾天，會大量在戶外移動。用不到 MBP 的完整效能，更想要盡可能輕便。所以打算借用家人的 MacBook Air M2 作為寫作設備，能省下將近 400 公克。 如果 Apple 推出低價版 MacBook，我應該還是會買，就看重量能輕到什麼程度了。畢竟，出門在外寫寫文章，A 系列處理器的 Mac 不但效能夠用，續航力給人的放心。我也很好奇，在搭配雲端 AI 工具的情況下，是否甚至一些輕度開發工作都能用這麼入門的 MacBook 勝任呢？ **希望 Apple 再給我一次 M1 般的奇蹟感受。** ### 🖥️練習用 SwiftUI 畫 Mac mini：總結篇 URL: https://ethanhuang13.plus/learning-swiftui-macmini-summary/ Last updated: 2026-08-13T06:06:35.000Z 系列已經到了尾聲，我們來做兩件事情： 1. 把 Mac mini 的三面放在一個畫面當中切換 2. 加上電源開關與狀態顯示效果 本文的程式碼概念並不複雜，可以學到 enum、`CaseIterable`、extension、Swift Observation 的基本使用方式。資深開發者可以輕鬆看完，而如果你是初學者，把每一行都讀懂會對熟悉 SwiftUI 很有幫助（不妨貼給 AI 解釋）。 ## 集中顯示與切換 讓我們新增一個 `MacminiM4View`，來放三種角度的畫面。並新增 Picker 切換視角。 把三個視角建立成一個 enum，並且使用 extension 延伸出每個視角的顯示文字： ```swift enum ViewPoint: CaseIterable { case top case side case bottom } extension ViewPoint { // 延伸出 title。不同的視角就顯示不同的文字 var title: String { switch self { case .top: "Top" case .side: "Side" case .bottom: "Bottom" } } } ``` 請注意，這個 enum 有標上 `CaseIterable`，能夠自動產生所有 cases 的集合。用途我們很快就會看到。 核心概念如下： _This post is for paying subscribers only._ ### 🖥️打造屬於自己的工作桌面 URL: https://ethanhuang13.plus/build-your-own-workspace/ Last updated: 2026-08-13T06:06:34.000Z [昨天](https://ethanhuang13.plus/reduce-developer-pain-with-phone-stand/)因為推薦了在工作桌擺放手機架，想起了在 [weak self podcast](https://weakself.dev/?ref=ethanhuang13.plus) 的 Discord 伺服器，有個 `#battle-station` 頻道，許多開發者朋友在上面分享自己的工作桌。 ![weak self 是個 iOS 工程師自己買了東西之後勸敗的節目，開設的 Discord 自然也少不了一些勸敗的頻道。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-22-at-05.33.04@2x.png) weak self 是個 iOS 工程師自己買了東西之後[勸敗的節目](https://weakself.substack.com/)，開設的 Discord 自然也少不了一些勸敗的頻道。 於是，我去翻了一下自己以前分享過的工作環境，發現好久沒更新了。把舊照片貼過來，也給自己一個整理桌面的機會。 ## 版本演進 最早一次發文是在 2022 年 4 月。那個時候已經有升降桌、大螢幕、麥克風、HomePod 等。 _This post is for paying subscribers only._ ### 🧱減少開發者職業傷害，請買手機架 URL: https://ethanhuang13.plus/reduce-developer-pain-with-phone-stand/ Last updated: 2026-08-13T06:06:33.000Z 我買 iPhone 時，通常都是買最大螢幕的版本，方便看內容、電池續航力也最好。但是相對的就會是最重的型號。 手機重量太重，對於開發者的一項重大傷害，就是在實機開發時，每次從 Xcode 把 App 跑到 iPhone 上，要把手機從桌上拿起來操作，確認 App 的修改情況。反覆這個動作，對手腕的負擔不小。 印象很深刻，iPhone 14 Pro Max 讓我用到手會痛，所以 15 Pro Max 推出時，一看到重量規格明顯下降，立刻就換機。 ## 盤點每年最重的 iPhone 最重有多重 我們來看一下名稱有 Max 的所有 iPhone，也就是每一代最重的 iPhone： - [iPhone XS Max](https://support.apple.com/zh-tw/111880?ref=ethanhuang13.plus): 208g - [iPhone 11 Pro Max](https://support.apple.com/zh-tw/111878?ref=ethanhuang13.plus): 226g (+18g) - [iPhone 12 Pro Max](https://support.apple.com/zh-tw/111874?ref=ethanhuang13.plus): 226g (+0g) - [iPhone 13 Pro Max](https://support.apple.com/zh-tw/111870?ref=ethanhuang13.plus): 238g (+12g) - [iPhone 14 Pro Max](https://support.apple.com/zh-tw/111846?ref=ethanhuang13.plus): 240g (+2g) 史上最重 - [iPhone 15 Pro Max](https://support.apple.com/zh-tw/111828?ref=ethanhuang13.plus): 221g (-19g) 史上最輕 - [iPhone 16 Pro Max](https://support.apple.com/zh-tw/121032?ref=ethanhuang13.plus): 227g (+8g) - [iPhone 17 Pro Max](https://www.apple.com/tw/iphone-17-pro/specs/?ref=ethanhuang13.plus): 230g (+3g) iPhone XS Max 是史上第一個有 Max 名稱的 iPhone，螢幕是 6.5 英寸。隔年的 iPhone 11 Pro Max 則是首次出現三個後鏡頭的 iPhone，所以重量增加不少。 被我嫌重的 14 Pro Max 果然是史上最重，而換成鈦金屬外殼的 15 Pro Max 則是史上最輕，瘦身成功。 目前最新的 17 Pro Max，採用更輕的鋁合金外殼，剛好介於這兩者的平均值，不算太糟。 ## 手機太重的對策 手機太重又要實機開發，有許多對策。使用 Mac 上的「[iPhone 鏡像輸出](https://support.apple.com/zh-tw/120421?ref=ethanhuang13.plus)」App 是一個方式，但並非萬能。比如：無法實測觸控範圍、無法使用鏡頭或 Face ID，而且一次只能綁定一台 iPhone。 有些開發者習慣在模擬器或 Preview 上開發，這沒問題。但是你總是要在實機上測試操作是否順手、觸控範圍會不會太小。有些硬體功能也無法用模擬器取代。 所以，我個人在開發時還是習慣插線（效率部分的原因，之前寫過[一系列專題](https://ethanhuang13.plus/tag/iphone-usb-speed-series/)）。最好的辦法，就是買個手機架。這種東西不貴，又可以保持手腕的輕鬆，強烈推薦各位開發者為自己準備幾個。 我重視手機架到什麼程度呢？之前任職的公司，每個 iOS 工程師至少會有 2 支 iPhone。我當 Team Lead 時，就**幫整個團隊每人申請採購 2 個手機架**。 我家裡有 4 個手機架，因為工作位置不固定、而且非開發情境也很實用，例如在餐桌或客廳用手機。 ## 挑選手機架的建議事項 _This post is for paying subscribers only._ ### 🖥️練習用 SwiftUI 畫 Mac mini：底部 URL: https://ethanhuang13.plus/learning-swiftui-macmini-bottom-view/ Last updated: 2026-08-13T06:06:32.000Z 接續[前篇](https://ethanhuang13.plus/learning-swiftui-macmini-top-view/)，繼續畫 Mac mini M4 的底部。 [官網](https://support.apple.com/zh-tw/guide/mac-mini/apd4e7055d3cmm/mac?ref=ethanhuang13.plus)上的圖片是這樣： ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-20-at-01.17.31@2x.png) 這一面最大的挑戰，是要怎麼畫出一整圈的散熱孔，以及塑膠殼與金屬機殼的同心圓角。如果你知道方法的話，其實很簡單。但我**強烈建議你不要看答案，先自己想想看**。 這是我的實作與 Preview 截圖： ![MacminiM4BottomView 與 Preview](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-20-at-01.41.27@2x.png) MacminiM4BottomView 與 Preview 練習用的程式碼如下，完整版放在文章最後： ```swift import SwiftUI struct MacminiM4BottomView: View { private let bodyWidth = 512.0 var body: some View { chassis .aspectRatio(1, contentMode: .fit) .frame(width: bodyWidth) .foregroundStyle(Color(white: 0.7)) .overlay { plasticCover } .overlay { vents .frame(height: bodyWidth * 0.8) } .overlay { macMiniLogo } .overlay(alignment: .topTrailing) { powerButton } } private var chassis: RoundedRectangle { RoundedRectangle(cornerRadius: bodyWidth / 4) } @ViewBuilder private var plasticCover: some View { ContainerRelativeShape() .aspectRatio(1, contentMode: .fit) .foregroundStyle(Color(white: 0.2)) .padding(bodyWidth / 50) .containerShape(chassis) } @ViewBuilder private var vents: some View { ZStack { // 試著自行實作 } } @ViewBuilder private var macMiniLogo: some View { Text("Mac mini") .font(.system(size: bodyWidth / 12)) .fontWeight(.medium) .foregroundStyle(Color(white: 0.1)) } @ViewBuilder private var powerButton: some View { Button( action: {}, label: { Circle() .foregroundStyle(Color(white: 0.1)) .frame(width: bodyWidth / 12) .overlay { Image(systemName: "power") .foregroundStyle(Color.white) } .padding(bodyWidth / 9) } ) } } #Preview { MacminiM4BottomView() } ``` `macMiniLogo` 與 `powerButton` 相對簡單，我就不做說明了。 ## 塑膠殼與金屬機殼的同心圓角 金屬外殼 `chassis` 使用 `RoundedRectangle`。而它裡面一圈的則是黑色的塑膠殼。這部分的小挑戰是，怎樣畫出同心（concentric）的圓角？ 我們可以使用 `ContainerRelativeShape`，並且用 `.containerShape` 指定它的 container 形狀就等於是 `chassis` 這個 `RoundedRectangle`。這樣子我們就不用自行計算內圈的 cornerRadius 要減多少，直接達到同心的效果。 ## 怎麼畫一圈散熱孔 _This post is for paying subscribers only._ ### 🖥️練習用 SwiftUI 畫 Mac mini：正面 URL: https://ethanhuang13.plus/learning-swiftui-macmini-front-view/ Last updated: 2026-08-13T06:06:31.000Z 接續[前篇](https://ethanhuang13.plus/learning-swiftui-macmini-top-view/)，繼續畫 Mac mini M4 的正面。 這一面有幾個挑戰： 1. 機殼的光澤 2. 機殼上的插孔及電源燈 3. 底部的散熱孔 這是我的實作與 Preview 截圖： ![MacminiM4SideView 與 Preview](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-16-at-22.07.12@2x.png) MacminiM4SideView 與 Preview 程式碼如下： ```swift import SwiftUI struct MacminiM4SideView: View { private let bodyWidth = 512.0 private let bodyAspectRatio = 3.0 private var bodyHeight: Double { bodyWidth / bodyAspectRatio } var body: some View { VStack(spacing: 0) { chassis vent } } @ViewBuilder private var chassis: some View { Rectangle() .foregroundStyle( LinearGradient( stops: [ .init(color: Color(white: 0.7), location: 0.0), .init(color: Color(white: 0.9), location: 0.1), .init(color: Color(white: 0.9), location: 0.9), .init(color: Color(white: 0.7), location: 1.0), ], startPoint: .leading, endPoint: .trailing ) ) .aspectRatio(bodyAspectRatio, contentMode: .fit) .frame(width: bodyWidth) .overlay { HStack { Spacer() HStack(spacing: bodyWidth / 16) { usbCPort usbCPort } Spacer() Spacer() HStack(spacing: bodyWidth / 16) { powerIndicator audioPort } Spacer() } .offset(y: bodyHeight / 8) } } @ViewBuilder private var usbCPort: some View { Capsule() .aspectRatio(1 / 3.5, contentMode: .fit) .frame(height: bodyHeight / 5) } @ViewBuilder private var powerIndicator: some View { Circle() .foregroundStyle(Color(white: 1)) .frame(height: bodyHeight / 20) } @ViewBuilder private var audioPort: some View { Circle() .foregroundStyle(Color.black) .frame(height: bodyHeight / 10) } @ViewBuilder private var vent: some View { Rectangle() .frame(width: bodyWidth * 0.8, height: bodyHeight * 0.2) .rotation3DEffect(.degrees(-60), axis: (x: 1, y: 0, z: 0)) .offset(y: bodyHeight / -22) .foregroundStyle( LinearGradient( colors: Array( repeating: [Color.black, Color.black.opacity(0.8)], count: 32 ) .flatMap { $0 }, startPoint: .leading, endPoint: .trailing ) ) } } #Preview("Side View") { MacminiM4SideView() } ``` 我們一樣會用到[前一篇](https://ethanhuang13.plus/learning-swiftui-macmini-top-view/)提到的 `bodyWidth` 技巧，並且把 `bodyAspectRatio` 跟計算的 `bodyHeight` 也都寫出來了。方便有些元件要直接拿這些變數來用。 ## 機殼的光澤 _This post is for paying subscribers only._ ### 💸一些你已經付了錢，卻沒用到的功能 URL: https://ethanhuang13.plus/unused-paid-features-you-already-have/ Last updated: 2026-08-13T06:06:30.000Z 有有時在網路上看到人們在尋找特定功能，其實已經付過錢、能直接使用。這篇文章分享幾個我平時有在用的**付費服務的冷門功能**。 ## iCloud+ 的隱藏電子郵件功能 有些不熟悉的網站或服務跟你要 E-mail。不太信任它的情況下，你可能會想要使用一些免洗 E-mail 帳號的服務。 _This post is for paying subscribers only._ ### 🖥️練習用 SwiftUI 畫 Mac mini：從俯視角開始 URL: https://ethanhuang13.plus/learning-swiftui-macmini-top-view/ Last updated: 2026-08-13T06:06:29.000Z 前一篇文章[💻學習 SwiftUI：為什麼從畫 Mac 開始？](https://ethanhuang13.plus/learning-swiftui-mac-layout-practice/)的反應比預期熱烈。所以我決定延伸一下，分篇說明怎麼畫 Mac mini。 這是我的實作與 Preview 截圖： ![MacminiM4TopView 與 Preview](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-14-at-21.01.35@2x.png) MacminiM4TopView 與 Preview 程式碼如下： ```swift import SwiftUI struct MacminiM4TopView: View { private let bodyWidth = 512.0 var body: some View { RoundedRectangle(cornerRadius: bodyWidth / 4) .aspectRatio(1, contentMode: .fit) .foregroundStyle( LinearGradient( colors: [Color(white: 0.9), Color(white: 0.8)], startPoint: .topTrailing, endPoint: .bottomLeading ) ) .frame(width: bodyWidth) .overlay { Image(systemName: "apple.logo") .resizable() .aspectRatio(contentMode: .fit) .frame(width: bodyWidth / 3.5) .foregroundStyle(Color.black) } } } #Preview("Top View") { MacminiM4TopView() } ``` 以下說明實作重點。 _This post is for paying subscribers only._ ### 💻學習 SwiftUI：為什麼從畫 Mac 開始？ URL: https://ethanhuang13.plus/learning-swiftui-mac-layout-practice/ Last updated: 2026-08-13T06:06:28.000Z 我最近在教新手 **SwiftUI 排版**時，會用一個特別的教學方式：先畫一些 Apple 裝置的外觀，而不是直接就畫 App 的介面。 這個作法就是我身為新手時的練習策略： SwiftUI 剛推出時，我在找練習語法與排版規則的題目，突然低頭看到正在使用的 [MacBook Air M1 鍵盤](https://gist.github.com/ethanhuang13/8587d10689e3735354f975f6a25ef9fa?ref=ethanhuang13.plus)有點複雜但也滿有挑戰性，就在幾個小時內，用 300 行左右的程式碼完成了。 ![用 SwiftUI 畫的 MacBook Air M1 注音鍵盤](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-22.40.36@2x.png) 用 SwiftUI 畫的 MacBook Air M1 注音鍵盤 而最近，我則是讓學生畫 Mac mini M4。 ![Mac mini M4 上面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-22.46.23@2x.png) Mac mini M4 上面 ![Mac mini M4 正面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-22.46.27@2x.png) Mac mini M4 正面 ![Mac mini M4 底部](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-22.46.31@2x.png) Mac mini M4 底部 其實我畫得並不完美。遠看有模有樣，放大後破綻不少。但是沒關係，重點是過程非常好玩、畫完以後成就感十足。 ## 為什麼要畫 Mac？ 我的思路很單純：**用最單純有趣的方式學習排版規則**。 _This post is for paying subscribers only._ ### ⚠️iOS 開發補完計畫 #4 開啟支援 iPad 只有一次機會 URL: https://ethanhuang13.plus/ios-missing-manual-ipad-support-rule/ Last updated: 2026-03-02T05:37:22.000Z 很久沒有寫「[iOS 開發補完計畫了](https://ethanhuang13.plus/tag/ios-missing-manual/)」，這個系列的文章都會免費公開給所有讀者，特別適合新手，而且是 AI 工具大概不會告訴你的事情。 今天要分享的這個坑，甚至連一些[資深 iOS 工程師也不見得知道](https://x.com/tualatrix/status/1970860148903329844?s=46&ref=ethanhuang13.plus)，那就是：**一個 iOS app 如果有支援 iPad，一旦上架過 App Store，就不能改回只支援 iPhone。** ## Xcode 新專案預設支援 iPad 在 Xcode 新增 iOS 專案時，預設都會支援 iPad。如果沒有特別把它移除，那麼打包（Archive）後上傳到 App Store 送審時，系統以及審查人員就會認定：這個 app 是有做好 iPad 支援。 ![Xcode 專案：這個 iOS App 支援 iPad](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-21.23.42@2x.png) Xcode 專案：這個 iOS App 支援 iPad 有支援 iPad 的意思是，app 在 iPadOS 上執行時，是可以自由調整視窗大小的。如果不支援 iPad，app 會以 iPhone 介面呈現（如果開發者手邊沒有 iPad，可以使用模擬器看看效果）。 除此之外，我們必須提供給 App Store 頁面符合 iPad 尺寸與規範的截圖。審查人員也很有可能會使用 iPad 做審查。 所以，如果不打算支援，要在打包之前移除 iPad 的支援設定。 ## 已經上架的 iPad App 不能移除支援 [App Store 官方規則](https://developer.apple.com/library/archive/qa/qa1623/%5Findex.html?ref=ethanhuang13.plus)有說到： > ... does not allow uploading an updated version of an app when the update runs on fewer devices than the version of the app currently in the App Store. This is by design. 也就是說，App Store 上的新版 app，支援的裝置不能少於舊版的。從文件底部的日期 2010 年來看，這個規則應該是初代 iPad 推出當年就存在的。 ## macOS 與 visionOS 呢？ 有些讀者可能會問：那 iOS app 在 Xcode 一併勾選的 macOS 與 visionOS 的支援呢？這部分不會有問題，因為我們上傳的是 iOS App，macOS 與 visionOS 都是 Apple 以自動相容的方式支援。 以 iPlayground iOS App 為例，你可以在 Apple silicon Mac 與 Apple Vision Pro 上使用這個 App，但它們是自動相容的版本。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-21.47.29@2x.png) Apple silicon Mac 與 Apple Vision Pro 上的 iOS App 提供設定可以隨時調整 你甚至可以隨時關掉這個功能，它們就會立刻在 Mac 或 visionOS App Store 上消失，風險非常低。 如果要開發並上架完全原生的 Mac 或 visionOS app，而不是基於 iOS，其實要另外新增平台。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-12-at-21.46.01@2x.png) 原生 Mac 與 visionOS App 要另外新增 總之，我們只需要擔心是否要支援 iPadOS。 ## 結論 整理規則如下： - 支援 iPad 可以之後增加，但不能拿掉 - 不支援 iPad 的 App，在 iPad 上會以放大模式執行 - macOS / visionOS 的自動相容可自由開關 是否一併支援 iPad，在設計與工程方面的成本會差很多。 **重點提醒：開發者要想清楚是否要支援 iPad，而不是直接沿用 Xcode 新專案的預設選項。** 此外，我建議 **iOS 開發者儘早考慮從哪一版要開始支援 iPad**。不管是一開始就一併支援 iPad、後續增加，或是永不支援 iPad，在安排開發計畫時都會有不同的策略。這已經超過本文的範圍了，讀者若有興趣的話，有機會再談。 ## 延伸閱讀 - 官方文件：[Technical Q&A QA1623: Why am I getting device support errors when uploading my app?](https://developer.apple.com/library/archive/qa/qa1623/%5Findex.html?ref=ethanhuang13.plus) ### 🐜推坑《空洞騎士》與《絲之歌》的三個理由 URL: https://ethanhuang13.plus/mac-gaming-hollow-knight-silksong/ Last updated: 2026-08-13T06:06:27.000Z 《空洞騎士》是三人團隊 Team Cherry 的第一款作品，也是我最喜歡的遊戲。到什麼程度呢？我擁有全部平台的版本，而且我的 Steam 帳號頭像，就是《空洞騎士》中的小騎士。 時隔多年，續作《空洞騎士：絲之歌》終於推出，帶給玩家更盛大的挑戰。我也玩得很開心。雖然還沒玩完，但是趁著連假介紹一下可以用 Mac 玩的遊戲，剛好。 老實說，這兩款遊戲的難度都很高，講求高速操作、反應、學習，並且有反覆嘗試的挫折。我沒有玩得非常好，也**不輕易推薦給任何人**。 不過，我仍想推坑這兩款遊戲給讀者。不是因為「這個遊戲太讚了，必玩」，而是因為少見在 Mac 上有這麼優秀體驗的遊戲、藝術價值，以及創作態度。 ## Mac 上少有絕佳體驗的遊戲 《空洞騎士》與《絲之歌》都是由 Unity 開發的。支援各大遊戲平台，包括 Mac。動作遊戲最好是透過手把來操作，而兩款遊戲都有完整支援 Mac 上連接藍牙手把。 根據我的實測，《絲之歌》在最低階的 Apple silicon，也就是 Mac mini M1 上，能夠輕鬆跑出 4K、100 FPS 以上的效能。 ![《絲之歌》能在 M1 上跑出 4K、100+ FPS 的表現](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-07-at-02.47.25@2x.png) 《絲之歌》能在 M1 上跑出 4K、100+ FPS 的表現 動作類型的遊戲，通常要 60 FPS 才不會影響需要即時反應的操作。這兩部作品在 Mac 上可以輕鬆達到。 如果用 M1 的表現來推測的話，近幾年的 iPhone 要達到一樣的流暢應該是毫無問題，只可惜沒有 iOS 版。 _This post is for paying subscribers only._ ### 🕳️Xcode 開啟資料夾會開成什麼？教學現場踩到的開發坑 URL: https://ethanhuang13.plus/xcode-open-folder-pitfall/ Last updated: 2026-08-13T06:06:26.000Z 最近在學校教 iOS 開發新手。我請學生 clone 並打開指定的 Xcode 專案，並介紹設定 Build Settings、登入 Development Team 等常見操作。但是，等我講了快十分鐘，走下台看看大家操作的情況時，卻發現有幾位同學的 Xcode 視窗的檔案列表裡，找不到專案檔。 一番研究之後，我找到了問題。原來他們打開的是 Package，而不是專案。 我當下感到困惑，隱約知道是怎麼回事。回去檢討以後，覺得學到了寶貴的一課。 ## Xcode 能打開各種專案與檔案 Xcode 是個功能豐富的編輯器，能打開的檔案類型不少。 如果要開發一個 app，我們會去打開 Xcode Workspace（`.xcworkspace`） 或 Xcode Project（`.xcodeproj`）。 如果是開發 Swift Package，則是會打開 `Package.swift`，或是該 Package 所屬的資料夾。 那麼問題來了：假如一個資料夾，本身既是 Swift Package，裡面又有專案檔，那麼**叫 Xcode 打開資料夾，會發生什麼事情呢？** ## 試試看三種打開方式 比如說這個 [mlx-swift-examples](https://github.com/ml-explore/mlx-swift-examples?ref=ethanhuang13.plus) repo，有 Xcode project 跟 `Package.swift`： ![mlx-swift-examples 資料夾](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-08-at-17.49.58@2x.png) mlx-swift-examples 資料夾 叫 Xcode 打開某個資料夾，至少有三種方式： 第一種拖曳資料夾的方式，就不示範了。 第二種是從 Welcome 頁面，或 File 選單的 Open...，叫出檔案面板、選擇資料夾，並按下 Open。 ![Xcode 的 Welcome 頁面](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-08-at-17.53.49@2x.png) Xcode 的 Welcome 頁面 ![打開專案所在資料夾](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-08-at-17.58.05@2x.png) 打開專案所在資料夾 第三種 `xed` 指令，是 Xcode 的內建指令，可以用來開啟檔案或資料夾。如果你不知道的話，可以趁機學一下： 先 `cd` 到專案資料夾，再輸入 `xed .`，就會有等同於前兩種方式的效果。 你猜結果怎麼樣呢？ _This post is for paying subscribers only._ ### 🪟管理 SwiftUI Preview 視窗的超實用技巧 URL: https://ethanhuang13.plus/swiftui-preview-window-management/ Last updated: 2026-08-13T06:06:25.000Z 我常說：使用 SwiftUI，就應該要善加利用 Preview。尤其是，在[適當切分模組](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/)以後，Preview 的即時更新效果並不會太差。 但是，你有沒有遇過這些困擾？ 1. 切換檔案再切回來，Preview 要重新載入 2. 切換 Tab 再切回來，Preview 要重新載入 3. 想要同時看多個裝置的 Preview 今天我要告訴你一個非常實用的技巧，解決以上這些問題。 ## 先看效果 _This post is for paying subscribers only._ ### 💡小知識：Apple 裝置 UDID 拼湊規則 URL: https://ethanhuang13.plus/apple-device-udid-chip-ecid/ Last updated: 2026-08-13T06:06:23.000Z 今天來分享個我最近才學到的開發小知識。 你知道嗎？Apple 各裝置的 UDID，也就是顯示在 Xcode Devices and Simulators 視窗這個欄位的數值，其實是拼湊出來的。 ![Xcode Devices and Simulators 視窗上的 Identifier 資訊](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-02-at-15.59.40@2x.png) Xcode Devices and Simulators 視窗上的 Identifier 資訊 這是我在先前「[探究 iPhone 的 USB 速度對開發體驗的影響](https://ethanhuang13.plus/tag/iphone-usb-speed-series/)」的過程中學到的事情： Apple 的 `lockdownd` 與 `libMobileGestalt` library 都可以提供裝置的獨特 ID，也就是 UDID (Unique Device Identifier)。 前者需要 root 權限，應該是給系統內部使用。一般開發者有需要取得 UDID 的話，應該使用後者，透過 `UniqueDeviceID` key 即可。 ## UDID 是如何拼湊出來的？ _This post is for paying subscribers only._ ### 🤖如果這篇文章的讀者是 AI…… URL: https://ethanhuang13.plus/when-reader-is-ai/ Last updated: 2026-08-13T06:06:24.000Z 今天是假日，分享個輕鬆的小故事。 我的上一篇文章 [🔄不靠套件，輕鬆跨裝置同步 Cursor 與 VS Code 設定](https://ethanhuang13.plus/sync-vscode-cursor-settings-symlink/)是簡單實用的技巧分享，只需要幾分鐘的設定。 沒想到，在刊出以後，讀者 Harry Ng 跟我說，他把文章貼給 Claude Code，直接完成所有的設定步驟。 ![Harry 跟我說，他直接叫 Claude Code 讀我的文章，並照著設定](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-03-at-11.53.18@2x.png) Harry 跟我說，他直接叫 Claude Code 讀我的文章，並照著設定 甚至連合併 Cursor 與 VS Code 既有設定檔的內容、備份，都一併搞定。 ![Claude Code 完成我文章中的設定步驟](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/10/CleanShot-2025-10-03-at-08.40.09@2x.jpeg) Claude Code 完成我文章中的設定步驟 ## 會用 AI 工具的人就是會用 其實 AI Agent 能做到這些步驟很合理。因為這個技巧，完全是建立在檔案系統的解決方案，所有操作都可以靠指令完成。 但我沒想到有讀者會用「整篇丟給 AI 來操作」這種方法在「使用」13+ 的技巧教學文章。當下的第一個感受是：不愧是[建立了 AI Coding Club 的 Harry](https://www.threads.com/@harryworld/post/DHaACV8I0Gu/%E6%88%91%E6%AD%A3%E5%BC%8F%E5%AE%A3%E4%BD%88%E8%A6%81%E8%A8%AD%E7%AB%8B%E4%B8%80%E5%80%8B-ai-coding-club%E8%AE%93%E6%9C%89%E8%88%88%E8%B6%A3%E5%AD%B8%E7%BF%92%E7%B7%A8%E7%A8%8B%E4%BD%BF%E7%94%A8-ai-%E5%8D%94%E5%8A%A9%E6%88%96%E6%98%AF-vibe-coding-%E7%9A%84%E6%9C%8B%E5%8F%8B%E4%B8%80%E8%B5%B7%E4%BA%A4%E6%B5%81%E5%AD%B8%E7%BF%92%E5%88%86%E4%BA%AB%E6%9C%80%E6%96%B0%E7%9A%84%E5%AF%AB-app-%E6%8A%80%E5%B7%A7%E6%84%9F%E8%A6%BA?ref=ethanhuang13.plus)，會用 AI 工具的人就是會用。 ## 如果讀者是 AI…… _This post is for paying subscribers only._ ### 🔄不靠套件，輕鬆跨裝置同步 Cursor 與 VS Code 設定 URL: https://ethanhuang13.plus/sync-vscode-cursor-settings-symlink/ Last updated: 2026-08-13T06:06:22.000Z 在整理昨天的 [AI 工具使用現況文章](https://ethanhuang13.plus/my-ai-tools-usage-202509/)時，我發現還沒分享過怎樣共用 [Cursor](http://cursor.com/?ref=ethanhuang13.plus) 跟 [VS Code](https://code.visualstudio.com/?ref=ethanhuang13.plus) 設定。像是字體、快速鍵、Task 等常用設定，都可以在兩者之間無痛轉移，甚至可以跨設備同步。 為什麼要同步？AI 工具一直在變化。可能上個月在用 Cursor Pro，這個月改用的 VS Code + Copilot，下個月又顛倒過來。另一方面，VS Code 有內建設定的雲端同步，但是 Cursor 並沒有，如果你在多台 Mac 之間使用 Cursor，就會比較麻煩。 這篇把無痛轉移設定的技巧分享出來。作法非常簡單，幾分鐘就可以設定完畢。 ## 找到原始設定檔 由於 Cursor 是從 VS Code 分出來的，設定檔基本上相通。 把 VS Code 或是 Cursor 關閉以後，找到設定檔的資料夾： _This post is for paying subscribers only._ ### 🤖用得更省、用得更巧──我的 AI 工具使用現況（2025 年 9 月） URL: https://ethanhuang13.plus/my-ai-tools-usage-202509/ Last updated: 2026-08-13T06:06:21.000Z 這是我連續第三個月分享 AI 工具使用現況。9 月份我的軟體開發工作比較少，比較多教學與寫作的工作，所以較少使用 AI Coding 工具，不過對話型工具仍舊是日常生產力工具。 目前日常使用的 AI 工具有： - 對話型 AI 助理：ChatGPT、Claude - CLI AI Coding Agent：Claude Code - AI Coding IDE：Cursor - 語音輸入工具 ：Spokenly（免費） ## GPT-5 回到實用程度 [上個月](https://ethanhuang13.plus/my-ai-tools-usage-202508/)我說到新推出的 GPT-5 不是很好用，所以用 Claude app 取代 ChatGPT app。 但是，新模型上線一陣子以後，OpenAI 似乎把 GPT-5 模型選擇調好了（GPT-5 底下有一堆模型，依照需求自動切換）。現在 ChatGPT 對我來說又回到 4o 時代的實用程度。 總之，我重新訂閱了 ChatGPT Plus。 ## 從來回對話，轉變成修改第一則訊息 以前使用對話型 AI 時，我習慣在對話中來回討論。比如請 ChatGPT 幫我審稿文章，第一步先貼上整篇文章並要求審稿、我依照意見修改、把修改完的版本貼在後續對話中，重複這個步驟直到雙方都滿意。 但是現在，我更傾向回頭去編輯原始訊息，例如把修改好的文章取代第一則訊息中的舊版文章。好處顯而易見： _This post is for paying subscribers only._ ### ⚡️探究 iPhone 的 USB 速度對開發體驗的影響：求知策略與總結 URL: https://ethanhuang13.plus/iphone-usb-speed-series-conclusion/ Last updated: 2026-08-13T06:06:20.000Z 我們在[前言](https://ethanhuang13.plus/iphone-usb-speed-intro/)談到了 USB 速率與插線開發的問題，[第二篇](https://ethanhuang13.plus/iphone-usb-speed-measure-usb-and-network/)與[第三篇](https://ethanhuang13.plus/iphone-usb-speed-measurement-with-usbmuxd/)分別談到網路測速與 USB 測速的具體步驟與實測數據。[第四篇](https://ethanhuang13.plus/iphone-usb-speed-demo-devicesupport-debugging/)文章談到傳輸介面與速率對於常見開發操作的實際影響，甚至錄了影片示範。 [第五篇](https://ethanhuang13.plus/iphone-usb-ai-model-new-challenge/)文章中，我談到了在 iPhone 上運行 AI 模型的發展趨勢，包括我與 Mattt 針對 Hugging Face 的對話。發文當天晚上，Hugging Face 就推出了 Swift Transformers（請參考 [Apple 開發者週報 #248](https://www.ethanhuang13.com/i/174853228/swift-transformers?ref=ethanhuang13.plus)）。這些舉動都強化了我說開發者選購 iPhone 需要考慮高速傳輸機制的論點。 系列的最後一篇文章，我想談一下重要學習點，以及一些延伸思考。第一個想談的是：求知的策略。 ## 求知的策略 除了前面那些測試數據、測速軟體的操作、甚至實驗結論以外，我更希望讓讀者領略到的，是**面對有爭議或是缺乏共識的技術話題時，能夠提供其他人能夠重複操作實驗的方法步驟，作為討論基礎**。 人們在網路上提出看法，往往是基於自己的經驗與知識，這並沒有錯。但是如果能夠一併提供得到答案的步驟，以及自己的實驗數據，能夠讓更多人學到求知的方法，而不只是答案本身。 不但如此，我在寫這些文章的過程中，為了要教大家，所以就更深入地了解了 iperf、usbmuxd、Swift Transformers 等技術。**在分享時，收穫最多的永遠是自己**。 ## 乘數效應，以及花公司的錢 還有一件事情想說：個人開發者與企業工作效率的需求是不一樣的。因為公司的人多、自動化場景多，所以一個動作需要多花幾秒，很容易被放大。 個人開發時候，相較於要買一台新 iPhone Pro 的高昂成本，多等個幾秒在忍受範圍。但是，經營公司時，在設備上節省的成本，很容易就會浪費在軟體開發人力成本（時間）上。比如某個開發操作每次要多花 30 秒等待時間，乘上每人、每天重複的次數，累積起來就不得了了。 因此，如果我的角色是 iOS team lead 或是自己開公司雇用 iOS 工程師，會要求採購 15 Pro 以上機種作為開發機、購買 USB 3線材，並且要求同事們插上 USB 線來開發。 我認為**上班族工程師應該蒐集需求證據，來要求公司提供設備**。讓公司出錢來使自己工作更輕鬆，難道不是軟體工程師該掌握的生存之道嗎？有機會我會多談這類策略議題。 _This post is for paying subscribers only._ ### 🗓️13+ 使用指南與 2025 年 9 月主題回顧 URL: https://ethanhuang13.plus/monthly-review-2025-09-usage-guide/ Last updated: 2025-10-30T22:03:02.000Z 我打算在每個月底都提供一篇總結與回顧，目的是： 1. 整理近期主題，方便讀者挑重點複習 2. 讓尚未訂閱的朋友了解 13+ 的內容與價值 3. 公告與提醒 今天這篇的前半為使用指南，後半為主題整理。 ## 提醒：13+ 的年費方案限時提供到今天 提供年費方案，代表我承諾未來一年會繼續寫作，是個十分慎重的考慮。 **年費方案限時提供到今天（9/30）**。如果想要訂閱，不要錯過囉。 👉[**啟動未來一年的學習之旅**（按這裡打開 Patreon）](http://patreon.com/ethanhuang13/?ref=ethanhuang13.plus)。 ## 13 的話 這個月，我經營這份專欄累積一年了。「週間每天更新的挑戰」也持續超過一個月，並且從默默嘗試到公開挑戰。 有的時候，擠不出時間或體力，只好清晨起來寫。但是不論如何，每天寫完、排程好一篇自己滿意的文章，都覺得非常充實。心情就像完成了一天最重要的事情，非常快樂。 讀者對我非常支持。光是這個月，就增加了 13% 以上的訂閱者。而在年費方案開啟以後，已經有**超過三分之一的讀者選擇年費**，表示對我過去一年的肯定、以及對未來一年的信心。 9 月份，**我最喜歡的主題是「探究 iPhone 的 USB 速度對開發體驗的影響」**。我發現不少開發者並不重視實機開發的時候要插線，以及 USB 3 的速度。而我說服人們的作法是：教大家實測，用可以重現的步驟與數據來證明。 我認為這是工程師在討論技術問題時，一個非常重要的原則。希望讀者除了學到幾招測速的技巧以外，更重要的**用數據證明論點，並且可以教人重現你獲得數據的步驟**。 以下提供一些讓 13+ 這個專欄更好讀、更好用的使用指南。 ## 從目錄頁面了解全貌 13+ 已經寫滿一年，文章累積超過 90 篇。如果你中途才開始訂閱，可能會不知道怎麼去看之前的文章。 很簡單。當你訂閱以後，就可以在[官網](https://ethanhuang13.plus/)登入（用你訂閱的 Patreon/vocus 帳號的 E-mail），看到所有文章。 接著，到[目錄頁面](https://ethanhuang13.plus/index/)，按照分類與 Tag 來瀏覽，或是往下捲動，按照時間來閱讀。 尚未訂閱的朋友，也可以從[目錄](https://ethanhuang13.plus/index/)點進去各篇文章試看。 ## 開啟官網電子報 訂閱 13+ 的新朋友，都會收到從官網發出的電子報。內容可能會跟 Patreon 或 vocus 發出的信件重複。 但是，Patreon 不支援內嵌程式碼、圖片有時候會有問題。所以我更推薦閱讀官網版本的電子報。 如果你沒有收到電子報，想要調整設定，只要在登入以後，按右上角的[帳號](https://ethanhuang13.plus/#/portal/account)，就可以選擇是否要開啟。 ![13+ 官網的帳號設定](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-29-at-23.40.32@2x.png) 13+ 官網的帳號設定 ## 讀完文章請幫我按個讚 官網電子報最後都會有這個區塊。如果你喜歡當天的主題與內容，請幫我按左邊的讚、反之就按右邊。這樣我就會知道是否有需要調整文章的主題方向。 ![13+ 官網電子報的按讚區塊](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-29-at-23.44.18@2x.png) 13+ 官網電子報的按讚區塊 習慣讀 Patreon 版本電子報的話，也可以對喜歡的文章按 Like。 ![13+ Patreon 電子報的按讚區塊](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-29-at-23.37.13@2x.png) 13+ Patreon 電子報的按讚區塊 當然，讀完有心得想分享的話，歡迎留言！ 本文的後半段，整理 9 月所有文章的主題。雖然我會規劃未來的主題、每天要寫什麼文章。但是實際開始撰寫以後，常常會遇到文章需要再拆散成更多篇、或是開展出支線的情況，所以事後歸納是有必要的。 **文章雖多，但是不需要有全盤吸收的壓力。一個月下來有抓到幾個重點，我覺得就值回票價了。**請參考以下主題整理，挑有興趣的部分進行回顧。 ## 本月主題1：iPlayground 幕後花絮 延續 8 月底的準備參加研討會主題，在 iPlayground 之後分享了一些背景故事。 如果你只想看一篇，我推薦 9/4 的 [🇯🇵iPlayground 與日本 iOS 研討會的跨國火花](https://ethanhuang13.plus/iplayground-japan-connection/)。 - 2025-09-01: [💪為何我選擇「個人軟體時代」作為 iPlayground 閉幕題目（免費公開）](https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/) - 2025-09-02: [🗜️只給我講 20 分鐘？限制條件反而成就佳作](https://ethanhuang13.plus/constraints-create-excellence/) - 2025-09-03: [📖為什麼現在是學習 TCA 的最好時機？](https://ethanhuang13.plus/why-learn-tca-now/) - 2025-09-04: [🇯🇵iPlayground 與日本 iOS 研討會的跨國火花（免費公開）](https://ethanhuang13.plus/iplayground-japan-connection/) - 2025-09-05: [🤝研討會系列文章整理（免費公開）](https://ethanhuang13.plus/conference-series-wrap-up/) ## 本月主題2：Swift Dependencies 套件推坑 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 是我幾乎每個 iOS app 都會用到的套件，非常值得推薦給大家。因為寫到一半被其他主題「插隊」，還需要幾篇才會完結。 - 2025-09-08: [📦套件推坑：Swift Dependencies 超讚。它解決了哪些問題？](https://ethanhuang13.plus/swift-dependencies-why/) - 2025-09-09: [🕕時間看似單純，但很難測試，靠 Swift Dependencies 來救](https://ethanhuang13.plus/swift-dependencies-control-date/) - 2025-09-10: [🔀UUID 的隨機特性很好，測試的困難就交給 Swift Dependencies](https://ethanhuang13.plus/swift-dependencies-control-uuid/) - 2025-09-16: [✨Swift Dependencies 的語法靈感來自 SwiftUI Environment](https://ethanhuang13.plus/swift-dependencies-environment-syntax/) ## 本月主題3：13+ 年度回顧與展望 感謝老朋友、公開挑戰，以及給新朋友的推坑文。 - 2025-09-17: [🎂13+ 滿一週年了！感謝老朋友](https://ethanhuang13.plus/13-plus-one-year-love-you-three-lessons/) - 2025-09-18: [🗓️13+ 挑戰每日更新對你我的意義](https://ethanhuang13.plus/13-plus-daily-challenge/) - 2025-09-19: [➕13+ 一週年，開始你的每天五分鐘啟發之旅（免費公開）](https://ethanhuang13.plus/13-plus-get-started-daily-5min-journey/) ## 本月主題4：探究 iPhone 的 USB 速度對開發體驗的影響 如前面所說，這是我這個月最喜歡的一個系列。剩下一篇總結。 - 2025-09-22: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：前言（免費公開）](https://ethanhuang13.plus/iphone-usb-speed-intro/) - 2025-09-23: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：如何得知連線速率](https://ethanhuang13.plus/iphone-usb-speed-measure-usb-and-network/) - 2025-09-24: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：實測 USB 速率的方法](https://ethanhuang13.plus/iphone-usb-speed-measurement-with-usbmuxd/) - 2025-09-25: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：示範常見開發情境](https://ethanhuang13.plus/iphone-usb-speed-demo-devicesupport-debugging/) - 2025-09-26: [⚡️探究 iPhone 的 USB 速度對開發體驗的影響：AI 模型需要高速傳輸](https://ethanhuang13.plus/iphone-usb-ai-model-new-challenge/) ## 獨立文章 除了各大主題，還衍生了一些支線與雜談。不知道你喜歡這樣的單篇，還是更偏好主題系列呢？ - 2025-09-11: [🌬️從 Apple 2025 年 9 月發表會聊聊「升級感」](https://ethanhuang13.plus/apple-2025-sep-event-cost-feeling-value/) - 2025-09-12: [💸iOS 26 就要來了，準備好了嗎？](https://ethanhuang13.plus/ios-26-iphone-17-launch-reminder/) - 2025-09-15: [📦解決 SwiftSyntax 編譯超慢的問題](https://ethanhuang13.plus/prebuilt-swiftsyntax/) - 2025-09-29: [💡開發好習慣：閱讀 Release Notes](https://ethanhuang13.plus/dev-habit-read-release-notes/) ## 結語 日常更新一個多月下來，我發現 13+ 正在演變成一個陪伴 iOS 工程師成長的「學習系統」（而不是一套按部就班的「系統化學習」課程）。每天早上一些新的內容，刺激讀者建立起每天都學一點東西的習慣，進而發展成屬於自己的學習系統。 你對於開發方面的學習，有什麼心得或策略嗎？訂閱 13+ 對你有哪些幫助呢？不妨趁著月底進行一次回顧，也歡迎與我分享。 ### 💡開發好習慣：閱讀 Release Notes URL: https://ethanhuang13.plus/dev-habit-read-release-notes/ Last updated: 2026-08-13T06:06:19.000Z 今天不是上班日，所以分享一個最近遇到的小坑。順便再次提醒開發者要養成閱讀 Release Notes 的好習慣。 前幾天，一位開發者朋友在用 Xcode 26 開發時遇到問題，來問我：「為什麼 SwiftUI 的 [@Animatable macro](https://developer.apple.com/documentation/swiftui/animatable%28%29?ref=ethanhuang13.plus) 沒辦法使用？官方文件上寫著支援 iOS 13 以上。」 我聽著覺得 `@Animatable` macro 這個關鍵字很眼熟，翻了一下資料，就回答他說：「這是個坑。官方文件寫的是還在 beta 版的資訊。」 為什麼我會知道呢？因為我每週撰寫 [Apple 開發者週報](https://ethanhuang13.com/?ref=ethanhuang13.plus)，有閱讀 Xcode 與 iOS 的 [Release Notes](https://developer.apple.com/news/releases/?ref=ethanhuang13.plus) 的習慣。 ## Animatable 是什麼？ [Animatable](https://developer.apple.com/documentation/swiftui/animatable?ref=ethanhuang13.plus) 是個 protocol，用在 SwiftUI 建立動畫所需參數。過去開發者需要自行實作 [animatableData](https://developer.apple.com/documentation/swiftui/animatable/animatabledata-6nydg?ref=ethanhuang13.plus)。 至於今天的主角 [@Animatable macro](https://developer.apple.com/documentation/swiftui/animatable%28%29?ref=ethanhuang13.plus)，則是 Apple 在 Xcode 26 新增的功能。可以直接套用在某個 type 上，方便用 property 來實作動畫屬性。 ## 坑 這位朋友的 app 需要支援 iOS 26 以前系統版本，Xcode 26 不讓他使用 `@Animatable` macro。只能自行實作 `animatableData`。 但是，如果你去看 [@Animatable macro 的文件](https://developer.apple.com/documentation/swiftui/animatable%28%29?ref=ethanhuang13.plus)，會發現上面就寫著從 iOS 13 起支援。這是怎麼回事？ _This post is for paying subscribers only._ ### ⚡️探究 iPhone 的 USB 速度對開發體驗的影響：AI 模型需要高速傳輸 URL: https://ethanhuang13.plus/iphone-usb-ai-model-new-challenge/ Last updated: 2026-08-13T06:06:18.000Z 我之所以會[發推文](https://x.com/ethanhuang13/status/1968912516056014858?ref=ethanhuang13.plus)說 [iPhone Air 與 17 的 USB 2.0 不夠用](https://www.threads.com/@ethanhuang13/post/DOxboUbCdDw?ref=ethanhuang13.plus)、請買支援 USB 3 的 Pro 系列，最主要原因是我留意到開發時安裝大檔案的效率瓶頸。這個需求，目前遇到的開發者很少，但是未來可能會變成一個明顯的開發效率問題。 也就是：**在 iOS 上執行 AI 模型，需要放入動輒上百 MB 甚至幾 GB 的檔案。** ## 在 iPhone 上執行 AI 模型不再是玩具 不知道讀者朋友有沒有留意到，iOS app 執行本地 AI 模型的可行性越來越高了。 首先，iPhone 的運算能力持續增加。如果你有關注 iPhone 17 系列的 A19(Pro) 的性能表現測試報告，特別是 GPU 與 AI 運算方面，應該會知道這代 SoC 相較於前代有明顯增長、記憶體也更充足。iPhone 17 Pro 甚至能夠[執行 8B 的 LLM](https://www.youtube.com/watch?v=kUmx3MJzmfw&ref=ethanhuang13.plus)。 其次，iOS 26 開始，Apple 提供了 Foundation Models，讓開發者更容易「入門」 AI 應用。**可以預見的是，許多開發者會開始接觸 AI 功能，並加入到 app 當中。一旦不滿足於 Apple 原生的方案，就會尋求第三方模型。** 第三，[MLX](https://github.com/ml-explore?ref=ethanhuang13.plus) 是 Apple 的 Machine Learning 框架。它的發展，讓**在 Apple 平台上執行第三方 AI 模型的難度降低**。除了 C++ 與 Python，也支援 Swift。我這陣子研究了一下 [MLX Swift](https://github.com/ml-explore/mlx-swift?ref=ethanhuang13.plus)。只要下載 [mlx-swift-examples](https://github.com/ml-explore/mlx-swift-examples?ref=ethanhuang13.plus)，裡面就有非常多 AI 應用的範例，包括 LLM、VLM、Chat、Stable Diffusion 等。這些範例可以跑在 Mac，也可以在 iOS 設備上執行。 ## 從 MLX 的 Examples 發現下載模型缺乏效率 這就要說到我發現傳輸速率影響開發效率的問題。 第一次執行的時候，[mlx-swift-examples](https://github.com/ml-explore/mlx-swift-examples?ref=ethanhuang13.plus) app 會從 Hugging Face 下載開源的 AI 模型回來。這些模型有幾百 MB 起跳，超過幾 GB 也不罕見。下載一個模型往往需要幾分鐘的時間。 如果開發或測試流程需要反覆地刪除 app、重新安裝，就得重新傳輸模型檔案，非常浪費時間。因為 iOS app 有 sandbox，不像 Mac 可以輕鬆備份已下載的模型檔。手動從 Document browser 讀取檔案是個 workaround，但無法自動化。 不久之前，[ 知名開發者 Mattt 表示，他正在與 Hugging Face 合作](https://x.com/mattt/status/1965375375510569401?ref=ethanhuang13.plus)，開發一些 Swift Package 與工具，讓開發者更容易在 Swift 使用這些模型。並且在[蒐集開發者的意見](https://x.com/mattt/status/1965375377859399822?ref=ethanhuang13.plus)。你可以看到 [mlx-swift-examples](https://github.com/ml-explore/mlx-swift-examples?ref=ethanhuang13.plus) 裡面下載模型使用的 [Swift Transformers](https://github.com/huggingface/swift-transformers?ref=ethanhuang13.plus) package，Mattt 目前是主要維護者之一。 我發現到從 example apps 下載模型檔非常花時間，對於開發與測試非常不利。所以就[建議 Mattt](https://x.com/ethanhuang13/status/1970512440032211031?ref=ethanhuang13.plus)，能否使用 Mac 當成 cache server？而要是有什麼辦法，能夠利用 USB 3 來高速傳輸就更好了。[他覺得是很好的建議](https://x.com/mattt/status/1970523323319885873?ref=ethanhuang13.plus)。 > Mattt: That's a great idea! I'm thinking through an overhaul about how models are loaded and managed, so your suggestion comes at the perfect moment. 讀者如果有什麼好點子，也不妨[回覆他的推文](https://x.com/mattt/status/1965375377859399822?ref=ethanhuang13.plus)。 ## 更多 AI 模型應用的例子 在過去，iOS 開發者很少有機會接觸到安裝容量有幾百 MB 的 app。通常只有遊戲，或是大公司沒有詳細規劃依賴與模組的時候，才會有這種可能。所以 USB 2.0 的速度不是什麼問題，甚至許多開發者習慣了使用無線開發。但是在裝置上運行 AI 模型這個需求，將會徹底改變插 USB 線開發的意義。 如果你有找一些能下載 AI 模型的 app 來玩玩看的話，就會發現，下載幾個幾 GB 的模型是很常有的事情。並不是只有 [mlx-swift-examples](https://github.com/ml-explore/mlx-swift-examples?ref=ethanhuang13.plus) 為了示範才會這樣做。 _This post is for paying subscribers only._ ### ⚡️探究 iPhone 的 USB 速度對開發體驗的影響：示範常見開發情境 URL: https://ethanhuang13.plus/iphone-usb-speed-demo-devicesupport-debugging/ Last updated: 2026-08-13T06:06:17.000Z 歡迎來到系列文章的第 4 篇。 不知道讀者有沒有注意過，Xcode 與 iOS 裝置的連線，具有有多重路徑，並且會自動切換。 透過網路時，Mac 與 iOS 設備會透過 Bonjour 協定找到區網中的彼此。而從[昨天的文章](https://ethanhuang13.plus/iphone-usb-speed-measurement-with-usbmuxd/)中，我們知道，iOS 設備插上 USB 連接到 Mac 時，是使用類似 TCP 的機制連線。 如果你想親自嘗試，可以採用以下操作步驟： 1. 把 iPhone 插上 USB 線 2. 從 Xcode 16 或 26，把 app 跑起來 3. 按 `Cmd + 7` 切換到 Debug Navigator 4. 把 USB 線拔掉 這時會發現，debugging session 沒有中斷。 ![Xcode Debug Navigator](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.18.05@2x.png) Xcode Debug Navigator 在這個過程當中，假如按下 `Cmd + Shift + 2` 打開 Devices and Simulators 視窗，可以發現 Connected 的裝置旁邊的地球符號。如果有的話是走網路、沒有的話，是走 USB 線。 ![Devices and Simulators 視窗](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.18.37@2x.png) Devices and Simulators 視窗 接下來，我要以幾個開發中常見的情境，來比較無線、USB 2.0、USB 3 這幾種連線方式的速度差異： - 準備 DeviceSupport 檔案 - 從 Build 完 App 到實機，到能夠開始操作 - Breakpoint - View Debugger - Memory Graph 如果你有時間，我建議直接看以下影片的示範，可以得到比較深刻的印象： _This post is for paying subscribers only._ ### ⚡️探究 iPhone 的 USB 速度對開發體驗的影響：實測 USB 速率的方法 URL: https://ethanhuang13.plus/iphone-usb-speed-measurement-with-usbmuxd/ Last updated: 2026-08-13T06:06:16.000Z [在前一篇文章中](https://ethanhuang13.plus/iphone-usb-speed-measure-usb-and-network/)，我說找不到實測 USB 傳輸速率的方法。很高興地，今天已經有所突破。這篇就來介紹這個方法與實測結果。 在開始介紹以前，得先說明一下，Mac 與 iOS 在透過 USB 連線時，是走一套虛擬網路介面，而不是直接走 USB 的通訊協定。 ## 簡介 usbmux 這套介面使用一個 daemon 程序，叫做 [usbmuxd](https://theapplewiki.com/wiki/Usbmux?ref=ethanhuang13.plus)，它的功能是提供一個類似 TCP 的機制，進行通訊。透過這種機制，不同的程式可以採用不同的 port 進行溝通，而不會有獨占 USB 資源的問題。 你可以從**活動監視器**（Activity Monitor）或**系統監視程式**（Console）看到它的存在。 ![從活動監視器看到 usbmuxd](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.22.06@2x.png) 從活動監視器看到 usbmuxd ![從系統監視程式看到 usbmuxd](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.22.43@2x.png) 從系統監視程式看到 usbmuxd 位置在 `/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/Resources/usbmuxd`。 而一些備份或與 iPhone 傳輸資料的軟體，包括非 Mac 平台的軟體，都是使用相容 usbmux 的實作來達成的。 例如，[libimobiledevice.org](https://libimobiledevice.org/?ref=ethanhuang13.plus) 有一套跨平台的（以 Linux 為主）開源實作，來達成與 iOS 設備通訊。 ## 使用開源的 libusbmuxd 實測 USB 速率 而我們用來進行 USB 實際傳輸速率的方式，就是使用 usbmuxd 的相容套件，建立起虛擬網路的 port，然後再使用 iperf3 測速。 步驟如下： 1\. 安裝 [libimobiledevice](https://github.com/libimobiledevice/libimobiledevice?ref=ethanhuang13.plus) 與 [libusbmuxd](https://github.com/libimobiledevice/libusbmuxd?ref=ethanhuang13.plus)。 ```bash brew install libimobiledevice brew install libusbmuxd ``` 2\. 把 iPhone 透過 USB 線與 Mac 連接 3\. 配對裝置 `idevicepair pair`。第一次可能會被詢問裝置密碼，輸入完畢以後再送出一次相同指令 4\. 輸入 `iproxy 2222 22` 來啟用虛擬的網路，讓本地的 2222 port 轉發到裝置的 22 port（請注意：每次插拔 USB 都需要重新執行 3、4 兩個步驟） ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.42.18@2x.png) 5\. 把 iPhone 的 Wi-Fi 關閉，並打開 [iPerf app](https://apps.apple.com/tw/app/iperf-speed-test-tool/id951598770?ref=ethanhuang13.plus)，進入 Server Mode，會看到 iPhone 的 IP ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/IMG_7397.png) 6\. 在 Mac 上，使用 iperf3 指令，搭配上一步驟看到的 IP ```bash iperf3 -c 169.254.134.43 ``` ## 實測結果 在我的 iPhone 16 Pro Max，使用 10 Gb/s 的 USB 3 傳輸線，可以跑出 6.12 Gb/s 的速率！ ![在終端機執行 iperf3，平均 6.12 Gb/s](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.47.49@2x.png) 在終端機執行 iperf3，平均 6.12 Gb/s 使用理論值為 5 Gb/s 的 USB Hub，實際速率是 3.21 Gb/s。 ![在終端機執行 iperf3，平均 3.21 Gb/s](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.54.24@2x.png) 在終端機執行 iperf3，平均 3.21 Gb/s 至於使用 Apple 原廠的 USB 2.0 規格 USB-C 傳輸線，只得到 303 Mb/s 的速率，比理論值 480 Mb/s 低上不少。 ![在終端機執行 iperf3，平均 303 Mb/s](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-24-at-00.50.54@2x.png) 在終端機執行 iperf3，平均 303 Mb/s 重新整理一次[前一篇](https://ethanhuang13.plus/iphone-usb-speed-measure-usb-and-network/)的速率列表，由慢到快： - **93.8 Mb/s**: Mac 接 100 Mbps 乙太網路（爛網路線） - **303 Mb/s**: USB 2.0（Apple 原廠充電傳輸線） - **500 Mb/s**: Mac 與 iPhone 都接上 Wi-Fi 6 AP - **700 Mb/s**: Mac 接乙太網路 + iPhone 接 Wi-Fi 6 - **940 Mb/s**: Mac 與 iPhone 都接乙太網路 - **3.21 Gb/s**: USB 3 Hub（5 Gb/s 規格） - **6.12 Gb/s**: USB 3（10 Gb/s 傳輸線） 實測結果顯示，iPhone 的 USB 3 速率可以達到 USB 2.0 的 20 倍。對於 Mac 接上1 GbE、iPhone 走 Wi-Fi 6 的情況，也有 8.7 倍速的差異。 此外，透過 usbmuxd 沒有達到 USB 規格的理論值，大概只剩下 61\~63 %。可以看得出來這套虛擬網路層是有一些損耗的。 ## 結語 最後，跟讀者分享一下，我是怎麼找到實測 iPhone USB 速率的方法。 _This post is for paying subscribers only._ ### ⚡️探究 iPhone 的 USB 速度對開發體驗的影響：如何得知連線速率 URL: https://ethanhuang13.plus/iphone-usb-speed-measure-usb-and-network/ Last updated: 2026-08-13T06:06:15.000Z [接續前文](https://ethanhuang13.plus/iphone-usb-speed-intro/)，我想知道 Mac 與 iOS 設備之間的連線速率對於開發體驗的影響。兩台設備之間可以透過 USB 線與網路進行通訊。 在繼續閱讀下去以前，需要重點強調：我提供的是我查到的資料、測試方法與結果，而非絕對的真理。歡迎讀者一起來實驗、交流。 ## 先說結論 1. Mac 與 iOS 設備都連到同一個 Wi-Fi AP 時，理論速度可能與插 USB 2.0 傳輸線差不多 2. Mac 接上乙太網路、iPhone 使用 Wi-Fi，會比兩者都使用 Wi-Fi 更快 3. 如果你在使用 iPhone 15/16/17 Pro(Max) 開發，**請不要使用原廠盒子內那條 USB-C 編織傳輸線**，因為那條線只有 USB 2.0，浪費了 USB 3 規格該有的速度 4. 注意線材的品質與實測速率 ## 如何得知 USB 速率？ 我們可以從 Mac 的系統報告看到當前 USB 裝置的速率。 打開系統設定，從「一般」、「關於」，捲動到最下方，打開「系統報告」。 ![打開系統設定，從「一般」、「關於」，捲動到最下方，可以看到「系統報告」](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-23-at-05.33.31@2x.png) 打開系統設定，從「一般」、「關於」，捲動到最下方，可以看到「系統報告」 再點選「硬體」、「USB」，找到 iPhone。 我目前使用的是 iPhone 16 Pro Max。我在家裡找到一條線，可以跑出最高的速率，10 Gb/s。 ![系統報告顯示 iPhone 的 USB 連結速度為 10 Gb/s](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-23-at-05.40.05@2x.png) 系統報告顯示 iPhone 的 USB 連結速度為 10 Gb/s 接下來，我把 iPhone 接到 Hub 上，使用一條 USB-A 轉 USB-C 的線材。顯示為 5 Gb/s 的速率。 ![系統報告顯示 iPhone 的 USB 連結速度為 5 Gb/s](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-23-at-05.42.02@2x.png) 系統報告顯示 iPhone 的 USB 連結速度為 5 Gb/s 接下來，我改成插上 iPhone 盒子裡面附上的那條 Apple 原廠 USB-C 充電線，得到的速率為 480 Mb/s。 ![系統報告顯示 iPhone 的 USB 連結速度為 480 Mb/s](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-23-at-05.43.09@2x.png) 系統報告顯示 iPhone 的 USB 連結速度為 480 Mb/s 值得注意的是，**系統報告並不會即時更新。如果有插拔 USB 設備，請手動按 `Cmd + R` 來重新整理**。 這邊的數字反映的是目前走的 USB 規格。 - **480 Mb/s**: USB 2.0 - **5 Gb/s**: USB 3.0 = USB 3.1 Gen 1 = USB 3.2 Gen 1×1，接點為藍色 - **10 Gb/s**: USB 3.2 Gen 1×2 或 USB 3.2 Gen 2×1 USB 3、3.1、3.2 系列的規格名稱一直改來改去（請參考[維基百科](https://zh.wikipedia.org/zh-tw/USB%5F3.0?ref=ethanhuang13.plus)），[Apple 的規格就只寫 USB 3](https://support.apple.com/zh-tw/121032?ref=ethanhuang13.plus)。 ## 能否實測 USB 速率？ 也許你會想問，USB 速率能否實測？ _This post is for paying subscribers only._ ### ⚡️探究 iPhone 的 USB 速度對開發體驗的影響：前言 URL: https://ethanhuang13.plus/iphone-usb-speed-intro/ Last updated: 2025-12-20T05:17:38.000Z 前幾天我在網路上[發文](https://x.com/ethanhuang13/status/1968912516056014858?ref=ethanhuang13.plus)，[提醒](https://www.threads.com/@ethanhuang13/post/DOxboUbCdDw?ref=ethanhuang13.plus)開發者： > 以防有人不知道 > iPhone Air 跟 17 都不適合拿來當開發機 > 它們只有 USB 2.0 > 開發者請買 Pro 收到的回應，大概可以歸納成這幾種： 1. 沒差，傳輸佔據的時間不多 2. 沒差，我都用 Wi-Fi，沒插線 3. 沒差，以前的 iPhone 不也是只有 USB 2.0（Lightning）？ 4. 什麼情況需要用到高速的 I/O？ 看得出來，大部分開發者沒有很重視 iOS 設備的 I/O 速度。 先說，我會發那則訊息，是因為： 1. 一般的 iOS app 不會有上百 MB、安裝時間受到 I/O 的影響很小。但是，我最近剛好在玩**本地 AI 模型的 app，動輒有幾 GB 的模型要下載**。開發時如果能從 Mac 上高速傳輸至 iPhone，會節省非常多時間 2. iPhone 15 Pro、16 Pro、17 Pro（包括 Pro Max）支援 USB 3.2 Gen 2，速度最高可達 **10Gb/s** 3. 其餘 iPhone 支援 USB 2.0，速度最高可達 **480 Mb/s** 4. 2022 年以後的 iPad Pro 支援 USB 4 與 Thunderbolt，速度最高可達 **40Gb/s** 5. 雖然 Xcode 連到 iOS 裝置可以透過 Wi-Fi，但是我個人的開發經驗來說，**插線總是比走網路快且穩定** 總之，我認為有必要做一些實驗，用實際數據來說明。所以我這幾天就在研究這件事情。 先說部分實驗結論： 1. Debugging 的時候插拔 USB 線來觀察，可以發現 Xcode 與 iOS 裝置之間，會維持多條連線，包括 USB 跟區域網路，並且按照速度自動切換優先順序 2. 對於所有的 iOS 開發者來說，USB 3 最明顯的使用時機應該是從裝置複製 DeviceSupport 檔案到 Mac 上。但差異沒有到 10 Gb vs 480 Mb 的 20.8 倍，而是 3 倍左右 3. 啟動 app、跳到 Breakpoint、打開 View Debugger、打開 Memory Graph 等情況，插線遠比走區網快得多 後續的文章，我會把實驗步驟、結果的數據、截圖或影片整理出來，並且討論： 1. 哪些開發需求在有高速 USB 會是有利的情況？ 2. 哪些開發需求，USB 的速度無所謂？ 3. USB 3 實際上最快可以到多快？ 4. 還有哪些可以延伸進行的實驗？ 5. 最重要的：開發者應該如何選擇開發或測試設備？ > 還沒訂閱的朋友，如果你對這個主題興趣，請[成為 13+ 的會員](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)來了解更多。我正在進行每個工作日發表一篇文章的挑戰，在 9/30 以前限時開放年費方案。請參考 [➕13+ 一週年，開始你的每天五分鐘啟發之旅](https://ethanhuang13.plus/13-plus-get-started-daily-5min-journey/)。 ### ➕13+ 一週年，開始你的每天五分鐘啟發之旅 URL: https://ethanhuang13.plus/13-plus-get-started-daily-5min-journey/ Last updated: 2025-09-19T05:49:56.000Z 如果每天早上 6 點，你的信箱都有一篇新文章，帶來工具技巧、策略方法、系統思考、人生哲理，各種層次的刺激。一年之後，你會發現自己的成長。 [13+](https://ethanhuang13.plus/) 經過我一年的探索，現在以每週一到五更新的方式經營。因為我相信，**最好的學習方式不是速成，而是持續累積**。 讓你的一天，從五分鐘閱讀的啟發開始。 13+ 的**年費優惠方案限時開放至 9/30**。 [立刻到 Patreon 開始訂閱](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)！ ## 13+ 是個怎樣的專欄？ 我是 13（讀作一三），一名資深 iOS 工程師。這裡有我許多[免費 iOS 開發資源分享](https://ethanhuang13.notion.site/?ref=ethanhuang13.plus)，包括 240 多期的 Apple 開發者週報。 13+ 是我首次嘗試付費寫作專欄，並且已經經營了一年，文章多達 85 篇。 內容是我面對 AI 對於軟體工程師工作方式與職涯未來的衝擊，進行實驗、思考。 結合自身 iOS 軟體開發、團隊管理、社群參與的經驗、心理與學習方面的背景，提供獨到的見解，有許多一般技術專欄不會看到的切入方向。 之所以要挑戰每個工作日更新，是為了訓練自己的思考。對於讀者，也會產生一種**長期累積的學習效果**，是種絕無僅有的訂閱體驗。 我的寫作風格是：**不強調自己是對的，而是分享實際經驗與觀點，邀請你親自嘗試。** 13+ 的主題方向廣度、個人風格特色、每日更新的頻率，都讓這個專欄與眾不同。 所有過去的文章與分類，都可以在這個[目錄頁面](https://ethanhuang13.plus/index/)找到並且試看，歡迎參考。 ## 現在就是訂閱 13+ 的最好時機 13+ 在 Patreon 的訂閱費用是 13 美金/月。**在 2025/09/30 以前，我會限時開放年費訂閱方案**，折扣 13%。 年費方案並不只是一個折扣活動，而是經過深思熟慮之後下的決定。因為，預先收取一年的訂閱費用，表示我未來一年還會持續更新、提供許多有價值的分享。這是一個重大的承諾。 專欄已經經營整整一年、每日更新已經持續一個月了。每天接收一點刺激，學習效果遠比未來一次消化 200 篇文章更好。 ## 13+ 適合我嗎？ 你可以看看[會員們的推薦文](https://ethanhuang13.plus/testimony/)。 我認為，13+ 特別適合這樣的讀者： - [Apple 開發者週報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)讀者，給自己一個好理由支持 13 持續寫作 - 熱愛學習與思考 - 喜歡自己動手實作 - 不相信速成，相信累積的學習效果、重視長期價值 - 處於職涯探索或成長階段的軟體工程師、創作者與學習者 ## 結語 **一天五分鐘的閱讀，你有可能獲得一項開發技巧、一個避免踩坑的經驗、一個改變思維的觀點，或是一個職涯發展的啟發。** 想知道每日閱讀累積的力量能帶來什麼改變？[立刻到 Patreon 訂閱](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)，我們一起來實驗。 現在訂閱，即可解鎖過去所有文章、參與未來的學習實驗。也可以先啟動月付方案，9/30 以前再升級成年費。 > 如果你已經是訂閱的會員，請幫我分享這篇文章，推坑給更多朋友加入！ ### 🗓️13+ 挑戰每日更新對你我的意義 URL: https://ethanhuang13.plus/13-plus-daily-challenge/ Last updated: 2026-08-13T06:06:14.000Z 從上個月中，我啟動了每個工作日發表一篇文章的自我挑戰。加上今天這篇，已經是連續第 27 篇文章了。我自己都覺得不可思議，但好像能夠繼續下去。 為什麼我要每天發表？用了什麼策略？對於讀者的意義又是什麼？今天一次告訴你。 ## 前提：使用 AI 工具輔助寫作的失敗經驗 七月我開始使用 Claude Code，並且用語音轉文字模型快速輸入。除了拿來寫程式以外，我也把過去文章都丟進 Claude 分析。 我試著先把想寫的內容講出來，再要求 Claude 參考其他文章的風格，把逐字稿轉變成文章，最後我再自行編修。 本來以為用講話的方式寫文章會很有效率──花十分鐘「講出」一篇文章，稍微修一下，好像就可以發表了。結果卻是：整個七月我只發表了 4 篇文章，而且我對那幾篇也不算是特別滿意。 這是因為，Claude 幫我寫出來的文章，雖然原始內容來自我的話、寫出來的文字也像我的說話語氣，但是它沒有辦法取代我經過自己思考以後濃縮重點的過程。讀起來完全不覺得是自己寫的文章。 用 AI Agent 來寫程式，也常常有類似的感覺。程式碼有測試與規範作為檢驗標準，所以比較沒關係。**寫文章卻不能沒有自己的靈魂。就算讀者看不出來，我自己也無法接受。** 於是，我開始思考寫作對我來說到底是什麼一回事。 原來，寫作不只是生成文字的結果，**寫的過程本身就是目的**。我喜歡寫作，因為這是個很有挑戰性的思考過程。如果跳過這個過程，讓 AI 幫我生成文字，即使草稿來自我的口語，我也不算是有思考到。 **寫作沒有捷徑**。我得自己想清楚要講什麼概念、希望讀者看完這篇文章以後帶走什麼。 **不要讓 AI 代替自己的思考。**這是我的寶貴教訓，也是演變成每日更新的前奏。 ## 新的寫作策略：從定義最終收穫開始，自然形成短篇 AI 幫我編修的文章都太長，失去重點，我何不先從自己真正想講的東西開始？於是，八月中我開始嘗試全新的寫作策略。 針對一篇新文章，我會從這兩個角度之一發想： 1. **Takeaway**：讀完這篇文章能帶走的一兩句話 2. **Call to action**：讀完這篇文章之後能立刻採取的行動 這是一個非常有力的寫作策略。它會自然地指引我的寫作過程，讓文章長成令我滿意的結果。 在這種新的寫作策略下，**短篇、講重點**變成新的目標，並且追求字數越少越好。甚至會覺得：**字數太多，是因為想得不夠清楚**。 寫作一下子變得容易很多。想要講的東西太多？拆成好幾篇，從不同角度切入，形成一個完整主題。 而對讀者來說，原本文章太長不易吸收。改成多篇在不同天發表，就可以用多個時間點增加「接觸面積」。對特定主題產生興趣，再交叉閱讀。 我對這種寫作策略的成品，滿意度很高，寫起來也比以前快，所以對於高頻率發文越來越有有信心，於是就嘗試每個週一到週五都發表一篇文章。 ## 每日更新的獨特性 我以前無法想像每天都發表文章，這種頻率感覺很要命。不過目前的寫作策略，以及八月到現在 27 篇文章，這件事搞不好有機會做到。 這個世界上，有極少數的幾個人，做到幾乎每天更新。我知道的例子，商業與科技領域有 [Ben Thompson 的 Stratechery](https://stratechery.com/?ref=ethanhuang13.plus)、行銷方面有 [Seth Godin 的 Blog](https://seths.blog/?ref=ethanhuang13.plus)。以前還有[灣區日報](https://www.wanqu.co/?ref=ethanhuang13.plus)，是以精選他人文章的方式在經營，可惜已經停止更新了。 能夠做到每天都發表文章，本身就是一件很厲害的事情了。既然我喜歡寫文章、有很多東西想寫，何不挑戰看看？ 我是不是世界上唯一一個，每天用中文、從軟體工程師的角度出發，在經營付費專欄的人呢？而且文章品質是維持過去一年的水準。 **這種事情，就算挑戰失敗了也算是成功了。而訂閱 13+ 的你，就是陪我一起見證這件事情的夥伴。** 不過，在確定要做每日更新挑戰以前，我想了一下：如果今天我是讀者，對於訂閱一份個人作者經營的日報，有什麼期待？ ## 創造每天一點學習刺激、持續累積的訂閱體驗 我想要付費訂閱這樣的一份電子報：每天早上起來，給我一點思考的刺激。 內容可以是工具技巧、技術新知、策略觀點、系統思考，或是作者的人生經歷。 我喜歡的一些資深工程師 blog（連結我放在文末），他們吸引我之處不只是技術深厚，還包含了歲月累積下來的智慧。一些獨特經驗的小故事，讓人印象深刻。 還有，我並不相信速成學習。出社會一陣子的人，往往已經形成了自己的價值觀與做事方式，而且非常難改。這些東西，有的時候限制了自己的進一步成長，但也很難靠自己去突破。 寫個幾篇文章，不會對讀者帶來什麼長遠的正面價值。如[前一篇](https://ethanhuang13.plus/13-plus-one-year-love-you-three-lessons/)提到的，我也沒有預期每篇文章都會被認真讀完。 但是，如果每天都有文章能閱讀，長期下來，會不會累積出足夠的啟發呢？我很想知道答案。 而只有持續寫下去，才會知道結果。歡迎你日後跟我分享，長期訂閱 13+ 對你有什麼啟發。 總之，我想把 13+ 經營成每天都給讀者一些刺激與思考的專欄。因為這就是我自己會想要訂閱的東西。 還沒訂閱 13+ 的朋友，如果你也想體驗每日思考刺激的累積效果，歡迎[立刻加入](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus)。 _This post is for paying subscribers only._ ### 🎂13+ 滿一週年了！感謝老朋友 URL: https://ethanhuang13.plus/13-plus-one-year-love-you-three-lessons/ Last updated: 2026-08-13T06:06:13.000Z 今天，13+ 專欄滿一週年了！過去一年，我寫了 [82 篇文章](https://ethanhuang13.plus/index/)，比我原本預期地還要多。 我要用三篇文章來慶祝。 今天這篇是對會員們的感謝，分享**三個寶貴收穫**，並說明[**年費方案**](https://www.patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus)。明天我會介紹**「每工作日更新挑戰」**。後天則是邀請新朋友訂閱的**推坑文**。 ## 收穫一：有時候，人們會默默地支持你成功 我一直有付費支持其他創作者的習慣。像是訂閱 [fatbobman](https://www.patreon.com/fatbobman/?ref=ethanhuang13.plus)、[Digital Foundry](https://www.patreon.com/digitalfoundry/?ref=ethanhuang13.plus)、[ChaoCode](https://www.youtube.com/@ChaoCode?ref=ethanhuang13.plus)，以及購買一些獨立開發者的作品。坦白說，我分配給觀看他們內容的時間並不多，但希望他們能夠繼續保持創作的熱情，所以就持續付費支持。 我相信：**用自己的錢，去支持自己喜歡的人事物，是一件很棒的事！** 直到開啟了 13+ 這個付費專欄，我才發現這件事情也發生在自己身上了。 我做過許多免費的開發者資源，包括 [240+ 期的電子報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)、[110+ 集的 Podcast](https://weakself.dev/?ref=ethanhuang13.plus)。雖然接受捐助與贊助，本質上都是免費提供。 13+ 是我第一次做打從一開始就收費的內容。很快地我就深刻地體會到：**有些人不擅表達，但是會用實際行動（出錢）支持**。 宣布啟動這個付費專欄，是在 [Apple 開發者週報 #217](https://www.ethanhuang13.com/p/217?ref=ethanhuang13.plus)。週報發出去當天，我很驚訝地發現，第一篇文章都還沒有寫，已經有好幾位朋友付費加入了。 後續讓我更感動的是，有好幾位前同事來訂閱 13+！曾經共事過的人，主動花錢支持我的新計畫，對我來說意義重大。 非常感謝所有會員的支持。我希望這個專欄的內容也能支持你們。 ## 收穫二：勇於嘗試，快速修正 回顧這一年的寫作進展，好像軟體開發的演進歷史。 我標了版號，不想看的朋友可以跳過： ```Markdown - v0.1（2024 年 9 月）：玩過 Cursor 以後，覺得很想跟大家介紹 AI 工具，就開啟了專欄。一開始想說這會是一系列「課程」，但是很快地就發現，我並不想做課程，而是想寫文章。寫了多篇「iOS 開發 AI 輔助工具」、「SwiftUI + TCA」 - v0.2（2025 年 2 月）：從公司離職。開始撰寫「學習 SwiftUI」 - v0.3（2025 年 4 月）：停止撰寫「學習 SwiftUI」、架設了 Ghost Site 作為官方網站 - v0.4（2025 年 5 月）：開始「iOS 開發補完計畫」 - v0.5（2025 年 6 月）：停止「iOS 開發補完計畫」、開始將 Claude Code 及 Claude Project 納入寫作流程 - v0.6（2025 年 8 月）：改名 13+。減少使用 AI 輔助寫作，追求重點明確的短篇。開始挑戰每工作日都更新 - v1.0（2025 年 9 月）：確立每個工作日發表一篇文章的節奏，並且樂在其中 ``` 13+ CHANGELOG 重點是，每一次改版，都是對於這個專欄的重新定位、修正不滿意的地方。這當中也包含了多次失敗的實驗。像是撰寫與[停止「學習 SwiftUI」一書](https://ethanhuang13.plus/ios-developerplus-update-writing-site-ideas/)、啟動與[放棄「iOS 開發補完計畫」](https://ethanhuang13.plus/ios-missing-manual-free-transition/)、[從 iOS Developer+ 改名 13+](https://ethanhuang13.plus/rebrand-13-plus/) 等等。 坦白說，大張旗鼓地宣布一項寫作計畫，後來又調整或取消，感覺不是太好。 但是，不斷調整在所難免。軟體服務尚且會隨著時間改變功能，何況是由個人撰寫與經營的付費專欄。 只是每次修改，多少都會違背先前的宣布與承諾。所以，我很感謝會員們的包容與持續訂閱。 很高興的是，經過多種嘗試與調整，這一年下來，我已經找到了有效的寫作策略。從 8 月中開始，每個週一到五都有一篇新文章發表，相信讀者觀察到我已經掌握了一些好方法（留待明天的文章分享）。 透過多方嘗試與失敗，走向正確的道路，是我這一年非常重要的收穫。**如果你有什麼想做但不確定的事情，就去試試看吧，很多事情要親自試了才會知道。** ## 收穫三：我寫故我在 一整年的專欄寫作經驗下來，我發現自己真的很喜歡寫文章。 有時候明明已經忙不過來，但是一旦有想寫的題目，我還是會大半夜回到電腦前打開草稿。 長久以來，我很喜歡去想這兩個問題（讀者也不妨詢問自己）： 1. 如果我不需要工作（財務自由或滿足退休條件），**每天會做什麼事情**？ 2. 這件事情，我是否**現在**就能做呢？ 這一年下來，我發現自己的答案越來越清楚：如果擁有不需要賺錢的生活，我還是想要**每天寫一些有啟發性的東西，與大家分享**。 對我來說，**寫作本身就是目的，而不是手段。** 寫作就是用語言在精煉思考的過程、文章就是思考的結果。寫文章就是把事情想清楚以後，用文字來表達。 我覺得**以寫作來思考，比寫程式困難、更具有挑戰性**，而且是 AI 無法取代的能力。AI 能夠產生大量文字，我也嘗試過用 AI 工具來幫忙寫文章。但是多篇文章驗證的結果是：**AI 工具參與越少，我對於成品的滿意度反而越高**。因為是自己想出來的文字。 寫完一篇自己滿意的文章、安排好隔天早上發表，都是我一天當中最有成就感的時候。 一年下來，我對於持續經營這個專欄，更有信心了。 ## 年費方案，限時開啟 最後，我想邀請在 Patreon 訂閱的會員，從月費轉換成年費方案。 我上週在 Patreon 開啟年費方案，有些會員收到系統通知信就立刻啟用了。特別感謝你們的支持。 其實我早就可以開啟年費方案的功能，但是遲遲沒有進行。 原因很簡單，這不是一項「功能」而已。**收了年費，專欄就要再更新一年。對我來說，是一個巨大的承諾。** 雖然我喜歡寫文章，但是有這麼多值得分享的東西，還能夠再寫一年嗎？ 趁著滿一週年，我仔細想了想，應該辦得到。因為，我想出新題目的速度，大於寫出來的速度。目前已經列了幾十個想寫的主題，又一直有在充實與學習新事物。 不過，我並不打算一直開著年費方案的選項。這不是一個週年慶促銷的概念，而是檢視自己的寫作能量之後，承諾未來一年會繼續產出好文章。 **9/30 以後，我就會把選項關閉**，直到我感覺到「庫存的題目多到一年都寫不完」，才會開啟。 13+ 的年費方案會折扣 13%。 👉[請到 Patreon 調整方案](https://www.patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus)。 _This post is for paying subscribers only._ ### ✨Swift Dependencies 的語法靈感來自 SwiftUI Environment URL: https://ethanhuang13.plus/swift-dependencies-environment-syntax/ Last updated: 2026-08-13T06:06:12.000Z 這篇文章是推坑 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 系列的第四篇。前面三篇談到了這個套件[解決的問題](https://ethanhuang13.plus/swift-dependencies-why/)，並以 [Date](https://ethanhuang13.plus/swift-dependencies-control-date/) 與 [UUID](https://ethanhuang13.plus/swift-dependencies-control-uuid/) 為範例。 接下來，我要先介紹 dependency client 的語法是怎麼來的。 以 Swift Dependencies 內建的 `Date` 工具為例，用法是：`@Dependency(\.date.now) var now`。 如果你熟悉 SwiftUI，可能會覺得有點微妙。那是因為，Swift Dependencies 的語法靈感正是來自 SwiftUI。更精確的說，是 [Environment](https://developer.apple.com/documentation/swiftui/environment?ref=ethanhuang13.plus) 機制。 ## 簡介 SwiftUI Environment 在 SwiftUI 當中，[Environment](https://developer.apple.com/documentation/swiftui/environment?ref=ethanhuang13.plus) 是「從上層往下層傳遞」的資訊，相對於 [Preferences](https://developer.apple.com/documentation/swiftui/preferences?ref=ethanhuang13.plus) 是由下往上傳遞。 你可以在任何 SwiftUI View 加上 `.environment(\.key, value)`，指定 value 來覆蓋這個 View 以下所有讀取 `@Environment(\.key) var value` 的地方。 SwiftUI 預設提供了許多 Environment Key。你只要輸入 `@Environment(\.` 就可以從自動完成列表看到各種 keys。 ![自動出現的 Environment Keys](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-16-at-00.33.51@2x.png) 自動出現的 Environment Keys 除了這些內建的 Environment Key，SwiftUI 也提供了自訂的方式。 最初的語法是使用 [EnvironmentKey](https://developer.apple.com/documentation/swiftui/environmentkey?ref=ethanhuang13.plus)，並且用 computed var 的方式延伸 [EnvironmentValues](https://developer.apple.com/documentation/swiftui/environmentvalues?ref=ethanhuang13.plus)。後續 Apple 提供了簡化的語法，我放在文章最後作為補充。 完整實作一個自訂 Environment 的方式如下，摘自[官方文件](https://developer.apple.com/documentation/swiftui/environmentkey?ref=ethanhuang13.plus)： ```swift // 1. Create a custom EnvironmentKey private struct MyEnvironmentKey: EnvironmentKey { static let defaultValue: String = "Default value" } // 2. Extend EnvironmentValues with computed var extension EnvironmentValues { var myCustomValue: String { get { self[MyEnvironmentKey.self] } set { self[MyEnvironmentKey.self] = newValue } } } // 3. Override a value on a SwiftUI view MyView() .environment(\.myCustomValue, "Another string") // 4. Read the value in a SwiftUI view @Environment(\.myCustomValue) var customValue: String ``` ## 在 Swift Dependencies 宣告自訂的 dependency client 看完了 SwiftUI Environment 的宣告與使用語法，接下來我們回頭看 Swift Dependencies。 這篇文章暫時不解釋 Swift Dependencies 的語法與實作細節，之後會討論。目前請先把焦點放在語法的觀察上。 在宣告自訂的 dependency client 時，通常會有以下結構： 1. 以 `Sendable` struct 為基礎型別 2. 每一個方法都是以 `@Sendable` closure 的方式提供 3. 建議加上 `@DependencyClient` Macros 來自動產生部分 closure 的預設值，簡化語法。需要`import DependenciesMacros` ```swift import Dependencies import DependenciesMacros // 1. Create a dependency client @DependencyClient public struct APIClient: Sendable { public var fetchNumber: @Sendable () async throws -> Int } ``` 之所以加上 `public`，是因為通常 dependency client 的宣告與使用，會在不同的模組。至於為何使用 struct 與 closures，以及 `@DependencyClient` Macros 做了哪些事情，會在之後的文章進行討論。 接著，我們要讓這個型別遵循 `TestDependencyKey`，並且實作 `testValue`： ```swift // 2. Conform to TestDependencyKey protocol extension APIClient: TestDependencyKey { public static let testValue = Self() } ``` 最後，延伸 `DependencyValues`，讓它可以被 `@Dependency` 找到。 ```swift // 3. Extend DependencyValues with computed var extension DependencyValues { public var apiClient: APIClient { get { self[APIClient.self] } set { self[APIClient.self] = newValue } } } // 4. Usage @Dependency(\.apiClient) var apiClient let number = try await apiClient.fetchNumber() ``` ## 比較 Swift Dependencies 與 SwiftUI Environment 語法 假如我們把 SwiftUI EnvironmentKey 拆成兩個步驟來寫，就可以看到 Swift Dependencies 跟它幾乎一模一樣 ： _This post is for paying subscribers only._ ### 📦解決 SwiftSyntax 編譯超慢的問題 URL: https://ethanhuang13.plus/prebuilt-swiftsyntax/ Last updated: 2026-08-13T06:06:11.000Z 在繼續 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 推坑系列之前，我想先介紹一下對於開發體驗十分重要的東西：Prebuilt [SwiftSyntax](https://github.com/swiftlang/swift-syntax?ref=ethanhuang13.plus)。 ## Swift Macros 的理想 vs 現實 2023 年，[Swift Macros](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/?ref=ethanhuang13.plus) 作為 Swift 5.9 的一個重要功能推出，方便 library 開發者自行創造更簡便的語法。 Apple 的 frameworks 開始採用 Macros 簡化語法，例如 SwiftData 的 `@Model`、`@Query`，SwiftUI 的 `@Entry`。 但是實務上，Swift Macros 並沒有像 property wrapper 等簡化語法的功能一樣被第三方開發者廣泛使用。一個實際的理由就是因為**增加了明顯的編譯時間**。 Swift Macros 的用意是提供簡單的語法，並且會自動被開展成較為複雜的版本。而為了做到產生語法的效果，**Swift Macros 依賴於** [**SwiftSyntax**](https://github.com/swiftlang/swift-syntax?ref=ethanhuang13.plus) **這個 library** 去產生合法的 Swift 語法。 這個 SwiftSyntax 過去是以 [Package](https://github.com/swiftlang/swift-syntax?ref=ethanhuang13.plus) 的方式來使用。換言之，一旦專案使用到任何 Swift Macros，就需要有 SwiftSyntax 的參與。**SwiftSyntax 不僅會一併被加入專案原始碼，也要完整編譯整個 library。** ## 編譯 SwiftSyntax 相當費時 SwiftSyntax 並不是一個小 library。在 Apple silicon 的 Mac 上編譯，需要至少一分鐘的編譯時間。在一些 CI server（包括 Xcode Cloud）上更是[有機會延長數分鐘](https://mjtsai.com/blog/2024/02/27/slow-swift-macro-compilation/?ref=ethanhuang13.plus)。這個問題困擾我的程度，甚至到了把 MacBook Air M2 換成 MacBook Pro M3 Max 這麼嚴重。 如果是 SwiftUI 的模組引用了使用 Swift Macros 的套件，那麼 SwiftSyntax 增加的編譯時間，基本上就可以破壞 Preview 即時更新的效果。 對於使用 library 的開發者來說，雖然能夠享受到優雅、簡化過的語法，但是增加許多編譯時間，完全得不償失。 開發者社群對於 Swift Macros 這樣的矛盾一直頗為無奈，也有一些開發者試圖自行編譯 SwiftSyntax 成 binary 與 xcframework。例如： - [swift-precompiled/swift-syntax](https://github.com/swift-precompiled/swift-syntax?ref=ethanhuang13.plus)（[作者 Yume 在 CocoaHeads Taipei 的演講](https://www.youtube.com/live/nGTGC5RBxzM?t=2970&ref=ethanhuang13.plus)） - [square/swift-syntax-prebuilt](https://github.com/square/swift-syntax-prebuilt?ref=ethanhuang13.plus) 但這些都不是一勞永逸的辦法，最好還是要由 Apple 出面解決。 ## Xcode 26 提供了預先編譯的 SwiftSyntax _This post is for paying subscribers only._ ### 💸iOS 26 就要來了，準備好了嗎？ URL: https://ethanhuang13.plus/ios-26-iphone-17-launch-reminder/ Last updated: 2026-08-13T06:06:10.000Z 我想在 Apple 正式推出 iOS 26 之前，做個簡單提醒。還有，如果你真的沒注意到的話，**新款 iPhone 今晚開始預購**。本文內容具有時效性，請及時閱讀。 ## 正式發布時間 台灣時間 9/10 凌晨的 Apple 發表會結束之後，Xcode 26、iOS 26 等的 RC 版就釋出了。 **正式版則將於台灣時間 9/16 推出。** RC 就是 Release Candidate，有興趣的朋友現在就可以更新到 iOS 26 與 Xcode 26。如果沒有發現重要問題，正式版本就會等同於 RC，不用再更新一次。 我已經把 iOS、macOS、watchOS 都升級到 26 了。可以跟讀者分享的是，macOS 升級之後幾天都還在持續有發熱及系統功能在運作。並且在一些 UI 相容上比較有問題，尤其是運行 iOS app，或是 Catalyst。 至於 iOS 26，我使用上完全沒有遇到問題。 ## 已經可以上傳支援 Liquid Glass 的 App 積極的開發者，應該之前就試過 Xcode 26 beta 版本對於自家專案的影響。如果之前已經準備好，**現在已經可以使用 Xcode 26 RC 打包、上傳 app 了**。 我在當天就把 iPlayground app 用 Xcode 26 RC 打包上傳，而且[從送審到上架只花了 30 分鐘](https://x.com/ethanhuang13/status/1965711740999766115?ref=ethanhuang13.plus)。看來 App Store Review Team 應該有加派人手解決大批遷移到新版的 apps。 ## 暫時不使用 Liquid Glass 的辦法 如果你暫時還無法把使用者介面改成 Liquid Glass，但又必須開始使用 Xcode 26，可以在 Info.plist 增加這個 key 並設定為 YES。 ```Swift UIDesignRequiresCompatibility ``` 但是，Apple 強調[**這是一個暫時的機制**](https://developer.apple.com/documentation/BundleResources/Information-Property-List/UIDesignRequiresCompatibility?ref=ethanhuang13.plus)**。建議在 iOS 27 推出之前完成把使用者介面遷移到 Liquid Glass 的工作**。 請儘早與開發團隊中的設計同事討論應對時程。 ## 新 iPhone 今天晚上預購 台灣時間，**9/12 週五晚上 8 點開始預購**。想搶第一批的請事先準備好。 想必讀者不是第一次買 iPhone。App Store app 要提早填好什麼東西可以加速購買流程，應該就不用特別教囉。 ## 一些個人想法 _This post is for paying subscribers only._ ### 🌬️從 Apple 2025 年 9 月發表會聊聊「升級感」 URL: https://ethanhuang13.plus/apple-2025-sep-event-cost-feeling-value/ Last updated: 2026-08-13T06:06:09.000Z 昨天凌晨熬夜看了 Apple 的發表會，新的 iPhone、Apple Watch 和 AirPods Pro 都登場了。 身為 iOS 開發者、又是[勸敗節目](https://weakself.dev/?ref=ethanhuang13.plus)的共同主持人，每年的 Apple 新產品對我們來說都很重要，所以今天想來聊聊這次的新產品。並且特別從「升級感」這個角度切入。 ## AirPods Pro 3：光是續航增加到 8 小時就決定買了 AirPods Pro 3 的晶片沒更新、充電盒電量變小。據說降噪效果有增加，但對我來說最大的賣點是：耳機本體的續航從 6 小時變 8 小時。 因為我會戴著 AirPods Pro 2 睡覺當耳塞，睡前聽點東西來助眠。6 小時的續航，會在睡到一半發出低電量警告音，那個音量沒辦法調低或關掉，有可能會把我吵醒。 8 小時剛好是我睡飽的時間，**不會被打斷睡眠就是我預期的主要升級感與購買理由**。而原本的 AirPods Pro 2 還可以當成專門在工作房間使用的設備，就不用在臥室之間拿來拿去了。 ## Apple Watch：才剛換，跳過 我今年初才從 Watch 8 換成 Ultra 2，當時最主要的**升級感在於續航力翻倍**。這次的新機沒有任何更換的必要，所以整個跳過。 ## iPhone 17：沒有遺憾到有點無聊 iPhone 17 把很多 Pro 的功能下放了，特別是現在全線的螢幕都是同等級 ，都有ProMotion、Always-On Display 等功能，這很有趣。 [參考官網比較表](https://www.apple.com/tw/iphone/compare/?modelList=iphone-17,iphone-16-pro,iphone-17-pro&ref=ethanhuang13.plus)，可以把 iPhone 17 想成是 16 Pro 拿掉望遠鏡頭的便宜版本。如果用不到望遠鏡頭和 USB 3，17 是比 16 Pro 更划算的選擇。 這樣的 iPhone 17，簡直沒有遺憾到有點無聊。而這是件好事，可以輕鬆推薦給對於規格沒有特殊需求的 iPhone 使用者。 ## 讓大家拍手的前鏡頭升級 所有新機型都有 Center Stage 前鏡頭。它用了正方形感光元件，透過軟體裁切，做到直拿手機也能拍橫的照片。 這對常自拍的人來說太方便了！比如說我在參加研討會時，會瘋狂跟大家合照，不用再費力地橫拿手機，還要提醒大家看綠色的燈（靠近鏡頭的位置）。 所以，**對於常常有在拍需求，或是使用到前鏡頭的使用者來說，我認為這是今年 iPhone 的最大賣點**。據說媒體發表會現場這個功能獲得最大聲的掌聲，跟我在家看直播的感受一樣。 當然，如果你覺得橫拿手機沒什麼不方便，那這功能對你來說可能就沒什麼。升級感這件事，真的非常個人。 ## iPhone Air：重新思考 iPhone iPhone Air 是今年最特別，也是最吸引我的產品。 _This post is for paying subscribers only._ ### 🔀UUID 的隨機特性很好，測試的困難就交給 Swift Dependencies URL: https://ethanhuang13.plus/swift-dependencies-control-uuid/ Last updated: 2026-08-13T06:06:08.000Z [上一篇 Swift Dependencies 文章](https://ethanhuang13.plus/swift-dependencies-control-date/)以 `Date` 為範例，相信讀者已經體會到，即使是時間這麼基本的型別，也可以造成測試上的困難。而 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies/?ref=ethanhuang13.plus) 可以在測試環境下，替換掉當下的系統時間，使得測試時的行為能夠符合預期。 在這篇文章中，我們繼續延伸昨天的例子，加深印象的同時多介紹一點概念。 在一個筆記 app 中，指定 `id` 來存取特定一篇筆記，是很常見的需求。所以，我們打算把 `Note` 加上 `id` 欄位，並且使用 `UUID` 型別，以確保唯一性。 ## UUID 唯一性的用途 `UUID` 的特性就是在產生時會有唯一性、不會重複。這對於確保資料之間不會衝突，是非常好的特性。 但是，如果我們直接寫 `let id = UUID()`，就會跟上一篇的 `Date()` 發生一樣的問題──無法控制產生的結果。 ```swift struct Note { // v5 let id = UUID() // 新增 id 欄位，隨機產生 let createdDate: Date var modifiedDate: Date var text: String = "" { didSet { @Dependency(\.date.now) var date modifiedDate = date } } init() { @Dependency(\.date.now) var date self.createdDate = date self.modifiedDate = date } } ``` ## 不控制 UUID 產生的結果，就不好測試 大部分情況，其實我們並不在意 `UUID` 的值，因為相信系統會做到產生唯一、不衝突的值，就夠了。 但假如我們把它當成某個關鍵邏輯的參考依據，那麼這種隨機特性，就會讓測試失敗。 舉例來說，我們會想要筆記有個穩定的排序規則，依照 `modifiedDate`、`text`、`id` 這三個條件。理論上時間與內文是有可能重複的（比如我們做了複製同一則筆記的功能），所以最後就以 `id` 為依據。 我們可以幫 `Note` 簡單地實作 `Comparable` protocol。如果你不熟悉這個比較 tuple 的語法，簡單來說它會由左到右依序比對 `modifiedDate`、`text`、最後才是 `id`。 ```swift extension Note: Comparable { static func < (lhs: Self, rhs: Self) -> Bool { (lhs.modifiedDate, lhs.text, lhs.id) < (rhs.modifiedDate, rhs.text, rhs.id) } } ``` 但是在測試時，無法得到穩定的結果。 ```swift @Test( "[non-deterministic] Ensure note default sorting order - will fail randomly" ) func sortNotesWillFail() { let notes = withDependencies { $0.date.now = .init(timeIntervalSinceReferenceDate: 0) } operation: { [Note(), Note(), Note()] } let sorted = notes.sorted(by: <) // UUID() 是隨機的，即使 `modifiedDate`、`text` 相同，也無法預測排序後的順序 #expect(notes == sorted) #expect(notes[0] == sorted[0]) } ``` > 💡技術細節： > 各種程式語言的 UUID 主要是參照 [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122?ref=ethanhuang13.plus)，並且有多種版本。 > > 有幾個版本的 UUID，具備 time-ordered 的特性（例如 [UUIDv7](https://uuid7.com/?ref=ethanhuang13.plus)），產出的 id 直接當字串來排序，就具備時間遞增的效果。這類 UUID 能兼顧唯一性與遞增排序，特別適用於一些資料庫的應用。 > > 而 Swift Foundation 的 [UUID](https://developer.apple.com/documentation/foundation/uuid?ref=ethanhuang13.plus) 是依照 [RFC 4122 version 4](https://datatracker.ietf.org/doc/html/rfc4122?ref=ethanhuang13.plus) 的規格產生的。它會參考當下時間產生，但是產出的隨機字串並沒有遞增特性。所以連續呼叫的 `UUID()` 的結果，不會是穩定的順序。 ## 透過 Swift Dependencies 的 UUIDGenerator 來控制產生結果 就像 `Date`，[Swift Dependencies](https://github.com/pointfreeco/swift-dependencies/?ref=ethanhuang13.plus) 也內建 `UUID` 的注入方式。方法是：`@Dependency(\.uuid) var uuid`。 _This post is for paying subscribers only._ ### 🕕時間看似單純，但很難測試，靠 Swift Dependencies 來救 URL: https://ethanhuang13.plus/swift-dependencies-control-date/ Last updated: 2026-08-13T06:06:07.000Z [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 的[官方文件](https://swiftpackageindex.com/pointfreeco/swift-dependencies/main/documentation/dependencies/quickstart?ref=ethanhuang13.plus)雖然很詳細，但是我想挑戰用自己的方式去說明。就從[前一篇](https://ethanhuang13.plus/swift-dependencies-why/)有提到的 `Date` 開始說起吧！ 假設我們的 app 是個筆記軟體，有一個 `Note` type。裡面有建立與修改筆記的時間欄位： ```swift struct Note { // v1 let createdDate = Date() var modifiedDate = Date() var text: String = "" } ``` 這樣寫的話，**兩個欄位的日期有低機率會不相同**。 以我在 M4 的 Mac 上反覆執行以下測試 1,000 次，有 2% 的機率會有時間差： ```swift import Testing @Test("Init Note and ensure modified date is the same as created date") func initNote() { let sut = Note() #expect(sut.createdDate == sut.modifiedDate) } ``` ## 提示：如何在 Xcode 進行反覆測試 1\. 在 Xcode 的測試上面按右鍵，選 Test Repeatedly… ![在 Xcode 的測試上面按右鍵，選 Test Repeatedly…](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-09-at-01.03.16@2x.png) 在 Xcode 的測試上面按右鍵，選 Test Repeatedly… 2\. 選 Maximum，並輸入一個較大的數字，再按 Run ![選 Maximum，並輸入一個較大的數字，再按 Run](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-09-at-01.04.26@2x.png) 選 Maximum，並輸入一個較大的數字，再按 Run 3\. 錯誤結果顯示，有 2% 的情況 `createdDate` 與 `modifiedDate` 並不相等。 ![錯誤結果顯示，有 2% 的情況 createdDate 與 modifiedDate 並不相等。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-09-at-01.04.58@2x.png) 錯誤結果顯示，有 2% 的情況 `createdDate` 與 `modifiedDate` 並不相等。 很顯然的，`Note` 在 init 的時候，兩個 properties 分別呼叫了一次 `Date()`，而**兩次得到的系統時間，可能有極細微的差異**。實際情況會依照硬體的運算速度而不同。 `Note()` 的這種現象，我們可以稱之為 **non-deterministic**，也就是無法得到完全穩定的結果。 要避免這種問題，我們要修改程式碼，讓 `Date()` 只使用到一次。： ```swift struct Note { let createdDate: Date var modifiedDate: Date init() { let date = Date() self.createdDate = date self.modifiedDate = date } } ``` 再跑重複 1,000 次的測試，就完全通過了。 現在，`Date()` 寫在 `init()` 裡面，所以沒有辦法從外部修改。也許我們可以把 `date` 丟進 `init` 當參數，再設個預設值： ```swift init(date: Date = Date()) { ... } ``` 這樣，一切問題就解決了嗎？ ## 修改的時候更新日期 事情沒有這麼簡單。 比如說，我想確保 `Note` 的文字被修改時，`modifiedDate` 會更新，所以我們幫 `text` 增加一個 `didSet` 來修改 `modifiedDate`。 ```swift struct Note { let createdDate: Date var modifiedDate: Date var text: String = "" { didSet { modifiedDate = Date() } } init(date: Date = Date()) { self.createdDate = date self.modifiedDate = date } } ``` 測試就期望 `modifiedDate` 要比 `createdDate` 更晚。 ```swift @Test("When note text updated, modifiedDate also updated") func updateNoteText() { var sut = Note() sut.text = "New" #expect(sut.modifiedDate > sut.createdDate) } ``` 結果，你猜怎麼樣？會有一定的錯誤率。 ![錯誤結果顯示，有 93% 的情況 modifiedDate 並沒有 > createdDate。](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/CleanShot-2025-09-09-at-02.06.46@2x.png) 錯誤結果顯示，有 93% 的情況 `modifiedDate` 並沒有 > `createdDate`。 因為 `init()` 的 `Date()` 與 `didSet` 的 `Date()` 是分成兩次呼叫，但在**測試時有可能在系統時間的最小單位還沒切換之前，就連續被呼叫**，導致無法達成兩個時間之間 `>` 的條件。 這又是一個 **non-deterministic** 的情況，真頭痛。 我們先把這個問題暫時放一邊，再舉一個稍微複雜但實際的需求。 ## 再稍微複雜一點的需求 比如說，這個筆記 app，如果遇到 `Note` 的最後修改時間超過一個月，在畫面上的顏色就要變淡。 這種需求屬於畫面上的邏輯，我們可以另外寫一個 computed var，放在 extension。例如： ```swift extension Note { var isOutdated: Bool { // grayed out notes edited > ~one month Date().timeIntervalSince(modifiedDate) >= 30 * 86_400 } } ``` （請注意，30 \* 86400 不是一個很精準的一個月的定義。比較好作法是用 `Calendar` 做日期的計算，不過這邊我們可以先簡化。） 如果要進行測試的話，問題就大了。**我們要怎麼創造出一個修改日期超過一個月的 `Note`？** 上述的例子都還只是很簡單的 model 單元測試需求，但是遇到 `Date()` 這種由系統控制結果的東西，測試就變得幾乎無法撰寫，或是得不到決定性的結果。 顯然，我們不應該直接使用 `Date()`，而是要掌控「讀取當前系統時間」時，拿到的值。 ## 掌控時間 透過 Swift Dependencies，我們可以把前述的 `Date()` 都改寫成 `@Dependency(\.date.now)`，這是 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 內建的功能。然後在測試的時候就可以覆蓋掉了。 語法如下： _This post is for paying subscribers only._ ### 📦套件推坑：Swift Dependencies 超讚。它解決了哪些問題？ URL: https://ethanhuang13.plus/swift-dependencies-why/ Last updated: 2026-08-13T06:06:06.000Z 歡迎來到「套件推坑：Swift Dependencies」系列的第一篇。從這篇文章開始，我會介紹 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 這個我很愛用，且**幾乎無法不使用**的套件。 多年使用下來，我認為它是一個十分優秀的依賴注入套件，**適合幾乎任何 iOS 專案**，所以很想推坑給大家。 我會談**為什麼要使用（它解決了哪些問題）、有哪些重要功能、什麼情況下使用、介紹底層實作的機制**。 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 是由 [Point-Free](https://www.pointfree.co/?ref=ethanhuang13.plus) 團隊開發出的依賴注入的工具套件，它的語法參考了 SwiftUI 的 `@Environment`，並且大量運用於 [TCA](https://github.com/pointfreeco/swift-composable-architecture?ref=ethanhuang13.plus)。不過，[Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 可以完全獨立於 TCA 或 SwiftUI 使用。 每個實際運作的 iOS app 一定有無法控制的外部因素。舉例來說，提供地理定位服務的 app，需要使用者確認權限、裝置提供定位資訊。更簡單的例子如伺服器回傳的資料、系統時間、使用者偏好的語系、網路與藍牙連線狀況等等。 這些不可控制的因素，只能在 runtime 才能決定。開發者雖然可以事先寫好條件，但是直接讀取實際的值，很難進行測試，有些條件甚至需要重新安裝 app。反覆測試的話，非常沒有效率。 ## 分離正式與測試環境，控制外部條件 開發者要根據條件進行不同的處理。而這些條件如果直接綁在設備或使用者的設定上，就**完全無法撰寫測試**，來確保各種分支的邏輯正確。 一個常見的情況，是向使用者要求某種隱私權限。根據使用者同意、不同意，要進行對應的流程。我們可以寫一個 `LocationPermissionClient`，把正式與測試的版本分開來實作。 正式的實作，就依照系統 API，呼叫 `CLLocationManager` 的方法。 測試時，我們可以在不同 test func，指定要求權限之後回傳的結果是同意、還是不同意，方便寫出對應的後續測試。 ```Swift // Before: 無法測試的程式碼 if CLLocationManager.authorizationStatus() == .notDetermined { // 要怎麼測試這個分支？ } // After: 完全可控 @Dependency(\.locationClient) var locationClient if locationClient.authorizationStatus() == .notDetermined { // 測試時可以指定回傳值 } ``` 如此一來，我們就不需要反覆手動刪除 app 重裝來重現測試條件，而是**把所有外部條件都變成可控的**。 ## 解決 Preview 編譯緩慢問題 許多開發者都困擾 SwiftUI 的 Preview 更新速度太慢，不堪使用。 不過，其實這往往是因為 SwiftUI 的模組同時編譯了太多不必要的外部依賴。透過合適的模組化（可參考[🥇 SwiftUI + TCA 專案的模組化最佳實踐](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/)或是 [iPlayground app 的程式碼](https://ethanhuang13.plus/iplayground-open-source-app-story/)），可以大幅改善 Preview 的效率。 其中關鍵就是在於把 SwiftUI 不需要編譯的外部依賴分隔開。我的工具策略就是利用今天的主角 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus)。 _This post is for paying subscribers only._ ### 🤝研討會系列文章整理 URL: https://ethanhuang13.plus/conference-series-wrap-up/ Last updated: 2025-09-04T22:00:33.000Z iPlayground 2025 結束了。這段期間我寫了 9 篇文章，從事前準備到事後回顧、推坑理由、小故事一應俱全。無論你是否參加，都能從中找到適合自己的內容。讓我們快速回顧與總結： ## 為什麼要參加研討會？ [😇為什麼要參加技術研討會](https://ethanhuang13.plus/why-attend-tech-conferences/)給出了幾個實際理由，包括跳脫平時狀態、了解自己的技術實力與定位、獲得意外的收穫。 後續，我分享了過去[😇參加研討會的三個小故事](https://ethanhuang13.plus/tech-conference-memorable-stories/)，以及多年來觀察到[🇯🇵iPlayground 與日本 iOS 研討會的跨國火花](https://ethanhuang13.plus/iplayground-japan-connection/)。這些都是所謂參加研討會的意外收穫。如果你想看點輕鬆的故事，就從這兩篇讀起吧！ ## 實用指南 另外，如果你沒有參加過研討會的話，[😇做好準備，讓研討會更好玩](https://ethanhuang13.plus/iplayground-2025-preparation-tips/)是不錯的入門文章。 而[👋不擅長社交工程師的研討會生存小技巧](https://ethanhuang13.plus/conference-social-tips/)對於較為內向的朋友應該會有些幫助。 ## 技術重點 [📲iPlayground 開源 App 背景故事](https://ethanhuang13.plus/iplayground-open-source-app-story/)一文分享了使用到的一些技術細節。而[📖為什麼現在是學習 TCA 的最好時機？](https://ethanhuang13.plus/why-learn-tca-now/)顧名思義是一篇 TCA 推坑文章。 ## 講者幕後觀察 我發現不只是我，其他講者都反映出「人們在一些限制條件下，往往能產生更好的表現」這個道理。寫在[ 🗜️只給我講 20 分鐘？限制條件反而成就佳作](https://ethanhuang13.plus/constraints-create-excellence/)。 最後，我在這次 iPlayground 擔任收尾的講者以及選題，是有特別用意的。詳情請看[💪為何我選擇「個人軟體時代」作為 iPlayground 閉幕題目](https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/)。 ## 結語 這 9 篇文章從不同角度談論研討會，希望能夠給你一些啟發，並且期待在更多研討會看到你。如果你喜歡我的文章，不妨按讚並分享給更多朋友。 我計畫之後在 13+ 繼續用這種「大主題、多篇短文」的方式來寫作，敬請期待。也歡迎讀者回饋我有興趣的主題。 ### 🇯🇵iPlayground 與日本 iOS 研討會的跨國火花 URL: https://ethanhuang13.plus/iplayground-japan-connection/ Last updated: 2025-09-04T05:13:35.000Z 我多次鼓勵開發者去參加國外的研討會，會有許多意想不到的收穫。本文藉由 iPlayground 與日本 iOS 研討會之間的互動小故事，來增加一些說服力。也可以當作一些趣聞來閱讀。 > 本文刊出後來自 iPlayground 官方補充與更正：1\. 日本講者 Yusuke Kita 是自行投稿參加 2\. 鳳梨酥活動是熱心會眾 Alex Hu 自發性舉辦的 3\. 疫情期間 2020 iPlayground 有辦成（找不到2天的場地差點辦不成） ## 2017 年因為參加 iOSDC 而催生出 iPlayground 讀者可能聽過，iPlayground 成立是因為「2017年9月，一群到東京參加 [iOSDC](https://iosdc.jp/?ref=ethanhuang13.plus) 的工程師們，在看到國外蓬勃活躍的程式力，熱血自此被點燃，決心舉辦一場兼具廣深度又有趣的 iOS 研討會。」（摘錄自 [iPlayground 2019 年官網](https://iplayground.io/2019/?ref=ethanhuang13.plus) 上的介紹。） 是的，iPlayground 的誕生，完全是因為見識到「日本的開發者社群辦出十分有當地特色的研討會，我們也可以舉辦屬於自己的研討會」。 ## 2019 年首次邀請日本講者 2019 年，主辦單位邀請了一些日本的知名開發者如 [Kishikawa Katsumi (@k\_katsumi)](https://x.com/k%5Fkatsumi?ref=ethanhuang13.plus)、[Daiki Matsudate (@d\_date)](https://x.com/d%5Fdate?ref=ethanhuang13.plus)、[Yusuke Kita (@kitasuke)](https://x.com/kitasuke?ref=ethanhuang13.plus)，以及在日本（自行投稿）工作的[王巍(@onevcat)](https://x.com/onevcat?ref=ethanhuang13.plus) 來擔任講者。可以說是 iPlayground 國際化的起點。 補充當年一些有趣的紀錄： - [從 Tank Lin (@tank1005) 的合照推文可以看到當時大家的樣子](https://x.com/tank1005/status/1175816830792818688?ref=ethanhuang13.plus) - [鳳梨推文展現社群互動](https://x.com/ethanhuang13/status/1176745902473543680?ref=ethanhuang13.plus) - [Alex Hu 準備給外國朋友品嚐的鳳梨酥大賽](https://x.com/theiPlayground/status/1175293366105333760?ref=ethanhuang13.plus) - [我擔任宣傳組的心得串](https://x.com/ethanhuang13/status/1175971213560008704?ref=ethanhuang13.plus)，提到拉起 Twitter 使用率、合照活動、weak self podcast 跟開發者週報的起源 ## 2025 年與 try! Swift Tokyo 的連結 沒有想到因為疫情的緣故，2021-2023 iPlayground 都沒有辦成，中斷了交流。2024 年小規模重啟。今年 2025 年才恢復到以往規模，並且我看到不少與 [try! Swift Tokyo](https://tryswift.jp/en/?ref=ethanhuang13.plus) 研討會的互動與影響。 [Daiki Matsudate (@d\_date)](https://x.com/d%5Fdate?ref=ethanhuang13.plus) 現在是 try! Swift Tokyo 主辦人，今年再度來台灣參加 iPlayground 參加並擔任講者。他發了許多有趣的推文，例如[便當菜色跟六年前一樣](https://x.com/d%5Fdate/status/1962462266273804528?ref=ethanhuang13.plus)。 try! Swift Tokyo 曾在日本疫情爆發時，臨時決定停辦。原本有很多台灣人準備要參加（印象中超過十位），頗為遺憾。不過去年與今年，台灣有許多開發者去了 try! Swift Tokyo，也有不少人有興趣再參加明年的活動。 我去參加研討會時，都會開台灣人群組，把大家拉進來，集合照相。今年就有超過 20 位眼尖的讀者，可能會發現幾位朋友在這屆 iPlayground 擔任講者或工作人員。 ![台灣開發者在 try! Swift Tokyo 2025 Day 1 合照](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/IMG_0959.jpeg) 台灣開發者在 try! Swift Tokyo 2025 Day 1 合照 ![台灣開發者在 try! Swift Tokyo 2025 Day 2 合照](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/IMG_1015.jpeg) 台灣開發者在 try! Swift Tokyo 2025 Day 2 合照 而這次[我剛好坐在 Daiki san 旁邊](https://x.com/ethanhuang13/status/1961698051485307264?ref=ethanhuang13.plus)，看到他在[發推文](https://x.com/d%5Fdate/status/1962043225457463691?ref=ethanhuang13.plus)，我就[提議](https://x.com/ethanhuang13/status/1962051923831595444?ref=ethanhuang13.plus)把大家找來合照。最後就有了[這些照片](https://x.com/d%5Fdate/status/1962073534928499142?ref=ethanhuang13.plus)。 ![iPlayground 2025 台日開發者大合照](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/09/DSC04802.jpg) iPlayground 2025 台日開發者大合照 **2026/04/12-14 的 try! Swift Tokyo，我們可以在櫻花季集合🌸，再拍幾張像這樣的合照。不覺得這樣的跨國交流，別有一番浪漫嗎？** ## 技術方面的啟發 這次與 [Flitto](https://www.flitto.com/?ref=ethanhuang13.plus) 的即時翻譯技術合作，是幾位工作人員參加 try! Swift Tokyo 時體驗到效果很不錯，而去推動、促成的。相信許多有參加的朋友有體驗到它的優良效果。 Daiki san 用了 iPlayground app 以後，[補充了當初整合開發的背景故事](https://x.com/d%5Fdate/status/1962025990697390174?ref=ethanhuang13.plus)。 而如同我在[📲iPlayground 開源 App 背景故事](https://ethanhuang13.plus/iplayground-open-source-app-story/)一文提到的，App 的開源是受到 try! Swift Tokyo 的影響。這些我就不重複展開了。 ## 一句話帶走 **與各國的開發者社群有交流會催生出很多故事跟火花。很鼓勵台灣的讀者，除了 iPlayground 以外，也多去不同地方的研討會交流。** ## 延伸閱讀 - [😇為什麼要參加技術研討會](https://ethanhuang13.plus/why-attend-tech-conferences/)── 意外的收穫是一大魅力 - [😇參加研討會的三個小故事](https://ethanhuang13.plus/tech-conference-memorable-stories/) - [👋不擅長社交工程師的研討會生存小技巧](https://ethanhuang13.plus/conference-social-tips/)──結伴同行可以大幅降低難度 ### 📖為什麼現在是學習 TCA 的最好時機？ URL: https://ethanhuang13.plus/why-learn-tca-now/ Last updated: 2026-08-13T06:06:05.000Z 如果你剛參加完 iPlayground，對 [TCA](https://github.com/pointfreeco/swift-composable-architecture?ref=ethanhuang13.plus) 產生興趣，這篇文章幫你整理學習資源以及理由。 去年我在 iPlayground 演講的題目是「[🗣️Why SwiftUI? Why TCA?](https://ethanhuang13.plus/why-swiftui-why-tca-iplayground-2024-slides/)」。當時選這個題目，是希望把在公司團隊多年來使用 SwiftUI 與 TCA，作為 iOS apps 主要框架的經驗，分享給大家。 我給出的「Why TCA」理由是： 1. 😋已入坑，小孩愛吃，會再回購 2. 🚥能輕鬆寫出很關鍵的測試 3. 👮狀態集中管理 + 可組合 4. 👽優秀的外部依賴管理能力 5. 🤖適合搭配 AI 工具 當時的投影片我只有把檔案放在 13+，現在我也公開在 [SpeakerDeck](https://speakerdeck.com/ethanhuang13/why-swiftui-why-tca?ref=ethanhuang13.plus)。歡迎分享給更多人參考： 一年過去，TCA 在台灣社群的熱度明顯提升。iPlayground 就有兩場 TCA 相關的主題，儼然成為架構方面的熱門話題。 - YC Hsu 的 [What We Learned from Building a Production App with TCA](https://hackmd.io/@iPlayground/ry09yxMugg?ref=ethanhuang13.plus) - Art 的 [TCA 演化史：單向資料流如何繁衍成架構雨林](https://hackmd.io/@iPlayground/HkV0JxM%5Fxx?ref=ethanhuang13.plus) YC 提到是看了我在 2023 年底開始錄製的「[iOS 開發配飯吃 • SwiftUI + TCA 系列](https://youtube.com/playlist?list=PL%5FISTqHGWkNyN2qbc5wVDRyE6baEQ-BqU&si=vbkFi%5F5AGS4jTRdd&ref=ethanhuang13.plus)」影片學的。Art 則是與我一起經歷實戰的前同事。 除了上述影片系列，現在學習 TCA，又多了幾個中文資源可以參考： ## SwiftUI-TCA-Template [SwiftUI-TCA-Template](https://github.com/ethanhuang13/SwiftUI-TCA-Template?ref=ethanhuang13.plus) 是我結合了多年的 SwiftUI 與 TCA 實戰經驗而建立的 SPM 模版專案。iPlayground app 就是以此為基礎。 我在 2024 年底寫這篇[介紹文](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/)時，只有說明原理，一直到今年中才開源。所以當時讀過但尚未用過的朋友，可以重新參考。 ## iplayground-app-2025 [iplayground-app-2025](https://github.com/iplayground/iplayground-app-2025?ref=ethanhuang13.plus) 是開源的專案。 我在前幾天的文章 [📲iPlayground 開源 App 背景故事](https://ethanhuang13.plus/iplayground-open-source-app-story/)以及 iPlayground After Party 的 Lightning Talk 有提到，這應該是台灣社群比較有規模的開源 TCA sample project。 未來有機會的話，我會把這個專案拿來當成教材，錄製影片或寫寫文章。 但你不需要等我。想學 TCA 的話，請直接 clone repo、抓下來親自研究！ ```bash git clone https://github.com/iplayground/iplayground-app-2025 ``` ## Point-Free 最後，如果想認真把 TCA 學起來，我當然是推薦原作者 [Point-Free 官方](https://www.pointfree.co/?ref=ethanhuang13.plus)。 如果你還沒訂閱 Point-Free，**使用我的**[**推薦連結**](https://www.pointfree.co/subscribe/personal?ref=Bzfb7AYk)**，你我都可以獲得 $18 的 credit，相當於一個月免費**。 ## 我該學習 TCA 嗎？ 現在學習 TCA，外部條件已經齊備：框架穩定、資源豐富、社群討論度高。剩下的是你個人的內部條件。 如果你無法判斷是否該投資時間去學 TCA，這裡提供幾個簡單的判斷標準： _This post is for paying subscribers only._ ### 🗜️只給我講 20 分鐘？限制條件反而成就佳作 URL: https://ethanhuang13.plus/constraints-create-excellence/ Last updated: 2026-08-13T06:06:04.000Z 這次 iPlayground 有個我感受很深的講者幕後故事，與對應的道理：**人們在一些限制條件下，往往能產生更好的表現。** ## Paul 的演講比試聽時感覺好上 10 倍 Paul 是倒數第二位講者，在我之前。他的題目是「[Learning Engineering for Software Engineers](https://hackmd.io/@iPlayground/HJanOez%5Fel?ref=ethanhuang13.plus)」，是很有深度的主題。 我十分欣賞他在台上的表現，把複雜的學習工程介紹清楚、侃侃而談。相信聽眾能感受到，這個主題底下有很多值得探究的內容，並且被他的自信所吸引。 這場研討會由於整體時間的限制，許多場次只有 20 分鐘。對於有很多內容的講者來說，是極大的挑戰。為了確保演講品質，我約了幾位講者進行演練，其中就包括 Paul。 演練的時候，Paul 十分苦惱。他表示，已經砍掉 2/3 想講的東西，但內容還是太長。我們試聽的幾位朋友給了他許多參考意見，老實說我有點擔心，但也只能期待他本人做出最佳取捨。 而最終版本，我驚訝地發現，聽起來感覺比試講時好上 10 倍。是由節奏、概念轉換、投影片的字數與頁數的刪減，以及台風，共同組成的效果。 **對於創作者來說，有太多想法要表達，卻因為長度限制，不得不刪減，是很痛苦的過程。但是這種限制，反而使得最終成果被逼著成為最有重點、最好理解的版本。** ## 其實我也是 我第一次在準備試講時產生了 12,000 的逐字稿，可以講滿一個小時。即便去掉口語也有 8,000 字，但最後版本不到 5,000 字。 我刪掉了很多不必要的鋪陳與舉例，但是重點反而更凸顯了。逼著自己抓住聽眾每一秒注意力而濃縮出的版本，遠比剛開始的長篇大論好得多。 ## 有沒有辦法用一句話描述這件事物是什麼？ 「用限制來產生更好結果」的道理，在 iPlayground 其他角落也上演著。 _This post is for paying subscribers only._ ### 💪為何我選擇「個人軟體時代」作為 iPlayground 閉幕題目 URL: https://ethanhuang13.plus/iplayground-2025-closing-personal-software-era/ Last updated: 2025-08-31T22:00:05.000Z iPlayground 2025 順利落幕了。接下來一週，我打算分享幾個幕後花絮。 今天先來說，我選擇「個人軟體時代」作為 iPlayground 閉幕題目的理由。 ![13 在 iPlayground 演講的照片](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/IMG_6903.jpg) 我在 iPlayground 2025 的講台 文章主要寫給聽過這場演講的朋友，**不會把演講的主要論點再說一遍**。沒參加的讀者可以透過[投影片](https://speakerdeck.com/ethanhuang13/ge-ren-ruan-ti-shi-dai?ref=ethanhuang13.plus)和 [HackMD 共筆](https://hackmd.io/xmjNOLSKSKOWzTeVQxzXCQ?view&ref=ethanhuang13.plus)了解演講內容。 ## 初衷：緩解 AI 焦慮，作為研討會收尾 我的初衷很單純：因為看到這個時代，許多人有「AI 焦慮」，想做出一場緩解大家 AI 焦慮的閉幕演講。 於是自告奮勇，希望給這屆 iPlayground 做個好的收尾。 ![感謝大家的厚愛 我還沒填表單 但是有跟 @DinDin 聊了一個題目方向： 「AI 時代，iOS 工程師的焦慮、優勢，與機會」 我本來是想自己去做意見調查再確定題目 不過，如果這種軟性主題是大家想聽的，我覺得頗適合當作「收尾」，Keynote 的機會則可以留給其他人](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-09-01-at-00.35.25@2x_.png) 兩個月前，我確定了「照顧自己的需求，做屬於自己的軟體」這樣的主軸，寫完第一大綱以後，就在腦中持續醞釀。直到 iPlayground 前兩週，才開始整理正式大綱。 投影片在最後幾天才製作（因為我優先開發 iPlayground app。這使得「講者 13 」很想揍「App 開發者 13」），一直到演講前幾小時才定稿。 ## 行動提示 在準備講題的過程中，我意識到光是舉出一些個人軟體例子還不夠，要給大家一些具體行動提示。 我的主要論點是：**去做一些滿足自己需求的軟體、side projects，就有機會使用各種 AI 工具，就不容易焦慮了。** 也就是說，第一步是要先了解自己需求，接下來是要採取行動。 於是，我在投影片尾聲寫下這些行動提示： **今天回家的路上，想一下你可以開始做什麼給自己的軟體。** - 基本版：滿足自己單點需求的軟體 - 進階版：打造一個符合自己的工作/生活流程，讓自己變強、又好玩的系統 至於中間各種論點與舉例，請參考[投影片](https://speakerdeck.com/ethanhuang13/ge-ren-ruan-ti-shi-dai?ref=ethanhuang13.plus)。 ## 獲得許多回饋，看起來有達成目的 散場時，一些朋友過來說很有啟發、被激勵到、要來做個人軟體了。我也在網路上看到一些貼文或訊息。許多人都表示會去採取行動： ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-31-at-22.40.10@2x.png) > [Vicky Ciou](https://x.com/vicky%5Fciou/status/1962156609062453264?ref=ethanhuang13.plus): 今天有被 13 大大給激勵到。準備想一個為自己而寫的小 App 來開始！ > [Krauser](https://x.com/Crescentdence/status/1962144392866931031?ref=ethanhuang13.plus): 13’s closing summary was the perfect way to wrap up the event. > 匿名會眾在 [HackMD](https://hackmd.io/xmjNOLSKSKOWzTeVQxzXCQ?view&ref=ethanhuang13.plus): 13 的這個主題實在太浪漫了！！！ > 我覺得這類主題也很重要也很有意義，沒有心理健康生活也不會健康，生活不健康寫出來的扣也不健康 看起來有達成我當初設定的目的：鼓勵大家用照顧自己的行動，來幫助自己對抗焦慮。 能夠給大家一些啟發，我真的很開心。也很謝謝 iPlayground 與整體社群給我機會做這樣的演講。 期待看到更多人開始他們的個人軟體之旅！ ## 隱藏主題 其實我有一頁投影片沒有放，因為我還沒有想清楚要怎麼解釋，只是隱約地有這個感覺：「在 AI 時代，更應該關注人性」。 也許這句話是整個演講的隱藏主題吧！等我想得更清楚再寫成獨立文章。 ## 其他補充 1. 「滿足自己的私慾」是在台上突然講出來的。其實我本來的用詞只是「滿足自己的需求」，不過這樣好像更令人印象深刻？ 2. 還有很多例子，因為時間不夠而刪除了。比如[蔡依林標準時間](https://jolinsleeptime0930.online/?ref=ethanhuang13.plus)、[焦慮戳戳樂](https://apps.apple.com/tw/app/%E7%84%A6%E6%85%AE%E6%88%B3%E6%88%B3%E6%88%B3-%E8%A8%98%E9%8C%84%E4%BD%A0%E7%9A%84%E7%84%A6%E6%85%AE%E6%AC%A1%E6%95%B8/id6743371838?ref=ethanhuang13.plus) 3. 在說到「SaaS」時，用了戴口罩 emoji 😷 作為諧音爛梗（SARS...），沒想到大家笑了 4. 現場有不少 [weak self podcast](https://weakself.dev/?ref=ethanhuang13.plus) 聽眾。波肥出現在我那頁「把咖啡轉換成程式碼的...（工具人）」。而喬喬則是透過 [@Tatsuz0u](https://x.com/Tatsuz0u?ref=ethanhuang13.plus) 遠從日本帶來的設備，以[「罐頭音效」](https://x.com/weak%5Fself/status/1961678366840688920?ref=ethanhuang13.plus)的形式出現，產生了不錯的笑果。非常謝謝他 ### 😇做好準備，讓研討會更好玩 URL: https://ethanhuang13.plus/iplayground-2025-preparation-tips/ Last updated: 2025-08-28T22:00:41.000Z 明天就是 iPlayground。要參加的朋友，除了[官方寄出的行前通知](https://iplayground.substack.com/p/2025-notice-app-sponsors)必看以外，我也寫了一些個人的小小提醒。 ## 下載官方 App [按這裡從 App Store 下載](https://apps.apple.com/tw/app/iplayground-2025/id6751350620?ref=ethanhuang13.plus)，裡面有許多實用連結。除了 iOS 以外，此 app 也支援 Apple Silicon Mac。 我在寫這段文字時，Widget 功能已經開發完畢，能顯示當前與後續議程。如果新版來得及更新到 App Store，就可以派上用場。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-29-at-00.23.38@2x.png) 如果你閒來無事，或是沒機會參加這次研討會，可以去翻翻 [source code](https://github.com/iplayground/iplayground-app-2025?ref=ethanhuang13.plus)😂 我沒有因為趕時間而隨便寫，裡面有很多 SwiftUI 的寶藏可挖。 ## 預估行程、提早抵達 這次的地點在「[政大公企中心](https://maps.app.goo.gl/Yw4ZaVtQL8aJoYU3A?ref=ethanhuang13.plus)」，讓不熟悉的朋友會直覺聯想到在「政大校本部」。實際上地點差了十萬八千里。 App 裡面有地圖跟環視，方便打開你 Apple Maps 或 Google Maps。這樣就一定不會跑錯了。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-28-at-23.57.15@2x.png) 有點囉唆的提醒，但我認真覺得：**參加活動盡量提早到，更容易進入狀況，心情會更好。今晚就早點睡吧！** ## 研究議程 這次議程只有一軌，沒得選，不用換場地。 不過，還是可以看一下哪些議程是比較有興趣的，分配體力。 ## 留意特殊活動 第一天晚上有 After Party 與 Lightning Talk。另外還有轉盤抽抽樂、紀念印章蒐集、問卷填寫等等。有下載 app 的話，從「我的」分頁進去就可以快速跳轉。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-29-at-00.00.25@2x.png) 贊助商的攤位也會有精彩的活動，可以多加留意。 ## 個人設備 會場不一定有網路跟電源，所以最好自備行動電源。 ## 衛生小提示 夏天天氣熱，記得帶水瓶、多喝水。容易流汗的朋友可以準備一些應對措施。 另一方面，因為人數眾多，帶著口罩以備不時之需，也是個衛生好習慣。 ## 準備好心情 就如我前幾天的文章所說，參加研討會是很特別、很愉快的經驗。養足精神，好好享受吧！ ## 行動提示 下載官方 App、預習活動時間表與交通資訊、提前抵達，用愉快的心情享受兩天的活動！ ## 延伸閱讀 - Medium: [如何讓你的 iPlayground 更好玩](https://medium.com/@ethanhuang13/%E5%A6%82%E4%BD%95%E8%AE%93%E4%BD%A0%E7%9A%84-iplayground-%E6%9B%B4%E5%A5%BD%E7%8E%A9-769a3f72d6cf?ref=ethanhuang13.plus) （2018 年撰寫） - [👋不擅長社交工程師的研討會生存小技巧](https://ethanhuang13.plus/conference-social-tips/) - [📲iPlayground 開源 App 背景故事](https://ethanhuang13.plus/iplayground-open-source-app-story/) ### 👋不擅長社交工程師的研討會生存小技巧 URL: https://ethanhuang13.plus/conference-social-tips/ Last updated: 2026-08-13T06:06:03.000Z 讀者可能會覺得，像 13 這麼愛發表文章、主持 Podcast、錄 YouTube，應該是很外向的人吧。實際上，我超不擅長閒聊，在現實生活跟一群人相處時，通常都是最安靜的那個。**在現實講話的難度，跟在網路上差太多啦！** 如果你跟我的情況類似，甚至有點「社恐」，參加研討會的時候該如何是好？ 先說，雖然我一直鼓勵大家在研討會多互動、認識新朋友，但是如果兩天下來都沒有聊到什麼天，也完全沒問題！**用自己舒服的方式參與、享受其中，才是最重要的。** 但如果，你內心是想跟大家互動，只是有點卻步，我今天準備了幾個小技巧。 ## 結伴同行 最基本降低難度的方式，就是找朋友或同事一起參加。（iPlayground 有「[結伴同行票](https://iplayground.kktix.cc/events/2025general?ref=ethanhuang13.plus)」，應該就是為了這種情況設計的。） 問一下自己認識的人會不會去，這樣到了現場遇到熟人，就可以立刻安心一些。 ## 觀察參加者名單，事先想好要打招呼的人 研討會都會公布講者、工作人員，甚至列出參加者名單（iPlayground 的在[網頁](https://iplayground.kktix.cc/events/2025general?ref=ethanhuang13.plus)最下面）。如果有你特別想認識、或打招呼的對象，可以先**確認一下對方最近在研究什麼**，或是發表過什麼東西令你印象深刻。碰面時，就可以提出來，不會缺乏話題。 我在國際研討會看到一些高手，第一次打招呼都會猶豫很久才鼓起勇氣。最實際的作法就是確認他們最近在做什麼，來開啟話題。 比如我在 WWDC19 Keynote 結束後，偶然第一次碰到 [Paul Hudson](https://x.com/twostraws?ref=ethanhuang13.plus)。當時 Apple 才剛發表 SwiftUI。我就問他說「你是否準備要推出 Hacking with SwiftUI？」，因為他的「[Hacking with Swift](https://www.hackingwithswift.com/?ref=ethanhuang13.plus)」教材非常實用，眾所周知。而他也馬上回答我說：「沒錯，我已經準備好要...」。就是一次簡短、順利、愉快的互動。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/77FF84C0-0FE4-47A2-9492-164CB39685B3_1_102.jpeg "Met Paul Hudson in WWDC19") ## 給講者肯定 令我印象深刻的講者，我常常會在聽完演講以後，公開發推文給予肯定與感謝。有機會再找他們聊天。 很多講者看起來台風穩健、經驗豐富，其實私底下緊張到不行。就算是再厲害的人，被肯定還是很開心的事。而且稍後如果有機會面對面聊天，就會更容易一點。 ## 準備 Link in Bio 軟體工程師很少會用到名片這種東西，公司印了一兩盒，永遠發不完。 你有個人網址、GitHub、常用的 SNS 帳號，可以準備好 QR Code 的形式讓別人快速交換資料，比實體名片好用。 我自己是用 [Gravatar](https://gravatar.com/ethanhuang13?ref=ethanhuang13.plus)，內建 QR Code。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/ethanhuang13.qr.png) 有些人則是會使用 [Linktree](http://linktr.ee/?ref=ethanhuang13.plus)（但我覺得對於工程師來說沒有很好用）。 這類型的服務很多，提早開個帳號，把公開聯絡方式準備好，會事半功倍。 ## 合照 _This post is for paying subscribers only._ ### 📲iPlayground 開源 App 背景故事 URL: https://ethanhuang13.plus/iplayground-open-source-app-story/ Last updated: 2025-08-26T23:47:44.000Z 今年 iPlayground，我自告奮勇接下了 iOS app 的開發（[按這裡下載](https://apps.apple.com/tw/app/iplayground-2025/id6751350620?ref=ethanhuang13.plus)）。開發背後的一些小故事，我覺得可以拿出來分享，就寫了這篇文章。 ## 接手理由 參加 [try! Swift Tokyo](https://tryswift.jp/?ref=ethanhuang13.plus) 時，發現它們的 [app](https://apps.apple.com/tw/app/try-tokyo-2025/id6479317240?ref=ethanhuang13.plus) 做得不錯，而且有[開源](https://github.com/tryswift/try-swift-tokyo?ref=ethanhuang13.plus)。在第一天活動時，遇到 app 有個使用者體驗上的困擾，但應該不難修。想說我如果能修好，可以去發個 PR。 結果等想到時上去一看，已經有人發了 PR 搞定了。**這就是一個熱衷開發的社群會有的樣貌，真的很貫徹開源精神，我覺得超棒**。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-27-at-00.30.14@2x.png) 另一方面，try! Swift Tokyo 的 app 使用 SwiftUI 與 TCA，跟我熟悉的框架一模一樣。於是產生了一個念頭：如果我來寫 iPlayground 的 app，也許有機會**在國際 iOS 社群之間做個比較、互相學習**。 再者，雖然我錄製過多集的 [iOS 開發配飯吃 • SwiftUI + TCA 系列](https://www.youtube.com/playlist?list=PL%5FISTqHGWkNyN2qbc5wVDRyE6baEQ-BqU&ref=ethanhuang13.plus)，也寫過一些 [TCA 相關文章](https://ethanhuang13.plus/tag/swiftui-tca/)，但是從來沒有一個比較複雜的開源 app 作為範例。這會是個很實際的 sample project。 ## 規劃與資料準備 一個研討會的 app 會有哪些功能，不難想像。主要就是顯示議程、講者、工作人員、贊助商、場地資料，以及重要連結等等。 [iPlayground 的官網](https://iplayground.io/2025?ref=ethanhuang13.plus)已經使用一個[開源 repo 放一些 JSON 檔](https://github.com/iplayground/SessionData/tree/2025/v1?ref=ethanhuang13.plus)，所以 app 只需要沿用即可。 不過我想說，既然是 JSON，如果多人協作時不小心改壞就不好了。就用 Claude Code 寫出一個 Swift Package，用 `Codable` 確保資料欄位，並且寫一些測試來確保格式與欄位正確。 這些 GitHub Actions 的 CI 工作流程，都可以在[這裡](https://github.com/iplayground/SessionData/actions?ref=ethanhuang13.plus)看到。比較有趣的是，這邊用的是 Ubuntu 的 runner 來跑測試，而不需要 Mac。算是利用了一下 Swift 跨平台的特性。 ## 注入現在時間，進行時空跳轉 上述的部分，我有在開發時直播與錄影（作為宣傳活動的手段）展示，都在這個[ iOS 開發配飯吃 iPlayground 2025 App 開發特別篇播放清單](https://www.youtube.com/playlist?list=PL%5FISTqHGWkNxp2k6N1Qg-xkt-vRCeXFYq&ref=ethanhuang13.plus)。 後面的部分，因為時間的因素，就沒有錄影了。以下我用文字補充。 有一個比較特別的巧思：app 主要是在研討會期間使用，只要對照時間表，可以得知顯示當前的活動進展。所以我們在議程列表放置了一個目前、下一個、下下一個活動內容的小區塊。而且可以按下去，直接跳轉到列表。 像這樣的功能，一定得測試。最好是能在 SwiftUI Preview 就可以直接操作不同時間點的效果。 我使用了 Point-Free 的 [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies?ref=ethanhuang13.plus) 來注入「現在」。透過修改 `@Dependency(\.date.now)` 讀出的時間，就可以做時空跳轉。 這是我覺得非常重要的技巧。相關程式碼可以從[這裡](https://github.com/iplayground/iplayground-app-2025/blob/22afb872a78fa7ca76129502d05d73d429cf551c/Sources/Views/Today/TodayView.swift?ref=ethanhuang13.plus#L240)開始看起。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-27-at-00.42.36@2x.png) ## 場地資訊用上了台灣街景 另一個有用到的好玩技術，是 Apple MapKit 的 Look Around。 Google Maps 的街景功能，在 Apple Maps 叫做 Look Around（環視）。2023 年 9 月底，[Apple Maps 在台灣有完整的環視功能](https://www.apple.com/tw/newsroom/2023/09/apple-rolls-out-all-new-map-across-taiwan/?ref=ethanhuang13.plus)，所以開發者可以免費拿來用。效果很好、實作起來也很簡單。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-27-at-01.21.17@2x.png) 展開的效果，請看我[推文上的錄影](https://x.com/ethanhuang13/status/1959518879568593281?ref=ethanhuang13.plus)。 實作的程式碼，則是在[這邊](https://github.com/iplayground/iplayground-app-2025/blob/22afb872a78fa7ca76129502d05d73d429cf551c/Sources/Views/AboutView.swift?ref=ethanhuang13.plus#L112)。我為了要讓它符合 Swift Concurrency，所以在[載入時](https://github.com/iplayground/iplayground-app-2025/blob/22afb872a78fa7ca76129502d05d73d429cf551c/Sources/Views/AboutView.swift?ref=ethanhuang13.plus#L146)先在 `Task.detached`，再切回 `Task { @MainActor in`。如果你知道更好的方法，可以跟我分享。 ## 使用到的 AI 工具 這次我用得比較多的 AI 工具反而是 Cursor，因為 SwiftUI 我還是自己寫，然後用 Cursor 的自動完成來加速。這個過程還是跟以前一樣舒服。 至於 Claude Code，主要是用來幫忙完善 TCA 的測試覆蓋。 另外，這次 iPlayground 使用了跟在 try! Swift Tokyo 一樣的 Flitto 翻譯服務，所以我有稍微參考一下如何實作，但看起來他們的 app 只是將 SDK 的 sample code 稍作修改 。 那樣當然是可以用。但為了好玩，我花了一點時間**用 Claude Code 把 sample code 的 view model 改成 TCA 的 reducer**。 主要卡住的點在於，Flitto SDK 是 xcframework。所以，我自己把 header 翻出，貼給 Claude Code 去參考，不然它會一直瞎猜 property name。其他的部分就很順利了。 ## 行動提示 - 從 iPlayground [SessionData](https://github.com/iplayground/SessionData?ref=ethanhuang13.plus) 與 [App](https://github.com/iplayground/iplayground-app-2025?ref=ethanhuang13.plus) 的 Repo 參考：CI 設定方式、模組的切法、TCA 的用法，以及 AI 工具在 PR 的互動等 - 到 App Store [下載 iPlayground iOS App](https://apps.apple.com/us/app/iplayground-2025/id6751350620?ref=ethanhuang13.plus) - 如果遇到問題，請[發 PR 給我們](https://github.com/iplayground/iplayground-app-2025/compare?ref=ethanhuang13.plus) ## 延伸閱讀 - [🗣️Why SwiftUI? Why TCA?─iPlayground 2024 演講投影片](https://ethanhuang13.plus/why-swiftui-why-tca-iplayground-2024-slides/) - [🥇SwiftUI 讀完就入坑 #9 SwiftUI + TCA 專案的模組化最佳實踐](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/) - GitHub: [iplayground/SessionData](https://github.com/iplayground/SessionData?ref=ethanhuang13.plus) - GitHub: [iplayground/iplayground-app-2025](https://github.com/iplayground/iplayground-app-2025?ref=ethanhuang13.plus) - YouTube: [iOS 開發配飯吃 iPlayground 2025 App 開發特別篇](https://youtube.com/playlist?list=PL%5FISTqHGWkNxp2k6N1Qg-xkt-vRCeXFYq&si=qjhCETywXMOLwcCH&ref=ethanhuang13.plus) ### 😇參加研討會的三個小故事 URL: https://ethanhuang13.plus/tech-conference-memorable-stories/ Last updated: 2026-08-13T06:06:02.000Z 我參加過的軟體技術研討會算不少了。從美國的 WWDC、[AltConf](https://x.com/altconference?ref=ethanhuang13.plus)，台灣的 [iPlayground](https://iplayground.io/?ref=ethanhuang13.plus)、[COSCUP](https://coscup.org/?ref=ethanhuang13.plus)、[MOPCON](https://mopcon.org/?ref=ethanhuang13.plus)，以及亞洲各地的 [iOSDC Japan](https://iosdc.jp/?ref=ethanhuang13.plus)、[try! Swift Tokyo](https://tryswift.jp/?ref=ethanhuang13.plus) 、[Let's visionOS](https://letsvisionos24.swiftgg.team/?ref=ethanhuang13.plus)、[iOS Conf SG](https://www.iosconf.sg/?ref=ethanhuang13.plus)。 參加研討會有太多意外與驚喜。比如說，在現場認識的新朋友，後來變成同事的，至少就有 3 位。還有 2 位朋友是在國外初次認識，後來才知道他們搬到台灣了。 在研討會認識新朋友常常有後續。除此以外，我今天想分享三個小故事。 ## 在 WWDC 跟 Apple 員工合照，害對方惹上麻煩 2016 年是我第一次去 Apple 的 WWDC。 WWDC 有所謂的 Lab，就是面對面跟 Apple 員工諮詢各種問題的地方。不光是技術問題有 Lab 可以諮詢，產品設計與商業方面，也有對應的 Lab。大部分 Lab 都需要事先預約，會有人管控出入。雖然叫做 Lab，其實就是在展場臨時圍起來一塊區域。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/61716248-6296-4712-A71F-28DC79D9BE60_1_105_c.jpeg) 因為是公司出錢，當然會有出差任務。不過，我當時沒有技術的問題要問，所以就去 App Store Review Lab，問一下上架相關的問題。 _This post is for paying subscribers only._ ### 😇為什麼要參加技術研討會 URL: https://ethanhuang13.plus/why-attend-tech-conferences/ Last updated: 2026-08-13T06:06:01.000Z 這週六、日，在台灣有一年才有一次的 Apple 開發者研討會──[iPlayground](https://iplayground.io/2025?ref=ethanhuang13.plus)。 所以，從今天到週五，我安排了一系列的專題來談開發者研討會的事，包括參加有什麼好處、經驗分享、籌備背景故事、參加準備小技巧等等。 接下來，我就要說明，為什麼你應該把握參加研討會的機會。 ## 理由一：跳脫平時的狀態 工作與生活的模式若是一成不變，腦袋容易僵化。有可能變得焦慮或是厭世。 去參加研討會，脫離平時工作與生活的範圍，獲得新的刺激，有時候本來困擾自己的問題可能就這樣解決了。 我去過 4 次 WWDC，後來因為疫情，好久都沒有機會參加國際研討會。一兩年前，工作方面的心理狀態不是很好的時候，去參加研討會獲得的刺激，對於恢復狀況有很大的幫助（參見[🎆2024 年終回顧與感謝](https://ethanhuang13.plus/2024-year-end-review-thanks/)）。**恢復每年去研討會的習慣，我就更容易找回自己的節奏。** ## 理由二：了解自己的技術實力與定位 有些人想到技術研討會，可能會當成去上課、去學習。 但是上課跟學習，平時就有很多管道了。研討會特別的地方在於，講者是精挑細選出來的，有一定的水準、一字排開。現場又有許多的聽眾，會即時做出反應。 每當講者提到的一個概念，不妨**觀察一下現場其他人的反應、跟自己的理解程度**。對照一下，就可以大致上理解到自己的相對水準。 如果有不足之處，就知道要加強什麼。如果發現自己懂的其實不比講題內容還少，表示你有一定的實力了，也許下一次能投稿當講者呢。 ## 理由三：意外的收穫是一大魅力 **有時候，人生當中那些無法規劃的事物，才會留下最美好的回憶。** _This post is for paying subscribers only._ ### 🤝與 AI 進行建設性溝通 URL: https://ethanhuang13.plus/constructive-communication-with-ai/ Last updated: 2026-08-13T06:06:00.000Z 我最近看到[一則推文](https://x.com/danshipper/status/1957469842178441523?ref=ethanhuang13.plus)提到，他們公司使用 AI 工具開發軟體，發展出一個工程哲學叫做 [Compounding Engineering](https://every.to/source-code/my-ai-had-already-fixed-the-code-before-i-saw-it?ref=ethanhuang13.plus)（中文也許能翻成複利工程）。 [我覺得很有趣](https://x.ethanhuang13/status/1957886998011875378?ref=ethanhuang13.plus)，因為這個就是我在使用 AI 工具時，很自然會做的事情。簡單來說，當你要求 AI 寫程式，而它偏離預期方向時，要去討論怎麼樣把規範定義地更清楚，這樣以後 AI 犯錯的機率就會越來越少，甚至可以更早辨識出可能犯錯的地方，開發就會越來越有效率。 ## AI 容易犯錯但能溝通的例子 一些 AI 模型雖然聰明，但沒有最新的知識。我很常遇到的是 Claude Code 去使用舊版 TCA 的語法，而我希望它採用新的。所以我會在 CLAUDE.md 放上新版語法的範例，作為規範。 或者是，在執行測試時，Claude Code 會優先使用 `swift test`。但我的專案是 iOS 專案，需要用 `xcodebuild test`。這種指令範例，我也會寫在 CLAUDE.md 裡面。 ## 我的自訂指令實例 當我遇到 Claude Code 偏離預期方向時，會打斷它並且修正指令。如果情況很嚴重，就會事後跟它討論問題出在哪、如何避免之後類似問題再發生。 以下是我的自訂指令： _This post is for paying subscribers only._ ### 🤖我的 AI 工具使用現況（2025 年 8 月） URL: https://ethanhuang13.plus/my-ai-tools-usage-202508/ Last updated: 2026-08-13T06:05:59.000Z 上個月我寫了一篇[🤖我的 AI 工具使用現況（2025 年 7 月）](https://ethanhuang13.plus/my-ai-tools-usage-202507/)。一個多月過去了，變化滿大的，以下跟讀者分享。 我目前幾乎每天都會使用的 AI 工具有： - Claude app：幾乎完全取代了 ChatGPT app - Claude Code：完全交給 AI Agent 寫程式時的最好選擇 - Cursor：自己寫程式時，依然有最佳的自動完成效果。另外也是我的文件編輯器 - 免費的 Spokenly 取代了 Wispr Flow - 取消訂閱了直播與錄影工具 Riverside，改用 OBS + Spokenly ## Claude app 的專案功能可以讀取 GitHub Repo 我喜歡使用它的專案功能，可以讀取 GitHub Repo 的指定資料夾下的所有內容。比如說「13+」這個寫作專案，我把文章都放在一個 Repo，Claude 就可以直接讀到最新內容，在對話討論中要讓 Claude 拿之前的文章內容出來參考，就很有效率。 值得一提的是，我發現，目前 repo 如果有新的內容，Claude 不會自動讀取最新的 commit。要在桌面版或網頁版（手機版看不到這個選項）按一下同步按鈕才行，希望之後能夠改良成自動更新，就會更省事。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/08/CleanShot-2025-08-20-at-19.47.16@2x.png) ## 取消訂閱 ChatGPT Plus 是因為失去控制感 我的訂閱大概還有一個月的有效時間，但現在已經很少使用了。 思考一下背後的原因，主要是因為 GPT-5 推出。它會自動判斷要使用什麼模型跟思考方式，減少使用者切換的麻煩。但是過去手動切換 o3 跟 4o，可以**明確預期** AI 的思考深度與回應時間，才是我想要的。 不過，退訂 ChatGPT Plus 不是什麼大事。有需要的話，我隨時都會訂回來。 ## Claude Code 的用途十分多元 我使用 Claude Code，不只是在開發軟體專案。還包括生成 script、指令、安裝新學習的工具，或是討論我的寫作專案。 在這邊重點向讀者介紹：**Claude Code 的 GitHub Actions 功能**（[官方文件](https://docs.anthropic.com/zh-TW/docs/claude-code/github-actions?ref=ethanhuang13.plus)）。 _This post is for paying subscribers only._ ### 🚀採取行動才能改變狀態 URL: https://ethanhuang13.plus/change-state-by-action/ Last updated: 2026-08-13T06:05:58.000Z 許多讀者知道，我在開發 SwiftUI 專案時，幾乎都會搭配 [TCA(The Composable Architecture)](https://github.com/pointfreeco/swift-composable-architecture?ref=ethanhuang13.plus) 這個框架。 SwiftUI 的畫面由狀態驅動。改變狀態，就會改變畫面。而 TCA 能把狀態管理得很好。這是因為，在 TCA 的設計上，任何狀態（`State`）修改，都只能在叫做 `Reducer` 的單元裡面執行。而要進到 `Reducer`，只能從發生行動（`Action`）開始。 用一句話來說：使用者的操作或系統事件 → `Action` → `Reducer` 依照邏輯來改變 `State` → SwiftUI 的畫面更新。 這個設計是限制，也是它能把狀態管理做好的原因，因為你完全無法從外部去干擾狀態，一切都要從 `Action` 來觸發。 換句話說，**要改變狀態，就必須從行動開始**。 某天我突然想到，人生不也是這樣嗎？ _This post is for paying subscribers only._ ### 🧩拆分任務到可以執行的程度 URL: https://ethanhuang13.plus/breakdown-to-doable/ Last updated: 2026-08-13T06:05:57.000Z 如果你覺得有些事情很困難到不想去做，不妨嘗試這個策略：**把任務拆分到可以輕鬆踏出第一步**。 只要可以被拆解，難度就會直線下降。 想換工作？需要準備履歷資料、練習面試，甚至有可能要刷題。這些事情都很麻煩，但一定有可以開始執行的第一步。閱讀我之前這篇[🤖你的 ChatGPT 裡應該要有個履歷專案](https://ethanhuang13.plus/chatgpt-project-for-resume-writing/)，就是開始準備履歷資料的好方法。 _This post is for paying subscribers only._ ### 🤔計畫模式不是 AI 專屬的用法 URL: https://ethanhuang13.plus/plan-mode-like-a-pro/ Last updated: 2026-08-13T06:05:56.000Z 許多人開始使用 AI Agent 以後，都會發現，先切換到 Plan Mode 來討論計畫，再開始執行，效果會比一開始就直接做好很多。 如果你沒有用過 Plan Mode，以 Claude Code 來說，就是按 Shift + Tab 切換模式到 Plan Mode，此時輸入的內容會變成在討論計畫，而不是直接執行指令。Claude 會提出計畫，並且可以反覆討論，直到你覺得看起來合理，再開始執行。 這種先計畫再執行的工作模式，其實不是 AI 專屬的用法，而是專業的腦力工作者常見的工作方式。 _This post is for paying subscribers only._ ### 🔍追求否定意見，降低犯錯風險 URL: https://ethanhuang13.plus/negative-feedback-reduces-errors/ Last updated: 2026-08-13T06:05:55.000Z 你可能遇過一些人用 ChatGPT 上癮，事事參考 AI 的意見，甚至信奉為真理。我認為，當一個人說：「ChatGPT 沒有否定我的意見」，比另一個人說：「ChatGPT 同意我的意見」，顯得更有智慧。 你也知道 AI 常常會提供「幻覺」。讓我告訴你，怎樣有效利用它的知識，但不被騙。 ## 熟悉領域 vs 陌生領域的錯覺 許多人在使用 AI 工具時，都會有一種「感覺」：我不熟悉的東西，AI 好像很厲害；我懂的東西，AI 就不行了。 這個現象的原因很單純：只有足夠的知識，我們才能做出正確的判斷。那種 AI 在陌生領域「很厲害」的感覺，其實只是錯覺。 既然這樣，我們如果拿 AI 工具來學習、來確認一些事情，就很容易被誤導。其實同樣的情況不僅限於 AI，毫無保留地接受他人意見，也很容易被騙。 ## 波普爾的否證啟發 哲學家[卡爾·波普爾](https://zh.wikipedia.org/zh-tw/%E5%8D%A1%E5%B0%94%C2%B7%E6%B3%A2%E6%99%AE%E5%B0%94?ref=ethanhuang13.plus)反對「從觀察到歸納」的求知方法，提出[「否證」](https://zh.wikipedia.org/wiki/%E5%8F%AF%E8%AF%81%E4%BC%AA%E6%80%A7?ref=ethanhuang13.plus)的概念。他認為：再多的證據都無法歸納出真理，因為你還沒有看到特例。 比如說，「綿羊都是白色」這句話，是因為你沒見過其他顏色的綿羊，不代表這句話就是 100% 正確。 所以，他的做法是：雖然我們永遠無法得到真理，但是可以用相反的例子，來「逼近」真理。每見到一隻白色綿羊，都可以讓「綿羊都是白色」這句話的正確度更接近 、但永遠無法達到 100%。 ## 日常應用的策略轉換 我把這個原則套用在使用 AI 工具上。雖然技術決策並不是非黑即白，波普爾的[否證法（證偽原則）](https://zh.wikipedia.org/wiki/%E5%8F%AF%E8%AF%81%E4%BC%AA%E6%80%A7?ref=ethanhuang13.plus)跟我的日常應用也不能直接混為一談，但我借重了他刻意尋找反例的精神。 核心觀念就是：**如果連 AI 都能指出明顯問題，那就應該再想想。** _This post is for paying subscribers only._ ### 🔧打造快速回饋系統是值得的投資 URL: https://ethanhuang13.plus/build-feedback-systems/ Last updated: 2026-08-13T06:05:54.000Z [上一篇](https://ethanhuang13.plus/learning-from-quick-feedback/)我談到**快速得到回饋是高效率學習的關鍵**。但光有原則還不夠，你需要把它變成**系統**。 不是偶爾想到才用快速回饋，而是建立一套可重複、可依賴的系統。這通常需要一些前期投資，但長期回報是巨大的。 ## 例子一：SwiftUI Preview 我在過去的文章與教學，多次強調**寫 SwiftUI 時要搭配 Preview**。 我的意思並不只是「要用 Preview」，而是要做到「要盡力維護 Preview 讓它好用」。這甚至成為我在帶領開發團隊的規則。原因就是，我們必須讓 Preview 成為一個開發時的回饋系統。 許多人在使用 Preview 都會遇到準備時間太久的問題，這往往是因為沒有把模組切分乾淨，放入了不必要的依賴。我之前公開的 SwiftUI + TCA template，把模組切好，讓 Preview 只 build 它需要的部分，而非整個 app。這樣可以大幅加快回饋速度。（請參考[🥇SwiftUI 讀完就入坑 #9 SwiftUI + TCA 專案的模組化最佳實踐](https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/)） 有些開發者則是會捨棄 Preview，使用 [Inject](https://github.com/krzysztofzablocki/Inject?ref=ethanhuang13.plus) 或 [Hot Reloading](https://github.com/johnno1962/HotReloading?ref=ethanhuang13.plus) 這類第三方工具，在模擬器上即時看到變化。雖然工具不同，目的完全一樣是即時看到回饋，而且可以持續使用。 要讓 iOS app 的 UI 開發形成有效的回饋系統，初期需要花時間設計架構、跟 team member 協調好開發規範。但一旦建立好，後續開發 UI 都能快速看到結果，效率持續受惠。 ## 例子二：使用 AI Agent 開發時自行測試並修正 你有沒有試過讓 AI Agent 修 bug，並且一次修到好？只要條件許可，這是很有可能達成的。關鍵還是在回饋系統的建立。 _This post is for paying subscribers only._ ### 🔄快速得到回饋是高效率學習的關鍵 URL: https://ethanhuang13.plus/learning-from-quick-feedback/ Last updated: 2026-08-13T06:05:53.000Z 這是我在各種學習場合都會追求的策略：「盡快獲得結果的回饋」。我保證這會是你一生受用的技巧。 ## 舉例 不知道寫 SwiftUI 畫面長什麼樣子？用 Preview。 不確定一個新同事，或是新的 AI 工具的實力？先給他小任務，看看反應。 TDD(test-driven development) 的精神是什麼？從測試快速得到結果，然後來實作或修正。 我推薦 Swift 新手用 Playgrounds 來學習，就是因為可以立刻看到一段程式碼的執行效果。 學語言的時候，反覆唸出單字，並且跟老師的標準比對來修正。 你可能也聽過新產品要推出 MVP 的觀念。這裡的重點不是 minimal，而是盡快推出去做市場驗證，然後快速修正。 上述這些事物都是盡量快速得到回饋，來修正錯誤。並且重複這個步驟，直到進步跟完成。 ## 效果 有了即時回饋，學習者可以： _This post is for paying subscribers only._ ### 🔄心中有答案，只差說出來 URL: https://ethanhuang13.plus/talk-it-out-self-reflection/ Last updated: 2026-08-13T06:05:52.000Z 你有沒有在生活或工作中，突然感到一陣迷惘的經驗？明明有很多計畫和想做的事，卻在某個瞬間冒出一種「我到底在幹嘛？」的感覺。尤其在忙碌完的空檔，特別容易出現這種狀態。 我安排給自己的「工作」多半是本來就想做的。但有時候，如果今天特別沒精神、做不下去，或是事情沒得到預期的結果而提不起勁，我會意識到，該釐清一下狀態了。 _This post is for paying subscribers only._ ### 🚀重大更新：iOS Developer+ 正式更名為「13+」 URL: https://ethanhuang13.plus/rebrand-13-plus/ Last updated: 2025-08-16T06:20:44.000Z 親愛的讀者，你好！ 我想跟你說明一個重要的變化：**iOS Developer+ 專欄正式更名為「13+」**。 ## ⚡TL;DR - iOS Developer+ 改名為 13+，更貼近我一直以來分享的內容核心：AI 工具、軟體職涯、自我學習，而不僅限於 iOS 技術 - 網址從 iosdeveloper.plus 換到 [ethanhuang13.plus](https://ethanhuang13.plus/)，舊連結會自動轉址 - 會員權益完全不變 - AI 工具及工程師的因應，本來就是我開啟這個專欄的初衷，也會持續分享相關議題 - 將會開展「學習使用 AI 工具來學習」的實驗並分享心得 - 雖然專欄改名，但我的日常工作還是以 iOS 開發為主 - 歡迎訂閱與宣傳（透過 [Patreon](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus) 或 [vocus](https://vocus.cc/salon/ethanhuang13?ref=ethanhuang13.plus)） ## 💭為什麼要改名？誠實面對現實 過去幾個月來，我發現自己在專欄裡分享的內容，很大比例都放在 **AI 工具使用**、**職涯建議**，與 iOS 開發技術本身沒有直接關係的主題上。 讀者應該看得出來，我寫文章滿隨心所欲的。雖然會有系列主題規劃，但打開寫作工具時，通常還是看當下的心情，或是目前最有興趣想討論的主題。 從最近幾個月寫出的文章來看，我覺得用「iOS Developer+」這個名稱已經不太合適了。 與其說這是一個分享 iOS 技術為主的專欄，不如說它更像是我身為資深工程師，在使用 AI 工具、工作流程、iOS 技術、職場經驗等主題的分享平台。特別是一些比較深入、個人的思考見解。 所以這個專欄，更像是以 13 我個人為出發點的各種分享，而不只是 iOS 開發。也就是說，這是我的個人品牌。 許多朋友一開始可能是因為想接觸 iOS 的深入技術而開始訂閱。但我相信，持續訂閱下來的朋友，應該是支持我目前寫作的內容方向。畢竟，如果發現我寫的東西跟期待不同，可能就取消訂閱了。 對我來說，這個專欄最重要的核心是：**我能夠把一些深入思考的內容，或是一些寶貴的經驗跟大家分享。** 我會分享的東西，都是覺得對讀者會有幫助的，哪怕跟讀者的期待可能有所不同。 這次改名，更像是誠實地面對自己會寫出什麼文章內容，而做的事後修正。就像是軟體專案在開發的過程中，要不斷依照實際狀況調整架構以及 refactor。 ## 📱iOS 開發依然是我的日常 我要澄清一點：我對 iOS 開發的關注並沒有減少。沒有「轉職」或「放棄」iOS，反而是透過 AI 工具，讓我更有效率地持續進行 iOS 開發與教學。 比如說，我最近在幫 [iPlayground 研討會](https://iplayground.io/?ref=ethanhuang13.plus)開發他們的 iOS App，運用多年的 SwiftUI 跟 TCA 經驗，搭配 AI 工具。這個開發過程我有在 YouTube 頻道「iOS 開發配飯吃」上直播，並剪成影片，也歡迎[前往觀看](https://www.youtube.com/watch?v=miLxYVmbxAc&list=PL%5FISTqHGWkNxp2k6N1Qg-xkt-vRCeXFYq&ref=ethanhuang13.plus)。 即便我在「13+」大量分享 AI 工具心得，但大半日常工作還是在 iOS 專案的開發上，或是 iOS 技術的教學。 ## 🤖關於 AI 的思考就是分享動機 為什麼「13+」會寫很多 AI 工具相關的文章呢？幫各位[複習一下](https://ethanhuang13.plus/ios-ai-tools-0-autocomplete-comparison/)： > 我開始做 iOS Developer+ 付費會員的契機，就是玩過 Cursor 以後，對於 AI 工具輔助軟體開發有了全新的認識，非常想要分享。 是的，看到 AI 工具的實力，就是我開啟這個專欄的契機。當然，整個專欄的內容不僅限於 AI 相關，但是主軸肯定跟 AI 脫離不了關係。 讀者朋友們對 AI 工具的接觸程度不同。一定有些人比我還會用。也可能在職場上沒有太多機會使用這些工具，因為公司政策，或是還沒想到合適的使用場景。 不管熟悉程度如何，都沒關係，因為我認為對於所有讀者來說，這些主題都會有幫助： - 面對 AI 工具迅速發展，資深工程師（我）怎麼看待軟體工程師職涯的變化與調適。包含學習策略與心態上 - 一些 AI 工具技術的踩坑經驗與綜合性評論。這方面的分享，很適合那些自己有 AI 工具使用經驗，想要參考其他人是怎麼使用，作為對照 - 培養軟技能方面的提醒，尤其是不容易被 AI 取代的人性層面價值 - 一些你可能沒有想到的 AI 工具使用方法 我自認為在 AI 方面的思考滿多的，不只是在使用工具而已。比如[🧠把 AI 當成人來減少學習負擔](https://ethanhuang13.plus/ai-as-human-mental-model/)，或是探討 [⛰️ AI 時代更值得追求的四件事](https://ethanhuang13.plus/ai-era-four-things-worth-pursuing/)，以及[💪如何不因 AI 而焦慮](https://ethanhuang13.plus/how-i-use-ai-without-anxiety/)。相信這些文章多少對於讀者在面對 AI 的衝擊，有所幫助。 我不想把重點放在特定 AI 工具如何使用的教學上，因為變化太快。倒是建議讀者自行多多嘗試，然後跟我的經驗分享做對照。 ## 🧪新嘗試：使用 AI 工具來學習 關於「[學習 SwiftUI](https://ethanhuang13.plus/why-write-learning-swiftui-book/)」這本書，我之前[寫到第四章](https://ethanhuang13.plus/tag/learning-swiftui/)就停下來了。那時候越寫越覺得準備不足，又接近 WWDC，我覺得很快就會被翻掉。果然後來 Apple 推出了很多新東西，包括 Liquid Glass。 但除此之外，那個寫作計劃還有一個致命缺陷：**如果現在要談任何學習主題，不把 AI 放進去討論，就很容易變成過時的教材。** 我的意思不是用 AI 來生成 SwiftUI 程式碼，而是要把 **AI 當作輔助學習的工具**。這不只是技術實驗，而是我們這個時代學習方式的重大轉變。 身為教育心理學背景出身的人，我在自學這件事情上有不少理論基礎與實際經驗。長期關注我的朋友知道我做過 Podcast、電子報、YouTube，甚至經營付費專欄，都是因為有興趣去摸索，然後逐漸學會的。 AI 工具的出現，讓教學出現了全新的方式。學習計劃與教材可量身訂做、AI 助教可以即時回饋與修正學生的知識、學習過程可以被記錄下來、提供符合大腦機制的反覆練習策略，這些都開啟了學得更好、更有效率的可能性。反過來說，過度依賴 AI 工具，而沒有真正學習，也是一大隱憂。 雖然大部分軟體工程師不見得會需要**教**，但是**持續學習**是軟體人在職涯上不斷前進的關鍵。所以用 AI 輔助學習是遲早的事。 所以，我現在對於學習新技術，會很積極地觀察和實驗：**我們怎麼搭配 AI 工具去學習？** 我相信對於願意付費訂閱此專欄的讀者朋友來說，「學習」是你的重要目的。接下來要說明我打算怎樣在「學習使用 AI 工具來學習」進行實驗。 ## 🎓我會實際應用在自學與教學上 我自己「使用 AI 來學習」的實驗題目是 Android 開發。雖然 iOS 開發我做了十多年，但 Android 經驗幾乎是零。讓 AI 用 iOS 知識來教我 Android 開發，應該會是一個很有效的正向學習遷移。 我很榮幸在今年 9 月開始擔任臺灣大學 iOS Club 的講師，會有許多 iOS 開發的基礎課程要上。我不會完全從零開始教 Swift，會搭配實驗「怎麼搭配 AI 工具來學習」這件事情。 學會一樣技能是第一層，能夠教人是第二層。現在有了 AI 工具，教人用 AI 工具學習變成第三層。不用說，這是個巨大的挑戰。我會把重點心得在 13+ 專欄與各位分享，搞不好，可以算做第四層了。 你對於「學習使用 AI 工具來學習」有興趣嗎？那麼請持續訂閱 13+。我會用「使用 AI 工具學習 SwiftUI」為示範主題，希望順便把之前想寫「學習 SwiftUI」一書的「坑」給填起來。 ## 📊關於文章深度與數量 最近我在嘗試寫更有深度的文章。比如 7 月的這幾篇： - [🤖你的 ChatGPT 裡應該要有個履歷專案](https://ethanhuang13.plus/chatgpt-project-for-resume-writing/) - [🧠我把 AI 當成人，是為了減少認知跟學習的負擔](https://ethanhuang13.plus/ai-as-human-mental-model/) - [⛰️AI 時代，四件更值得追求的事情](https://ethanhuang13.plus/ai-era-four-things-worth-pursuing/) - [🤖我的 AI 工具使用現況（2025 年 7 月）](https://ethanhuang13.plus/my-ai-tools-usage-202507/) 不過我也有意識到，相較於其他月份，7 月的文章數明顯較少。我在思考深度與數量的平衡。歡迎告訴我你的偏好。 ## 📝具體變化說明 - **名稱**：iOS Developer+ → **13+** - **網址**：iosdeveloper.plus → [**ethanhuang13.plus**](https://ethanhuang13.plus/)（舊網址會自動轉向） - **定位**：從「iOS 開發者進階內容」→「技術工作者的進階思維」 以下保持不變： - **內容品質**：同樣的深度思考和實務經驗分享 - **更新頻率**：每週 1-2 篇的節奏 - **會員權益**：所有訂閱權益完全不變。包括[官網](https://ethanhuang13.plus/)登入看全文與電子報、Notion 存取與留言等功能 - **價格**：維持原有收費標準 改名還有一點好處，就是：不受「iOS 開發者」的定位所限制。你可以把「13+」當成一個軟體工作者的職涯分享專欄，並且分享給更多人知道。 ## 👋Hello 新朋友，如果你不認識我的話 我叫 **13**，是一名台灣的資深軟體工程師，專精 iOS 開發超過 10 年。 ### 我做過什麼？ - 曾任美商上市公司 iOS 主管 - 上架過 10+ 個 iOS App，寫過數十個 side projects - 發行超過 **240 期**技術電子報，累積 **2700** 訂閱者。自稱是台灣的 iOS 開發消息轉發站 - 錄製 **110+ 集** Podcast，分享開發經驗 - 4 次參加 WWDC 現場，3 次擔任 iPlayground 講者 - 這是我做過的所有 iOS 公開內容，因為太多了，請另開網頁：[https://ethanhuang13.notion.site/](https://ethanhuang13.notion.site/?ref=ethanhuang13.plus) ### 為什麼你會想看我的內容？ **實戰經驗分享**：我習慣分享實際的踩坑經驗與解決方案。從 iOS 技術選型到團隊管理，從 AI 工具到職涯規劃，都是第一手的經驗談，供你參考。 **不同的觀察視角**：我的學術背景是**教育心理學與輔導**，這讓我在討論技術話題時，會更加留意： - 工程師的身心健康和職業傷害 - 學習方法與策略 - 團隊協作和溝通技巧 - 瞭解自身需求、目的、動機 **AI 工具使用心得與思考**：分享各種開發輔助工具的實用體驗，比如 [🔥來玩 Claude Code 吧](https://ethanhuang13.plus/ios-ai-tools-11-lets-claude-code/)和[🤖我的 AI 工具使用現況](https://ethanhuang13.plus/my-ai-tools-usage-202507/)，以及它們如何影響軟體開發工作流程。更重要的是，我關注工程師面對 AI 的衝擊，怎樣調適。 還有很重要的一點，我的寫作風格：**我喜歡說「請試試看」，而不是「我是對的」。我喜歡分享，給人參考，但不會強迫讀者一定要接受。**畢竟每個人都有自己的經驗，對於同樣的事情（即使是技術）也會有不同的判斷。 ### 誰適合訂閱？ 主要是**對 AI 工具有興趣的技術工作者**，想了解這些工具在實際開發工作中的表現和影響。另外，我也經常分享**自學的方法和心得**。 **資深的 iOS 工程師或已經工作好幾年的開發者**，想要更精進自己或在職涯方面發展的話，也很適合訂閱。職涯發展到一定程度，關注技術以外的 soft skill 其實是不可避免的。這部分我在專欄裡寫到蠻多，比如[團隊管理經驗](https://ethanhuang13.plus/one-year-prep-for-quitting/)、[工作與生活平衡](https://ethanhuang13.plus/why-taking-vacation-shows-strength/)，非常適合大家來訂閱。 雖然我的技術背景以 iOS 為主，但內容涵蓋軟體開發思維、AI 工具應用、學習方法，偶爾也會分享外商工作和團隊管理的心得，**應該適用於大部分的軟體開發者**。 ## 💳訂閱方式 13+ 的官網是由 Ghost 架設的，預設的付費機制是透過 Stripe。但 Stripe 不支援台灣的銀行帳號，也就是說我無法收款。所以作為 workaround，目前使用 [Patreon](https://patreon.com/ethanhuang13?ref=ethanhuang13.plus) 或 [vocus](https://vocus.cc/salon/ethanhuang13?ref=ethanhuang13.plus) 這兩個平台來開放訂閱。你可以選擇偏好的平台。 這兩個平台以及 Notion 上都有 13+ 的文章全文，但我更鼓勵讀者到官網 [ethanhuang13.plus](https://ethanhuang13.plus/) 閱讀並開啟接收電子報（新會員預設會開啟）。使用你註冊會員的 E-mail 即可登入觀看。 ## 🙏感謝與期許 謝謝你看到這裡。 感謝所有會員一路以來的支持，讓我能夠探索各式各樣不同的主題。有時候我扯得比較遠，但大家都繼續支持。 **13+ 的專欄對我來說，最主要的意義是：當我有深度思考或踩坑經驗時，有一個地方讓我分享這些內容。** 但我也希望各位付費訂閱的朋友，能夠帶著對你真正有幫助、有價值的東西回去。雖然目前收到的回饋還不多，但每一個回應對我來說都很珍貴。我很歡迎大家回覆電子郵件，或在訂閱的平台上留言，告訴我你想看什麼主題，或是你覺得哪幾篇文章特別有收穫。**如果你願意告訴我你需要什麼，或是你覺得什麼最有價值，會讓這個專欄變得更好。** 如果你覺得 13+ 對你有幫助，也請你把這個改名公告分享給朋友，讓更多技術人受惠。 改名「13+」對我來說，是誠實面對自己寫作方向的修正。對你來說，代表這個專欄會繼續分享那些你已經喜歡的內容：AI 工具實戰、職涯發展建議、資深工程師的思考模式。 名字變了，但初衷不變：分享對你有幫助的深度內容。 期待在「13+」繼續相會。 **13 於 2025/08/06** ### 🤖你的 ChatGPT 裡應該要有個履歷專案 URL: https://ethanhuang13.plus/chatgpt-project-for-resume-writing/ Last updated: 2026-08-13T06:05:51.000Z 說到寫履歷，很多人都知道要好好準備、不定期更新，才能在需要時立刻派上用場。實際上呢？通常都是想換工作、找工作的時候才開始整理自己的履歷。到了那個時候，往往會忘記那些值得放到履歷的職涯成就，這就讓職場的轉換又多了幾分摩擦力。 我想提醒一個簡單但很有效的方法：**用 AI 工具寫履歷**。 關鍵在於，**使用專案功能**。ChatGPT 跟 Claude（付費版）都有這個功能，可以長期蒐集工作表現。需要輸出時，再使用 ChatGPT Canvas、Claude Artifact 這類編輯功能來協助。 ## 建立長期蒐集系統 我之前在這個專欄已經多次肯定過 ChatGPT 的長期記憶功能的優勢，就是可以**在不同的時候回到同一件事情上進行討論**。履歷就是一個幾乎每一個在職場工作的人都會有的「長期專案」。 像履歷這種事情，我們在回憶自己做過什麼的時候，如果集中在一個時間點去想，就會覺得很麻煩。 但如果它是一個躺在 ChatGPT 或是 Claude app 裡面的專案，就可以在不同時間內回去跟它對話，去更新一些記錄，那就是一個很輕鬆的方式了。 蒐集的方式可以是文字，也可以是一些圖表。重點是，蒐集時不用太考慮格式的部分，而是不定期地把一些工作成就放進去就好了。也不用太在意一次講很多東西，或是說東西太少，都無所謂。 這樣就變成一個很輕鬆、但是有效的蒐集流程。 ## 從技術成果到商業價值的包裝 作為一個工程師，有的時候想要呈現工作表現，可能會覺得說我做了 A 功能、B 功能、C 功能。 其實在看履歷的人通常會期待看到的是：你在這份工作中真正的貢獻是什麼？比如說它解決了什麼商業上的問題，或是使用者的痛點，而不是說做了什麼功能或修了多少的 bug。 _This post is for paying subscribers only._ ### 🧠我把 AI 當成人，是為了減少認知跟學習的負擔 URL: https://ethanhuang13.plus/ai-as-human-mental-model/ Last updated: 2026-08-13T06:05:50.000Z 這幾年 AI 工具蓬勃發展，我一直用「如果這些 AI 其實是人的話，它的表現算好還是不好」這樣的視角來評價和判斷它們。主要原因是，這樣做能有效降低認知負荷跟學習負擔。 以下舉幾個例子。 ## 用直覺判斷 AI 的聰明程度 心理學上，要判斷一個人的智商或是在某項專業領域的能力，需要標準化的測驗，以及嚴格的變量控制。最終得到一個可以用來比較的分數。 但是在日常生活當中，我們並不會用這些工具，而是自然而然地透過對話和觀察反應，來判斷一個人的專業能力或聰明程度。在很短的接觸時間，就能產生一個大概的印象。 這種人類基本上都會有的技能，用在對話型的 AI 上面也很直覺。AI 的反應快不快、有沒有理解我們的意思、有沒有做出正確的回應，如果運用人與人互動的直覺，可以讓我們減輕很多思考負擔。 你不需要像研究人員，準備標準化測試來檢驗 AI，只要用自己熟悉的主題跟它們聊聊，就可以在對話中判斷它的水準。 ## 反應速度透露智慧線索 反應速度是心理學中常常用來判斷人們智力高低的一項指標。一個人思考時，他是不假思索就給答覆，還是想了一下才回答？我們很容易觀察到這些速度差異，也感受得到某些問題，對方花了更多腦力去反應。 而使用 AI 工具時，反應速度也可以是很自然能夠感受的指標。有些對話模型幾乎不假思索就會吐出結果，有些會經過所謂的思維鏈或思考過程。我們可以用跟人對話的臨場反應來判斷這個 AI 花了多少「腦力」，或是它在快速反應的情況下答得好不好。 比如說我剛接觸 Cursor 時，因為它的 Tab Completion 很精準而且非常快速，好像猜得到我要做什麼事情，就像有讀心術一般！這些表現就讓我對它的「聰明」留下深刻印象。 值得注意的是，AI 工具的反應速度當然有很多的影響因素。輸入的內容、模型的訓練、工具設計，乃至於當前算力有多少，都會影響所謂的「反應時間」。不過人也是一樣的，在不同條件下（例如精神好 vs 沒睡飽）的反應也大不相同。 所以，我並不是要拿對 AI 反應的直覺，當作判斷 AI 工具本身能力的指標。而是「這個 AI 工具現在的表現，能不能幫助我完成需要的工作」。這個直覺判斷，跟把一項工作能否交代給某人，基本相同。 ## 管理技能的無縫轉移 在使用 Cursor Agent 以及後來的 Claude Code 這些 AI agent 工具時，我發現它們能掌握的範圍越來越廣，寫得越來越好。所以，人機之間的角色逐漸變換，我負責下指令跟檢驗成果，而讓 AI 主要擔任撰寫程式碼的工作。 這些經驗讓我直接想起當工程師主管時的角色轉換。從一個自己寫程式的工程師變成要指揮、帶領其他人一起完成專案。我有分派工作的權限跟責任，並且負責團隊的工作流程規劃跟把控。而 code review 與回覆意見，越來越佔據工作時間。 這些帶團隊的技能跟工作流程，到了在用 AI Agent 時，對我來說根本是一模一樣的。我完全可以用帶人類團隊的技能來帶 AI、教 AI 學會我（們）團隊的開發規範。 從 Claude Code 目前的能力水準，**我預測未來軟體工程師會有越來越多機會變成上述這種「AI 管理職」的角色**。不管你喜不喜歡管人，管理 AI 的工作狀況可能都是未來職涯上跑不掉的事情了。 ## 團隊新人與 AI Agent 的導入邏輯 在軟體開發團隊有新人加入時，比較好的團隊會有文件與資深工程師作為教練，讓新人可以快速上手。比較沒經驗的團隊，則可能把權限開給新人以後，讓他自己去研究。 同樣的，在把專案導入 AI Agent 時，公認比較好的作法也是準備好專案介紹的文章、團隊開發規範的文件。Cursor 的 .cursorrules、Claude Code 的 CLAUDE.md、ChatGPT 的 AGENTS.md 都是這樣的東西。其實內容跟新人 onboarding 的文件，本質上大同小異。 如果手邊的專案沒有這些文件，在導入 AI Agent 時，至少也會先叫他分析現況，整理一些文件。這就跟叫新人自己去研究、寫寫筆記，是一樣的過程。而且我們還會去根據它/他整理地怎樣，多少就可以判斷掌握程度與能力。 你看，新人 onboard 跟把 AI Agent 導入專案，所需要的文件跟流程非常相似。評估他們表現也能夠用相同的方法。所以，若你具備讓新人快速上手的能力的話，導入 AI Agent 應該一點也不難。 _This post is for paying subscribers only._ ### ⛰️AI 時代，四件更值得追求的事情 URL: https://ethanhuang13.plus/ai-era-four-things-worth-pursuing/ Last updated: 2026-08-13T06:05:49.000Z AI 工具的普及正在改變軟體開發的遊戲規則。有些事情，以前因為麻煩而不做，現在因為有了 AI 的協助，變得更容易達成，也更值得去做了。 今天想分享四個我認為在 AI 時代，特別值得重新檢視的事情。 ## 寫測試：從時間限制變成必要實踐 資深工程師都明白在軟體開發中，測試的重要性。好的測試覆蓋以及測試關鍵邏輯，對於程式的維護和後續修改都有很好的保障。寫好的測試，可以在後續無數次運作中確保當初程式的行為保持一致。就成本效益來說，是非常划算的投資。 但是在實務上，人們就是不愛寫測試，原因很簡單：**寫測試要多花時間**。 今天花一個小時寫測試，也許未來可以拯救無數小時解 bug 的時間。但問題是，現在連一個小時都沒有就要交付程式碼了。在時間壓力下，寫測試往往被犧牲。 **現在有了 AI，這不再是問題**。 AI 寫測試非常快，而且寫完測試也可以叫 AI 工具去執行。**寫測試這件事從之前的「因為沒有時間或麻煩所以不寫」，變成了「不叫 AI 寫測試是一種浪費」。** 我認為，真正懂軟體工程的人應該會善加利用 AI 來做好測試工作。不管是用測試驅動的方式開發，或是撰寫測試程式碼來補強覆蓋。 我現在用 AI Agent 開發 app 時，都會先確保有設定好讓 AI 能夠呼叫測試的指令。不管是透過 MCP，還是直接下指令（比如說 `xcodebuild test` 指令）。一定要讓 AI 可以執行測試，並讀到測試結果。 這樣一來，Agent 就可以不斷反覆地自動修正。他們可以先寫測試，然後再實作，並且在過程中，如果測試失敗，可以根據測試失敗的結果來修正。不管是開發一項新功能，或是修復既有的 bug，我們總是能夠讓 Agent 執行測試，來確保沒有影響到既有的行為。 這會讓 AI 去開發變得安心，因為知道寫出來的東西是有測試覆蓋。只要看得懂、且同意那些測試程式碼，就可以知道程式有照著希望的行為去實作。 所以，我鼓勵讀者，如果過去對測試並沒有很追求，或是不曾真正認知到測試的價值，那在 AI 時代這變成了軟體工程師不可不懂、不可不用的技能。 我已經說明了「為什麼要寫測試」。而工程師要學習的是： - 怎樣維護測試環境 - 瞭解哪些東西值得測試 - 審查 AI 的測試程式碼（你可以不自己寫，但是 AI 寫的一定要讀） ## 做計畫與文件：從維護負擔變成方向指引 許多工程師不喜歡寫文件，或者會聲稱「程式碼本身就是文件」。 用過 AI 工具的人都能看到，它們在寫文件或分析規格、進行程式碼閱讀和理解方面的能力十分優秀。可以寫出各式各樣的文件，不管是規格文件、開發計畫或補充資料。 以往我們會覺得寫文件要花工程師許多額外的時間，而且最可怕的是，如果程式碼修改了，但文件沒有跟著修改，文件就失去意義了。所以維護文件是曠日廢時且吃力不討好的事情。 **但就如同測試一樣，現在 AI 在文書處理方面的速度非常快，而且可以做得很好**。甚至你的英文寫作不夠好，都可以靠 AI 來幫你寫。 所以在適當的時候，完全可以透過 AI 來產生與更新文件。比如說你今天開發的是一個 Library，裡面可能會有些 Sample Code、教學或上手步驟、使用方法。這些東西以前要自己寫可能比較麻煩，但現在 AI 都可以幫你做得很好。 **文件也是讓 AI 寫出來的程式碼更符合我們需要的必要手段**。各家 Agent 都有所謂的 rule file，用來指引 AI 依照特定方式去開發。其實，跟人類工程師加入新團隊要遵循的 onboarding 文件，並沒有本質上的區別。 許多人都從經驗中發現，要讓 AI 寫出好的程式碼，建立文件來指引開發計畫是不可或缺的步驟。導入 AI 輔助開發的起手式，可以先讓 AI 分析專案的現況並寫成文件，就可以判斷 AI 的技術掌握能力。接著，再根據需求，與 AI 討論開發計畫，這也是一種不斷更新的文件。 總之，AI 很會寫文件。身為人類，我們應該要善加利用。並且去學習： - 要有哪些文件、目的是什麼 - 文件應該要放哪些內容 - 要求 AI 更新文件的時機 ## Code Review：維持軟體品質不可犧牲的工作流程 不知道你有沒有待過有良好 Code Review 文化的開發團隊？（我會這麼問是因為，許多 iOS 工程師任職的公司，可能只有一兩位工程師。） 有好的 Code Review 文化的團隊，工程師寫完功能或修 Bug 會有其他工程師去確認，並且回覆需要修改的意見，或是趁機交流一些技巧、互相切磋學習。Code Review 對於追求專案的品質，以及團隊慣例的一致性，是不可或缺的流程關卡，也是團隊一起成長的好方法。 Code Review 也是團隊管理者的重要工具。自從當我擔任 team lead 後，動手寫 code 的比例越來越少。不過在 Code Review 時，往往能抓到同事程式的一些問題，比如架構方面的，或是可能沒有注意到的細節。也很常趁機分享幾招寫法。閱讀程式碼並提供回饋，對於提升專案品質是有重大意義的。 不過，既然 Code Review 是流程關卡，就需要相當的時間，而且往往會有互相等待的情況。 比如我以前帶的團隊，除了 Pull Request 的作者之外，需要至少兩個人看過並且 Approve 才可以 Merge。為了維護專案的品質，這個要求十分合理，但要徹底落實的話，就需要每個人在做手邊任務的同時，又要花時間去看別人的程式碼。所以往往會在開發週期的後半段，大家在 Slack 上互相提醒與拜託別人幫自己看 PR，不然會來不及 merge。 在 AI 能夠寫程式的時代，我認為 Code Review 變得更重要了。一方面，為了追求軟體品質的高標準，需要透過人類工程師 Code Review 來把關，這點與人類工程師團隊合作時並無不同。 有的人 Vibe Coding 的做法是連看都不看 AI 寫什麼，這在某些情況下是可以的。但如果這份程式碼，是你要交出的工作成果，那麼不管是自己寫，還是 AI 來寫，都是你的責任。你可以不寫程式，但一定要閱讀並**親自確認 AI 寫的程式，因為 AI 不會幫你負責任何事**。 另一方面，AI 也能夠 Code Review，所以人類工程師或 AI 交付的 PR，也應該讓 AI 來審查。 我現在大量使用 AI 來做 Code Review。一人開發的專案，沒有同事可以幫我 Code Review，但我開放權限給 Cursor BugBot、Claude Code，以及 GitHub Copilot 。它們都有讀取 GitHub Pull Request 的能力，可以在模型上直接閱讀 PR 內容然後提供意見。 AI Reviewer 使用的模型雖然跟實作的 AI 差不多，但是視角不同，所以還是常常能抓出問題來。 總之，一方面我叫 AI 寫程式、自己審查。另一方面我也用 AI 來審查 PR。換作是跟人類工程師組成開發團隊的話，我的工作流程也是一樣的。 如果你所屬的團隊過去沒有堅持 Code Review 的好習慣，現在是加強這方面的好時機。 _This post is for paying subscribers only._ ### 🤖我的 AI 工具使用現況（2025 年 7 月） URL: https://ethanhuang13.plus/my-ai-tools-usage-202507/ Last updated: 2026-08-13T06:05:48.000Z 休假兩週回來了。來分享一下我目前的 AI 工具使用現況給讀者參考。 由於 AI 工具變化很快，每個人的工作目標與流程習慣都不盡相同，所以只能說是 2025 年 7 月的一個 snapshot 吧。 我目前幾乎每天都會使用的 AI 工具有： - ChatGPT app - Cursor - Claude Code - Claude app - Wispr Flow ## ChatGPT ChatGPT 是最大眾化的 AI 產品，功能也是最廣的。我訂閱了 ChatGPT Plus。 值得一提的是，如果你試著去取消訂閱，可能會像我一樣獲得三個月半價的挽回優惠。 簡單來說，我拿它來使用的情境有： - 4o 來蒐集想法、整理思緒、基本文字處理 - 一個人散步時使用進階語音模式進行聊天 - 討論長期計畫（因為有跨對話的記憶能力） - Work with Mac Apps 功能用來審稿 - 針對自己不熟悉的領域，使用 o3 及 Deep Research 來建立初步的認識 - Codex 目前對於 iOS 開發的實用度不高，但是可以窺見未來 AI Agent 在軟體開發的一種實用工作流程 以下補充說明各種用法。 _This post is for paying subscribers only._ ### 🏃能者過勞：AI 時代的生產力陷阱 URL: https://ethanhuang13.plus/ai-productivity-trap/ Last updated: 2026-03-03T02:22:36.000Z 最近我在使用 Claude Code，在短短的幾天內就用它完成了非常多的事情。之前也寫了[來玩 Claude Code](https://ethanhuang13.plus/ios-ai-tools-11-lets-claude-code/) 那篇文章，邀請大家一起來使用。 前幾天，Google 也推出了非常類似的工具 [Gemini CLI](https://github.com/google-gemini/gemini-cli?ref=ethanhuang13.plus)，所以我們現在有更多的選擇，甚至可以[交叉使用這些不同的工具](https://x.com/ethanhuang13/status/1938784896107032878?ref=ethanhuang13.plus)，因為它們各自有擅長的地方。 但是，我很快就注意到自己使用這些 Agentic AI 工具會上癮。於是，我在最近一集的 [weak self podcast](https://weakself.substack.com/p/112) 裡面提到「能者過勞」這件事情，提醒大家要適度休息。今天來把這些想法寫成文章。 ## 當 AI 成為你的「優秀員工」 當你發現一個工具可以提升工作效率的時候，一開始應該會覺得很高興，因為這可以省下大量工作時間。但是像 AI Agent 這種工具，它快速做完之後就會停下來等你的輸入，也確實能接住你的需求，就會想再給它下一步的工作，甚至不斷想要丟更多工作。 我們可以說，這其實就是一個慣老闆的心態吧。當你發現一個優秀的員工表現很好，而且工作效率很高的時候，你會怎麼「使用」這個員工呢？會讓他做完之後就去休息嗎（尤其這個員工是 AI）？應該更會傾向想：「既然你這麼厲害，就多做一點」吧！ 所以，AI 工具你用得越好，只會越用越多而已，因為你總是會有事情可以找它來做。而且以 Claude Code 的吃到飽方案來說，你用得越多，它越划算。不用實在太吃虧了。 透過 AI 工具，我們個人的效率可能會提升。但另一方面，如果我們是員工，主管或老闆看著我們使用 AI 工具的效率提升了，那他們對我們工作效率的期待也會上升。 ## 歷史不斷重演 這其實並不是什麼很新奇的事情，而是自從工業革命以來不斷歷史重演的一件事情：**生產力工具帶來革命性的變化，大幅提升了工作效率。但是人們的工時並沒有減少，工作量也並沒有減輕。** 不會因為你的工作時間減半，就只需要上一半時間的班，對吧？人們永遠只會有更多的事情要做。 AI 工具能提升我們的效率多少呢？有可能不是兩倍三倍，而是十倍甚至一百倍，就看你有多麼會使用它們。我用 Claude Code 可以一次開發四個專案，當中的瓶頸可能是我去 review 這些程式碼，或者說它們改完之後的這些 pull request。所以用的時候覺得自己很忙，因為 AI 工具都很認真在工作，我也很投入地在看它們做出來的結果。 ## 跑步機效應：必須很努力才能留在原地 這種生產力提升，但標準也同時拉高的情況，這就像跑步機一樣：必須很努力往前跑，才可以留在原地。 這個現象不會只發生在你我身上，而是會發生在不久將來整個社會的普遍現象，尤其是寫軟體的人。因為大家的效率都提升了，不管是五倍、十倍還是一百倍，我們的效率提升會變成一個新的常態。 也就是說，在大家還在摸索怎麼使用這個工具的時候，有的人學得比較快，有的人學得比較慢。學得快的人在短期可以有爆發式的生產力提升，但長期來看呢？大家都會漸漸追上來，雇主對人們工作效率的期待也會提升。所以到最後，其實我們還是停留在原地。 ## 記得休息，別燃燒自己 所以 Claude Code 我用了沒幾天，就出來勸世，提醒大家要記得休息、睡覺。因為它確實能做出很多的事情，可是你持續地投入你的時間在它上面，加快地完成那些事情，只是在燃燒自己而已。工作效率已經提升非常多了，何必要把自己的身心健康都賠進去呢？ 我承認用 Claude Code 或是 AI agent 來寫程式是真的會上癮的，但它不會是一個長久之計。人們必須還是回到自己的生活步調、工作節奏的合理的狀態。 ## 重新思考工作的意義 不要因為 AI 工具能做很多事情，就瘋狂地加自己的班。反而是可以停下來暫緩，思考一下：如果原本你要花兩個禮拜才能完成的某些 refactoring，現在只要花一天就可以完成了，那麼一些重要、但過去積壓著沒去做的事情，優先度就可以拉高。 我們可以把一些繁瑣的事情交給 AI 來做，比如說補測試、寫測試，或是採用 TDD 的方式去開發。我們工作的方式其實是可以做轉變，而不是一味地加功能。 有些你想了很久沒做的點子，其實是可以拿出來搞了。或是一些舊的專案，如果是自己翻出來做點維護工作，很浪費時間，但現在用 AI 工具讓它直接分析一下這個專案的現況，然後列出一些改進的計畫，一步一步去執行，就變成一個滿快樂的事情。 總而言之，我覺得大家可以去思考怎麼樣調整自己的步調。問自己：**真正想做什麼、什麼才是最重要的事情？或者說有哪些事情 AI 沒辦法做到，所以更應該花時間去做那些事情？** ## 選擇跳出，而非勝出 讀者也都知道我今年在 gap year。我離職的一個重要原因就是認為 AI 的工具會大爆發，想利用這段期間，重新調整自己的步調，思考自己真正該去做的事情是什麼、該去學的或加強的技能。 而到了 Claude Code 推出的時候，我覺得這就是當初期待看到的現象：實際工作方式的轉變。 我並不是在這裡勸大家也要離職，然後專心來想這些事情。但我總覺得不要只把焦點放在去追逐 AI 工具的最新的變化，而是去思考有更長遠價值、不會被這些跑步機上拖著跑的東西。 今天文章就先到這裡了。希望大家有一個健康的身心、記得休息。我從明天開始會出國休假一週，就是一個具體的休息行動。 ## 延伸閱讀 - [🗾你應該要安排休假](https://ethanhuang13.plus/why-taking-vacation-shows-strength/) ### 🪧公告：iOS 開發補完計畫改為免費專欄、不定期更新 URL: https://ethanhuang13.plus/ios-missing-manual-free-transition/ Last updated: 2025-06-20T14:37:48.000Z 親愛的讀者您好， 在此宣布「iOS 開發補完計畫」將調整經營方式。 ## 長話短說 即日起，「iOS 開發補完計畫」從付費專欄改為**免費公開**、不定期更新。 因為這一個月的實驗結果顯示：讀者需求與我預期有明顯落差，也讓我的寫作動力受到影響。 ## 實驗一個月，結果不理想 「iOS 開發補完計畫」是從 2025/05/23 開始，至今將近一個月的時間。 當初的構想與公告[在這裡](https://www.patreon.com/posts/129667474?ref=ethanhuang13.plus)。 原訂計畫是，每週至少要寫 2 篇 iOS 開發的新手補充知識，但是**最終只寫了 4 篇**。 最主要原因是，這個系列專欄的迴響遠低於預期，也影響了我的寫作動力。 專欄有提供給學生申請免費資格，總共有 7 位學生來信索取免費資格、最後只有 4 位有兌換。 只有 1 位朋友付費訂閱。 我還嚴重低估了撰寫初階文章的難度。 有些文章對於有經驗的人來說，就是幾句話的概念。但是針對新手必須從頭說明很多基礎概念，反而比進階的題目更難準備、更費時費力。 ## 處理方式 由於寫作的頻率只有當初宣告的一半，我已主動退款給那位付費的朋友。 該方案已經關閉，無法訂閱。 過去已經撰寫的文章，已經全數轉成免費文章，歡迎觀看： - [🐣iOS 開發補完計畫 #0 商業觀念篇：Apple 對開發者的態度是什麼](https://www.patreon.com/posts/129617023?ref=ethanhuang13.plus) - [💻iOS 開發補完計畫 #1 開發環境篇：新手如何選擇開發配備](https://www.patreon.com/posts/130165693?ref=ethanhuang13.plus) - [🧊iOS 開發補完計畫 #2 學寫 App 不會讓你賺大錢，但是絕對值得（商業觀念篇）](https://www.patreon.com/posts/130492492?ref=ethanhuang13.plus) - [🐣iOS 開發補完計畫 #3 WWDC 是什麼？開發者應該關注哪些重點](https://www.patreon.com/posts/131506340?ref=ethanhuang13.plus) ## 後續經營方式 我對於「從 AI 學不到的 iOS 開發知識」還是有很多東西想寫。 原本這個計畫的啟動主要就是寫給學生。所以，未來如果從教學互動中發現一些新手盲點，我就會視為正面訊號，將它們整理成篇章。 原本學生需要來信申請才能閱讀，現在只要免費註冊 Patreon 就能看到，省下彼此的時間與流程。 ## 結語：熱情是創作者最寶貴的資源 雖然「iOS 開發補完計畫」作為入門付費專欄的結果是失敗的，但是我覺得是個有效的實驗。 我本來就喜歡做各種嘗試，看看效果，然後快速調整。 當初覺得「iOS 開發補完計畫」應該會有許多人需要。但實際上，從我能接觸到的受眾來說，並非如此。 「iOS 開發補完計畫」總共只有 1 位朋友付費訂閱。相較之下，iOS Developer+ 最近每週至少新增 2 位會員，這讓我清楚知道，該專注在進階知識的寫作上。 這一個月下來我最大的收穫就是，**身為創作者，要保護好自己的創作熱情**。及時止損。 今後我會繼續專注在 iOS Developer+ 的寫作，歡迎訂閱。以下是最近寫的兩篇文章： - [🔥來玩 Claude Code 吧──iOS 開發 AI 輔助工具 #11](https://ethanhuang13.plus/ios-ai-tools-11-lets-claude-code/) - [🛤️我的 WWDC25 新東西試玩路線](https://ethanhuang13.plus/wwdc25-tryout-roadmap/) 感謝大家的支持。 ### 🔥來玩 Claude Code 吧──iOS 開發 AI 輔助工具 #11 URL: https://ethanhuang13.plus/ios-ai-tools-11-lets-claude-code/ Last updated: 2026-08-13T06:05:47.000Z ## 前言 說到 AI agent，[Claude Code](https://github.com/anthropics/claude-code?ref=ethanhuang13.plus) 已經出來好一陣子了，但我最近才開始玩，一玩就上癮了。這篇文章就簡單來說一下它為什麼好玩，以及邀請大家一起來試試看。 ## 什麼是 Claude Code？ 最近 Claude Code 在 [Claude 的 Pro 方案](https://support.anthropic.com/zh-TW/articles/8325606-%E4%BB%80%E9%BA%BC%E6%98%AF-claude-pro?ref=ethanhuang13.plus)（也就是每個月 20 美金的方案）就有包含，所以我們可以用相對於 ChatGPT Plus 或是 Cursor Pro 的同等價位來嘗試 Anthropic 自己出的 AI Agent 功能。 Claude Code 的特色是，它是在終端機上運作的，不用綁定特定的 IDE，所以你可以在各種終端機的介面使用，包含 Cursor 或是 VS Code 也可以，甚至可以透過 SSH 連線到主機上去操作。 這種終端機使用者介面的特色，相較於有一個完整的 IDE agent，雖然限制了捲動範圍，但反而更能聚焦在一些操作上。 既然是在終端機上操作，那麼你就可以使用任何指令來做各式各樣的事情，包含讀取檔案內容、修改檔案、寫 Script、寫程式，或是去執行各式各樣的工具，包含 Git 的操作。像是叫它讀取多個專案裡面的 Git 記錄，來幫忙摘要過去幾個月做了什麼事情。所以不用把它當成只是寫程式的工具，你可以拿它來做各種在電腦上透過終端機能做到的操作。 ## 推坑原因 不過這些並不是我最想邀請大家來玩 Claude Code 的原因，而是因為 Anthropic 現在提供的方案便宜到一個誇張。 當你訂閱 Claude Pro 或是 Max 方案的時候，你可以**在一定時間內一直使用 Claude Code**。 把 Pro 方案的使用量算作 1 單位的話，Max 方案（100 美金一個月）的使用量是 5 個單位。有趣的是，如果你覺得這樣還不夠，可以升級到 200 美金的 Max 方案，這個時候的使用量會是 Pro 的 20 倍。換言之，從 100 美金到 200 美金這一個區間，有非常大的邊際效益。 不過，其實使用幾天下來，我還沒有到真的需要用到 200 美金這個等級。 為什麼呢？因為相較於使用 API Key 用多少算多少的計費方式，訂閱 Claude Pro 或 Max 的話，Claude Code 的使用量會在 5 個小時後歸零！ 也就是說，當你今天開始送出第一個訊息，它就會計時 5 個小時。如果用完使用上限，就會暫時不能使用（終端機會顯示幾點會歸零），等到時間到了，就可以繼續使用了。 Claude 4 模型本身就強、Claude Code 的 agent 能力也十分出色，能夠有效完成我想要做的事情。所以 Pro 方案用到把使用量用完之後，就直接升級到 Max 100 美金的方案了。 ## 吃到飽與使用量統計 這個計費方式等於是短時間內可以冷卻的吃到飽。 這樣子是不是真的划算呢？有一些軟體或工具可以抓取 Claude 資料夾裡面的 log 來計算使用了多少 token，然後推算如果是用 API key 的話總共花了多少錢。 _This post is for paying subscribers only._ ### 🐣iOS 開發補完計畫 #3 WWDC 是什麼？開發者應該關注哪些重點 URL: https://ethanhuang13.plus/ios-missing-manual-3-what-is-wwdc/ Last updated: 2025-12-20T05:19:14.000Z ## 前言：給初學者的 WWDC 觀念澄清 最近 WWDC25 剛結束，相信你已經在新聞上看到「Apple 發表了 iOS 26、全新視覺介面」之類的報導，然後興奮地想要體驗新功能，但是又被一些開發者勸退。 WWDC 到底是什麼？為什麼開發者這麼重視？那些 beta 版本又是怎麼回事？ 今天我們就來聊聊 WWDC 的真正意義，以及身為開發者應該關注的重點，順便澄清一下很多人對於 WWDC 的誤解。 ## WWDC == 全球開發者大會 Apple 每年都在 6 月舉辦 WWDC，在外行人眼中，已經變成固定的發表會時間。但是，對於內行人來說，WWDC 是什麼？為什麼 Apple 要舉辦 WWDC？開發者又應該關注什麼？ WWDC 的全名是 Worldwide Developer Conference，顧名思義就是「全球開發者大會」。重點在「開發者」三個字，這是 Apple 專門為了開發者舉辦的技術研討會，主要目的是發表新的開發工具和 API、教開發者如何使用新功能、讓開發者提前適應變化。 一般消費者看到的 Keynote 只是開場，真正的重頭戲是接下來一整週的技術議程，有一百多個專門針對開發者的技術會議。 Apple 成立於 1976 年，而第一屆 WWDC 則是在 1983 年開始。當時的名稱叫做 The Apple Independent Software Developers Conference，內容是不對外公開的，參加者要簽保密協議。 接下來的幾年，名稱也都不太一樣，但是目的都相同，就是 Apple 針對外部開發者，介紹新功能、新系統。 從 1990 年起，Apple 就固定使用 WWDC 這個名稱，每年都舉辦開發者研討會。前面十來年在聖荷西 San Jose Convention Center 舉辦，從 2003 年起，都在舊金山 Moscone Center。 2016 年比較特別，第一天的 Keynote 在舊金山市的 Bill Graham Civic Auditorium，其他議程則回到 Moscone Center。2017 年開始，又改回 San Jose Convention Center。 2020、2021 這兩年，受到疫情的影響，採取完全線上的方式，並且所有的議程改成預錄影片。2022 年開始，由於新總部 Apple Park 已經啟用，Keynote 就移到 Apple Park 內部，是每年 Apple Park 難得大規模開放外賓進入的時候，並且保留了議程採用預錄影片的形式。 （對歷史有興趣的朋友，可以參考 [Wikipedia](https://en.wikipedia.org/wiki/Worldwide%5FDevelopers%5FConference?ref=ethanhuang13.plus)。） ## 我的 WWDC 參加經驗 我剛好去參加過 2016\~2019 這 4 屆，也就是疫情之前，全面實體舉辦、沒有預錄議程的時代。所以，對於現在的 WWDC 舉辦形式（花錢飛一趟美國參加現場的 WWDC、坐在 Apple Park 大草皮曬太陽看預錄的影片），我是興趣缺缺。 不過，根據今年有去參加 WWDC 的開發者朋友表示，現場有增加一些座談，而開發者社群也會在周邊舉辦許多活動，所以去那邊待一週絕對不會無聊。前提是你不害羞去參加各種活動，或是要有人作伴。 所以，現在我會說，如果你從來沒有去過實體的 WWDC，還是可以當成一個目標去存錢、並且期待能抽到籤。畢竟，一輩子能一口氣看到那麼多 iOS 開發者，就是在 WWDC 的實體現場了。當作畢生一次的朝聖目標，還是很值得的。 ## 以前報名費不便宜 以前，WWDC 的主題是以 Mac 作業系統、Mac 上的軟體為主，當時開發者沒有那麼多人。而在史上最賺錢的產品──iPhone──推出以後，Apple 一步一步變成全球市值最大的公司。許多開發者在 iOS 平台上開發、賺錢，所以 WWDC 也變得越來越多人想參加，逐漸演變成要抽籤才能參加。 隨著規模擴大，舉辦的成本也越來越高。到了 COVID-19 之前一屆的 WWDC19，去參加時要繳納 $1599 的費用。 繳這麼多錢有什麼好處嗎？實體的東西，通常是一件外套、識別證，就這樣，哈。 但是，能夠去現場跟 Apple 工程師面對面討論，是非常難得的事情。 我都開玩笑地形容：Apple 工程師平常整年都被關起來，只有 WWDC 這週能夠被放出來跟外面的開發者接觸。 在這些面對面場合中，你可以直接展示自己的程式碼、遇到的問題，然後從 Apple 工程師口中得到解答。 我親眼看過 Apple 工程師聽完問題以後，打開自己的電腦，看著內部的實作，然後回答說：應該要怎麼呼叫這些方法才好。這是非常難得的機會。 現在 Labs 是以線上形式進行，但是能夠與 Apple 工程師一對一討論問題，還是很值得把握的。我在之前的[生存指南文章](https://ethanhuang13.plus/wwdc-survival-guide-2025/)也有強調要在 Keynote 結束後，趕緊去預約一對一 Labs。 ## 小插曲 順便講個小故事好了。 2016 年我第一次去 WWDC，非常興奮。因為是出差，帶著公司交代的任務，去 App Store Review 的 Lab 問問題。得到解答以後，我問了 App Store 的員工能否一起照相，就合照一張。 接著，我去了趟洗手間。在走回來的路上，被剛才的 Review 團隊的員工攔住。 他說：「請把剛才的照片刪掉，因為我們內部政策的關係… 不然我會惹上麻煩。」 這件事給我留下深刻的印象。因為 Review 團隊是守門員的角色，要阻止不良的 app 上架。如果有惡意的開發者知道他們的長相、聯絡上特定審查員，就可能會有安全上的疑慮。我當然立刻把照片刪掉了。 ## 許多人的期待沒有設定正確 WWDC 發表的所有新功能都是 beta 版本，通常要等到 9月 會搭配新 iPhone 推出正式版本。很多人會把 beta 當正式版來批評，這其實就是期待沒有設定正確。 Beta 就是「測試版本」，功能還在開發中，可能會有 bug，只有開發者可以安裝，需要開發者帳號，會頻繁更新，Apple 每 1-2 週就會推出新的 beta，不適合一般用戶使用，因為可能會讓裝置變不穩定。 Apple 這樣做的原因是讓開發者有時間適應新的 API 和功能，收集回饋意見讓 Apple 改進，確保開發者可以提前更新自己的 App，確保在新系統上正常運作。 所以當你看到有人批評「WWDC 發表的功能很爛」時，要記住這些都還是半成品。Beta 1 是在 WWDC 當天發布的，就我跟一些 Apple 工程師聊過的，有些東西根本是在發表會前幾天趕著做完（或來不及而砍掉）。 ## 開發者應該做什麼事情 真正的開發者，遇到 beta 版的 bugs，且嚴重影響他們的 apps 與專案時，會去做的事情是回報問題。我鼓勵你學習怎樣正確地回報 bug 與意見回饋給 Apple，詳情請見 [Bug Reporting 官網](https://developer.apple.com/bug-reporting/?ref=ethanhuang13.plus)。 作為 iOS 開發初學者，WWDC 對你來說意味著學習新技術的機會，每年 WWDC 都會有大量的技術議程影片，這些都是免費的第一手學習資源。透過新功能的發表，你可以看出 Apple 未來想要推動的方向。 看到新的 API 和框架後，你可以開始規劃要學習哪些新技術，為未來的職涯做準備。 重要提醒：作為初學者，不要急著安裝 beta 版本的 Xcode 或 iOS。我並不是說不要裝，而是**安裝 beta 版也是要有策略的**。這可以說是資深工程師踩坑經驗的一環。 最不容易「受傷」的方式是裝在專門的開發機或測試機，與私人設備分開。更安全地，是連登入的 iCloud 帳號都分開。 不過坦白說，會嚴格照著這個作法的人很少啦。我也不會阻止你去踩坑（因為自己痛過才學得更快？） 如果你想了解更多 WWDC 的實用資訊，我有寫過「[**🥷WWDC 生存指南 2025 版**](https://ethanhuang13.plus/wwdc-survival-guide-2025/)」是免費公開的，另外「[🛤️**我的 WWDC25 新東西試玩路線**](https://ethanhuang13.plus/wwdc25-tryout-roadmap/)」只有 iOS Developer+ 會員能看到，這些文章會告訴你如何有效利用 WWDC 的資源，以及開發者應該做的具體行動。 對一般用戶來說，WWDC 可能只是看個熱鬧，看看今年會有什麼新功能。但對開發者來說，WWDC 是技術學習的寶庫、了解未來方向的指南針、與全球開發者交流的機會。 ## 結語 WWDC 不管對於資深或新手開發者，都是非常資訊爆炸的情況。我還是再次建議這個路線：想清楚自己的真正目的，然後隨著興趣去探索新事物。 ### 🛤️我的 WWDC25 新東西試玩路線 URL: https://ethanhuang13.plus/wwdc25-tryout-roadmap/ Last updated: 2026-08-13T06:05:46.000Z WWDC25 發表的東西非常多。 以往每天會放出一部分 Session 影片，但是今年比較奇妙，所有影片在第一天就都放出來，所以我在第一天就覺得 WWDC「週」已經結束了。 熬夜看 Keynote，導致接下來幾天作息被打亂，學習效率也不是很高。所以我決定放慢節奏，先整理一下想玩的東西，再一個一個嘗試。 以下項目我依照**重要性排列**，給讀者參考： ## Platforms State of the Union 如果你一部 WWDC Session 的影片都還沒看，請先從 Platforms State of the Union 看起，了解概況。 文字版的[官方文件](https://developer.apple.com/documentation/updates/wwdc2025?ref=ethanhuang13.plus)也很實用，可以快速過一遍有興趣的框架。 ## Xcode 26 beta 只需要 macOS 15.4 就可以安裝。 **用來編譯手邊的專案，看看有沒有明顯問題。** 建議使用 [Xcodes app](https://github.com/XcodesOrg/XcodesApp?ref=ethanhuang13.plus) 下載。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/06/CleanShot-2025-06-12-at-13.55.19@2x.png) ## #Playground macros 這是看到 Xcode 26 之後我最喜歡的新功能，可以用很簡單的方式把小段 Swift 程式碼跑起來。 _This post is for paying subscribers only._ ### 🥷WWDC 生存指南 2025 版 URL: https://ethanhuang13.plus/wwdc-survival-guide-2025/ Last updated: 2025-06-06T14:31:07.000Z WWDC 是 iOS 開發者一年當中最容易被資訊淹沒的時候，我會在這篇文章中分享我的應對策略。 本文撰寫給 iOS Developer+ 會員，但也開放給「iOS 開發補完計畫」的訂閱者，並限時免費公開一個月給所有人觀看。喜歡這篇文章的讀者們，歡迎[訂閱 iOS Developer+](http://patreon.com/ethanhuang13/?ref=ethanhuang13.plus)，並分享給更多朋友。 ## 生存目標 不管你的角色是工程師、開發者、或是純粹對 Apple 新技術有好奇的使用者，Apple 在 WWDC 發布的上百件新事物中，我們的核心問題是：「下一步要做什麼？」 用這個角度來作為輕重緩急順序，你篩選資訊會輕鬆許多。也可以減少資訊焦慮及 FOMO 的傷害。 以往我在公司任職 iOS 工程師時，每年 WWDC 都會為同事準備三個面向的重點報告： - 可用的**新技術** - **設計**與使用者體驗的變化 - **商業**方面的衝擊 身為 iOS 工程師，我們對 Apple 的瞭解遠比其他部門的同事來得透徹。如果你可以從上述角度快速整理出重點並分享，好讓同事們對於新版 iOS 正式到來能有所準備，應該可以留下深刻的好印象。 ## iOS 工程師的價值 我認為，如果你任職於一間公司，在 WWDC 期間，有兩件事情可以凸顯你的價值： 1. 快速掌握 Apple 政策對公司帶來的影響，並回報給相關同事，以應對可能帶來的商業衝擊。這會比埋頭關注新技術更優先 2. 提早準備好那些無法解決的技術問題（特別你認為很可能是 Apple 的 Bug），並在 WWDC 期間預約一對一 Lab 來請求 Apple 工程師協助 ## 做好商業衝擊的準備 Apple 通常會因為使用者隱私的機制或新功能，宣布新的政策並更新 App Store Review Guidelines、強制開發者要限期調整及因應，否則不予更新。 過去的例子有：Sign In with Apple、IDFA、Privacy Labels、Privacy Manifest 等等。這些機制的變動，有些需要後端的開發，有些需要 PM 協助釐清，有些甚至會影響整個商業模式。不可不謹慎對待。 積極面來說，Apple 推出的新功能、新技術也可能有助於公司業務的發展。要**把握機會，爭取研究的時間**。 在我看來，優秀的 iOS 工程師，不只會開發出符合需求、效能優雅的 app。更重要的是能**主動**將對公司有影響的事情拋出來，儘早安排對策。這對於建立你的專業形象很有幫助。 而如果你是獨立開發者，或是接案型的工作者，去瞭解 Apple 的新政策也是必要的功課。隱私政策影響到的不會只是企業內開發者。 Apple 通常會用 ”[Updated guidelines now available](https://developer.apple.com/news/?id=9txfddzf&ref=ethanhuang13.plus)” 的標題，將 App Store 的政策更新刊登在 [Apple Developer News 網站](https://developer.apple.com/news/?ref=ethanhuang13.plus)。另外，[Upcoming Requirements](https://developer.apple.com/news/upcoming-requirements/?ref=ethanhuang13.plus) 也是常常要去留意的頁面。 ## 設計與使用者體驗的變化 每年 iOS 及各平台都會有一些視覺與使用者體驗的變化。 謠傳今年各平台的主畫面會改成類似 visionOS 那種玻璃光澤的介面，並且啟用圓形的 app icon。 姑且不論事情的真實性（反正很快就會揭曉），我們可以回想一下去年 iOS 18 推出時，主畫面增加了深色 app icon 以及自由上色的模式，這使得既有的 app icon 的規格一下多出兩種要支援。 推出新的 icon 不僅僅是改個底色，設計師要花時間去研究在新版 iOS 上面的實際效果。像這種情況，就可以儘早告知設計師同事們來因應。 設計師雖然也會關注 WWDC，但你身為實作者，通常會更早掌握細節。今年想必更是如此。 關於視覺設計或使用者體驗相關的更新，可以從 HIG 的 [What’s New](https://developer.apple.com/design/whats-new/?ref=ethanhuang13.plus) 頁面看到。 ## 技術方面：解決了什麼問題 這會是接下來幾個月與 iOS 工程師同事之間反覆研究與討論的核心話題。 我通常會分成幾個程度來安排去研究的輕重緩急： - 新版 Xcode 的 Beta 版，因為可以第一時間就下載來玩，並且會以平均每兩週為單位推出後續的 Beta 版。Xcode 的 [Release Notes](https://developer.apple.com/documentation/xcode-release-notes?ref=ethanhuang13.plus) 要認真閱讀 - 新版 iOS 的 API，如果有 breaking changes。新版的 [Release Notes](https://developer.apple.com/documentation/ios-ipados-release-notes?ref=ethanhuang13.plus) 也要認真閱讀 - 新的 Swift 語法與功能通常不急。新版 Swift 不會有 breaking changes，即使去年推出的 Swift 6，至今也不強制使用（你可以修改 Language Mode 回 v5）。而如果你對於新版 Swift 有興趣，應該早就看過 Swift [6.1](https://www.hackingwithswift.com/articles/276/whats-new-in-swift-6-1?ref=ethanhuang13.plus)、[6.2](https://www.hackingwithswift.com/articles/277/whats-new-in-swift-6-2?ref=ethanhuang13.plus) 的消息了。[Swift Evolution](https://www.swift.org/swift-evolution/?ref=ethanhuang13.plus) 是開源的，所以反而沒有什麼急迫性 - 個別 SDK 或 frameworks 的更新。這個要看你目前的專案有用到哪些工具 - 無論是什麼技術，最關鍵的評價標準還是：「這能對我們手邊的專案解決哪些問題？」（或者是，造成了什麼問題…） 還可以趁這個機會，跟 PM 們討論，什麼時候適合停止支援舊版的 iOS。這個問題不僅僅跟使用技術的新舊有關，也跟專案的使用者特性有關。 （我待過一間公司，專門做 IT 設備，app 是給 IT 人員使用的。使用者升級軟體的比例極高，所以 iOS app 只需要支援前一版 iOS 以上就可以。） 除了看 Keynote 與 Platforms State of Union 的影片，也可以透過官方網站的文件來一探究竟。下面這幾個連結，推薦你加到書籤： - [**What’s new for Apple Developers**](https://developer.apple.com/whats-new/?ref=ethanhuang13.plus) 是我覺得對個別 Apple SDK 沒那麼熟悉的朋友，可以先大概掃過一遍的頁面 - 對於資深 iOS 開發者來說，Apple 把所有的文件更新都放在 [**Updates**](https://developer.apple.com/documentation/updates?ref=ethanhuang13.plus) 以及下一層的 [WWDC24](https://developer.apple.com/documentation/updates/wwdc2024?ref=ethanhuang13.plus)，想必今年會有 [WWDC25](https://developer.apple.com/documentation/updates/wwdc2025?ref=ethanhuang13.plus) 的。我覺得是很好的入口 - 另外還有 [**Technotes**](https://developer.apple.com/documentation/technotes/?ref=ethanhuang13.plus)，是許多較為獨立主題的文章，開發者不可不讀。 - 至於 Xcode 與各平台的 **Release Notes**，那更是基本工夫了。就像我以前說的： > 如果新版推出後，上班時你發現 iOS team 同事都沒有在讀 release notes，那就表示…應該是你要去讀😂 每個人的時間有限，透過這樣的說明，應該可以有更好的學習優先順序。 不過，我也常說：「學習最有效率的時候，就是有興趣的當下。」所以如果有個東西你真的很有興趣，讓自己暫時迷路也沒有關係。反正大方向我們也清楚了。 ## 謠言與預告 據說下一代 iOS、macOS 等全部都會改成 26 版起跳；或是視覺風格改成玻璃介面等等。我通常對於新版 iOS 的傳聞都當作聽聽就算了，因為實際上推出以後，看到 API 文件，才會知道真正要做的事情是什麼。 至於已知消息的預告方面，可以看看 Swift [6.2](https://www.hackingwithswift.com/articles/277/whats-new-in-swift-6-2?ref=ethanhuang13.plus) 跟 [Swift Evolution](https://www.swift.org/swift-evolution/?ref=ethanhuang13.plus)。 還有，Apple 向來在全球無障礙宣導日（GAAD）就已經預告未來要推出的 Accessibility 功能。詳細資訊可以看我在 [Apple 開發者 #230 的報導](https://www.ethanhuang13.com/i/163860662/gaad-%E4%BB%A5%E5%8F%8A-apple-%E9%A0%90%E5%91%8A%E8%BC%94%E5%8A%A9%E4%BD%BF%E7%94%A8%E6%96%B0%E5%8A%9F%E8%83%BD?ref=ethanhuang13.plus)以及[官方新聞稿](https://www.apple.com/tw/newsroom/2025/05/apple-unveils-powerful-accessibility-features-coming-later-this-year/?ref=ethanhuang13.plus)。 ## WWDC Day 1 最重要的是 Labs 第一天固定會有的就是 Keynote 跟 Platforms State of Union 這兩場長篇演講。 觀影方式，除了 Apple 官網以外，也可以在 YouTube 上觀看。 **上午的 Keynote 是「外行看熱鬧」**用的，內容是 Apple 給全球有興趣的觀眾看的。 在 Keynote 結束的那瞬間，先去[預約一對一 Labs](https://developer.apple.com/wwdc25/labs/overview/?ref=ethanhuang13.plus)，因為熱門的 Labs 像是設計方面的，往往會馬上被搶光。 就算你暫時沒有具體的技術問題或 bug 要問，也可以預約 Labs。要記得，WWDC 這週是 Apple 一年當中唯一一週有大量工程師停下手邊開發工作，來聆聽開發者心聲。所以不要低估 Labs 的價值。 把你的 side project 展示給 Apple 工程師，聽聽他們的回饋吧！ 預約完 Labs，此時就可以下載新版的 Xcode 與平台 SDK beta 版。要不要裝、怎麼裝，我們稍後再說。 **下午的 Platforms State of Union 才是「內行看門道」**，給開發者們知道實際上有哪些 API 與 SDK 的更新。 接著，後續幾天的 Sessions 會開放名稱與時段。因為錄影都是預錄、也可以重複播放，所以不需要急著看。照著自己的步調、挑有興趣的，或是跟同事們分配著看就好。 最有時間急迫性的還是 Labs。 ## 善用社群資源，提升整理效率 不管你再怎麼焦急地想要知道 Apple 發表的新東西，肯定都有人比你還要焦急。而且他們的所在時區，比大部分讀到這篇文章的讀者更友善。 所以，歡迎善用社群的力量，因為真正重要的東西總是會一再出現，不用怕跑掉。 [WWDC Notes](https://wwdcnotes.com/documentation/wwdcnotes/?ref=ethanhuang13.plus) 是集結社群力量撰寫的 Session 筆記。你可以參考一下之前的筆記風格，大概就會有一個概念。 如果你平時就有在經營 Twitter 帳號、追蹤一些開發者，那麼 WWDC 期間應該是看推文就很夠了。你也可以到 [iPlayground](https://discord.gg/yBvNcXS86a?ref=ethanhuang13.plus) 的 [Discord](https://discord.gg/yBvNcXS86a?ref=ethanhuang13.plus) 或是 [weak self podcast](https://weakself.substack.com/) 的 [Discord](https://discord.gg/KGdXZqXgFY?ref=ethanhuang13.plus) 參與討論。 當然，訂閱我的 [Apple 開發者週報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)也肯定能看到重點，只是時間就沒那麼即時。 ## 用 AI 協助蒐集與輸出，而不是詢問 我之所以要在今年特別寫這一篇 WWDC 生存指南，並強調「2025 年版」，是因為今年我們有了許多實用的 AI 筆記工具，在整理新知與筆記時的策略，與以往大不相同。 我每週都用 ChatGPT 協助蒐集大量新知，然後再匯出大綱來撰寫 [Apple 開發者週報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)。WWDC 的眾多消息，可能一小時內可以看到 30 條消息。這種情況下，更是適合用 AI 工具來整理。 我就不介紹各種不同的工具，直接以 ChatGPT 為例： - 首先，下載 ChatGPT 的 Mac app - 註冊帳號並登入 - 新增一個專案，名稱就叫 WWDC25 - 專案層級的指令，可以簡單寫著：「此專案用來蒐集 WWDC 的新消息。除非被要求整理，否則不要做太多回應。被要求整理時，以技術、設計（使用者體驗）、商業（包含強制性的政策改變等）為主要分類。」 - 接下來，每當你看到 WWDC 相關的新消息，不管是一行文字、一張圖片、影片畫面的截圖、一則推文，都可以丟進這個蒐集用的專案 - 可以沿用同一個對話 - 你也可以在 Apple Notes 上貼入各種文字與圖片，再一次貼給 ChatGPT。不過這樣圖片的輸入順序會亂掉 - 如果你不熟悉在 macOS 上截圖功能的話，強烈建議學起來。系統內建的框選截圖快速鍵是 Cmd + Shift + 4，並且可以用空白鍵選取游標所在的視窗（我個人是用 Cleanshot X，並且設定成一樣的快速鍵）。截完之後直接拖曳到 ChatGPT 的對話視窗，進行記錄。 - 別忘了 iPhone 上也可以使用 ChatGPT app，可以延續對話 這樣子，你就有一個能無腦丟入各種資訊，以及自己感想的資訊蒐集器了。 等到需要整理時，再請 ChatGPT 輸出，就可以按照技術、設計、商業衝擊來分類。 你甚至可以跟 AI 工具討論事情的輕重緩急，以及自己工作的下一步。 最簡單的方式，是現在就把我這篇文章整個複製貼上 ChatGPT 參考啦！ 想深入瞭解如何把 AI 當作計畫工具，我在 iOS Developer+ 專欄有寫過一篇⟨[🪓訂定目標、拆分任務與追蹤進度─iOS 開發 AI 輔助工具 #9](https://ethanhuang13.plus/use-ai-as-project-tool/)⟩，歡迎付費訂閱。 我不建議用 AI 工具來詢問 WWDC 的新知。Apple 最新的官方文件與資料，AI 工具並不好去爬。人類都還在試圖搞清楚的第一時間消息，看人類的討論會比問 AI 還快。 這些問題，也可以包括你在新版 iOS 遇到的問題。以下就來聊安裝 Beta 版的注意事項。 ## 安裝 Beta 版 所有的 Beta 版在 Keynote 結束後就會開放。屆時新版 Xcode 可能還無法使用 Xcodes 安裝，所以建議從 [Apple Developers Download 頁面](https://developer.apple.com/download/?ref=ethanhuang13.plus)下載。 請注意，一台 Mac 上有多個 Xcode 版本是很正常的事情。只要用 `xcode-select` 指令切換工具鏈用哪一個版本即可。而為了簡化操作，我十分推薦[使用 Xcodes app](https://github.com/XcodesOrg/xcodesapp?ref=ethanhuang13.plus)。 為什麼要安裝 Beta 版 iOS？有三大原因： 1. 玩玩新的 iOS 功能 2. 實驗新的 API 3. 確保既有的 app 沒有壞掉 就個人興趣來說，我覺得 1 > 2 > 3，但是就工作方面的重要性來說，應該是 3 > 2 > 1。 你可能聽過一些說法：別在個人設備上安裝 Beta 版、最好在測試機上裝、不建議在 Beta 版的系統上登入個人的 iCloud 帳號、另外準備一個開發專用的 iCloud 帳號等等。 對，這些都是很理性的建議。但是實際上許多人還是直接拿自己的 iPhone 升上去 Beta 1，包括我自己，哈。 只能說，後果自負😅 別忘了嘗鮮的同時，還是要去確認一下手邊的專案在新版 Xcode 與 iOS 上跑起來如何。 ## 測試 Beta 版 「確保既有的 app 沒有壞掉」，究竟是要測試什麼呢？ 比較合理的作法，是準備安裝了 Beta 版系統的測試機，並且用 Beta 版的 Xcode 編譯與安裝，然後拿給 QA 同事進行 regression test。 資源不足、或者你是一條龍開發者，那就得自己來了。 我多年前有寫過一篇⟨[♟️Xcode 與 iOS 相容性測試策略分析](https://www.notion.so/Xcode-iOS-f6560debc52544baadf3f3871ce4c0bc?pvs=21&ref=ethanhuang13.plus)⟩。時間不同，但是策略不變。歡迎參考。 還有一件事情要提醒：許多資深開發者都說過，如果沒有在 Beta 2 左右就回報 Bug，那正式版 .0 的時候通常來不及修好。從這個角度來說，Beta 1 是最重要的。Beta 1 有測到問題的話，也可以馬上在一對一 Lab 進行回報。 ## 結語：事前準備的檢查列表 這篇文章的最後，讓我們來確認一下哪些準備工作可以做： - 把 Keynote 時間[加入行事曆](https://developer.apple.com/wwdc25/WWDC2025%5FKEYNOTE.ics?ref=ethanhuang13.plus) - 確定自己的開發者帳號可以正常登入 - 為了準備觀看 Session，在 Mac 與 iOS 裝置上[下載 Developer app](https://apps.apple.com/us/app/apple-developer/id640199958?ref=ethanhuang13.plus)，或是[訂閱 @AppleDeveloper YouTube 頻道](https://www.youtube.com/@AppleDeveloper?sub%5Fconfirmation=1&ref=ethanhuang13.plus) - 現在可以去[註冊 Group labs](https://developer.apple.com/wwdc25/sessions-and-labs/?ref=ethanhuang13.plus#group-labs)。這個我在[兩週前的 Apple 開發者週報](https://www.ethanhuang13.com/p/231?ref=ethanhuang13.plus)就提醒過大家了。看起來性質類似過去幾年的 Digital Lounge - 如果目前就有 Bug 或技術問題要問，那你要搶在 Keynote 結束後[預約一對一的 Lab](https://developer.apple.com/wwdc25/labs/overview/?ref=ethanhuang13.plus)。所以 **Keynote 結束後不要馬上去睡覺**、也不是下載 Beta 版，而是去預約！因為熱門 Lab 會瞬間被搶光 - 有要預約 Lab 的話，[先發 Feedback](https://developer.apple.com/bug-reporting/?ref=ethanhuang13.plus)、準備好 Feedback ID，以便預約到 Lab 就可以直接給 Apple 工程師相關的資訊 - 有要參加任何 Lab 的話，提前下載好 Cisco [Webex](https://apps.apple.com/tw/app/webex/id833967564?ref=ethanhuang13.plus)，這是 Apple 官方指定使用的線上會議軟體。最好可以熟悉一下使用方式及權限設定 - 把 macOS 升到正式版的最新版，以迎接新版 Xcode beta。因為通常新的 Xcode beta 都會要求上一版 macOS 的最新版 - 如果同事之間有足夠數量的測試機，分配一下哪幾台要用來升級到新版 iOS beta（也有可能你在開發 tvOS 或 visionOS app，總之我都一律寫 iOS） - 設定 ChatGPT 的專案，專門用來蒐集並討論 WWDC 帶來的影響，與後續規劃 - 熟悉 Mac 截圖功能，用來快速捕捉畫面，並丟進 AI 工具 - 確認一整週的行事曆，安排好休息時間，因為參加 Lab 很有可能要熬夜 我想，要在 WWDC 期間生存下來的重點，並不是吸收了多少資訊，而是有**清楚的目標，以及穩定的步調，指引自己未來的工作方向**。WWDC 雖然只有一週，但在正式版 iOS 上線前，還有許多準備工作要進行。 希望經過這篇整理與說明，你能更從容地迎接即將到來的 WWDC。比較能安心地睡覺，而不擔心錯過重要事情。 👉 如果你覺得本文對你有幫助，歡迎[訂閱 iOS Developer+](http://patreon.com/ethanhuang13/?ref=ethanhuang13.plus)，並請分享給更多朋友。 ## Bonus: 與 iPlayground 一起看 WWDC 今年，台灣最大的 Apple 開發者研討會──iPlayground，在台北捷運國父紀念館站附近有舉辦實體的「[WWDC 一起看](https://iplayground.kktix.cc/events/2025wwdctogether?ref=ethanhuang13.plus)」活動。這個活動也有被[刊登在 Apple WWDC 官網](https://developer.apple.com/wwdc25/community?q=Taiwan&ref=ethanhuang13.plus)。 我本人也會去參加。 活動會簡單收個 $100 場地費，詳細報名資訊[請看這裡](https://iplayground.kktix.cc/events/2025wwdctogether?ref=ethanhuang13.plus)。 如果你無法現場參與，也可以加入 [iPlayground 的 Discord](https://discord.gg/yBvNcXS86a?ref=ethanhuang13.plus)，在線上即時聊天。 ### 🧊iOS 開發補完計畫 #2 學寫 App 不會讓你賺大錢，但是絕對值得（商業觀念篇） URL: https://ethanhuang13.plus/ios-missing-manual-2-reality-still-worthy/ Last updated: 2025-12-20T05:20:59.000Z 如果你學習 iOS 開發是想做個 App 賺大錢，那麼我今天是來潑你冷水的。 做一個 App 要賺到幾千、幾萬台幣，並不難。但是要賺到百萬、千萬，會經歷各種的挑戰。本質上，那已經是在經營一門生意，不只是寫程式。 另一方面，我今天也會分享，即使寫 App 賺錢不容易，但是認真走過一段開發之路，肯定會有許多豐富、意想不到的收穫。 ## 寫 App 能賺多少？ 讓我們假想一下，如果一款 App，每個月可以對一位使用者收費 $100 台幣，一年就可以收入 $1,200。如果有 1,000 個使用者，就可以有 $1,200,000 的營收。 扣掉 Apple Small Business Program 減免過後的 15% 抽成、匯率損失，以及稅，你大概可以拿到一百萬台幣。 一百萬台幣很多嗎？對於一個在公司上班的 iOS 工程師來說，真的不多。但是你要付出的心力會比上班族多出許多。 除了寫程式以外，你要懂得設計、使用者體驗、行銷、客服，還有許多行政雜事。如果一個人處理不過來，需要雇用或外包，你還得付出管理人事的成本，包括薪資與時間。 相對地，在別人公司上班，只要有足夠的開發能力、可以準時交付需求，該下班的時候就能下班。薪水會準時入帳，否則公司就違法。 從機會成本來說，寫 App 創業還真不划算。 ## 獲得使用者不容易 再說到 1,000 個使用者、一百萬的收入，你真的拿得到嗎？ 首先，要讓 1,000 個使用者付費，他們必須先看到你的 App、看到了之後有下載、下載之後有打開、打開之後有進到付費頁面、進到付費頁面之後有真的付費訂閱。這叫做轉換漏斗。 假設： 1. 曝光 → 下載：2%（App Store 看到後願意下載的比率） 2. 下載 → 打開：80%（下載後至少打開一次） 3. 打開 → 查看付費頁面：30%（使用者探索到付費頁面） 4. 查看付費頁面 → 訂閱：5%（看到付費頁面後真的訂閱） 把每一個步驟的轉換率相乘，你會得到一個殘酷的結論：至少需要 400 萬次的曝光，才可能有 1,000 個付費使用者。 這還是上述每個轉換率有達到的情況。 ## AI 能幫忙寫程式，反而加劇了競爭 現在有 AI 能幫忙寫程式了，開發一款 App 的難度降低。這對於經營一門 App 生意來說，沒有帶來優勢，反而是讓競爭更激烈。你會使用 AI 工具，別人也會。搞不好，還用得更有效率。 Apple 最近剛好發了一篇[新聞稿](https://www.apple.com/tw/newsroom/2025/05/the-app-store-prevented-more-than-9-billion-usd-in-fraudulent-transactions/?ref=ethanhuang13.plus)，裡面提到過去一年協助超過 220,000 位開發者發布他們在 App Store 上的第一個 App。這表示，平均每天至少有 600 個新的開發者。這還不包括有經驗開發者的新 App，以及存在已久、佔據市場先機的舊 App 呢。 再者，軟體開發只是軟體生意的一小部分而已。把程式寫好，還會遇到要設計出美觀實用的介面的挑戰。還有行政、法規等等問題。 搞定了這些，好不容易上架了，許多人發現自己的 App 只有初期衝上 去一波下載量，後面就被浪潮淹沒了。這才發現原來寫 App 還需要許多行銷知識。 換個方式，讓我們用視覺的方式比喻。**我覺得做出一個 App 並上架，就像是在一片花海中的一朵小花。** ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/06/IMG_3756.jpeg) 當所有的花都在爭奇鬥艷的時候，你的花朵要如何脫穎而出？ 非常大朵？顏色與眾不同？還是長在特別顯眼的位置？ ## 留住使用者更不容易 更慘的是，大部分的軟體訂閱服務，使用者在訂閱沒多久就會取消。你必須不斷改進產品，留住使用者。 這方面，我推薦閱讀 RevenueCat 的 [State of Subscription Apps 2025](https://www.revenuecat.com/state-of-subscription-apps-2025/?ref=ethanhuang13.plus)。RevenueCat 提供了行動應用程式訂閱制的後台與分析服務，他們的資料非常有代表性與參考價值。今年的報告有 200 多頁，但你可以看摘要就好。 30% 的年費方案使用者在第一個月就取消訂閱。 至於我為什麼上述只提訂閱制，而不談其他收費模式，那是因為訂閱制為了要把使用者留住，所以與把產品越做越好的方向一致。 如果你只想賺一次錢，也不在乎經營回頭客，那就不需要採用訂閱制。但是對於重視累積長期價值的人來說，訂閱制更加合理。 總而言之，寫一個 App 上架就能夠賺到足以替代上班工作的持續收入，你需要面對的挑戰困難重重，沒有做下去之前，十分難以想像。 ## 我自己的故事 我並不是一個成功的獨立開發者，曾經做過的 iOS App 也就賺到幾萬塊錢而已。 那是我自學 iOS 開發不久之後開發的產品。白天醒著、晚上睡覺，腦中都在想怎麼讓這個 App 更好。在有限的技術能力下，費盡多個月的心力，終於做出自己理想的功能與設計。 好不容易上架，受到許多使用者好評與媒體報導。但是，一來它並不是一個非常大眾化的產品。二來，我當時選擇的是單次付費解鎖功能，而不是訂閱制，所以它無法創造持續的現金流。那個時候 iOS App 的訂閱制也不普及就是了。 總之，從投入的心血與時間來看回報，它是非常賠錢的一個專案。 但是對我來說卻是非常紮實的人生經歷。 沒有多久以後，我收到了使用者之一（另一個 App）的邀約，去他們公司面試，加入他們新成立的線上服務團隊，成為第一個 iOS 工程師。 老闆不懂 iOS 但親自來面試。我給他看了 App 的設計理念、使用者體驗細節，以及各種巧思，包括考慮到不同螢幕尺寸的 iPhone 的差異。他看完後，丟下一句：「我知道這個人可以做什麼了。」於是我拿到這份工作。 後來，公司甚至送我去了 4 次 WWDC，對我職涯的影響非常巨大。在職期間加薪 4 次，在我離開那間公司時，薪水是剛加入時的翻倍（到我離開下一間公司時又翻倍，這就是另外的故事了）。 我並不是學習寫程式出身的，大學跟研究所讀的是教育心理。台灣的軟體開發業界我一個人都不認識。但是因為自己做的 App，打開了成為正職軟體工程師的門。 多年後我回顧起來，覺得更寶貴的是，我為自己寫過好多 Apps，有很多沒有上架，而是我自己生活的一部分。 ## 我寫給自己的 13 App 在這邊，分享給你我寫給自己的 2025 年健康生活 App，名稱就叫做「13」。 從今年 1/1 新增專案以來，我每天都打開來用，並且不斷根據實際使用情況來調整 App 的功能。 這款 App 放入了許多我對生活節奏與健康的思考與實踐，這是我學會寫 App 的一大好處。 目前尚未上架，如果你有興趣，可以[下載 TestFlight 來玩玩看](https://testflight.apple.com/join/aKw8HrQK?ref=ethanhuang13.plus)。 ## 結語：寫 App 絕對值得，但不是為了賺錢 單靠寫 App 在 App Store 賺大錢是個有**可能**、**可行**性卻非常低的事情。 不過，能寫出屬於自己的 App，本身就是無可取代的經歷與成就感。 也許這件事會讓拓展你未來的機會。 而即便不用來向對外世界證明什麼，也是你自我創造力的實現。 希望我在給你潑冷水的同時，也有鼓勵到你。 我們下一篇「iOS 開發補完計畫」再見。 2 App 0:00 /732.6563265306122 1× ### 💻iOS 開發補完計畫 #1 開發環境篇：新手如何選擇開發配備 URL: https://ethanhuang13.plus/ios-missing-manual-1-buy-mac/ Last updated: 2026-03-18T07:52:09.000Z > 2026/03/18 更新：為了 Apple Silicon M5 系列更新 今天我們來聊 iOS 開發新手一定會遇到的問題：如何選擇合適的開發配備。 ## 你需要一台 Mac 要開發 iOS App，必須使用 Apple 的 Xcode 這套軟體。而 Xcode 只能在 macOS 上運行，macOS 則必須搭配 Mac 硬體。因此，我們來探討如何選擇一台適合開發 iOS App 的 Mac。 我自己使用過的 Mac 超過 10 台。以 Apple Silicon 版本來說，用過 M1、M1 Pro、M2、M3 Max、M4 等不同晶片來進行開發工作，並且經手過數十個大小規模的 iOS 專案，所以對於如何合理選擇配備，算是有一定的把握。 至於更早期的 Intel Mac，我們就不多做討論了，建議直接從 Apple Silicon 的款式開始考慮。 ## 學生開發者與初學者的首選：MacBook Air 如果你是學生，打算購買一台全新的 Mac 作為開發用途，在目前這個時間點（2026 年 3 月），MacBook Air M5 會是非常合適的選擇，無論是 13 吋或 15 吋都可以。 **以 13 吋的 MacBook Air M5** 為例，教育價新台幣 32,590 元就能買到配備 16GB 記憶體和 512GB SSD 的款式。 選擇開發用的 Mac，我們主要關注三個重點：處理器、記憶體和 SSD 容量。 **處理器（CPU）：** M5 處理器是非常合適的選擇。當然，使用更早期的 Apple Silicon 晶片也可以，像是 M4 的效能已經相當不錯了。 **記憶體（RAM）：** 目前蘋果全系列新品都至少配備 16GB 記憶體，不再有 8GB 的選項。16GB 是必要的，因為在我們使用開發工具時，模擬器本身就會佔用一部分記憶體。此外，開發過程中你不會只用到 Xcode 和模擬器，還會開啟網頁查詢資料，或執行其他輔助工具，所以記憶體千萬不能省。 **固態硬碟（SSD） 容量：** 目前 MacBook Air 最低階的款式已經搭配 512 GB SSD。開發過程中，Xcode 會產生各種檔案，例如程式碼快取，容易塞滿硬碟。因此，512GB 是非常必要的。 ## **預算有限、選擇二手 Mac 的取捨** 如果預算不足，必須在規格上有所取捨，我認為最不能犧牲的是記憶體，16GB 是底線。 這也是為什麼我並不推薦購買 MacBook Neo 作為開發設備。雖然它的 CPU 足夠編譯軟體，但是記憶體只有 8 GB，沒辦法同時開啟太多程式（例如瀏覽器）。即使你目前能夠忍受，也沒辦法撐太多年。下一代的 MacBook Neo 搞不好會使用 A19 Pro 處理器，搭配 12 GB 記憶體，情況會好很多（如果 Apple 每年都會更新 MacBook Neo 的話，每年舊換新也是一種策略。但我們不知道會不會這麼頻繁更新。） 如果你購買 Mac 的主要目的是開發，但預算有限，我推薦二手的 MacBook Air M4 勝過 MacBook Neo。 其次，雖然不建議，但如果真的要省，可以考慮 256 GB SSD，但使用體驗會十分痛苦。 至於處理器的話，可以降級沒關係。其實 M1 晶片已經很不錯了。我自己有多台 M1 Mac 的使用經驗，對於學生或初學者來說，M1 的效能是足夠應付學習與基本開發需求。當然，如果預算到位，最好還是擁有一台 M5 的 MacBook Air，開發體驗會十分舒適。 ## 經驗豐富者或預算充足的選擇：MacBook Pro 如果你是已有經驗的軟體工程師，只是先前沒有接觸 iOS 開發，現在想添購一台 Mac，或者你的預算相對充足，那麼我會推薦 MacBook Pro M5 Pro，14 吋。 以 14 吋 MacBook Pro M5 Pro 為例，目前配備 15 核心 CPU、24GB 記憶體和 1 TB SSD 的官網售價約為新台幣 74,900 元。對於一位軟體工程師自用而言，這樣的配備，無論是處理器效能、記憶體還是 SSD 容量，都很夠用了，且可以用很長一段時間。 如果想在這個基礎上再升級，我建議優先考慮 CPU 核心數，增加 $7,000 可以獲得與 M5 Max 相同的 18 核心 CPU。 至於記憶體，24 GB 對於開發一般的軟體已經非常夠用了，如果要升級至 48 GB 需要加 $14,000，成本不低。只有清楚需要執行本地 LLM 的需求才認真考慮加記憶體，甚至選擇 M5 Max 晶片。 ## iOS 開發所需的測試裝置 iOS App 是運行在 iPhone 或 iPad 上的。我不建議你為了開發而去特地購買全新的 iPhone 或 iPad。如果你手邊已經有 iPhone 或 iPad，直接使用現有的設備即可。 除非你開發的 App 已經開始賺錢，並且你開始思考不同裝置款式在細節上的差異，為了滿足這些不同設備使用者的特定需求，才需要考慮購買相應的測試機。 如果你的 App 還沒有盈利，建議直接使用現有設備，或者考慮購買二手裝置、向朋友借用舊款設備都可以。 ## 養成觀察電腦效能的習慣 回到 Mac 配備等級的選擇。如果你還想追求更強大的電腦，我會反問：**你怎麼知道自己真的需要？** 我認為軟體工程師，或者認真從事開發工作的人，應該培養判斷電腦效能是否夠用的能力。這樣未來在做購買決策時才有依據。 具體的作法是使用監控程式。Mac 內建「活動監視器」可以觀察 CPU、記憶體使用率。不過該軟體不方便隨時查看，所以我們可以採用把使用率顯示在選單列的第三方程式，隨時都能看到 CPU 的負載情況。 我自己使用的是付費軟體 iStat Menus。而在免費的選擇中，我推薦一個可愛的軟體叫做 [RunCat](https://apps.apple.com/tw/app/runcat/id1429033973?mt=12&ref=ethanhuang13.plus)，它是一隻會跑步的貓。CPU 使用量越大，貓咪跑得越快。也能切換顯示 CPU 使用率的百分比。 為什麼要安裝這類軟體呢？如果你經常觀察到電腦在編寫程式或編譯程式碼時，CPU 使用率常常滿載，你就會知道目前的電腦已經全力在工作了。等到有一天你的軟體越開發越大、速度變慢，或感覺到效能瓶頸時，就能根據經驗判斷：「我這台 M2 的電腦在編譯這個專案時會吃滿效能。」考慮購買新電腦時，心中就有個底、有比較基準。 有一個開源專案叫做 [XcodeBenchmark](https://github.com/devMEremenko/XcodeBenchmark?ref=ethanhuang13.plus)，你可以用它來測試自己的電腦，或者查看表格，例如使用 Xcode 26 編譯一個複雜專案在不同 Mac 型號上的速度。 許多網友會分享自己的測試數據，例如 M2 電腦和一台搭載 M4 Max 16 核心 CPU 的電腦，後者編譯速度可能是你的兩倍或三倍。表格列出編譯所需的秒數，讓你預估花多少錢購買何種等級的電腦，能在編譯時節省多少時間。 然而，如果你在開發過程中，大部分時間都在撰寫程式碼，不常進行編譯並執行，那麼 CPU 效能對你的影響就沒那麼大。總之，養成觀察 CPU 使用率的習慣，能幫助你做出更合理的購買決策。 特別是如果你使用的是像 MacBook Air 這樣沒有風扇的機種，沒有聲音讓你知道電腦正在努力工作，你可能只感覺到它發熱。如果沒有監控軟體，你就不清楚它是否已經在滿載狀態下運行。 所以我認為，安裝一個效能監控軟體、時常了解電腦的負載，是軟體工程師必要的習慣與技能。當你未來需要更好的硬體時，才能有合理的判斷基準，而不是無腦升級。 ## AI 相關應用的特殊考量 最後補充一下：如果你打算開發 AI 相關的應用，所需的硬體可能會跟我們前面討論的配置差很多。像是本地跑大型語言模型，通常會吃大量記憶體。雖然也有一些人選擇用 Mac 來跑，但這些話題遠超出初學者的範疇，就不在這裡細談了。 ## 結語 今天我們說到了新手或初學 iOS 開發者所需的基本配備。希望經過我的說明，對於預算與開發體驗之間的關係能有個概念，知道至少需要什麼樣的配置才能順利開始。 我們應該把錢花在刀口上。不要一開始就把所有預算都投入到購買頂級硬體配備上，這樣並不會節省太多時間，反而可能是一種浪費。如果你真的因為開發 App 賺到錢了，再視情況考慮升級硬體。 希望這篇文章對你有幫助。下次再見！ ### 👩‍🎨《光與影：33 號遠征隊》實測在 M3 Max 可玩性高 URL: https://ethanhuang13.plus/expedition-33-mac/ Last updated: 2026-08-13T06:05:45.000Z iOS Developer+ 專欄偶爾也會聊[用 Mac 玩遊戲](https://ethanhuang13.plus/tag/mac-gaming/)的經驗。 角逐 2025 年度最佳遊戲的大黑馬《[光與影：33 號遠征隊](https://www.expedition33.com/?ref=ethanhuang13.plus)》，可以在 Mac 上遊玩。 這遊戲超棒，我已經在 PS5 Pro 上通關一週目、取得白金獎盃。很有可能就是我今年最愛的遊戲了。 為了支持開發團隊，我在 [Steam](https://store.steampowered.com/agecheck/app/1903340/?l=tchinese&ref=ethanhuang13.plus) 上又買了一次。並且在 Mac 上玩了幾個小時，覺得值得寫一篇文章，記錄一下我的測試結果。 雖然 Mac 不會是我最推薦遊玩這個遊戲的平台，但如果你的配備條件許可，不妨一試。 如果你想看我之前測試「暗喻幻想：ReFantazio」的心得，可以[看這一篇](https://ethanhuang13.plus/metaphor-refantazio-demo-mac/)。 ## 展示錄影 我的 MacBook Pro 14 吋 是 M3 Max、30 核心 GPU。 錄製影片會稍微影響圖形效能。實際遊玩時，戰鬥有維持在 30 FPS 以上。我覺得是能玩的程度。 影片有我的圖形設定供參考，以及小範圍移動與戰鬥流程（「顯示模式」要改成「無邊框視窗化」比較好）。 _This post is for paying subscribers only._ ### 🔃讓 Agent 透過 XcodeBuildMCP 自行修正錯誤─iOS 開發 AI 輔助工具 #10 URL: https://ethanhuang13.plus/ios-ai-tools-10-xcodebuildmcp/ Last updated: 2026-08-13T06:05:43.000Z [Claude 4 發表](https://www.anthropic.com/news/claude-4?ref=ethanhuang13.plus)以後我就開始在 Cursor 裡面使用。 初步觀察，它似乎又比之前的模型更聰明了，也知道一些較新的 Swift 與 SwiftUI 語法。官網顯示模型的訓練資料來到 2025 年 3 月。 但，還是沒有到「強者我同事」的體感（你可以忽略我這種沒有數據的主觀描述）。 我在寫這篇文章時，Claude 4 Sonnet 在 Cursor 的價格是 0.5x 個 credit，可以把握機會多玩玩看。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/05/CleanShot-2025-05-26-at-00.50.24@2x.png) ## 反覆驗證是常見的開發流程 不管是對於人類工程師，還是 AI Agent，不論有多聰明，要把 Swift 寫正確，編譯器的回饋是不可或缺的。 這應該是 iOS 工程師的常見工作流程： 1. 在 Xcode 寫完一段程式以後，按下 `Cmd + B` 去執行 2. `Cmd + 5` 切到 Issue Navigator、或是 `Cmd + 9` 切到 Report Navigator，看看有哪些 build error 要修 3. 修正完以後，再按一次 `Cmd + B` 重複這個循環直到可以順利 build 過。若有需要，把 App 跑起來看看效果。 ## XcodeBuildMCP 要讓 AI Agent 具備我上述描寫的工作流程，其實不難。 你可以教 AI 寫出 `xcodebuild` 指令、在 Terminal 執行，並讀取結果作為修正依據。 或者，更簡單的，使用 [XcodeBuildMCP](https://github.com/cameroncooke/XcodeBuildMCP?ref=ethanhuang13.plus) 作為 Agent 與 `xcodebuild` 的橋樑。 如果你對 MCP 不熟，我簡單說明一下：[MCP(Model Context Protocol)](https://modelcontextprotocol.io/introduction?ref=ethanhuang13.plus) 是讓 Agent 與外部工具串接的 protocol。只需要知道，現在越來越多工具支援 MCP，讓 AI Agent 能夠整合使用。MCP 原本由 Anthropic 提出，已經變成目前的主流與共識。各大 AI 模型與工具的廠商都有支援。 設定 XcodeBuildMCP 非常簡單，只要 1 分鐘。 _This post is for paying subscribers only._ ### 🪓訂定目標、拆分任務與追蹤進度─iOS 開發 AI 輔助工具 #9 URL: https://ethanhuang13.plus/use-ai-as-project-tool/ Last updated: 2026-08-13T06:05:42.000Z 最近我好像比較多在忙 [weak self podcast 的復出](https://weakself.dev/episodes/109?ref=ethanhuang13.plus)，以及「[iOS 開發補完計畫](https://ethanhuang13.plus/https-iosdeveloper-plus-ios-missing-manual-launch/)」的啟動。實際上，我還是更重視「iOS Developer+」的深度內容。 今天來分享一套我很少看到人們使用 AI 工具的方式，就是當作專案計畫的工具。 前陣子，我在臺灣大學幫[行動應用創新賽](https://maic.straighta.com.tw/?ref=ethanhuang13.plus)（MAIC）進行了一場演講，題目是「AI 的第三方技術與應用」。 我一開始就問所有的聽眾：「有沒有在使用 ChatGPT？」所有的聽眾都舉了手。 但是當我問起：「有沒有在使用 ChatGPT 做計畫？」幾乎沒有人舉手。 你呢？有沒有使用 AI 工具做計畫？ ## 使用 AI 工作協助做專案或學習計劃 通常，拿自己熟悉的東西來問 ChatGPT 或各種 AI 工具，很容易發現他們專業知識，還是不如我們。 但是用來做專案計畫，我就覺得是非常好的使用方式。 在那場演講中，我用參加比賽當作目標，示範怎樣使用 ChatGPT 做計畫。 下面是我跟 AI 討論計畫所用的 prompt。 _This post is for paying subscribers only._ ### 🐣iOS 開發補完計畫正式啟動 URL: https://ethanhuang13.plus/https-iosdeveloper-plus-ios-missing-manual-launch/ Last updated: 2026-03-02T14:11:21.000Z > 2025/06/20 更新：iOS 開發補完計畫改為免費專欄、不定期更新。詳情請見[公告](https://ethanhuang13.plus/ios-missing-manual-free-transition/) **之前**[**預告**](https://www.patreon.com/posts/127216347?ref=ethanhuang13.plus)**的「iOS 開發補完計畫」正式開始了。** **你可以**[**在 Patreon 訂閱**](https://www.patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus)**「13 的 iOS Developer 會員」或「13 的 iOS Developer+ 會員」來開始閱讀。** # **「iOS 開發補完計畫」簡介** 你是 iOS 開發新手嗎？想知道 iOS 開發的路上會遇到哪些坑嗎？ 那些 AI 學不到的 iOS 開發實務經驗，由 13 親自撰寫： - 專為 iOS 開發初學者、Vibe Coder、用 AI 學開發的人設計 - 每週更新 2 篇補完知識 - $5 美金/月 - 學生可以來信索取 3 個月的免費兌換連結（細節往下看） - [**點此加入會員**](https://www.patreon.com/ethanhuang13/membership?ref=ethanhuang13.plus) # **「iOS 開發補完計畫」是寫給誰的？** **iOS 開發初學者、用 AI 學習 iOS 開發的朋友、iOS Vibe Coder。** 身為資深 iOS 工程師，我大量使用 AI 工具輔助開發，也非常鼓勵搭配 AI 工具來學習 iOS 開發。 也因為這樣，我知道目前 AI 模型的 iOS 開發知識有所侷限。 有許多知識，或者「坑」，還沒有進入模型當中。也有許多觀點與經驗，沒辦法透過 AI 來習得。 所以，我想藉由這份補充資料，給想學習 iOS 開發、搭配 AI 工具學習的朋友，一些基本知識與經驗分享。 **這不是一套 iOS 開發入門教材或課程。而是實務經驗談，以及補充 AI 學習盲點的資料。** # **有哪些內容？** 在這篇[預告文章](https://www.patreon.com/posts/127216347?ref=ethanhuang13.plus)中，有列出超過 130 個我打算要寫的題目。 目前只有寫好第一篇，但我覺得是個不錯的開始。 - [商業觀念篇：Apple 對開發者的態度是什麼](https://www.patreon.com/posts/129617023?ref=ethanhuang13.plus) **後續的內容會以每週 2 篇左右的進度發表。**越多人訂閱，我的產出速度就會越快。 預計分享的內容，不一定都圍繞著程式語言。而是涵蓋了構思點子、開發、介面設計、使用者體驗、Accessibility、測試點子、送審、上架、產品經營、商業計畫等等面向。 開發一款 app 絕不是只有寫程式而已。網路上有許多很棒的程式課程，AI 也會教你寫程式（或幫你寫）。但是我會跟你分享的東西，是累積多年實務經驗下來的重點。 相信你也可以明白，許多經驗分享並不是教一次就能學會。有些「坑」，不管前人再怎麼提醒，還是得自己親自踩過才能學到。我能做的事情就是預先提醒。 # **「你是誰？」** 我叫 13，因為我的中文名字唸起來像是「一三」。 我從 iOS 6 時代開始自學 iOS 開發。 曾在兩家公司任職（其中一家是美商上市公司），擔任 iOS 主管或 team lead。 上架過的 iOS app 超過 10 個，也寫過數十個 side project apps。你可以從[**我的 GitHub**](https://github.com/ethanhuang13/?ref=ethanhuang13.plus) 瞭解我寫過的開源專案。 我在 iOS 開發社群有非常多分享。超過 230 期[**電子報**](https://ethanhuang13.com/?ref=ethanhuang13.plus)、100 集以上的 [**Podcast**](https://weakself.dev/?ref=ethanhuang13.plus)、[**YouTube 影片**](https://www.youtube.com/@ethanhuang13?ref=ethanhuang13.plus)、[**Notion 知識庫**](https://ethanhuang13.notion.site/?ref=ethanhuang13.plus)，以及[**大量的推文**](http://twitter.com/ethanhuang13?ref=ethanhuang13.plus)。加起來應該是全台灣最多的。 我去過 4 次 WWDC 現場。是疫情時代之前、Apple 舉辦一整週實體 WWDC 的最後 4 年。 參與台灣唯一的 iOS 開發者研討會 [**iPlayground**](https://iplayground.io/?ref=ethanhuang13.plus) 宣傳工作多次，擔任過講者 3 次。最近一次受邀擔任開場講者。 還有多次受 Apple 台灣教育團隊的邀請，到臺灣大學講課，分享 iOS 開發經驗。 我目前正在 Patreon 經營付費會員、分享進階的 iOS 開發內容，叫做「[**iOS Developer+**](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)」。而「iOS 開發補完計畫」是其中一個部分。 許多人喜歡我分享的東西。甚至有好幾位前同事主動來訂閱我的付費會員，令我非常感動。 最後一點，我的大學與研究所的主修是教育心理學。雖然不是職業教師，但是對於「教、學」這兩件事，一直都很有興趣。 # **為什麼想寫？** 我一直都想把自己累積的 iOS 開發知識整理起來。不過以往分享的對象都是已經在從事軟體開發的朋友。去整理他們大半都知道的事情，比較沒有意義。 直到最近，我有機會接觸許多在校學生、初學者，以及因為 AI 的緣故開始接觸 iOS 開發的人們。覺得撰寫「iOS 開發補完計畫」對於這些新朋友會很有幫助，自己也剛好可以藉由輸出知識來整理知識。 # **如何取得？費用多少？** 請到我的 Patreon 訂閱「[13 的 iOS Developer 會員](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)」，**每個月是 $5 美金**。每週我都會更新 2 篇左右的內容。 如果你是之後才開始訂閱，可以立刻看到所有已經發表的文章。 每一篇的內容不會太長，但是都會講至少一個重點。 （我的 Patreon 上另外有一個「[13 的 iOS Developer+ 會員](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)」等級，每月 $13 美金。是提供給資深 iOS 工程師，或是有一定程度的開發者的進階內容。不推薦初學者訂閱。） 收費的原因，並非財務上的（雖然我目前的主要工作就是寫作）。而是希望藉由一點收費，讓**學習者更有動力**。避免「我買了書就等於讀過」那種自我安慰效應。 **為什麼是訂閱制而不是一次付清？**這也是為了提高學習動力與效果。學習是細水長流，無法速成。 只要在訂閱期間，你就會持續收到我寄出的文章。這樣的學習節奏比較舒服。 值得一提的是，想要把 iOS 開發學好，還是要仰賴其他教材或是 AI 工具。訂閱這份會員是補充知識，而非一套完整課程。只是這些知識你可能很難自行得知──哪怕是靠著 AI 工具。 # **我是學生，可以減免訂閱費用嗎？** 非常可以，太可以了。 我很希望給學生開發者一些寶貴經驗，所以**一開始就打算免費提供給在學學生**。 實施辦法是這樣： 1. [**寄信給我**](mailto:eh13@hey.com)。內文告訴我你的學校電子郵件，郵件地址必須包含 .edu。你可以參考以下模版： ``` 標題：「iOS 開發補完計畫」學生方案 收件人：13 內文： 13 你好， 我是 OO 高中/大學的學生，正在學習 iOS 開發，想要索取「iOS 開發補完計畫」。 這是我的學校 Email：***@***.edu OOO ``` 1. 我收到信並確認無誤以後，會把「3 個月免費會員」的連結寄到你的學校電子郵件。**這個連結是專屬於你的** 2. 透過寄給你的連結，就可以把 Patreon 帳號升級成「iOS Developer」會員等級，為期 3 個月 為什麼只有 3 個月呢？因為我當初在從頭自學 iOS 開發的時候，只花了 3 個月就進入到送審上架階段。現在有 AI 工具的協助，開發小型 app 的時間更有機會縮短到數天。 我希望給學生免費的優待不是無上限的，才會更懂得珍惜與把握時間。 假如 3 個月到了，你想延長免費資格，那很歡迎你跟我分享學習 iOS 開發的收穫，我很樂意再給你後續的免費閱讀資格。 畢竟，我的目的不是從學生身上賺錢。主要還是為了刺激學習動力。 # **「我是資深開發者，也想要取得或贈送這項資源」** 如果你是資深 iOS 開發者，我十分推薦你訂閱我的「[**iOS Developer+**](http://patreon.com/ethanhuang13?ref=ethanhuang13.plus)」會員方案。裡面也會包含相同的內容，但是會有更多已經寫好、以及持續在發表的進階文章。而且還可以在[官網](https://ethanhuang13.plus/)或 Notion 上閱讀。過去的內容請參考 [**iOS Developer+ 內容預覽**](https://ethanhuang13.plus/)。 如果你想要贈送 iOS Developer 會員資格給其他人，比如說，想要買來送給學生（雖然我會免費提供給學生，但是你想要**資助我撰寫這些內容**），則非常歡迎你使用 [**Patreon 的送禮功能**](https://www.patreon.com/ethanhuang13/gift?ref=ethanhuang13.plus)。贈送的月數以及總數量，完全可以由你自己決定。 # **發行計畫終止的情況** 整套補充資料，我覺得要寫個 100 篇以上應該不是太大問題。 如果將來有一天我已經寫不下去、無法維持穩定產生內容的話，我會把全部的內容集結成一本電子書，提供給當時還有訂閱資格的會員下載。 並且會提醒會員停止訂閱（我無法在 Patreon 後台終止你的訂閱資格，需要你主動操作）。當然，如果你願意持續付費訂閱作為支持我的話，也完全沒問題。 假如你的程度或是興趣足以消化「iOS Developer+」的進階內容，也歡迎隨時升級。 ## Bonus: Podcast 在撰寫第一篇文章時，我發現用講的比用寫的還容易（我跟朋友做過超過 100 集的 Podcast）。所以未來部分主題我也打算用 Podcast 加文章的方式發表。 你可以在 Patreon 帳號資訊裡面取得私人 RSS Feed 網址，並加入到你的 App。 使用 Apple Podcast 請見[這篇](https://support.patreon.com/hc/en-us/articles/115000877506-Add-my-private-RSS-feed-to-the-Apple-Podcast-app?ref=ethanhuang13.plus)，其他 App 請見[這篇說明](https://support.patreon.com/hc/en-us/articles/115005429546-Which-podcast-apps-will-my-custom-audio-RSS-link-work-with?ref=ethanhuang13.plus)。 （備註：iOS Developer+ 也有在 [vocus](https://vocus.cc/salon/ethanhuang13?ref=ethanhuang13.plus) 上刊載，但是 vocus 不支援 Podcast。為了公平起見，只包含「iOS 開發補完計畫」的「13 的 iOS Developer 會員」方案暫時沒有在 vocus 上提供。） # **總而言之** 你還在等什麼呢？[**立刻加入我的 Patreon**](https://www.patreon.com/ethanhuang13?ref=ethanhuang13.plus)，並分享給想學習 iOS 開發的朋友吧！ ### 🐣iOS 開發補完計畫 #0 商業觀念篇：Apple 對開發者的態度是什麼 URL: https://ethanhuang13.plus/ios-missing-manual-0-apple-dev-relationship/ Last updated: 2026-03-18T07:36:04.000Z > 2026/03/18 更新：由於專欄已改為免費，移除舊的方案說明與 Podcast 部分。 我之前曾提到，想做一個比較適合新手的專欄系列，名為「iOS 開發補完計畫」，主要針對 iOS 開發新手、Vibe Coder 或是學生，分享一些從 AI 較難學到的開發知識或經驗談。 這系列文章是設計給新手開發者的專欄，免費提供。對於資深的工程師來說，這些內容可能相對基礎，甚至是已經非常熟悉的東西。 在「iOS 開發補完計畫」的開頭，我想和大家聊的第一個篇章，就是「商業觀念篇」。 ## Apple 與開發者之間的關係 身為開發者，有非常多東西需要學習，但我認為一開始最關鍵的，應該是認識 Apple 這間公司，用一個正確的視角來看待 Apple 與開發者之間的關係。如此一來，在遇到各種問題時，至少會有一個思考的基礎，明白 Apple 是如何看待我們開發者的。 我的直接答案是：**開發者是與 Apple 進行商業合作的夥伴**。 Apple 是一家透過打造優良硬體產品，搭配其軟體與服務，形成一個整合式生態系的公司。消費者因為喜歡這樣的產品與體驗，而持續購買 iPhone 或 Mac 等裝置，並使用上面的應用程式或作業系統。 我們這些第三方開發者，扮演的角色其實是在協助 Apple 壯大其生態系，使其護城河更加穩固。至少從 Apple 的視角來看開發者是這樣。 當然，我們自己一開始可能不會意識到這一點，或許是抱持著想做出屬於自己的東西，或是有個商業點子想實現，讓更多人使用自己的 App。 ## App Store 規範與抽成機制 然而，對 Apple 而言，它提供了平台和一群消費能力強、付費意願高的使用者，讓開發者能夠在其平台上創造新的商業機會，這是一種合作關係。因此，Apple 自然會在 App Store 上制定規範，並進行抽成。 無論是買斷制、訂閱制，或是儲值型的數位服務，都必須透過 Apple 的 In-App Purchase 機制，或是付費 App 也必須經由 App Store 的支付系統。這一直是 Apple 牢牢掌握的一環。 近年來有些公司，例如 Epic Games 或 Spotify，如果完全依照 Apple 的抽成規範，利潤會大幅壓縮，因此他們會抗議 Apple 抽成過高，或者主張 Apple 應該開放外部支付機制，允許 App 內連結至外部付費頁面。 美國法院前陣子也宣判，Apple 不能再阻止開發者引導使用者至外部進行付費，不能僅限於 In-App Purchase。目前美國已經開放，其他地區未來也可能會有類似的要求。但我想強調的是，在此之前，Apple 一直以來都將這條界線抓得非常緊，直到法院判決出爐。 ## App Store 商業模式的核心邏輯 這其實就是 Apple 的商業模式。它認為自己擁有非常優質的使用者群體，開發者是因為 Apple 創造了這樣的生態系並吸引了眾多消費者，才能在上面賺錢，所以 Apple 理所當然應該抽成。我不評論這樣的思路或商業模式是對是錯，但我認為這是一個相當合理的思考方向。 我們這些開發者對 Apple 的依賴程度，遠大於 Apple 對個別開發者的依賴。雖然 Apple 也需要大量優秀的開發者，但若論及個別開發者與 Apple 之間的關係，顯然是開發者更需要 Apple，而非 Apple 更需要特定的某一位開發者。 這比較是從商業權力的角度來分析。畢竟，Apple 是全球市值數一數二的超大型公司。我想，讀者應該可以認同我這樣分析 Apple 與開發者之間的關係。 ## Apple 提供開發平台與服務的成本 Apple 創造了這個開發平台，也向開發者收取每年 99 美元（約台幣 3400 元）的年費。這筆錢並不好賺。 因為 Apple 需要開發大量的開發工具、維護整個後台系統以及金流系統。例如，若是訂閱制服務，Apple 會協助處理消費者信用卡過期的問題，提醒消費者更新卡片資訊以避免扣款失敗，這些都是開發者不需要操心的。此外，Apple 還需要處理所有開放國家的稅務問題，開發者同樣不必自行處理這些金流的瑣事，Apple 都一手包辦了。 更不用說，Apple 每年都會更新大量的 API、推出新版的 Xcode 或更新開發工具、舉辦開發者大會 (WWDC)，並錄製非常多教學影片和撰寫許多技術文件。這些新工具讓我們可以實現新的功能，而這一切都需要投入龐大的成本。 Apple 之所以投入如此巨大的資源去建構這個開發平台，讓我們可以在上面進行開發，其本質我認為還是呼應了前面所說的——整個生態系的建立，有賴於眾多第三方開發者的貢獻。 ## 開發者必須遵守的遊戲規則 因此，對我而言，很重要的一點是：開發者在 Apple 的生態系或平台上進行開發，就必須遵守其遊戲規則。 Apple 可以拒絕與你進行商業往來，可以讓你的 App 無法上架。你有天馬行空的想法，想創造新的、好的體驗，這非常好。但如果你抱持著要顛覆 Apple 的商業邏輯或商業規範，想跟它對著幹，不遵守它的規則，那麼 Apple 當然也可以選擇不與你合作。 很多人可能都遇過 App 被 App Store 拒絕的經驗。有些情況是，你開發了合理的 App，卻被莫名其妙地拒絕，這種情況確實存在。但另一方面，也有許多拒絕是因為你的產品不夠成熟、不夠創新，或者市面上已經有更多優秀的同類產品，你的完成度還不夠等等。 我想，**Apple 並沒有義務一定要接受你的 App**。這或許是大家一開始不太能接受的觀點，但從我的角度來分析 Apple 的立場，這是合理的事情。 ## 維持與 Apple 的良好合作關係 總之，我認為大家還是可以藉助 Apple 的整個生態系或平台，去做出很棒的產品。但是，你必須抱持著一個態度：我是來和 Apple 一起做生意的，不會想要破壞彼此的合作關係，會遵守它的遊戲規則。 例如，它要求的隱私權揭露、資料控管、對使用者帳號及資料的保護等等，或者某些 API 沒有開放，你就不能用一些旁門左道的方式去使用隱藏的機制。盡可能地去維持與 Apple 良好的商業合作關係，這是我在一開始想提醒大家的一個觀念。 ## 結語 好，那麼以上就是我們第一篇的內容。如果喜歡的話，可以給我一些回饋，讓我知道這種形式不錯，或者這篇內容對您有幫助。我們就期待下次再見了。 ### 🎒我用了一年的日常背包都裝些什麼 URL: https://ethanhuang13.plus/my-edc/ Last updated: 2026-08-13T06:05:41.000Z 今天早上起來的時候，我突然想到可以來分享一下自己的 EDC──**身為 iOS 開發者的日常兼旅行背包，都放了什麼東西。** [EDC (Everyday Carry)](https://zh.wikipedia.org/wiki/%E6%97%A5%E5%B8%B8%E6%90%BA%E5%B8%A6%E5%93%81?ref=ethanhuang13.plus) 指的是一個人日常攜帶的物品。像是手機、錢包、鑰匙，或者背包裡固定放的東西。有些人會追求固定的 EDC 來應付日常各種狀況。 一查訂單歷史，才發現我的背包使用到現在正好滿一年，非常巧。看來這篇文章註定是要寫出來了。 當然，這篇的內容可能比較適合男性。 有趣的是，多數物品是在 Amazon Japan 買的，台灣不一定買得到。商品連結都是乾淨的連結。 ## 先說背包：[Tomtoc 城市隨行斜肩包 14 吋](https://www.amazon.co.jp/-/en/dp/B0C6MQDJ1V?th=1&ref=ethanhuang13.plus) 背包是 EDC 的主要容器與上限，所以要先講。 我的背包是 Tomtoc 的斜肩包。剛好裝得下 14 吋的 MacBook Pro，還可以放下不少東西，而看起來不會太大。 **選擇斜肩包是因為可以快速轉到前方拿取物品。搭捷運或電車時，也能迅速調整背法，減少佔用空間，是通勤族的好選擇。** 這個背包跟著我去過 5 個亞洲國家、幾場國際研討會、無數間咖啡廳，都沒有遇到什麼問題。十分滿意。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/05/IMG_2750.jpeg) 背面是這樣。可以自行更換左肩背或右肩背。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/05/IMG_2752.jpeg) Tomtoc 的背包多半使用 YKK 拉鍊，省力且堅固，而且有一些防水效果。 用過好的拉鍊，你就回不去了。 背包的容量很難拍攝，內部大概是這樣。還能塞好些東西，甚至一台 Nintendo Switch 加保護殼（但是會變得很重）。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/05/IMG_2749.jpeg) 外側的口袋有鑰匙圈的扣環，這種設計讓人可以很方便地找到鑰匙、且不容易搞丟。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/05/IMG_2751.jpeg) ## 裝了哪些東西 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/05/IMG_2739-1.jpeg) 背包裡的所有東西，由左到右、由上到下，依序是： _This post is for paying subscribers only._ ### 💪開始累積就不會焦慮了 URL: https://ethanhuang13.plus/start-accumulating-to-reduce-anxiety/ Last updated: 2026-08-13T06:05:40.000Z 分享一個小技巧、小習慣，來克服資訊焦慮。 **資訊焦慮往往是因為覺得有好多東西要學，學不完，不知道從何開始，乾脆放棄。**但其實，只要開始累積一點東西，自然就會解掉焦慮的狀況。 我從以前就有這個習慣：遇到 iOS 開發的坑時，很希望別人不要碰到一樣的問題。以前世界各地的 iOS 開發者喜歡在 Twitter 上分享（當時 Twitter 這間公司與 iOS 開發者社群的關係特別良好），所以我也在 Twitter 發表很多推文。這意外地讓我長時間下來累積了很多有益的東西。 後來，當我開始寫 Apple 開發者週報的時候，又多了一些蒐集、消化，再撰寫出來的過程。每週都寫，就每週都有一些產出跟進度。 我沒有資訊焦慮，因為或多或少，總是有消化了一些東西。 消化之後，變成什麼養分先不說。至少心裡會有踏實感，覺得自己有做了一點什麼。 ## 開一個新帳號吧 我推薦你做的事情很簡單。 **現在就開設一個專門用於開發方面 SNS 帳號，把讀到的資訊轉貼，同時加上自己的一兩句話。** 現在的 Twitter 充斥太多垃圾資訊，如果你不愛用 Twitter，推薦新開一個 Mastodon 帳號。特別推薦這個 iOS 開發者專屬的 Mastodon 伺服器：[iosdev.space](https://iosdev.space/?ref=ethanhuang13.plus)。 不想跟個人身分混淆的話，**可以用全新的名稱，就把它當成你在 iOS 開發方面的專門帳號。** Mastodon 的 iOS apps 很多。不知道用哪個的話 ，可以用[官方的](https://apps.apple.com/tw/app/mastodon/id1571998974?ref=ethanhuang13.plus)、[Ice Cubes](https://apps.apple.com/tw/app/ice-cubes-for-mastodon/id6444915884?ref=ethanhuang13.plus)（[開源](https://github.com/Dimillian/IceCubesApp?ref=ethanhuang13.plus)），或是 [Ivory](https://apps.apple.com/tw/app/ivory-for-mastodon-by-tapbots/id6444602274?ref=ethanhuang13.plus)（付費產品）。 ## 快速讀過，貼出連結跟心得 以後，當你看到一篇談開發經驗或技巧的文章、一場研討會演講錄影、一部 YouTube 影片、一個課程片段，有興趣就**當下把它看過去。不要存起來以後才看。存著往往就不會看了，而那正是你的資訊焦慮來源**（我個人不相信所有 Read it later 工具的效果。對我來說：Read it now or never）。 其實快速掃過去一篇文章的重點，也花不了你 3 分鐘。在第一次看到有興趣的當下就點下去看，是最有效果的。 _This post is for paying subscribers only._ ### 📦讓錯誤不可能發生：Swift Tagged 簡介 URL: https://ethanhuang13.plus/swift-tagged/ Last updated: 2026-08-13T06:05:39.000Z 我想來介紹一些我很愛用的套件。 [Swift Tagged](https://github.com/pointfreeco/swift-tagged?ref=ethanhuang13.plus) 是我幾乎寫每個 iOS App 都會預設使用的 Swift Package。這篇文章會介紹它解決的問題，以及解法背後的思路哲學。 ### 問題 一個 App 裡通常會有多種資料型別，而且許多都會有 ID(identifier)。尤其是 SwiftUI app 在顯示列表時，不管是 `List` 還是 `ForEach` 都可以傳入 [Identifiable](https://developer.apple.com/documentation/swift/identifiable?ref=ethanhuang13.plus) 的陣列。 在這種條件下，其實傳錯 id 是有可能發生的。比如說 User 的 ID 是 `String`、`Item` 的 ID 也是 `String`，那麼把 user.id 的值丟給 items 去查找，完全有可能發生。 _This post is for paying subscribers only._ ### 🚲Ａ來的電動腳踏車 URL: https://ethanhuang13.plus/stolen-ebike-of-the-mind/ Last updated: 2026-08-13T06:05:38.000Z 最近跟家人聊到 AI 的發展，產生一段有趣的對話，於是寫了這篇短文。 上半部有發在我的 [Threads](https://www.threads.net/@ethanhuang13/post/DIijBFsp5p6?ref=ethanhuang13.plus) 跟 [Twitter](https://x.com/ethanhuang13/status/1912775384204202308?ref=ethanhuang13.plus) 上。本來稱之為「幹來的電動腳踏車」，但我後來改成「Ａ來的電動腳踏車」，取 AI 的諧音。 下半部則是會員限定。 --- 靠 AI 開始寫程式、文案、圖片，其實是很棒的起點。 但這些速成作品看多了，會發現：**決定成品水準的，還是創作者的鑑賞力**。 自己看不出問題，就無從改進。 ## 快速衝上小山丘，接下來就要下坡了 前幾天我跟我妹聊到這件事。她是完全不懂程式的藝術人。 我說：「很多人用 AI 寫程式，好像很快就能衝上一座小山丘。 但到了山頂之後，反而不知道下一步要往哪走。 其實接下來要下坡，才能去爬更高的山。」 她秒回：「**衝那麼快，感覺是騎電動腳踏車欸——而且還是幹來的！**」 害我在咖啡廳笑到停不下來，差點聊不下去。 這比喻太妙了。Steve Jobs 說過：「[個人電腦是心智的腳踏車。](https://www.youtube.com/watch?v=NjIhmzU0Y8Y&ref=ethanhuang13.plus)」 那麼 AI 工具就是「Ａ來的電動腳踏車。」 AI 也是能幫助人創造很多東西的工具。關鍵是你怎麼用、會不會用。 最近我思考的問題，已經不是怎麼樣用 AI 提升生產力。 而是：怎樣持續強化自己的鑑賞力。 不管是軟體、寫作，還是美感。 _This post is for paying subscribers only._ ### 🪧近況更新：寫書進度、新官網測試與聊聊新坑 URL: https://ethanhuang13.plus/ios-developerplus-update-writing-site-ideas/ Last updated: 2026-08-13T06:05:37.000Z 感謝 iOS Developer+ 會員們一直以來的支持。 上週我參加了為期三天的 [try! Swift Tokyo](https://tryswift.jp/?ref=ethanhuang13.plus) 研討會。內容精彩，見到很多新舊朋友（光是台灣人就大概有 20 位！），社交能量耗盡啦～需要休息。 接下來幾天恐怕不會更新會員專屬文章，不過想趁這個空檔分享幾件重要的近況： ## 「學習 SwiftUI」一書的寫作進度 原本寫這本書，就是為了加深自己的 SwiftUI 知識，並把學習的方法分享出來。 果不其然，越寫就覺得越難寫。每個禮拜，我都會學到幾個之前不知道或沒用過的 SwiftUI API 與 modifier。有些很冷門，用不到也沒關係。但有些會影響到書中的邏輯與結論。畢竟，如果我都沒有搞懂全貌，要怎麼教人呢？ 所以，**我決定先把這本書的「開發」重心移到建立 SwiftUI 文件索引系統上**，也就是我在書中期許的那樣，有完整 SwiftUI 官方文件的索引、最好都能搭配 Preview 範例。這樣對於我寫書，以及讀者學習都會有實質的幫助。 寫作時程也會跟著調整。原本是打算 4 月底寫完，好趕在 6 月 WWDC 之前上架。現在我覺得要多花點時間，把特定主題弄懂，好寫得更完整。 反正 WWDC 的時候 Apple 一定會發表新東西。與其寫完馬上就要改版，不如就吸收新的東西再一次出版。 我還是會盡量每週連載。只是不一定會照著章節順序發表。可能會去補寫前面的，或是先挑某些專題。反正最後形成一本書的時候，也會重新編排順序。 ## iOS Developer+ 新官網 最近我用 [Ghost](https://ghost.org/?ref=ethanhuang13.plus) 架設了一個**新網站，目前還在測試階段**。網址就是之前的 [https://iosdeveloper.plus](https://ethanhuang13.plus/)（2025/07/28 更新：已改為 [https://ethanhuang13.plus](https://ethanhuang13.plus/)）。 原本這個網址是導到 Patreon，現在則是有真正內容的新官網。 這個官網對會員最大的好處，就是**可以有更好的閱讀與收信體驗**。 你可以**開啟設定來收到更精美排版的電子報**。 為了尊重你的電子郵件偏好，在這篇公告發送之前加入的會員，我沒有幫你打開，需要請你自行前往設定。步驟很簡單，只需要 1 分鐘： _This post is for paying subscribers only._ ### ⌨️學習 SwiftUI 第 4 章：描述式語法──採用實際物體做練習 URL: https://ethanhuang13.plus/learning-swiftui-ch04-declarative-syntax/ Last updated: 2026-08-13T06:05:36.000Z 從這章開始，我們會循序漸進地學習 SwiftUI。為了達到比較平緩的學習曲線，我建議**先熟悉如何用 SwiftUI 的語法來描述靜態版面**，再去學習怎麼讓畫面動起來。所以這章的內容就是來談談 SwiftUI 的語法是怎麼進行描述的。 「描述」是什麼意思？我不解釋，直接**示範**。下面是一小段 SwiftUI 的程式碼，你猜猜看是什麼東西： ```Swift HStack { leftJoyCon console rightJoyCon } ``` 是的，這是一台 [Nintendo Switch](https://en.wikipedia.org/wiki/Nintendo%5FSwitch?ref=ethanhuang13.plus)™！而且是單人遊玩的掌機模式。 _This post is for paying subscribers only._ ### 🤔多一點介面設計，少一點設計模式 URL: https://ethanhuang13.plus/api-design-over-patterns/ Last updated: 2026-08-13T06:05:35.000Z 今天起床時突然有個念頭，就寫了這篇文章。 可能會冒犯到一些人，先說個抱歉。 標題的**介面設計**指的是 API 設計。而**設計模式**，就是你知道的那個。 這兩者並沒有直接關係，只是我剛好想拿出來一起聊。 ## 設計模式的話題 在軟體開發工作中，有時候我們會遇到一些人強調所謂的**設計模式**或是**軟體開發原則**。在開發的起手式就會開始思考要採用什麼設計模式，或是在檢討程式碼的時候會用一些名詞：SOLID、DRY、KISS 之類的。或者是很喜歡討論軟體的架構。 其實我對於這類話題一直都滿頭痛的，也聊不起來。 所謂的「模式」，其實都是先形成以後才被**辨識**出來的。我指的是這個詞本來的意思，不僅只於程式語言的領域。 換言之，設計模式並不是從頭開始，而是**經驗累積的結果**。設計模式對於討論不同專案的異同是個很好的切入點，但是對於輔助開發當前的專案來說，實用度就沒那麼高了。 而架構也一樣，應該是依照專案的需求而**演進**的。需求不明確的情況下，強行套用某一個架構，往往容易累積技術債。 _This post is for paying subscribers only._ ### 📔只做筆記沒有意義 URL: https://ethanhuang13.plus/notes-are-useless-without-action/ Last updated: 2026-07-16T05:09:49.000Z 從小我就是個「好學生」，上課會乖乖寫筆記那種。課本、講義、論文，都會有滿滿的線條與重點。 高中時代偶然拿到一台 [Palm PDA](https://en.wikipedia.org/wiki/Palm%5F%28PDA%29?ref=ethanhuang13.plus)，我就開始在上面寫數位日記，累積幾百篇。 到了大學，Evernote 這種「第二大腦」的軟體推出，「紀錄想法可以創造出未來價值」的概念開始流行起來。 我很興奮地把各式各樣的知識都放進去，包括手寫筆記也都拍照建檔，妥善整理，覺得一定能夠成為我未來的助力。 除了 Evernote，我用過的筆記軟體不計其數。[Drafts](https://getdrafts.com/?ref=ethanhuang13.plus)、[Vesper](https://github.com/brentsimmons/Vesper?ref=ethanhuang13.plus)、[Simplenote](https://simplenote.com/?ref=ethanhuang13.plus)、[iA Writer](https://ia.net/writer?ref=ethanhuang13.plus)、[OneNote](https://www.onenote.com/?ref=ethanhuang13.plus)、[Google Keep](https://keep.google.com/?ref=ethanhuang13.plus)、[Bear](https://www.google.com/search?q=Bear%20note&ref=ethanhuang13.plus)、[Notability](https://notability.com/?ref=ethanhuang13.plus)、[NotePlan](https://noteplan.co/?ref=ethanhuang13.plus)、[Agenda](https://agenda.com/?ref=ethanhuang13.plus)、[Notion](https://www.notion.com/?ref=ethanhuang13.plus)、[Craft](https://www.craft.do/?ref=ethanhuang13.plus)、[Ulysses](https://ulysses.app/?ref=ethanhuang13.plus)、[Obsidian](https://obsidian.md/?ref=ethanhuang13.plus)，當然也少不了 Apple Notes。 甚至曾經寫了 [NoteBox](https://apps.apple.com/us/app/notebox-simple-powerful/id899446595?ref=ethanhuang13.plus) 這個快速筆記 app，作為獨立開發創業題目。 ## 囤積的意義何在？ 但是當我紀錄的筆記越多，就越發現沒有意義。只有盲目的囤積筆記，而沒有拿出來消化或轉變成其他有意義的東西。 坊間有許多整理筆記的方式。但是不論如何，對我來說，要維護這些筆記之間的關係都非常不直覺。 實際上，99.9% 的時候我還是打開 Google 搜尋，尋找下一個想知道的事情。極少會去筆記庫搜尋這些寫過的東西。 反而是一種情況：你聽說過有些人在 StackOverflow 找答案時，找到多年前自己寫的正確答案嗎？我就經歷過這種事。也常常在自己以前的公開推文挖到寶。 於是，工作幾年下來，我開始不寫正經的筆記了，不再維護「第二大腦」，從筆記囤積症痊癒。 因為我理解到，**那些真正值得記下來的事情，應該要輸出**，而不是輸入而已。 具體作法，如果是公司內部的事情，就在公司內部系統寫文件。 如果是可以公開的資訊，我就直接在 Twitter 發文、寫 blog、電子報、[Notion 的知識庫](https://ethanhuang13.notion.site/?ref=ethanhuang13.plus)，公開分享。當然，現在在 iOS Developer+ 寫文章更是如此。 真正重要的事情會一再出現，不一定要親自收藏。真正值得分享的東西，就直接分享。不用藏起來。 對我來說，做筆記這種**輸入**的動作並不重要。**輸出**成能夠分享與討論的知識才重要。 ## 行動才是筆記的目的 我現在對於筆記的實務是：形式不重要、過程不重要、整理不重要，最終有一個**行動**才有意義。 形式、過程、整理為什麼不重要？有 LLM 可以整理文字、語音，就不需要在意筆記的形式了。最後可以叫 AI 輸出與總結。 我所謂**行動**是什麼？ 一種是會去做某些事情。比如說整理旅行要的資料在一篇筆記上，到時候會當作**參考**。 另一種行動則是**產出**一個可以被他人閱讀的內容，也就是透過寫作讓他人知道一些知識、觀點、經驗。 寫文件是為了指引同事協作。 寫 blog、電子報是為了分享經驗，好讓他人可以少踩一些坑。而且可以從他人的回饋來修正自己的認知。 我們不是把筆記工具歸類於**生產力**軟體嗎？有某些特定結果才是我要的。 而不是堆積一些東西在筆記軟體的角落，然後永遠也不會翻看──那跟買回來不看的書、買回來不玩的遊戲、買了但沒有上的課程，是一樣的。 ## AI 時代的行動化筆記 我認為，許多人還是會囤積筆記。而且也不是每個人都習慣寫作與對外發表。 但是沒有關係。個人的筆記庫透過 AI 的協助將可以變成更有行動力。 比如我分享過，現在寫 [Apple 開發者週報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)的方式，就是平時看到覺得可以寫進當週的主題，就把連結跟標題輸入進 ChatGPT 的一個對話，等到週末寫稿時請它輸出成暫定的標題大綱，我再針對每一則消息寫內容。 ChatGPT 這種工具甚至不是筆記軟體。但它的產出效果，比起傳統筆記軟體好太多了。 我雖然沒有特別去找（也許 Notion AI 就符合），但想必下一代的筆記軟體都可以做到： - 從過去蒐集的點子，整理出現在最適合做的 side project - 從既有筆記庫歸納自己的知識水準以後，搭配外部搜尋，找到下一個最值得拓展知識的學習項目 - 從筆記庫歸納自己的盲點、興趣方向 - 叫 AI 從筆記出題目考自己 反正只要能夠輸入 LLM，這些事情都不難達到。 關鍵還是在，**你想拿這些筆記做什麼？** ## 結論 其實我寫這篇文章，無非想跟讀者分享：雖然我日常的文字產量很大，但其實我並沒有在寫什麼筆記。 如果你曾經好奇為什麼 13 可以寫那麼多東西，到底有什麼秘密？絕不是叫 AI 幫我寫。真正的答案是──**我沒有把時間用在寫筆記，而是直接寫下想分享的文字**。 ### 💖學習 SwiftUI 第 3 章：影響學習 SwiftUI 的個人因素 URL: https://ethanhuang13.plus/learning-swiftui-ch03-personal-barriers/ Last updated: 2026-08-13T06:05:34.000Z ## **缺乏可供學習的專案** SwiftUI 已經推出將近 6 年，為何許多 iOS 開發者還不熟悉 SwiftUI 呢？ 一個最基本的原因就是「用不到」。 工作會接觸到的專案往往需要支援較早的 iOS 版本，所以無法使用 SwiftUI。照理來說，這個現象應該會逐年下降，因為工作的專案會淘汰支援舊版本，那就可以開始使用 SwiftUI 了。 但是實際上，導入一項新技術需要大量的研究與試錯，如果開發團隊過去並沒有在 SwiftUI 上進行研究與投資，一旦可以使用時，也不知道從何開始。 所以，並不是沒有外在條件限制以後，就自然而然可以接觸新的技術。想要學習 SwiftUI 的話，早就可以在個人專案上進行了。 我在軟體開發工作上一直都是在公司的專案與個人專案交互參照與學習。雖然我會嚴格地區分公司與個人的設備、程式碼、工作時間，但是經驗與知識是存放在同一個大腦的。 我常常在 side project 進行研究、嘗試新功能或開發方式，等到有把握之後再帶到公司的專案。在公司專案採用的較大規模或深入的架構設計，則可以帶到 side project，免去一些彎路。這種相輔相成的知識與經驗累積，可以讓我在公司專案做技術決策時更有把握，甚至可以教同事們。 總而言之，我想說的是，如果因為在等待公司的專案採用某項新技術才去學，那可能永遠也學不到。開發者最好要有自己的 side project、有自己想做的題目與應用。不論這些題目是否賺錢或是能夠上架 App Store。只要有動力去維護它們，就有機會在開發過程中學習新的技術。 ## **自行建立學習動機** _This post is for paying subscribers only._ ### 😵‍💫學習 SwiftUI 第 2 章：SwiftUI 哪裡難學？ URL: https://ethanhuang13.plus/learning-swiftui-ch02-why-hard/ Last updated: 2026-08-13T06:05:33.000Z 久等了。 寫書真的不容易。 我原本的策略是，宣布自己要每週連載，來逼自己要有定期的產出。但是上週還是遇到了寫作瓶頸，想要把東西一次寫清楚、寫完整，反而就寫不出來了。 所以我這兩週做了一些調整。回頭寫一些 SwiftUI 專案，用實際的開發經驗來刺激寫作靈感。 另一方面，我也不追求照順序、一次到位。也許後續的發表順序會先從我更有把握的先開始寫。 最後就是，我本來是用 Cursor 這種寫 AI IDE 來輔助寫作，但是後來還是覺得「傳統」的編輯軟體更適合寫書。所以我又回頭去使用 Ulysses。至少它會顯示我已經寫了幾頁、字數多少。 以下是第二章預計的內容。 --- 從 UIKit 轉換到 SwiftUI，我一開始是很興奮的。但是沒有多久，就開始發現事情沒有這麼簡單。有些觀念得重新學習，不只是語法的變化而已。我也觀察到許多開發者有遇到和我一樣的學習障礙。 現在，我們來談一談這些 SwiftUI 的學習障礙。看看你是否也有類似的經驗？ 我想先談 SwiftUI 本身、文件、以及開發工具本身的問題。 至於我們學習者本身的狀況或者知識背景，留待下一章討論。 ## **Progressive Disclosure 的 API 設計** 我認為 SwiftUI 的語法很好閱讀。但是，**好讀跟好寫是兩回事**。 在建構 SwiftUI 內建元件時，我們有非常多的選項與參數。 Apple 官方聲稱這種 API 設計叫做 Progressive Disclosure（參見 [WWDC22 影片](https://developer.apple.com/videos/play/wwdc2022/10059/?ref=ethanhuang13.plus)），認為對於初學者可以使用比較簡單的語法快速上手，然後有需要時再改成更複雜的版本。 舉例來說，要寫一個 `Button`，最簡單的方式是： _This post is for paying subscribers only._ ### 🤯學習 SwiftUI 第 1 章：為什麼想學 SwiftUI？ URL: https://ethanhuang13.plus/learning-swiftui-ch1-why-want-to-learn/ Last updated: 2026-08-13T06:05:32.000Z 為什麼要學習 SwiftUI，可以分成客觀與主觀兩方面。 ### SwiftUI 已經是 Apple 平台應用的主要開發方式 客觀來說，**SwiftUI 是 Apple 主推的開發方式，投注了大量的資源**。 從發表至今，我們可以看到，Apple 對於 SwiftUI 十分重視，投注了比其他框架更多的資源。 從一開始，Apple 就精心設計 SwiftUI 的專屬語法。 為了實現全新的語法，他們在 Swift 語言加了很多功能。例如許多 Swift 使用者熟悉的 property wrapper，就是在 SwiftUI 宣布之前不久加入的。 甚至跳過正常的 Swift Evolution 流程，直接加入 function builder 功能，讓 SwiftUI 可以使用 `@ViewBuilder` 打造專屬語法（當時是 `_@functionBuilder`，後來正式名稱為 `@resultBuilder`）。 而為了讓開發者能夠有管理狀態的工具，初代 SwiftUI 就搭配著推出了 Combine。還有後來追加的 Swift Observation 等等。 Apple 還在 Xcode 新增了 Preview 的功能，可以即時地看到效果。[Apple 自己內部也大量使用 SwiftUI 來進行設計方面的開發](https://developer.apple.com/videos/play/wwdc2023/10115/?ref=ethanhuang13.plus)，因為能更直接地看到回饋與效果，而且會與 app 真實運作時的樣貌相同。 後續的每一年，SwiftUI 都新增了不少 API，來強化功能。每一年的 Xcode 也都為了 Preview 增加了一些功能、效率，或是至少更穩定一點。可以看到 Apple 持續投注資源在 SwiftUI 上，而且遠比 UIKit、AppKit 等既有框架更多。 Apple 也讓 SwiftUI 在他們的所有平台都可以使用。因為是跨平台，所以這套語法，開發者只要學習一次，就可以在 Apple 各平台使用（learn once, write anywhere）。 在 watchOS 上，SwiftUI 取代了過往難用的 WatchKit。後來推出的 visionOS，雖然還可以使用 UIKit，但是比較新穎或專屬的元件，就只有提供 SwiftUI 版本。 而有一些框架，像是 WidgetKit，甚至只能使用 SwiftUI 開發。 ### 理想與現實的落差 毫無疑問地，Apple 對 SwiftUI 有著很棒的願景。開發者也感受到 Apple 對 SwiftUI 的熱情。 但是，期待越高，現實與期望的落差越大。 _This post is for paying subscribers only._ ### 🗣️AI 工具小技巧：處理有瑕疵的字幕檔 URL: https://ethanhuang13.plus/ai-tips-fix-subtitles/ Last updated: 2026-08-13T06:05:31.000Z 原定本週二要發表的「學習 SwiftUI」章節，還在撰寫中。 作為墊墊胃的文章，我想把平時使用 AI 工具的用法跟大家分享。 _This post is for paying subscribers only._ ### 💪如何不因 AI 而焦慮，以及我使用各種 AI 工具的方式 URL: https://ethanhuang13.plus/how-i-use-ai-without-anxiety/ Last updated: 2026-08-13T06:05:30.000Z 不知道你有沒有在關心近期 AI 的演進。 光說最近一個多月推出的模型就有：DeepSeek R1、OpenAI o3-mini、Gemini Flash 2.0、Claude 3.7 Sonnet、Grok 3、GPT 4.5。 新模型、工具或功能，**以週為單位在推陳出新**，快到我甚至懶得照時間順序排列跟附上連結了。 AI 會讓你焦慮嗎？還是感到興奮？ 前陣子看到一個說法：「販售 AI 焦慮，開課的最賺錢。」 但我最討厭販售焦慮。多年來，我寫東西都是想要讓讀者減少焦慮。 所以今天來聊一下，怎樣才不會焦慮。並且交流一下我目前怎樣使用 AI 工具。 ### 焦慮來自於未知與缺乏掌控感 AI 的發展太快了。每隔幾天都會有新的東西，讓人追不上的感覺。 不過許多新技術都會衝擊人們的生活與工作方式。 差別只是在什麼時候、哪些方面、以什麼形式。我們因為較熟悉技術，在海景第一排近距離觀看，所以感受特別刺激。 我個人並不覺得「AI 會大量取代人工」這種事情的發生本身，會是焦慮主要的來源。因為社會的轉變往往比**想像**中還要慢。反而那個想像才是焦慮的來源。 還有一個，新東西一直出現，資訊過載，才是焦慮的來源。 **面對未知的事物，親自試試看，獲得最直接的回饋，是最好消除疑慮的方式。** 現在就打開 [chat.com](https://chat.com/?ref=ethanhuang13.plus)、[claude.ai](http://claude.ai/?ref=ethanhuang13.plus)、[grok.com](https://grok.com/?ref=ethanhuang13.plus)、[gemini.google.com](https://gemini.google.com/?ref=ethanhuang13.plus)，丟一兩個你目前正關心的問題，看看他們有什麼反應。反正都可以免費試用。 可以聊你擅長的程式問題，試試看他們的寫程式能力。 也可以問很生活化的題目。 我拿來問 AI 的問題越來越多元，給你參考： _This post is for paying subscribers only._ ### ✍️我為什麼要寫一本學習 SwiftUI 的書呢？ URL: https://ethanhuang13.plus/why-write-learning-swiftui-book/ Last updated: 2025-05-03T14:39:41.000Z 從今天開始，我會在 iOS Developer+ 連載「學習 SwiftUI」這本書。希望能夠在 4 月底寫完、5 月整理出英文版，並且出版、上架販售電子書。 作為第一線支持我的朋友，等書籍上架後，iOS Developer+ 的付費會員可以直接下載整本電子書，不需額外付費。 之所以要用連載的方式，是因為我要給自己沒有在上班期間的生活，一個目標與固定的節奏。不然我應該會過得很廢。 不過，老實說，對於寫出一本技術的書，**我到現在還是非常沒有把握**。 我出過很多文章、電子報、podcast、YouTube 教學影片，也在研討會演講過，就是沒有寫過書。 這對我來說是「挖坑給自己跳」的全新挑戰。 理性上來說，寫書，應該比我現在的能力稍微難一些，稍微努力一點應該是做得到的。（這是維持學習動力的一個重要策略，就是給自己一個難度比自己實力高一點的課題。因為太簡單會顯得無聊，太難的話一下就會放棄。） 感性上來說，我是一直在「好想把這個觀念講清楚」跟「我幹嘛要跟全世界說我在寫書」之間打架。 我已經想好了整本書的大綱，但是要一章一章寫出來，只能每週往前推進一些。 總之，以上是我真實的情況。希望接下來一段時間，可以持續地在 iOS Developer+ 分享我的心路歷程（當然還有實際的書本內容）。 還請多多支持。 至於為什麼要寫這本書，就從下文的「序章」開始說： ### 我為什麼要寫一本學習 SwiftUI 的書呢？ SwiftUI 從 2019 年推出到現在，已經有將近 6 年的時間，我也用了它 6 年，累積了不少實務經驗。也因為在公司的專案使用，所以與同事們有許多交流。我常常在跟其他 iOS 工程師交流的時候，觀察到他們的一些在學習上的障礙。 身為對學習與認知心理學有著濃厚興趣，而去讀了教育心理系的人來說，我對於怎麼把一個東西學起來一直感到好奇。所以當我發現許多人在學習 SwiftUI 遇到困難，就覺得特別有趣。 換句話說，我覺得 SwiftUI 很好玩，但是對我來說，掌握這項技術的學習過程，比它的內容知識本身還更有意思。 我認為，SwiftUI 其實並不難學，只是學習的時候要有一些策略。 尤其對於有著深厚的 UIKit 知識的資深 iOS 工程師來說，那些 UIKit 的知識對於學習 SwiftUI 往往是一種阻礙。因為**絕大部分 UIKit 的核心觀念，對於掌握 SwiftUI 沒有任何幫助。** 例如物件導向、記憶體管理、UIViewController life cycle 等等觀念。硬要套在 SwiftUI 上，只會感到十分挫折。而且無法掌握更關鍵的思考問題──如何設計與管理狀態。 反倒是一些接觸過其他的類似的前端框架的開發者，例如 Flutter 或者是 React Native，他們在學習 SwiftUI 的時候，往往能夠更快上手。 所以**這本書就是寫來給資深 iOS 工程師**，一起來試試看，在學習 SwiftUI 之前，先把腦中的一些東西先暫時放下，我相信這樣子學起來會容易很多。 另一方面，SwiftUI 的一些特性，讓它需要比較好的文件或者是學習資源，才能讓人確定一些 API 的行為。舉例來說，SwiftUI 有大量的 modifier。而這些 modifier 的作用範圍，以及他們的順序造成的差異呢？通常只有把它寫出來實際看結果，才可以確定。 但是，Apple 雖然有提供大量的文件跟教材，卻缺乏互動性，而且沒有好的編排結構。以致對於學習者需要掌握哪些知識，不太容易形成清楚的心智模型。 市面上有不少以 SwiftUI 教學為核心功能的 App，可以讓人直接嘗試效果。網路上也有大量附帶程式碼範例的文章。而我在本書的範例程式碼，則是想提供另一種取向，也就是直接使用 Preview 來學習。畢竟能夠即時看到一段程式碼的效果，也就是立即獲得回饋，是最快的學習方式。 說到 Preview，SwiftUI 的 Preview 雖然提供了即時回饋的理想。在現實上，它從一開始就有不少問題。不是更新非常慢，就是乾脆無法現。雖然每一年都有更新，但是要把 Preview 運用到足以發揮它的效果，非常考驗開發者的功力。所以，**本書也會提供一些讓 Preview 變得更實用的技巧**。 而最重要的是，我會把 SwiftUI 的知識與開發技能加以分類，讓讀者可以循序漸進地掌握不同的知識分支，而不是東拼西湊。 有了這樣的學習框架，未來有更多的 SwiftUI 知識需要學習時，就可以輕鬆地放在不同的位置，更容易掌握。例如有些 modifier 最好是先熟悉狀態管理，再來學習會比較好。 ### 你應該學習 SwiftUI 嗎？ iOS 開發社群對於學習 SwiftUI 的興趣是非常濃厚的。它的語法寫起來相當的簡潔，要快速做出一些東西會很舒服。在合適的條件下，它可以做出很不錯的產品。 不過在實際的工作機會上，很多專案還不見得能使用 SwiftUI，例如說專案需要支援的 iOS 版本還比較舊，所以轉換到 SwiftUI 有先天的限制。或者是特定版本的 SwiftUI 的 bug 不好處理等等。 不過隨著 SwiftUI 推出一年一年的過去，這些現象當作不學習 SwiftUI 的理由會越來越沒有說服力。 總之我覺得，SwiftUI 已經推出了這麼多年，不再是不成熟的技術。如果有好的學習策略，它其實很好玩，也很值得學。 該是時候把它學起來了。 ### 這本書適合誰？ 這本書**不是**為 iOS 開發初學者撰寫的。如果你是剛開始學習 iOS 開發的新手，或許能夠從本書獲得一些好的學習觀念，但是對於瞭解 SwiftUI 的核心知識，其他教材或書籍的輔助仍是不可或缺。 本書的目標讀者是： - 有一定 Swift 程式語言經驗的開發者 - 特別是有 UIKit 開發背景的資深 iOS 工程師 - 已經嘗試過 SwiftUI，但感到困惑或挫折的開發者 - 想要建立清晰 SwiftUI 心智模型的開發者 如果你已經熟悉其他描述式 UI 框架（如 React、Flutter 等），SwiftUI 的描述性框架特性應該會很容易上手，但仍然能從本書中得到學習策略的幫助。 ### 我的 SwiftUI 背景 我可以說是很幸運地，曾經在一間公司要開發新產品、並且建立新團隊的時候加入。 當時團隊決定使用 SwiftUI 與 [Point-Free](https://www.pointfree.co/?ref=ethanhuang13.plus) 的 [TCA(The Composable Architecture)](https://github.com/pointfreeco/swift-composable-architecture?ref=ethanhuang13.plus)，並且陸續招募了一些優秀的 iOS 工程師。所以我們有機會一起使用 SwiftUI 與 TCA，並且在過程中克服各種挑戰。 （TCA 搭配 SwiftUI 是非常優秀的狀態管理框架。但它不會是本書的重點。） 也因為這間公司因為商業模式的特性，使用者有很高的軟體升級意願，我們只需要支援當前與上一代的 iOS 版本。這就讓我們有機會可以逐年淘汰舊的 SwiftUI 版本，不管是舊的語法、機制，或是 bug。 我們有 3 個專案使用 SwiftUI 及 TCA 開發，畫面很多，功能越來越複雜。配合 TCA 撰寫了大量的測試，在開發中可以見招拆招。 綜合了團隊 3 年半的開發經驗來說，未來的專案還是會優先使用 SwiftUI（以及 TCA）。 至於我自己，平時就有大量的 side projects。大大小小的 SwiftUI app 也超過 10 個。我也從來沒有想過要放棄 SwiftUI。 總之，在合適的情況下，SwiftUI 是很不錯的選擇。 另一方面，這些經驗也讓我感到，一個人要自學 SwiftUI 滿困難的。有團隊一起研究的話，會簡單很多。這也是我想寫這本書的原因。 ### 我對於 SwiftUI 的態度 我的新的 iOS 或是蘋果平台的專案都是優先使用 SwiftUI 開發，可以說完全不會想要回去寫 UIKit 了。 但我並不會說 SwiftUI 是最好的選擇，或是完美無缺。（我對於學習 SwiftUI 的動詞向來是「入坑」。） 也不會說只要用 SwiftUI 就可以解決所有問題。有些應用程式或是特定畫面，就是不太適合用狀態管理的方式來開發。 SwiftUI 在特定情況的效能問題，也有待 Apple 持續解決。 不過這個框架的核心精神是好的。 所以，我會希望讀者掌握 SwiftUI 的知識以後，可以在適合的場合使用 SwiftUI，在不適合的場合，就使用其他技術。這才是對待技術比較實際的態度。 讓我們一起享受 SwiftUI 的學習過程吧！ ### 🥚我花了一年準備裸辭、後續內容計畫 URL: https://ethanhuang13.plus/one-year-prep-for-quitting/ Last updated: 2026-08-13T06:05:29.000Z 今天來跟會員們更新一下我的近況，以及後續計畫。 重大消息：昨天是我最後一天上班，今天一早我就開始全新的個人計畫，做自己想做的事情。 ### 為什麼想離職？ _This post is for paying subscribers only._ ### 🗾你應該要安排休假 URL: https://ethanhuang13.plus/why-taking-vacation-shows-strength/ Last updated: 2026-06-18T11:17:37.000Z 曾經有應徵者在面試時問我：「在你們團隊中，怎樣的人 Performance 會高？」 我想了想以後回答他：「應該是能夠把假休好的人吧。」 會這樣說，是因為我當時任職的公司是無限假制度，特休是沒有上限的。 也就是說，能在更短時間內把事情做完並請假休息、相較於靠加班才能完成工作的人，應該是更厲害的吧。 ### 無限假，怎麼放？ 無限假聽起來很爽，想放就放。實際施行起來，卻會有讓人不敢放假的問題。 因為不知道請幾天假才合理。請太多怕會引起主管或同事的不滿。最終反而變成請得假太少，失去它的意義。 但是在繁忙的工作以外，能夠**好好休假是避免職業傷害甚至 burnout 的必要措施**。 為了照顧大家的心理健康（包括我自己），接任 team lead 以後，我就做了幾件事情，來確保大家有好好地休假。 一個是做到**帶頭請假**。 我三不五時就說我要休假、請假天數夠高，這樣團隊成員才敢請假。 接著，請大家統計每一季的休假天數，互相參考數字。 這樣大家才知道請多少天假是團隊的平均範圍。（等到養成默契後就不用再統計） 然後，我會在 1 on 1 meeting 時，提醒每一位同事要把休假安排好。 有時候如果沒有特別想聊的主題，甚至可以直接把休假規劃當成談話主軸。 最重要是訓練好成員之間互相交接工作的能力。 每個人**要會交、也會接**，形成互補。 比如說，平時就會分享自己在做的事情（團隊成員負責的專案各不相同），也會有各種文件輔助。 這樣子當別人休假時，可以暫代對方的工作。每個人才敢安心地去休假。 畢竟如果休假還帶著工作去，就不算是真的休假了。 一開始大家還會因為工作內容忙碌，以及沒有安排休假的習慣，會不太敢請假。 但是隨著彼此休假的次數越來越頻繁，就開始會規劃比較久之後，甚至是一整年的休假計畫。 團隊的運作效率沒有負面影響，每個人反而會更健康。 ### 不敢請假嗎？ 雖然你的工作環境不一定有無限假制度，不過「不敢請假」應該是職場常見的情況。 如果主管沒有帶頭讓大家安心休假，那我反而覺得你更應該有意識地去安排假期。因為特休是身為員工的權益啊。 真的不敢請長假，就先從一兩天來請也好。試試看自己的狀態變化。 至於自己創業當老闆的人，就更應該懂得休息了。 ### 休假的好處 vs 安排休假的好處 你說，休假有什麼好處，我還不知道嗎？還需要特別寫一篇文章？ 當然，休假的時候放下壓力、轉換心情、去接觸平時生活不會接觸的地方、風景、食物、人們，或是遊戲。刺激大腦更開闊。這都很好理解。 但我這篇文章更想說的是**安排休假**的好處。 簡單來說，當我們安排了一個休假計畫，因為時間先卡位了，在那之前的的工作，就會有一種倒數計時的感覺。 再艱困的挑戰與壓力，都可以撐到休假就得到釋放。 知道何時可以喘氣，就可以憋更久的氣，這樣的概念吧。 所以抗壓性會提高。（倒也不是說工作都像在憋氣一般難受啦。） 再者，因為休假的時間明確，就產生了一種死線驅動的效應。 該做完的事情不會再拖、該交代的事情會整理好。 就我個人以及團隊的經驗來說，趕在放假之前把專案的開發重點搞定，都是常有的事。 這就是為什麼我會說，能把假休好的人，表現肯定不差。 **我自己的習慣是，這次休假完就會開始規劃下一次的休假或出國旅遊的時間。** 抓行程、訂飯店、訂機票，都是很好的刺激──「還有一些脫離日常生活軌道的新鮮事物在等著我」。 ### 工作狂休假的方式？ 確實有人是熱愛工作，感覺不到休假的必要。 但我會用心理健康風險的角度來說：burnout 人人都有可能會遇到。 因為 burnout 來自壓力的逐漸累積。假如平時沒有休假的習慣，在不知不覺當中，壓力水位升高到無法承受，已經太晚了。 最好還是有把心理壓力的水庫洩洪的習慣、降低風險。 有些人跟我說，真不知道要怎麼安排休假，就算排了時間也不知道要去哪裡、做些什麼。 可能太把生活重心放在工作。 休假時出國旅遊總是一個好選項，因為休假的一個重要目的就是去**過平常不會過的生活**。至少我是這麼認為的。 （所以，玩一些角色帶入感很深、或者世界感很強的電玩遊戲，也是一種短期替代方案。） 如果是平時很有規劃能力的人（軟體工程師多半都是吧），在休假時反而可以試試看，不要追求非得要去吃什麼、玩什麼、去哪個點，而是讓自己經歷一些「意外」。 我上個月進行了一趟整整四週的出國行程，待了四個國家，包括日本的四大城市。 沒有事先安排每天的行程，就是到了一個地方再研究要去哪。或是聽了計程車老司機的推薦，去吃當地美食。 意料之外的驚喜很多，比如偶然發現才剛開一個月的新地鐵站（Google Maps 上還沒有）、晚霞天色與水面倒影的絕美搭配、在咖啡廳二樓看著龐大車流在沒有號誌的圓環不斷擦身而過、[一打開旅館的門看到天井飄雪下來](https://www.threads.net/@ethanhuang13/post/DFuCldkxBzo?ref=ethanhuang13.plus)等等。 這樣很放鬆，也很好玩。 也有很多時間讓腦袋放空、做一些更深度的思考。 不想出國旅遊的話，學一個新技能或是找朋友見面也挺好的。 其實我認識很多軟體工程師都是休假高手，搞不好你比我更懂怎麼運用假期呢。 在此邀請你也分享自己的休假方式（Notion 可以留言）。 ### 休假時要想什麼 假如你跟我一樣，休假時腦袋還是無法停止思考，那麼有一個問題，我覺得非常值得在休假時思考：**「如果不再需要工作，那我會想做什麼？」** 其實就是提前思考「退休後要做什麼事情」。 那些你會一直想要做的事情。 那些讓你每天起床的內在動力。 也許不久的將來 AI 的發展會讓一些人不再需要工作（而不是被迫失去工作），誰知道呢？這個問題就會要提早面對。 假設前一個問題已經完全想清楚（實際上有可能要花很長的時間探索）。下一個問題則是：**「那我現在是否就能開始做這些事呢？」** 而我，之所以會開始 iOS Developer+ 會員，也是因為去年九月去了一趟清邁度假，終於有空玩了一下 Cursor AI，被刺激到，引發了我想教大家更多東西的念頭。 ### 結論 學生時代我們都經歷固定的寒暑假。不管學業再艱困，撐到學期末就解脫了。 那出了社會，有工作的情況下，為何我們不懂得創造自己的假呢？ 你下一次的休假計畫是什麼時候？這個休假計畫有讓你充滿期待嗎？ 如果答案都是「是」的話，那就是做對了。 **如果還沒安排的話，不妨現在就打開行事曆，規劃一個請假時段。** 而如果已經好好休假一次兩次，都沒能讓你找回工作動力、從各種職業傷害恢復的話，那就會是另一個話題──考慮**離職**。我們之後再細聊。 ### 補充 說來好笑，過年之前的一次會議上，我團隊的每個人都列了休假計畫。 結果是每個人都會去日本，只是時間不同。 台灣人真的太愛去日本了。 ### ❓陣亡率高達 8 成的面試題目─iOS 開發 AI 輔助工具 #8 URL: https://ethanhuang13.plus/tough-ios-interview-question/ Last updated: 2026-08-13T06:05:28.000Z 新春開工愉快。 許多人可能在過年前後轉換新工作，所以我來聊一個面試題目。 _This post is for paying subscribers only._ ### ✨iOS 開發 AI 輔助工具 #7：總結一下我做了什麼 URL: https://ethanhuang13.plus/ios-ai-tools-7-summarize/ Last updated: 2026-08-13T06:05:27.000Z 也許有些朋友還沒有認真開始用 AI 工具來輔助寫程式。 其實也不一定要用來寫程式才能用 AI 工具。 今天簡單介紹一個很實用的小功能： 不管是 VSCode + GitHub Copilot，或是 Cursor，這兩個 IDE 現在都有**產生 git commit 的功能**。 甚至連 icon 都一樣。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2025-01-14-at-22.10.07@2x.png) 切到 Source Control 頁面以後，按下圖上我框起來的按鈕。 就這麼簡單。 [GitHub Copilot 目前已經可以免費使用](https://github.blog/news-insights/product-news/github-copilot-in-vscode-free/?ref=ethanhuang13.plus)，有空時試試看吧～ ### 同場加映：使用 Cursor Agent 做總結 _This post is for paying subscribers only._ ### ☀️為自己寫 Side Project URL: https://ethanhuang13.plus/build-side-projects-for-yourself/ Last updated: 2026-08-13T06:05:26.000Z 新的一年，不知道你有什麼目標或是願望？我今年沒有設定什麼年度目標，而是把目標設定在過好每一天。 簡單來說，就是要過得更健康。 ### 目標 這幾年健康檢查的抽血報告，我的維生素 D 都偏低。平時 WFH 都在家、吃飯可以叫外送、冬天天氣冷。種種因素加起來就是不需要也不想出門。 長期下來就會缺乏運動、日照。心情容易越來越差。但是我只要一出門曬太陽心情就會變好。（嗯，如果你常常感到憂鬱，也許可以先確認自己接觸陽光的量夠不夠。） 於是，我設定的新目標，就是**每天都要出門曬太陽、散散步**。 ### 給自己一個動力 但是如果只是出門散步，其實沒有什麼動力。 剛好我在新年的第一天拿到新手機，想研究一下[攝影風格](https://support.apple.com/zh-tw/guide/iphone/iph939c00e95/ios?ref=ethanhuang13.plus)功能。 所以我給自己一個條件，就是要**出門拍一張我覺得滿意的照片**回來。 其實這很像一些遊戲的「每日任務」。 - 拍一張照片（1/1） - 曬太陽半小時（30/30） - 散步（1/1） ### 配套措施 既然有給自己的任務，我又很愛玩遊戲，於是我想說，那就來**寫一個屬於我自己的 app，把我的每日任務在 app 裡面顯示出來**。 _This post is for paying subscribers only._ ### 🕰️減少滑手機浪費時間的技巧，5 秒鐘就學會 URL: https://ethanhuang13.plus/reduce-phone-time-tips/ Last updated: 2026-08-13T06:05:25.000Z 新年開始，跟大家分享一個小技巧。 ### Doomscrolling 我們手機上都有一些會無意識去點開亂滑（[doomscrolling](https://en.wikipedia.org/wiki/Doomscrolling?ref=ethanhuang13.plus)）的 App 吧。 像我自己就是 Twitter、Threads，與 YouTube。有的時候，一不小心就會浪費掉幾十分鐘。 有的人會用 iOS 的螢幕時間（Screen Time），或者用一些第三方軟體來限制自己的使用，例如 [one sec](https://one-sec.app/?ref=ethanhuang13.plus)。 但我有一個更簡單的方式。 因為簡單，說不定最有效。 前提是：你是**有意識地想要不浪費時間、有更重要的事情要做**。 _This post is for paying subscribers only._ ### 🎆2024 年終回顧與感謝 URL: https://ethanhuang13.plus/2024-year-end-review-thanks/ Last updated: 2026-08-13T06:05:24.000Z 新舊年交際之時，我想由衷地感謝所有 iOS Developer+ 的會員，你們對我的意義重大。 讓我分享一下今年的心路歷程。 ## Burn Out 邊緣 今年初，我把「[13 的 Apple 開發者週報](https://www.ethanhuang13.com/?ref=ethanhuang13.plus)」停刊的時候，實際上我的狀況並不好。 我覺得工作內容很無聊，對於 iOS 社群也沒什麼參與的動力。 簡單來說，就是在 burn out 的邊緣。 過年的假期出國了一趟，回來以後我就一直在想要不要離職、gap 一段時間。 好友勸我：「現在工作環境比較困難，還是再觀察一下吧。」 於是我放慢速度再觀察了一下，並把「如果離職的話，財務與生活狀況會怎麼樣」都想了一遍，心裡稍微感到踏實。 剛好那個時間點，Apple Vision Pro 剛開賣、AI 工具的蓬勃發展，也許這些新東西可以點燃我的一些熱情與動力？ _This post is for paying subscribers only._ ### 🥇SwiftUI 讀完就入坑 #9 SwiftUI + TCA 專案的模組化最佳實踐 URL: https://ethanhuang13.plus/swiftui-tca-modularization-best-practices/ Last updated: 2026-08-13T06:05:23.000Z 5/8 更新：我把模組化專案的模版開源在此，歡迎使用 [https://github.com/ethanhuang13/SwiftUI-TCA-Template](https://github.com/ethanhuang13/SwiftUI-TCA-Template?ref=ethanhuang13.plus) ## 前言 切模組可以說是一門藝術，也是考驗程式碼架構與分類功力的絕佳方式。 今天要分享的模組化拆分法，是根據十來個專案，包括公司的 3 個中大型 SwiftUI + TCA 專案，累積三年半實務經驗，研究出的 **SwiftUI + TCA 模組化最佳實踐**的核心精神。 對於有在使用 TCA 或是想入坑 TCA 的朋友，應該會增加不少功力。 **這篇文章相當進階，最好是對 TCA 有一定使用經驗再來讀。** 我學習切模組的基礎是來自於 Point-Free 的 [Modularization: Part 1](https://www.pointfree.co/episodes/ep171-modularization-part-1?ref=ethanhuang13.plus)（這集免費）、[Modularization: Part 2](https://www.pointfree.co/episodes/ep172-modularization-part-2?ref=ethanhuang13.plus)，以及 Point-Free 的 TCA 示範專案──[開源遊戲 App isowords](https://github.com/pointfreeco/isowords?ref=ethanhuang13.plus)。 後來實際操作下去以後，覺得踩到了一些坑，所以逐漸發展成自己的解決方案。 ## 建議配菜 我在 [iOS 開發配飯吃 #0](https://www.youtube.com/watch?v=MLTpk7iukoc&ref=ethanhuang13.plus) 有教過把整個 iOS App 的程式碼，都放進 Local Swift Package 的作法。 一個好處是可以繞開 Xcode 專案檔容易衝突的問題，不過在 Xcode 16 用 Folder 就可以避開。 更重要的好處是，用 Package manifest 更容易定義用到的外部依賴，以及模組的切分。 這些模組拆分方法都是基於上面提到的 Local Swift Package。雖然你也可以在 Xcode 開 framework target 來切，但是我還是覺得放在 Package 比較管理。 所以如果你還不熟悉用 Local Swift Package 來搭配 Xcode 專案，可以看一下 [iOS 開發配飯吃 #0](https://www.youtube.com/watch?v=MLTpk7iukoc&ref=ethanhuang13.plus)。 ## 目標 我切模組的目標是： 1. 每個模組的職責非常明確（這是基本），讓分工合作的團隊成員都知道要怎麼分類與管理程式碼。獨立開發者的話，就把未來的自己當成團隊成員 2. TCA reducers 作為 App 的核心商業邏輯，能夠快速地執行 TCA reducers 的測試是至關重要的。要是編譯速度太慢，會讓人不想好好寫測試，TDD 也不可能實現 3. 確實掌控 reducers 的測試覆蓋率。測試覆蓋率可以用模組為單位來觀察，所以**切到剛剛好有需要測試的範圍為一個模組，這個覆蓋率就很有參考價值** 4. 可以順利跑起 SwiftUI Previews，達到接近即時更新的效果。之前的文章談過很多次，我很強調能夠看到 SwiftUI Previews 才能做好狀態設計。正確地切模組可以讓 Previews 每次更新只編譯需要編譯的部分，這樣就可以更快看到更新 5. 只有在跑整個 App 的時候才需要編譯外部依賴，進一步增進開發效率 6. 當有錯誤的時候，可以**依照依賴的順序來編譯不同模組，逐步排除問題**。這一點在現今的 Xcode 專案與 Swift 編譯器的表現下，會比想像中來得重要 ## 模組化架構圖 來看一張簡化版本的圖。 _This post is for paying subscribers only._ ### 0️⃣iOS 開發 AI 輔助工具 #6：從零開始 URL: https://ethanhuang13.plus/ios-ai-dev-tools-6-getting-started/ Last updated: 2026-08-13T06:05:22.000Z 這篇是給還沒開始使用 AI 工具的朋友，設計的一個輕鬆體驗任務。幾分鐘就能完成，適合用來感受第一個「Magic Moment」。如果你覺得 AI 還沒有什麼感覺，或許可以試試這個方法。 _This post is for paying subscribers only._ ### 🧪iOS 開發 AI 輔助工具 #5：我在公司開了一場 Workshop URL: https://ethanhuang13.plus/ai-tools-workshop-for-ios-team/ Last updated: 2026-08-13T06:05:21.000Z 最近我把研究 AI 工具的心得，在任職公司的 iOS Team 舉開了一次 3 個多小時的 Workshop。 我希望同事們不是只有完成公司交辦的工作，也要來學一些能帶著走的新技能。 公司政策限制能使用的 AI 工具，主要是 Copilot。但我希望大家能見識一下其他更厲害的工具，也把我研究出的技巧學起來。 這次 Workshop 的流程有經驗分享、實際操作，也有意見交流。同事們的反應還不錯。 綜合來說，有幾個東西是我希望每個人在這場都去體驗的： 1. **ChatGPT 的語音模式**：可以很流暢地進行對話，甚至直接打斷。也可以要求他的用語跟腔調 2. **ChatGPT 的記憶能力**：可以做一些比較長期計畫的回顧 3. 去比較 Claude 相較於 ChatGPT 產生程式碼與解釋技術的能力 4. **Cursor 的 Tab Completion 能力**：下載、註冊，並在實際的專案中使用。其他功能方面，Inline Chat 還行，Chat 跟 Composer 就再更不準確一點（或者說我們指令要更具體） 5. 去比較 Cursor、Copilot、Windsurf 產生程式碼、Code Review、修改既有程式碼的能力等等 在實際操作中，因為每個人想做的事情都不一樣（反映出軟體開發極大的多樣性），所以遇到的問題也都完全不同，滿好玩的。像是： _This post is for paying subscribers only._ ### 🔃SwiftUI 專欄 #8 連載再開。描述性框架、狀態驅動、TCA URL: https://ethanhuang13.plus/swiftui-8-tca/ Last updated: 2026-08-13T06:05:09.000Z **SwiftUI 本來就是我很關心且熟悉的主題，之後也會在 iOS Developer+ 分享。** 有兩個原因。 一個是 2022 年我就在 13 報寫過幾篇「[SwiftUI 一讀就入坑](https://www.ethanhuang13.com/p/swiftui-index?ref=ethanhuang13.plus)」專欄文章，一直都對於寫 SwiftUI 主題很有興趣。算是連載再開吧！ 另一個是，上個月我在 iPlayground 以「[Why SwiftUI? Why TCA?](https://www.notion.so/Why-SwiftUI-Why-TCA-iPlayground-2024-13522d68d8c580888413d0e8e0f394e3?pvs=21&ref=ethanhuang13.plus)」作為開場題目。為了準備，我對 SwiftUI 又有一些更深入的思考與認識。 演講時間只有 30 分鐘，內容非常緊湊。而我在台上的感覺是，很多重點沒有充分傳遞給台下聽眾，有點可惜。 總之，SwiftUI 有很多東西可以慢慢聊。 今天這篇文章我想來講講 SwiftUI 這類框架很重要的觀念──**描述性**與**狀態驅動**。 _This post is for paying subscribers only._ ### 🤖iOS 開發 AI 輔助工具 #4：評價 AI 工具的一把尺 URL: https://ethanhuang13.plus/ios-ai-tools-4-how-to-evaluate-ai-tools/ Last updated: 2026-08-13T06:05:20.000Z ### 前言：AI Coding 工具新消息速報 AI coding 領域真的是字面意義上的**每週**都有變化。 10/29，GitHub [宣布推出](https://github.blog/changelog/2024-10-29-github-copilot-code-completion-in-xcode-is-now-available-in-public-preview/?ref=ethanhuang13.plus)官方版本的 [Copilot for Xcode](https://github.com/github/CopilotForXcode?ref=ethanhuang13.plus) extension。那天我在公司開了一個線上會議，要求所有 iOS 同事都要安裝成功、貼出截圖證明，才能離開🤓 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-11-14-at-23.14.44@2x.png) 10/29 同時，GitHub 也宣布 Copilot 將會加入 Claude 3.5 Sonnet、o1-mini、o1-preview 等模型供選擇。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-11-14-at-23.15.07@2x-2.png) 10/30，由 [Daniel Edrisian](https://x.com/DanielEdrisian?ref=ethanhuang13.plus) 一個人開發就加入 [Y Combinator](https://www.ycombinator.com/companies/alex?ref=ethanhuang13.plus)，號稱要作為「The Cursor of Xcode」的 [Alex Sidebar](https://alexsidebar.app/?ref=ethanhuang13.plus)，[開始](https://x.com/juanjovn/status/1851687583694360592?ref=ethanhuang13.plus)受到眾多開發者關注。他非常積極地在更新功能，對這工具有興趣的朋友可以去產品的 Discord 伺服器直接跟 Daniel 討論。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-11-14-at-23.14.21@2x.png) 11/12，GitHub 又[宣布推出 Copilot Edits](https://code.visualstudio.com/blogs/2024/11/12/introducing-copilot-edits?ref=ethanhuang13.plus) 功能，可以同時修改多個檔案。應該是類似 Cursor Composer 的功能。 11/12 同一天，以插件形式提供 AI 寫程式功能的 [Supermaven](https://supermaven.com/?ref=ethanhuang13.plus)，宣布[加入 Cursor](https://www.cursor.com/blog/supermaven?ref=ethanhuang13.plus)，一起壯大。 11/14，[Codeium](https://codeium.com/?ref=ethanhuang13.plus) 推出從 VSCode fork 出來的 IDE，叫做 [Windsurf](https://codeium.com/windsurf?ref=ethanhuang13.plus)。口號是「Built to keep you in flow state」。成為 Cursor 與 Copilot 的另一對手。有興趣的話不妨看一下[宣傳影片](https://www.youtube.com/watch?v=3xk2qG2QPdU&ref=ethanhuang13.plus)。 上面是我隨手整理的，應該還有遺漏好些消息。 總之，這就是一個百家爭鳴、百花齊放的時代。 你是感到興奮，還是焦慮呢？ 今天要來分享，我用什麼視角看待眾多 AI 工具，來保持享受的心情，而不是焦慮。 iOS Developer+ 的讀者應該是資深 iOS 工程師為主，可以假定我們不是 AI 領域的專家。那麼有沒有什麼**資深 iOS 工程師既有的技能**，可以幫助我們評估 AI 表現的好壞？ _This post is for paying subscribers only._ ### 💡Side Projects: 專案與資料夾命名小技巧 URL: https://ethanhuang13.plus/side-projects-naming-tips/ Last updated: 2026-08-13T06:05:19.000Z 最近工作比較繁忙，今天分享一些小技巧。 ### Mac 使用者的 Developer 資料夾 不知道你有沒有種困擾，就是程式的專案，放在電腦裡要怎麼管理？ 其實 macOS 有個隱藏功能。 _This post is for paying subscribers only._ ### 🗣️Why SwiftUI? Why TCA?─iPlayground 2024 演講投影片 URL: https://ethanhuang13.plus/why-swiftui-why-tca-iplayground-2024-slides/ Last updated: 2026-08-13T06:05:17.000Z ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/IMG_3574.jpeg) 很榮幸能夠在 11/3 的 [iPlayground 2024](https://iplayground.io/2024/?ref=ethanhuang13.plus) 研討會擔任開場講者。 「Why SwiftUI? Why TCA?」 是我的題目。 _This post is for paying subscribers only._ ### 🤖iOS 開發 AI 輔助工具 #3：在 VSCode / Cursor 開發 iOS 專案 URL: https://ethanhuang13.plus/ios-ai-tools-3-setup-ios-project-in-vscode-cursor/ Last updated: 2026-08-13T06:05:18.000Z 11/5 更新：Rudrank 的電子書提供折扣連結。 最近 iOS 開發工具的 AI 輔助工具的發展，實在是滿熱鬧的。 以 Cursor 來說 ，最近有很多人都在研究並且寫文章，甚至有出書的。 我沒有寫得那麼快，不過我相信有興趣學的人其實早就自己動手了，所以開頭先列幾篇免費跟付費的資訊，大家可以互相做參考。 _This post is for paying subscribers only._ ### 🤖iOS 開發 AI 輔助工具 #2：Xcode 與 Cursor/VSCode 交互使用的絕技 URL: https://ethanhuang13.plus/ios-ai-tools-2-xcode-cursor-vscode-workflow/ Last updated: 2026-08-13T06:05:16.000Z ### 前言 這篇文章的內容本來規劃在更後面才出，但我覺得對 Cursor 有興趣的朋友，應該早就下載下來玩了。 所以還是先把我的絕技放出來。 影片是 Demo，沒有聲音。可以先看，也可以最後再看。 希望你會覺得訂閱 iOS Developer+ 會員值回票價。 今天要介紹的就是，**快速在 Xcode 與 Cursor / VSCode 之間切換的妙招**。 ### 在兩個 IDE 之間切換工作流程的問題 你可能會說，在 Mac 切換程式不就是按 `Cmd + Tab` 嗎？ 仔細分析工作流程會發現，如果某個檔案，我們在 Xcode 寫到一半，想要跳轉到 Cursor 進行 AI 編輯，那就得在 Cursor 打開同一個檔案。（Cursor / VSCode 找專案裡檔案的快速鍵是 `Cmd + P`。） 然後我們很有可能會去開到另一個檔案，這個時候若需要再跳回 Xcode 去看 SwiftUI Preview，那又得在 Xcode 去找到同一個檔案。（Xcode 的 Open Quickly 是 `Cmd + Shift + O`。） 一來，不同的 IDE 之間切換要重新開到相同的檔案。 二來，不同 IDE 相同功能的快速鍵完全不一樣。 這兩個問題都會造成所謂的 context switch。 如果不解決，就會影響我們的開發效率，甚至會破壞開發心流。 我們今天先教輕鬆在另一個 IDE 開啟同一個檔案的方法。 ### 從 Cursor / VSCode 跳轉回 Xcode 根據我的設定，如果我在 Cursor 或 VSCode 開啟了 iOS 專案進行開發，然後需要回到 Xcode 進行操作（例如跑測試、跑模擬器），我只要按下 `Ctrl + X`，就可以**一口氣做到打開 Xcode、打開同一個檔案，而且游標會定位到同一行**。 怎麼做到的呢？ _This post is for paying subscribers only._ ### 🤖iOS 開發 AI 輔助工具 #1：你信任 AI 嗎？ URL: https://ethanhuang13.plus/ios-ai-tools-1-do-you-trust-ai/ Last updated: 2026-08-13T06:05:15.000Z ### 前言 不好意思，這篇文章花了比我想像中還要多很多的時間寫。 我太在意要一口氣把想法都講完，結果卡在內容編排跟闡述的順序。 最後決定，砍掉大半，只講一部分想法，這樣才能儘快推進到設定環境與操作技巧的部分。 之後我會盡量少量多餐。 ### 正片開始 今天我們先來聊聊資深軟體工程師對於 AI 輔助工具可能會有的態度跟情緒。 因為我認為大部分的資深工程師，對於 AI 工具是**預設不信任**的。 就像一位新同事加入團隊，總是有經過面試。進來以後，我們也會觀察他的表現，再決定要怎麼合作。 不只是能力方面，還有為人處事，可不可靠。 另一方面就是網路上有太多宣稱「零基礎用 AI 來寫程式」的事情，不免令人懷疑到底有幾分真實性。 再怎麼說，AI 沒有像我有寫 10 年 iOS 的經驗吧。我踩過這麼多坑，它都懂嗎？🌚 「信任是贏來的」，AI 工具也是。 它們的「做人做事」怎麼樣呢？ ### 使用 AI 工具，會不會違反公司的保密政策？ 重話先說在前面，如果你是員工，打算在公司的專案使用任何線上 AI 工具，包括 ChatGPT、Copilot，或是 Cursor，**一定要先取得公司相關部門的同意**。因為程式碼屬於公司資產，你有保密的義務。 _This post is for paying subscribers only._ ### 🤖iOS 開發 AI 輔助工具 #0：自動完成能力，沒有比較就沒有傷害 URL: https://ethanhuang13.plus/ios-ai-tools-0-autocomplete-comparison/ Last updated: 2026-08-13T06:05:14.000Z 我開始做 iOS Developer+ 付費會員的契機，就是玩過 Cursor 以後，對於 AI 工具輔助軟體開發有了全新的認識，非常想要分享。 不說廢話，直接來看**三分鐘**大對決影片吧。 _This post is for paying subscribers only._ ### 🤕開發者職業傷害──Dependency 的故事、事故與世故 URL: https://ethanhuang13.plus/developer-injuries-dependency-stories/ Last updated: 2026-08-13T06:05:13.000Z 今天來分享一個我個人 iOS 開發職涯早期遇到的重大傷害，以及它教會我的事情。 ### 故事 大約在 2015 年初，也是我接觸 iOS 開發不到三年的時候，我正在幫自己的第一個獨立開發 iOS App，「快速筆記軟體 [NoteBox](https://apps.apple.com/tw/app/notebox-%E7%B0%A1%E6%BD%94%E6%9C%89%E5%8A%9B%E5%81%9A%E7%AD%86%E8%A8%98/id899446595?ref=ethanhuang13.plus)」 ，**升級雲端同步**的功能。 NoteBox 本來就有雲端同步，只是我最開始偷懶使用 [iCloud Key-Value Store](https://developer.apple.com/library/archive/documentation/General/Conceptual/iCloudDesignGuide/Chapters/DesigningForKey-ValueDataIniCloud.html?ref=ethanhuang13.plus#//apple%5Fref/doc/uid/TP40012094-CH7-SW1)。 你可以把 iCloud KVS 當作一個沒有衝突解決機制的雲端版 UserDefaults。當然，它的容量限制也絕對不是很好的長期儲存方案。 當時 Apple 已經發表 CloudKit，有著不需要使用者額外登入的好處，自然是重要選項之一。 另一方面，NoteBox 本來就有整合 Dropbox SDK，以利使用者一鍵把筆記輸出成檔案放在 Dropbox。 當時 Dropbox 有個叫做 [Datastore API](https://dropbox.tech/developers/the-datastore-api-a-new-way-to-store-and-sync-app-data?ref=ethanhuang13.plus) 的服務，提供給 mobile app 開發者很方便能同步非檔案的資料，類似後來推出的 Firebase Realtime Database，而且使用起來非常簡便。 它內建自動同步、衝突處理、離線儲存等功能。 重點是，它的同步速度非常迅速。兩台手機開著 NoteBox 在前景，在一台手機新增筆記，不到半秒就可以在另一台看到。 Datastore API 簡便且高效能，並且在各種多裝置 + 離線操作的測試條件之下，它都能正確合併資料。讓我對它十分有信心。 而且它還沒有跟開發者收費呢（！） 不過因為不是每個使用者都會登入 Dropbox，所以我同時做了 CloudKit 與 Dropbox Datastore 兩套方案，打算讓使用者自行選擇。 CloudKit 同步要寫得好不容易，需要考慮很多錯誤處理（這個情況，直到 2023 年 Apple 推出 [CKSyncEngine](https://developer.apple.com/videos/play/wwdc2023/10188/?ref=ethanhuang13.plus) 才變得比較簡單）。所以，雖然 Datastore 三兩下就串接完畢，我還是得在 CloudKit 上面花費大量時間開發及除錯。 還有，在兩種雲端儲存方案之間切換的機制也要做到好，也花了我不少力氣。 ### 事故 好不容易，就在我開發完畢兩套全新的同步機制、自行測試完畢，準備要把新版送審上線的時候， _This post is for paying subscribers only._ ### 💭用 Mac 試玩「暗喻幻想：ReFantazio」 URL: https://ethanhuang13.plus/metaphor-refantazio-demo-mac/ Last updated: 2026-08-13T06:05:44.000Z ### 前言 聽過 [weak self podcast](https://weakself.dev/?ref=ethanhuang13.plus) 的朋友應該都知道我很喜歡玩遊戲。 Apple 在 2023 年推出 [Game Porting Took Kit](https://developer.apple.com/games/game-porting-toolkit/?ref=ethanhuang13.plus)（以下簡稱 GPTK），讓 Windows 遊戲更容易可以在 Mac 上以轉譯的方式遊玩。 自從我[買了 MacBook Pro M3 Max](https://www.ethanhuang13.com/p/214?ref=ethanhuang13.plus) 以後，就常常把 Steam 遊戲庫裡的新舊遊戲拿來試試看，能否在 Mac 上玩。 雖然我規劃 iOS Developer+ 會員主要是要談 iOS 開發的進階話題，不過我想就當作是**額外福利**，也把怎麼在 Mac 上玩遊戲的研究心得，獨家分享給會員吧！ ### 簡介「暗喻幻想：ReFantazio」 暗喻幻想是 SEGA 旗下 Atlus 工作室，即將於 2024/10/11 上市的全新 RPG 大作。 是的，就是那個以「P5 天下第一」聞名的 Atlus。 而且本作的製作人都是 Persona 系列的核心成員。 喜愛 Persona 系列的朋友應該早就殷切期盼這款全新主題的大作到來，我就不贅述。 遊戲會出在 PS、Xbox 等主機平台，以及 [Steam](https://store.steampowered.com/app/2679460/ReFantazio/?l=tchinese&ref=ethanhuang13.plus) 上架。只有 Switch 不支援。 目前已經有試玩版可以遊玩整個序章，十分推薦有興趣的朋友下載來玩。 應該會玩得很過癮。 _This post is for paying subscribers only._ ### 🎯找到重要的事、先做重要的事 URL: https://ethanhuang13.plus/prioritize-what-matters-first/ Last updated: 2026-03-19T10:09:26.000Z 你相信軟體介面可以影響人們看待事物的方式嗎？ [GrandPerspective](https://grandperspectiv.sourceforge.net/?ref=ethanhuang13.plus) 是一個掃描硬碟後，用視覺化方式展現檔案大小的工具。 在 Mac 硬碟空間不夠時，我總是用它來找到要刪除的檔案。 它有三個厲害的地方，或者是我覺得做的對的地方。 ### 一、檔案大小與佔據畫面面積成正比 看上去越大塊的，就是越大的檔案。 游標移動到任何區塊，左下角就會顯示路徑跟檔名、右下角會顯示檔案大小。 資料夾也會被框起來，所以「個別檔案不大，但是整個資料夾很大」的情況也很容易發現（例如 Xcode 的 Derived Data）。 透過這個方式，當使用者覺得硬碟空間不夠時，可以憑著與生具來視覺能力，直覺找到想要刪除的檔案或資料夾。 雖然，身為軟體工程師的我們，對於檔案大小佔據了 KB、MB、GB，還是 TB 為單位，已經累積出直覺。但是對於不熟悉電腦的使用者呢？一個文件檔、一個音樂檔、一部影片，要佔據多少容量，他們通常沒有概念。 用視覺面積來代表檔案大小，是非常直覺的作法。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-10-02-at-11.25.03@2x-2.png) ### 二、一次看到全部的檔案 許多硬碟清理軟體，都把不同類型的資料夾分開處理。 比如，Mac 內建的儲存空間設定，是這樣子： ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-10-02-at-11.44.48@2x-2.png) CleanMyMac X 則是這樣： ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-10-02-at-12.34.51@2x-2.png) 它們設計成這樣，是讓使用者可以知道不同類型的檔案佔據多少空間。 但是實際上，我們什麼時候會需要知道儲存空間呢？**通常是要下載或安裝新東西，但空間不夠的時候**。 其實當下只需要**找到最大的幾個能刪除的檔案，刪掉或移動到別的空間，就夠了**。 在這件事情上，GrandPerspective 一次看到全部檔案的作法，對我來說就更加實際。 掃描完畢後，看到一個大區塊，游標移動上去，就看得到路徑、檔名、大小。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-10-02-at-12.38.54-2.gif) 如果是超多個零碎的小檔案，它們的整個資料夾也會被框起來。所以也可以很輕鬆地找到一群可能可以刪除的小檔案。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-10-02-at-12.40.47-2.gif) 發現是什麼不重要的檔案，就按右鍵 Reveal 到 Finder，手動刪除。（也可以開啟設定，在 GrandPerspective 的介面進行刪除。但我想自行確認）。 ![](https://storage.ghost.io/c/b5/ef/b5ef3a60-300e-4c93-99a1-ce3ec3f3c437/content/images/2025/04/CleanShot-2024-10-02-at-11.49.41@2x-2.png) ### GrandPerspective 影響了我解決問題的策略 這個操作方式不僅幫助我快速刪除大的檔案或資料夾，來清出足夠的空間，過程本身也很好玩。 只需要稍稍移動游標，就可以看到路徑、檔名、檔案大小，來學習「原來這個檔案會吃掉這麼多空間」，並且因為視覺化的刺激而留下深刻印象。 更重要的是，它讓我學到了應該用全局的觀點來解決問題。 後來，當我開發 iOS 遇到有效能問題的時候，我學會使用 Instruments。比如要解決卡頓問題的時候，找出當下佔據 CPU 時間最多的 func，當作優先改進的地方。 遇到 Swift 編譯時間太長，弄一個分析編譯時間的工具（現在 Xcode 有內建），然後從花費時間最久的開始拆解。 有的人解決問題是這樣：找到一個有機會**改進 2 倍**的地方，把時間花在上面去鑽研。但如果這個地方只佔據整體的 5% 呢？整體來說是從 100% 變成 105%，也就只是提升了 5%。 但如果是先看影響範圍最大的問題。比如說影響整體 60% 的地方，只要**改進它 20%**，整體來說就是從 100% 變成 112%，已經提升 12% 效能了。這麼做的難度往往遠低於前者，而且效益很高。 同樣的做事原則，不僅可以用在處理技術上的效能問題，也可以用在個人生產力、團隊運作，甚至家庭、社會。或是切換成時間的角度，檢視自己的人生，是否把寶貴的資源，用在重要的事情上？ **從全局的角度，找到最重要的事情，然後先去做。** 這是我從一個小小的工具軟體學到的智慧。 ### 三、長青軟體 前面說了，我覺得 GrandPerspective 有三個做的對的地方。 第三個，就是它維護地很好。20 多年來始終如一。 以 2024 年的審美觀來說，GrandPerspective 的介面看起來非常有年代感。 其實，在那個開源軟體還大量在 Source Forge 出沒的年代，GrandPerspective 就存在了。 [最早的版本大約是 2005 年左右](https://grandperspectiv.sourceforge.net/oldnews.html?ref=ethanhuang13.plus)，正好是我開始使用 Mac 時候。 **我很高興它沒有改變得太多，因為它早就把能做的事情做到非常好了。** 相較於一天到晚為了使用者利益以外的緣故而增加、修改、刪除功能的軟體界常態來說，實在是不可多見的寶藏。 GrandPerspective 可以在 [SourceForge](https://grandperspectiv.sourceforge.net/?ref=ethanhuang13.plus) 免費下載。如果要支持開發者的話，也可以在 [Mac App Store](https://itunes.apple.com/us/app/grandperspective/id1111570163?mt=12&ref=ethanhuang13.plus) 上購買，當作支持開發者。 這次的分享就到這裡。有什麼感想的話，歡迎留言給我喔！ 如果喜歡這篇文章，請考慮訂閱，並請推薦給更多人。謝謝。 ### 🔄iOS 開發的年度週期 URL: https://ethanhuang13.plus/ios-development-annual-cycle/ Last updated: 2026-08-13T06:05:12.000Z 我常常覺得 iOS 開發者就像農耕文化，有著以年為單位的工作週期。 不同的是，我們不看天氣吃飯，而是 Apple 的產品發布慣例。 多年來，iPhone 及新版的作業系統，總是在 9 月發表。往前推 3 個月是 WWDC 與各平台的 beta 版。 所以，有經驗的開發者知道什麼時候做什麼事情，能夠事半功倍。 以下是我歸納出的年度工作規劃： ### 9月 - Apple 發表新的 iPhone - 硬體效能新標準 - 可能會有一些 WWDC 沒有揭露的新硬體變化需要儘快適應。例如今年新增的 Camera Control，就給相機類 App 臨時增加工作 _This post is for paying subscribers only._ ### 🧐Swift 6 準備好了嗎？觀察社群動向 URL: https://ethanhuang13.plus/is-swift-6-ready-community-trends/ Last updated: 2026-08-13T06:05:11.000Z 標題不是「準備好 Swift 6 了嗎？」，意思完全不同～ 要把語法升級成 Swift 6，合理的順序是**從依賴的末端開始**。 因為，為了讓使用 library 的一方安心，library 提供的 types 與 API 與需要標記 `Sendable`、`@Sendable` 或是其他 Concurrency 的標記。 那些沒有準備好的 library，Swift 就會提示 import 前面要加 `@preconcurrency`。 換言之，如果要更新 app 的 Swift 語法，應該要先等 library 準備好以後才開始。 ### 查看個別 Library 的 Swift 6 準備情況 那麼，我們怎麼知道第三方 library 是否準備好了呢？ _This post is for paying subscribers only._ ### 🐣Swift 6 正式推出與應對策略 URL: https://ethanhuang13.plus/swift-6-release-and-adoption-strategy/ Last updated: 2026-08-13T06:05:10.000Z 隨著 Apple 正式推出 Xcode 16，Swift 6 也一併正式發布。 官網的文章 [Announcing Swift 6](https://www.swift.org/blog/announcing-swift-6/?ref=ethanhuang13.plus) 介紹了重點，頗值得一讀。最大賣點是嚴格的 Concurrency 語法，來避免可能的 data race。 在接下來幾篇文章中，我會以帶團隊及個人開發者的角度，分享一下我對 Swift 6 的看法跟應對策略。 **先講結論**：雖然是新的大版本，**Swift 6 毫無急迫性**。不管你是個人開發者，還是團隊的領導者，都沒有必要在此時此刻對 Swift 6 有太多的投資。 因為 **Apple 不會因為專案還在使用 Swift 5 語法，就不讓 App 上架**。而且，舊的 App 不會因為改成 Swift 6 就顯著提高穩定程度。 今天先聊一個觀念、名詞。 _This post is for paying subscribers only._