2026 年 6 月 8 日，Cupertino 的 WWDC 主題演講結束沒幾分鐘，Apple 就推送了 iOS 27 開發者 beta，並在 release notes 裡夾帶了一份正式的 SiriKit 棄用通知。一句話總結：App Intents 從此成為把你的 App 接上全新 Gemini 版 Siri 的唯一支援框架。如果你的 App 還靠 SiriKit 的 intent domains 在驅動 Siri，遷移倒數計時已經開始。
要理解這件事的份量，得回看來時路。SiriKit 在 2016 年登場，給的是一套固定的「意圖領域」選單——訊息、付款、叫車、健身——你的情境若塞不進 Apple 預烤好的桶子，就卡死。App Intents 則在 2022 年作為現代化、程式碼優先的接班人出現：你宣告一個 AppIntent struct，Apple 幫你建索引，它就同時出現在 Siri、Spotlight、Shortcuts 與 Widget。兩套框架並存了四年，團隊得以一拖再拖。6/8 終結了這段休戰：Apple 從「建議用 App Intents」正式升級為「SiriKit 已棄用」，並把新 Siri 的助理能力綁定在 App Intents 上。
誰會被影響？幾乎所有認真做 iOS App 的團隊——對跨平台工作室而言，就是每一個曾為 Siri 寫過原生 extension 的 Flutter 或 React Native 專案。新 Siri 跑在 Gemini 上，據報是一筆每年約 10 億美元的多年期合約，意味著助理流量即將變得更強、被用得更兇。Apple 給的緩衝期，大約是 2 到 3 年，之後依賴 SiriKit 的功能就會停擺。
接下來我會拆解 App Intents 實際怎麼寫、它和 SiriKit intent 差在哪、一張遷移成本表、主題演講沒明講的兩件事，以及 Flutter 工作室該把賭注下在哪。
技術細節
過去做 SiriKit 整合，你得開一個 Intents app extension、一個 .intentdefinition 檔，加上一個住在獨立 target 裡的 INExtension handler。App Intents 把這些全部收斂成一個編進主程式的 struct：
import AppIntents
struct BookSeatIntent: AppIntent {
static var title: LocalizedStringResource = "預約座位"
static var description = IntentDescription("為課程或活動預約座位。")
@Parameter(title: "課程")
var session: SessionEntity
@Parameter(title: "人數")
var seats: Int
func perform() async throws -> some IntentResult & ProvidesDialog {
let booking = try await BookingService.shared.reserve(session.id, seats: seats)
return .result(dialog: "已為 (session.name) 預約 (seats) 個座位。")
}
}真正的轉變是觀念，不只是語法。SiriKit 問的是「你的功能比較像 Apple 哪個領域？」App Intents 問的是「你的 App 提供哪些動詞和實體？」你建模自己的領域（SessionEntity、BookSeatIntent），系統——現在背後是 Gemini 的語言理解——負責把雜亂的自然語言對應到你的型別參數。同一個 intent 還自動變成 Shortcut、Spotlight 結果與互動式 Widget，一行多餘程式都不用寫。
三類讀者的立刻行動
- 工程師（程式碼級）：裝 iOS 27 beta，盤點每個 target 裡的
INExtension與.intentdefinition。先把流量最高的那個 intent 改寫成AppIntentstruct，確認它出現在 Shortcuts 後再接 Siri。 - 技術負責人（架構級）：清查哪些客戶 App 還依賴 SiriKit。把 2–3 年視窗當真，但別當寬裕——現在就把遷移排進正常的發版節奏，而不是 2028 年才手忙腳亂。
- 創業者／接案商（商業級）：把「SiriKit → App Intents 遷移 + 助理整備健檢」做成固定範圍的服務。手上有舊 iOS App 的客戶有一個躲不掉的死線，這是一筆好賣、時間框得住的案子。
比較與權衡
| 方案 | 優點 | 缺點 | 遷移成本 |
|---|---|---|---|
| 續用 SiriKit | 今天不用動工；既有程式短期照跑 | 已棄用；接不上 Gemini Siri；約 2–3 年後失效 | 延後，但會複利累積 |
| 遷移到 App Intents | 面向未來；免費獲得 Shortcuts/Spotlight/Widget 露出；Gemini 理解力 | 要重新建模領域實體；多一個測試面 | 每個 App 約 3–10 人日，視 intent 數量 |
| 放棄 Siri 整合 | 零維護 | 完全失去免手操作與助理發現性 | 低，但是能見度的損失 |
不會告訴你的事
- 「棄用」不等於「移除」，但護城河沒了。SiriKit 程式現在還能跑，可是新的助理能力一律 App-Intents-only。原地不動，等於悄悄從助理面消失，而對手正出現在那裡。
- Gemini 進到迴路裡，改變了你的測試負擔。一個機率性的 LLM 在把語言對應到你的參數，你必須測試各種模稜兩可的說法與失敗對話——型別參數有幫助，但消不掉這個新增的 QA 面。
- 隱私與 Apple–Google 的關係是策略風險。Siri 現在倚賴 Google 的模型（跑在 Apple 的 Private Cloud Compute 上）；一份這麼大的合約，也是一個你無法控制的依賴。
未來 3 個月會發生什麼
預期 Xcode 17 會推出遷移助手，從既有 .intentdefinition 自動生出 AppIntent struct；WWDC session 影片與 sample code 會大量湧現；第三方套件也會搶著把 App Intents 包成 Flutter／React Native 的橋接。觀察一個訊號：Apple 自家官方範例 App 何時拿掉最後一個 SiriKit target——那就是非官方的「可以全面押注」標記。
常見問題 FAQ
我必須整個 App 重寫嗎？
不用。只有對外暴露給 Siri／Shortcuts 的那部分要動。多數 App 只有少數幾個 intent，把那幾個改寫成 AppIntent struct，其餘照舊。
SiriKit 還能撐多久？
Apple 的棄用指引指向大約 2–3 年的視窗。棄用的 API 會持續可用到未來某版才移除；請把遷移排進正常發版節奏，不要賭硬性斷點。
App Intents 適用 Flutter 或 React Native 嗎？
可以，透過原生 platform channel／橋接。你在 iOS runner 裡用 Swift 寫 AppIntent，再呼叫進你的 Dart／JS 邏輯。原生那一層躲不掉，但很小且自成一塊。
遷移過程中使用者的 Shortcuts 會壞掉嗎？
建模正確的 App Intents 會自動驅動 Shortcuts。只要小心遷移、盡量讓 intent 名稱／識別碼保持穩定，使用者自建的 Shortcuts 就能繼續運作。
我的觀點（contrarian）
主流會解讀成「Apple 終於把助理 API 整理乾淨了」。我的判斷不同：真正的故事是，你 App 的被發現性，正被重新搬上一個你並不擁有的語言模型。SiriKit 的僵硬領域很煩，但它是決定性的。App Intents 加上 Gemini，意味著一個機率層現在替你決定你的動作何時出現在使用者面前——這是一個包裝成開發便利的新依賴。對 ScriptWalker 的業務啟示很具體：別把「App Intents 遷移」當成打勾項目來賣，要當成助理能見度來賣——把客戶的領域實體建模好、把對話與消歧寫細，把助理當成一條新的獲客通路。接下來兩年的贏家，是早動手、把 App Intents 當產品面而非水電管線的工作室。