適用於 iOS 的 Kotlin Multiplatform
Kotlin Multiplatform for iOS：關於整合、效能與工作流程的迷思
如果你已經花了多年時間開發 iOS 應用程式，你可能會想：使用 Kotlin Multiplatform 會影響效能嗎？我是否要放棄 Swift 的強大與優雅？開發人員體驗會像二等公民的權宜之計嗎？ 這些是大多數資深 iOS 工程師在考慮使用 KMP 時會提出的問題。
這篇文章根據實際使用情況，解析了 iOS 開發人員對 Kotlin Multiplatform 最常見的疑慮，讓你實務地了解 Kotlin Multiplatform 的 iOS 開發究竟是什麼感覺。
Kotlin Multiplatform 對 iOS 開發人員的意義
Kotlin Multiplatform 是一項技術，允許你根據實際需求分享多寡不一的程式碼——從單一模組到大部分的商務邏輯，甚至在適當的時候，可以使用 Compose Multiplatform 來分享 UI。
它並非試圖取代原生開發。相反地，KMP 讓你在跨平台分享程式碼的同時，仍能完全掌控哪些部分保持原生。
在最高層面上，KMP 讓團隊能夠：
- 無縫分享商務邏輯。
- 讓 Kotlin 程式碼可以從 Swift 中呼叫。
- 在 Kotlin 程式碼中使用完整的 iOS API 功能。
- 使用 Compose Multiplatform 建立可嵌入 SwiftUI 的畫面，或用 Kotlin 建置整個使用者介面。
- 直接從你的 Kotlin 程式碼中使用 MapKit 或 AVFoundation 等平台特定架構。
KMP 僅僅是另一個跨平台抽象層嗎？
並非如此——KMP 不會取代 SwiftUI 或 UIKit。相反地，它是原生開發的補充。
在實務上，這意義著你可以：
- 在 SwiftUI 或 UIKit 中建立 UI，利用原生 Swift 程式碼。
- 直接存取 iOS API，無需包裝函式（wrapper）或間接層。
- 在能發揮價值的地方整合共享程式碼，而非預設在所有地方都使用。
KMP 對 iOS 開發人員真的有用嗎？
雖然 KMP 是 Kotlin 生態系統的一部分，但它並不局限於 Android——它是一種在平台間共享功能的通用方法， iOS 團隊可以根據自己的條件來使用它。
對於面臨邏輯重複、各平台行為不一致以及維護成本不斷上升的團隊來說，它特別有用。使用共享層可以消除重複，同時保持完整的原生控制。
核心原則很簡單：
- 分享有意義的部分，例如商務邏輯、資料和網路。
- 將需要的部分保持原生，例如平台特定功能，並針對每個專案選擇 UI 是要共享還是原生。
- 根據需要隨時間調整平衡。
Kotlin Multiplatform 並非以 Android 為中心的解決方案；它是一項多功能的技術，可協助開發團隊提高一致性，同時又不失原生體驗。
圍繞 KMP 常有一些關於效能、複雜性和喪失原生控制權的迷思，但這些迷思並未準確反映其在實務中的運作方式。讓我們用基於經驗的答案來一一解析。
迷思：跨平台架構會損害 iOS 的效能與體驗
一個常見的擔憂是 Kotlin Multiplatform 會損害 iOS 應用程式的效能或體驗。這種假設通常是基於先前使用過橋接（bridge）或專有執行時（runtime）之架構（如 React Native）的經驗。
KMP 的運作方式不同。它使用 LLVM（與 Swift 相同的工具鏈系列）為 iOS 產生共享程式碼。沒有 JavaScript 橋接，沒有整合的執行時層，你的程式碼與 iOS 之間也沒有抽象層。這意味著你的應用程式將繼續以完全原生的二進位檔案運作，效能特性與典型的 iOS 開發一致。
迷思：Kotlin Multiplatform 是一項小眾或有風險的技術
你可能仍會將 Kotlin Multiplatform 與其早期的實驗階段聯想在一起。然而，Kotlin Multiplatform 已於 2023 年 11 月正式達到穩定（Stable）狀態，並已在所有支援的平台上準備好投入生產。KMP 已被許多知名公司用於真實的大規模 iOS 應用程式中，例如 Google、Duolingo、Booking.com、Sony、Philips 以及 McDonald's。
生態系統也持續成熟：適用於 iOS 的 Compose Multiplatform 於 2025 年達到穩定狀態，使得除了共享商務邏輯外，建置生產就緒的共享 UI 成為可能。根據 2025 年 Kotlin Multiplatform 調查，KMP 現在被視為生產可行，約 70% 的外掛程式使用者感到滿意或非常滿意，且約 80% 的使用者正在使用 Compose Multiplatform。
KMP 由 Kotlin 的開發者 JetBrains 支援。它不是一個業餘專案，而是一項策略性投資，將透過強大的工具支援、定期更新和不斷增長的生態系統支援持續演進。
迷思：Kotlin Multiplatform 僅適用於 Android 開發人員
Kotlin Multiplatform 常被認為是「Android 優先」，iOS 開發人員只是陪跑。
Kotlin 是一種通用語言，KMP 中的共享程式碼只是程式碼庫的另一個面向，並非由單一平台擁有。iOS 開發人員可以閱讀並貢獻程式碼、塑造 API 並影響跨平台設計。
在實務上，團隊採用不同的模式。許多 iOS 開發人員繼續主要在 Swift 中工作，特別是在 UI 密集的特性上，而共享商務邏輯則由工程師協作開發或由專注於跨平台程式碼的人員開發。
這帶來了更好的協作：團隊共同擁有邏輯的所有權，減少不一致性，並只需修復一次問題，而不是重複勞動。
迷思：我的 iOS 工作流程會變得更複雜
關於 KMP 的主要擔憂之一是它可能會干擾已建立的 iOS 工作流程。如果你已經經歷過 Objective-C → Swift → SwiftUI 以及不斷變化的工具鏈轉變，增加「另一件事」的想法可能會讓人感到精疲力竭。這種擔憂是合理的，這也是為什麼 Kotlin Multiplatform 設計為漸進式採用而非一次性到位。
你不需要在一夜之間接受全新的工具鏈。對於許多 iOS 開發人員來說，KMP 可以從僅取用共享模組開始。這意味著當你評估其有用性時，你的日常工作流程可以保持相對不受影響。
隨著深入使用，學習曲線是漸進的——而非全有或全無：
- 從使用共享的 Kotlin API 開始。
- 了解足夠的 Kotlin 以便閱讀共享程式碼並進行偵錯。
- 在合適的時候為共享邏輯做出貢獻。
迷思：Kotlin Multiplatform 產生的 Swift API 不符合慣用法
Kotlin Multiplatform 的 Swift 互通性仍是一個相關的擔憂。目前，Kotlin 程式碼透過 Objective-C 橋接呈現給 iOS，這可能使 Swift API 感覺不那麼自然，特別是在命名、可 null 性、泛型或非同步模式方面。
是的，如果管理不當，它感覺確實不像 Swift。然而，當開發共享程式碼時考慮到 iOS，建置良好的 Swift API 是可能的。以下是一些最佳實務：
- 保持 API 簡單且具備意圖。
- 避免無法正確轉換的 Kotlin 模式。
- 根據需要加入薄薄的 Swift 包裝函式。
- 直接在 Xcode 中驗證 API。
你也可以觀看演講錄製：「Kotlin Multiplatform 煉金術：將你的 Swift 互通性點石成金」。
Kotlin 的新工具——特別是 Swift Export——正邁向一個未來，讓 Kotlin API 能更直接且符合慣用法地與 Swift 整合，進一步減少摩擦。
Swift Export 旨在移除 Objective-C 層，而 Interopedia 則作為實務文件，幫助開發人員理解 Kotlin 程式碼如何暴露給 Swift，以及預期會看到哪些模式。像是 KMP-NativeCoroutines 和 SKIE 等程式庫更進一步修補了目前互通模型中的不足，改善了協同程式與 Swift async/await 的對應，並使產生的 API 對 Swift 更加友善。
迷思：共享 UI 意義著失去原生 iOS 體驗
一種普遍的誤解是使用 Kotlin Multiplatform 需要放棄完全原生的 iOS UI。事實並非如此。
KMP 根本不要求共享 UI。你可以只共享底層功能，並保持其餘部分原生：
- UI 可以使用 SwiftUI 或 UIKit 編寫，利用原生 Swift 程式碼。
- 動畫與互動可以保持完全原生。
- 平台 API 是直接存取的，不需要包裝函式。
你必須使用共享 UI 嗎？
這個策略完全是選配的，由每個團隊自行決定。主要前提很簡單：Kotlin Multiplatform 不會限制你如何設計介面。你可以使用 SwiftUI 或 UIKit 保持完全原生的 UI，使用 Compose Multiplatform 引入共享 UI，或根據需求結合兩種方法。
你最常用的畫面——如儀表板和核心產品流程——通常最好使用完全原生的 UI 來實作，在那裡你可以發揮最大的效能和平台特定的磨光。對於影響較小的區域，Compose Multiplatform 非常適合。例如設定頁面或不常使用的流程（如身分驗證）是共享 Compose UI 的理想候選者，在這些地方開發速度和程式碼重用比深度的原生優化更重要。
重要的是，Compose Multiplatform 與傳統 iOS UI 之間具有互通性，這意義著你可以在原生視圖旁邊嵌入共享組件，或隨著時間推移逐漸採用。這讓團隊能夠演進其 UI 策略，而無需預先承諾單一方法。
迷思：採用 Kotlin Multiplatform 意義著不再使用 Swift
一個常見的恐懼是引入 Kotlin Multiplatform 會讓 Swift 變得過時。但 KMP 並不是要取代它——Swift 對於 iOS 開發仍然至關重要。
你繼續為所有讓 iOS 應用程式感覺像 iOS 的部分編寫 Swift：
- 使用 SwiftUI 或 UIKit 的 UI。
- 導覽、動畫和使用者互動。
- 平台特定功能與整合。
- 應用程式生命週期與系統 API。
KMP 只是在旁邊增加了一個共享層。這意義著 iOS 開發人員繼續擁有原生體驗，共享商務邏輯通常是跨平台的共同努力，一些 iOS 工程師會貢獻 Kotlin 程式碼，而其他人則主要專注於 Swift。
現有專案中的 Kotlin Multiplatform iOS 整合
在現有應用程式中進行 Kotlin Multiplatform iOS 整合的最佳方式是從小規模開始。你不需要重新發明應用程式、重構所有內容，或在第一天就承諾採用完整的跨平台方法。
實際上，共享模組通常以以下形式提供給 iOS：
- 從通用程式碼建立的架構（framework）。
- 用於在組建目標間部署的 XCFramework。
- 根據團隊的工作流程，可能會使用 Swift Package Manager 整合相依性，或使用自訂設定。
關鍵點在於整合並非天生具有侵入性。你不是在替換應用程式的架構、UI 層或現有的 Swift 程式碼。你正在建立一個共享模組，讓你的 iOS 程式碼可以在任何有意義的地方使用。
這就是為什麼一個實際的起點通常是一個小型、低風險的區域，例如：
- 資料模型
- 驗證邏輯
- 網路
- 單一特性模組
這讓團隊能在保留原始 iOS 體驗的同時，觀察 KMP 如何融入程式碼庫。大多數團隊選擇漸進式採用：他們引入通用程式碼來解決特定問題，然後僅在效益確實存在時才擴展。這使得所有權易於維護。
何時使用 Kotlin Multiplatform 有意義（以及何時沒有）
當 iOS 和 Android 邏輯之間存在重疊，且這種重複開始造成困擾時，使用 Kotlin Multiplatform 就很有意義。對於希望在分享跨平台商務規則、網路、資料處理或領域邏輯的同時，保持原生 iOS 體驗的團隊來說，它特別有價值。
KMP 通常在以下情況是絕佳選擇：
- iOS 和 Android 應用程式使用相同的底層產品邏輯。
- 團隊需要修復兩次同樣的錯誤。
- 平台行為持續發生不同步的情況。
在以下情況可能不太適合：
- 應用程式高度依賴平台特性。
- 大部分的複雜性存在於 UI 層。
- 邏輯不足以支撐額外的設定與協調成本。
結論
使用 KMP，你減少了重複，同時增加了一個需要維護的共享層。你在實現一致性的同時引入了跨團隊協調，並保持原生 UI，但接受了一些互通性和工具的複雜性。
當共享程式碼能提供明確價值時——無論是小型、集中的邏輯片段還是較大的領域層——且不過度介入那些更適合由平台處理的領域，Kotlin Multiplatform 的效果最佳。
常見問題
實際上 Android 和 iOS 之間可以共享多少程式碼？
沒有固定的百分比；大多數團隊會分享商務邏輯、網路和資料層。確切的數量取決於你的應用程式以及平台間的重疊程度。帶有 Compose Multiplatform 的 Kotlin Multiplatform 允許你共享多達 100% 的應用程式程式碼（包括 UI），同時仍能與原生 API 整合。
Kotlin Multiplatform 會影響 iOS 應用程式的效能嗎？
沒有本質上的影響。共享程式碼是原生編譯的，因此效能與典型的 iOS 程式碼相當。
Kotlin Multiplatform 如何與 Swift 協作？
共享的 Kotlin 程式碼會被轉化為 Swift 可以使用的原生架構。在目前的模型中，互通性依賴於 Objective-C 橋接，這可能會引入一些摩擦。展望未來，這正在演進：JetBrains 的 Swift Export 旨在完全移除 Objective-C 層，實現與 Swift 更直接、更符合慣用法的整合。
iOS 開發人員需要學習 Kotlin 才能使用 KMP嗎？
不一定。你可以先從取用共享的 Kotlin 程式碼開始，然後根據偵錯或貢獻的需求逐漸學習 Kotlin。
我必須使用 Kotlin Multiplatform 分享 UI 嗎？
不，UI 分享是選配的。許多團隊保持 iOS UI 完全原生，僅分享底層功能。但越來越多的公司選擇分享 UI 程式碼，因為其結果在 iOS 上感覺非常原生。