Kotlin Toolchain 0.12：以一套設定發布跨平台函式庫

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-06

JetBrains 推出 Kotlin Toolchain 0.12，把 Kotlin 多平台專案的函式庫發布範圍擴展至 JVM、Android、iOS 及 WebAssembly（Wasm）。對同時維護手機 app、iOS 端及後端或桌面 JVM 程式的團隊而言，焦點不只是一項新增輸出格式，而是嘗試以同一套工具設定管理不同目標平台的函式庫交付。iThome 報道指出，工具會按設定產生各平台所需版本，讓使用端的建置工具自行取得相應產物。

這次更新也把 Wasm 網頁 app 建置列為預覽功能，並加入 Compose Hot Reload 與 MCP server。前者旨在縮短介面調整後的查看時間；後者則容許 AI 代理與正在以 Hot Reload 執行的 app 互動。不過，Wasm 功能仍在預覽階段，而且 Compose Multiplatform 函式庫使用的圖片、字型等資源暫未能隨函式庫發布，準備導入的開發者仍要評估專案邊界和交付方式。

發布流程由平台分流轉為統一描述

iThome 指出，Kotlin Toolchain 自 0.11 起已有函式庫發布能力，但當時只覆蓋 JVM；0.12 才延伸至 Kotlin 多平台專案。新版發布時會一併產生共用程式介面、各目標平台使用的函式庫檔案、原始碼，以及供建置工具辨識平台版本的資訊。換言之，函式庫作者可在發布端描述支援目標，而採用該函式庫的專案毋須手動從多個檔案中挑選 Android、iOS 或 JVM 版本。

這項安排的實際價值，在於降低共享模組「可寫但難交付」的成本。跨平台團隊常把商業邏輯、資料處理或網絡存取層放進共用程式碼，但一旦要提供予其他 app 或內部產品組使用，版本、產物名稱與相依關係容易隨平台增加而變得複雜。從 iThome 所述的產物結構推斷，0.12 把平台選擇交回建置工具處理，可減少使用者接錯套件的機會，也令函式庫維護者較容易以一個發布流程管理多個目標。

不過，統一發布不代表所有跨平台問題都已被抽象化。iThome 報道提到，當 Kotlin 呼叫 C 語言函式庫時，相關串接設定可隨多平台函式庫一併處理，使用者毋須自行重建相同設定。這對含原生依賴的共用模組尤其有用；但同一報道亦清楚列出例外：Compose Multiplatform 的圖片、字型等資源現時不能隨函式庫發布。若團隊的共享 UI 元件高度依賴視覺資產，仍須另行設計資源的封裝、分發與版本管理，未宜把「一套設定」理解成完全無需平台或資產層面的工作。

Wasm 令網頁端加入同一條工具鏈，但仍屬預覽

iThome 報道指出，Kotlin Toolchain 0.12 可直接建置和執行 Wasm 網頁 app，並容許專案採用自訂的 index.html 及其他網頁資源。若 Kotlin 多平台函式庫依賴額外 npm 套件，工具鏈亦會一併取得，開發者毋須逐項加入。這使網頁端開始進入同一套多平台工具鏈的管理範圍，對想在既有 Kotlin 共用程式碼之上延伸網頁介面的團隊，確實多了一條可探索的路徑。

但「可建置」與「適合正式採用」之間仍有距離。報道明確把 Wasm 網頁 app 支援定位為預覽功能，因此較合理的起點會是原型、內部工具或受控範圍的驗證，而非立即把關鍵網頁產品全面遷移。團隊亦應把自訂網頁資源和 npm 依賴納入測試範圍，確認它們在實際建置、部署和更新流程中的行為。這是根據已知功能狀態作出的工程取捨分析，並非 JetBrains 對成熟度或適用場景的承諾。

從工作流角度看，Wasm 的意義在於令共享程式碼的目標平台再多一個出口，而非自動消除網頁開發的所有差異。現有項目若只需復用資料模型或業務規則，可能較容易評估收益；若同時牽涉複雜前端資產、既有 npm 生態或多層部署配置，整合成本便要逐項核算。對香港的初創和軟件團隊來說，這類能力可作為技術選型時的參考，但來源未有提供本地供應、定價或實際採用資料，不能據此推斷本地市場影響。

Compose 熱重載配合 MCP，AI 代理可觸及運行中的介面

iThome 指出，開發者現可從命令列啟用 Compose Hot Reload，在 app 運行期間載入介面修改。這種縮短回饋循環的方式，對需要反覆調整跨平台介面的團隊尤其實用：修改後不必每次都以完整重新啟動來確認版面或元件變化。新版同時可啟動 MCP server，讓 AI 代理與透過 Compose Hot Reload 執行的 app 互動。

按報道所列能力，AI 代理可要求重新載入或重新啟動 app、取得視窗畫面，以及讀取介面元件結構。這代表代理不只依賴程式碼文字，也可能取得運行中介面的狀態，用於協助檢查改動結果或重複執行 UI 開發步驟。其吸引力在於把 AI 輔助由單純產生程式碼，延伸到可觀察、可操作的本地 Compose 流程；不過，代理可做甚麼、應由誰授權、哪些環境可啟用，仍是團隊導入時需要自行訂立的開發管治問題。

工具鏈與 IDE 的配合也有門檻。iThome 報道稱，Kotlin Toolchain 配合 IntelliJ IDEA 2026.2.1 或以上版本，可使用 Compose 預覽及更多 Android 開發工具；iOS 專案則可在執行設定中選擇裝置、Xcode 選項，以及除錯或正式建置模式。同時，0.12 要求以 JDK 17 或以上編譯，最低 Kotlin 編譯器版本提升至 2.2.20。這些要求意味著升級並非只更換一個建置工具版本，團隊還要檢查 IDE、JDK、編譯器與既有自動化流程是否一致。

下一步應看交付完整度與團隊採用成本

Kotlin Toolchain 0.12 最值得留意的，是讓多平台函式庫發布、Wasm app 建置及 Compose 開發流程更集中於同一套工具鏈。對已有 Kotlin 多平台基礎的團隊，先以一個共享函式庫驗證發布產物是否符合 Android、iOS、JVM 與 Wasm 的消費流程，會比一開始全面改造更容易辨識收益與限制。涉及 C 語言函式庫的模組，也可特別檢視新發布流程能否減少重複串接設定。

往後值得觀察的是，預覽中的 Wasm 建置支援何時走向更穩定，以及 Compose 資源能否納入函式庫發布範圍。前者關乎網頁端是否可成為可靠的交付目標，後者則影響共享 UI 元件能否真正以完整套件形式流通。至於 MCP 與 Hot Reload 的組合，較適合由有既定權限管理和測試流程的團隊先行評估；它能否提升效率，最終仍取決於代理操作能否安全地嵌入日常開發規範。