參加 conference 的核心感受
今年七月，我們參加了 iPlayground 2026，原本對一場 iOS conference 的想像是會看到很多原生技術的分享，不論是新功能介紹、架構設計，或是如何處理開發時的棘手問題。
實際聽完兩天後，最大的感受卻是很多 session 已經把焦點放在如何使用 AI、如何與 AI 合作，甚至談到產品上架後的經營，不一定侷限於 iOS 開發。
我認為這個轉變很合理，現在 AI 已經深入許多人的開發流程，我自己也很有興趣（加上我還算是 iOS 菜鳥，太深入的原生技術不一定能馬上吸收😅）。這次最有收穫的幾場，反而讓我開始思考做 App 的目的，以及使用者到底能從 App 中獲得什麼。
如果要用一句話說明這兩天最核心的 insight，我認為是：
AI 降低開發成本，讓我們更容易把功能做出來，也更有機會補齊以前容易被時間與資源限制擱置的事情。使用者如何認識產品、學會操作，在不同情境下能不能順利使用，以及產品上架後如何持續改善，都是值得花心力的地方。開發門檻降低了，產品能做好的事情卻還有很多。
讓使用者先理解產品再看見價值
「Core People：以人為本，打造更體貼的 App 體驗」是讓我對這件事很有感的一場。
講者特別強調新手教學。過去做 App，常常為了趕快上功能，就把這部分往後放。但一個 App 就算功能很多，使用者第一次打開時，也可能完全不知道該從哪裡開始。新手教學要幫他理解怎麼使用，以及這個 App 和自己有什麼關係。
講者提出的引導順序是：
- 確認需求
- 展現價值
- 個人化設定
- 示範操作
- 要求權限
- 介紹方案
我認同這個順序背後的想法：先讓使用者理解產品、感受到價值，再逐步引導他做設定與選擇。如果一打開 App 就先問要買哪個方案，很容易讓人打退堂鼓，或是直接把所有功能攤在眼前，也可能讓人不知道接下來該做什麼。
這和第一場「Designing Adaptive UX Through Learning Theory & AI」帶給我的感受很接近。那場把 UX 和教育連結起來，將 user 當作 learner，透過認知負荷、情境式協助等概念，思考如何讓使用者逐步理解我們做出的產品。
[原投影片] Designing Adaptive UX Through Learning Theory & AI
我蠻喜歡這個角度的詮釋，因為它讓「介面好不好用」多了一層可以具體思考的依據：人在面對這些資訊時，能不能理解？會不會負擔太大？此刻需要什麼幫助？畢竟在工作上，我參與的是成熟產品，有 planner、designer 的專業分工，dev 比較著重實作。但在自己的 side project 時，這個 mindset 特別重要，因為我都是想著解決自己的問題，所以對需求和操作方式早已瞭然於心，很容易忽略別人第一次使用時會遇到的盲點。
Core People 也談到 Widget、App Intents 等能力。雖然相關技術我已經接觸過，它仍提醒我，App 能提供的價值也存在於 App 外。平常我們很容易把注意力放在 in-app 的需求上，但使用者可能在其他地方、其他時刻，就能透過這些能力得到幫助。
為什麼你並不需要 ViewModel
在 iOS 的開發經驗中，我第一個學習的設計模式是 MVC(Model + View + Controller)，MVC 在實作時容易出現 FatVC 的問題，當畫面越來越豐富， VC(ViewController) 就會越長越大，越來越難維護。
MVVM(Model + View + ViewModel) 這種設計模式剛好能解決 FatVC 的問題，ViewModel 把邏輯從 ViewController 抽離，ViewController 只負責在 ViewModel 有改變的時候做對應的 UI 更新，這樣的做法成功讓 ViewController「瘦身」了。除了瘦身以外，原本 ViewController 裡有邏輯跟 UI 混雜，較難單獨針對邏輯寫 unit test， 但因為 ViewModel 只包含邏輯，這讓原本較難單獨針對邏輯寫 unit test 變為較容易寫 unit test，這是 MVVM 後來越來越受歡迎的主因。
因此我看到這個標題，我就很好奇，為什麼現在不需要 ViewModel 了，實際聽了 session 之後，我才發現這段話是有前提的。
講者主要想表達的是這張投影片:
主要的原因是「ViewModel 的依賴建立方式與 SwiftUI 相衝突」，因為 ViewModel 在初始化的時候，會需要一些依賴，它可能無法在建立 View 的時候取得，此時只能選擇延後初始化 ViewModel，因此講者才會說 ViewModel 本身的依賴建立方式不適合 SwiftUI。
session 中，講者又講了一些 SwiftUI 的實作案例來解釋為什麼 ViewModel 不適合套用於以 SwiftUI 實作的專案。
最後，整場 session 我認為讓我最有共鳴的投影片是以下這張:
每個專案的發展過程中，都會因程式邏輯、業務需求而讓專案越來越複雜，沒有萬能的架構、設計模式，而是應該要針對專案想解決的問題，導入適合的架構、設計模式，才能藥到病除，解決想解決的問題。
無障礙，也是在理解使用情境
「當觸控失效時，你的 App 還能順利使用嗎？」則讓我把使用情境想得更廣。
無障礙本來就在我的認知裡，但這場談到的一些細節，是我以前沒有特別注意，或覺得交給專業的人設計就好的事情。最讓我記住的，是任何人都有可能遇到操作上的障礙。例如手上拿滿東西，暫時無法碰螢幕時，如果能透過語音控制完成操作，這就是很實際的幫助。
這讓我想到，自己設計 App 時，除了考慮使用者是誰，也應該考慮他正在什麼狀態下使用。平常能順利觸控的人，在另一個情境裡，可能就需要不同的操作方式。
我也聯想到自己使用的 sim-use：透過 accessibility 提供的資訊，讓 agent 理解目前的畫面並進行操作。我以前開發 Android App 時就接觸過相關機制，但看到它被做成可以實際放進 AI 開發流程的工具，仍然覺得很厲害。
讓自己的故事成為 App 體驗的一部分
這次我最喜歡的 session，是 Thiago Komeno 的「How to Win the Swift Student Challenge」。
他分享自己第一次參賽時，雖然覺得做出的 App 不錯，但那也是其他人能做出的東西。後來，他開始想做一些只有自己才能做的作品。
他在演講與作品文章中提到，祖父留下的日記裡有舊日文，讓他無法輕易理解內容。從字典的想法出發，他逐漸把自己的故事放進作品：讓使用者尋找日記、閱讀內容，透過文字、插圖和旁白，走進一段語言與家族歷史的旅程。他還到橫濱的 JICA 日本海外移住資料館查閱史料，讓故事與細節有更扎實的根據。
[原投影片] 把家族故事、祖父母世代的日文與舊字體，以及日本人移民巴西的歷史，連結成作品的核心。
在分享過程中最打動我的，是他和這個作品之 間的關係，也是他能得獎的最核心原因，這種功能的字典到處都有，但他的故事是獨一無二的，使用者也因此有機會從另一個人的視角，去理解這個 App，得到一段值得記住、可以投入其中的體驗。
說實話工程師很習慣從「我要解決什麼問題」出發，這當然重要，但這場演講卻讓我往另外的層面思考：除了把工具做出來，我們還能帶給使用者什麼？故事、情感與自己的經歷，能不能也成為體驗的一部分？這和前面談到的以人為本、幫助使用者理解產品，核心概念都是相同的。
把 AI 開發流程串起來，減少人工接續
談回 AI，這兩天也有幾場讓我想到很具體的工作方式。
「Xcode 沒內建我愛用的 Coding Agent？iOS 開發的 Agentic Workflow 策略」是前同事的分享。他以前就提出過一些我覺得很新穎的做法，這次最讓我有共鳴的，是如何讓 AI 接續完成平常開發 App 所需的步驟：寫 code、build、在 simulator 上操作與測試，再根據結果修正。
當 App 很大時，光開 Xcode 就可能需要不少資源和時間。而且流程如果要由人手動接續，很容易被打斷：等 AI 改 code 時先去做別的事，改完後又要切回來手動 build、再測一次。每一段單獨看都不長，接在一起卻有很多 context switching。
我後來確實嘗試過把這些步驟串起來，搭配 sim-use，讓 agent 在 build 後操作 simulator、執行測試，有問題就回饋並修正。最近做的主要是規模較小的 Flutter App，所以沒有完整驗證大型 Xcode 專案的情境，但減少人工接續步驟，確實讓我的開發流程順暢很多。
我仍然會確認成果，尤其是 UI。即使 agent 能讀圖片、使用 Figma MCP，畫面呈現很多時候還是需要人工看過。另外，也會檢查新功能是否影響相關行為，有點像跑一輪簡化版的 regression。流程能夠連續執行之後，我可以把注意力放在這些確認上。
「從看不見到看得懂：ccxray 與 AI Agent 的可觀測性」則是我想繼續研究的一場。講者拆解和 AI 的對話背後發生了什麼，包括使用哪些 skill、工具，以及 cache hit rate 等資訊。這讓我看到，優化 AI 的使用方式，可以有更具體的觀察依據。
我還沒有實際使用 ccxray，所以目前最有感的是這個方向：既然我們越來越依賴 agent，就值得更清楚地理解它的執行過程，看看有哪些地方能改善。
AI 是加速器，也需要煞車
AI 的影響也延伸到上架之後。「App 上架之後呢？用 AI Agent 自動化行銷、客服與產品迭代」展示了如何把產品維運的不同環節串起來。我覺得實作很厲害，至少能處理許多基礎問題、簡化原本繁瑣的步驟，放大一個人能完成的事情。
不過我對品質要如何把關，仍然有疑問。AI 是槓桿，好的效果能被放大，錯誤也可能一起被放大。套用 Matt Pocock 的說法：
AI 是加速器，我們也得準備好煞車要放在哪裡
目前我會參考 one-way door、two-way door 的想法：可回復且回復成本低的任務，可以給 AI 更多自主空間；難以收回、影響較大的動作，就需要更謹慎。像客服回答使用者問題，簡單的狀況排除可能適合自動處理，但複雜情況涉及對外承諾或品牌信任，就會希望有人介入。
另外，人也需要判斷要做哪些事情。AI 太強、能做的太多，很容易讓我們看到什麼就想「這個也交給 AI 做好了」。但照單全收會影響前進的方向與速度，做得越多並不一定越好。
這些是我目前的思考，至於人究竟應該在什麼時候介入 AI 工作流，我還沒有完整答案。這是我從活動帶回來、想繼續探索的問題。
從開源參與和分享方式得到的啟發
在 Apple Container 的開源實戰分享裡，我對工具本身沒有太大興趣，畢竟目前完全沒有使用到，預期未來也用不到，不過講者參與開源的路徑，改變了我對這場演講的想像：先照文件操作，遇到問題就嘗試修正、發 PR，從小改動逐步熟悉專案並建立信任，再參與更重要的功能。後來想想，這和剛進公司時其實很像，讓我對貢獻開源少了一點距離感。
[原投影片] 不寫 Swift 也能貢獻 Apple Container
「ContentBuilder Is All You Need」的技術細節，我現在已經記不太清楚，卻記得講者如何編排內容。每一層的講解都有清楚的邏輯，讓人知道為什麼要繼續往下走，也願意繼續聽。現在一些 code 使用細節，我可能會先交給 AI，遇到問題再深入研究；但把事情講清楚、讓人跟得上的能力，仍然是我很想學的。
這又回到我最喜歡的幾場分享：無論是設計產品、介紹作品，還是講解技術，都需要想想對方如何理解、會在哪裡卡住，以及怎麼讓他願意繼續。
帶回日常開發的思考
聽完這兩天，我更想把這種關注帶回自己的開發裡。AI 讓我能更順暢地完成許多實作，也讓我更有理由花時間看使用者：他是否理解這個 App？能不能在需要的情境下使用？這個作品能帶給他什麼值得記住的體驗？
而當我們把更多工作交給 AI，人應該在哪裡介入、如何判斷哪些事情值得做，還需要繼續摸索。這次 conference 留給我的，既有可以嘗試的做法，也有值得帶回日常工作的問題。
相關資料
相關資料：iPlayground 2026 官網與議程｜Thiago Komeno 的 2026 作品介紹｜ccxray