Kotlin Multiplatform 開發 iOS 需要 Mac 嗎？2026 新手路線

Kotlin Multiplatform 開發 iOS 需要 Mac 嗎？2026 新手路線

Apple 官方系統要求頁面目前列出 Xcode 26.6 的相容環境；這直接說明一件事：Kotlin Multiplatform iOS 開發需要 Mac，至少在建置、啟動 iOS Simulator 和除錯階段如此。Apple 的 Xcode 系統要求 是判斷環境的依據。

但這不代表學生今天就必須買 Mac。較適合新手的獲勝路線是：Windows 用來學 Kotlin、寫共享程式碼和做 Android 開發；需要驗證 iOS 時，再按課程進度使用裝有 Xcode 的真實 Mac。等到每週都要進行 iOS 除錯，再評估長期設備。

這篇文章適合三類讀者：

  • 只有 Windows 電腦，準備由 Android 轉向跨平台開發的 Kotlin 初學者。
  • 需要完成 Android 與 iOS 雙端作業，但暫時無法購買 Mac 的學生。
  • 已能執行共享程式碼，卻卡在 iOS Simulator、Xcode 或真機測試的新手。

先分清楚：寫共享程式碼，和執行 iOS 是兩件事

最常見的入門失敗是這樣：學生在 Windows 的 Android Studio 完成範例，Android 端可以執行；接著按照課程說明點選 iosApp，卻找不到任何 iOS 裝置或模擬器。

這不是 Kotlin 程式碼一定寫錯，而是兩個工作被混在一起：

  • 編寫共享程式碼：處理資料模型、商業邏輯、網路請求等可共用部分。
  • 執行 iOS 應用程式：呼叫 Apple 的建置工具、模擬器和除錯環境。

Kotlin Multiplatform 官方 FAQ 說明，跨平台專案可以共享部分程式碼，但各平台仍有自己的工具鏈和平台專屬程式碼。官方 FAQ 對共享與平台程式碼的說明 可用來判斷 Windows 的工作範圍。

可以把它想成「公共作業」和「不同平台的答題紙」：

  • commonMain 是公共作業。它放可在多個平台重用的 Kotlin 邏輯。
  • Android 端是其中一張答題紙，可直接在 Windows 上測試。
  • iOS 端是另一張答題紙，需要 Apple 的 macOS 工具鏈完成最後驗證。

因此，「Windows 能不能寫 Kotlin Multiplatform」和「Windows 能不能完整執行 iOS」不是同一個問題。前者通常可以，後者有明確限制。

Windows 與 Mac 的工作邊界

只要課程還停留在 Kotlin 基礎或 Android 端，Windows 通常可以承擔主要學習工作。

Windows 可以先完成什麼

以下工作不必因為尚未有 Mac 而停下：

  • 學習 Kotlin 語法、類別、函式和協程概念。
  • 編寫 commonMain 中的共享商業邏輯。
  • 執行 Android 應用程式及檢查 Android 畫面。
  • 使用 Git 管理專案，與同學交換程式碼。
  • 撰寫測試、整理資料模型和處理一般網路請求。

例如，學生可以先在 Windows 內確認共享模組能否成功編譯：

./gradlew assemble

可能看到的輸出如下：

BUILD SUCCESSFUL

這只能代表目前指定的 Gradle 工作完成，不能推論 iOS 應用程式已經可以啟動。是否能跑 iOS，還要看專案是否進入 Apple 平台工作。

看到這些訊號，就要準備 Mac

以下情況出現時，Windows 的角色會由「主要工作站」變成「程式碼編輯端」：

  • 課程要求執行 iosApp。
  • 教材要求開啟 Xcode 專案。
  • 需要啟動 iOS Simulator。
  • 需要檢查 iPhone 或 iPad 的畫面行為。
  • 使用相機、推播通知等 iOS 專屬功能。
  • 需要產生 Apple 平台 Framework。
  • 需要簽名、連接真機或提交應用程式。

Kotlin Multiplatform 快速入門文件把 iOS 執行步驟放在 macOS 與 Xcode 環境中，而不是提供一個 Windows 版 iOS 模擬器。官方快速入門流程 是課程規劃時應優先參考的文件。

iOS Simulator 與 Xcode：真正的限制在哪裡

iOS Simulator 不是一般的 Android 模擬器套件。它屬於 Apple 的開發工具鏈，啟動、建置和除錯都需要 macOS 主機上的 Xcode。

所以，下面三種說法不能混為一談：

  • Windows 編輯器：可以編寫 Kotlin 和共享程式碼。
  • 雲端編譯服務：可能代為執行某些建置工作，但不等於能完整互動式除錯。
  • 遠端真實 Mac：可透過 VNC、SSH 或網頁控制台進入 macOS，操作 Xcode 和 iOS Simulator。

對初學者而言，第三種通常較接近課堂要求。原因很簡單：課程不只要一個建置結果，還可能要求查看畫面、點擊按鈕、觀察權限提示，或重新執行某個流程。

提醒： 不要把「成功產生檔案」當成「iOS 開發環境已完成」。如果沒有看到 iOS 畫面，便無法確認版面、權限、生命週期和平台專屬行為是否正確。

Apple 官方目前列出的穩定環境包含 Xcode 26.6。至於測試版工具，即使在網路討論中有人分享可用經驗，也不應被當成課程或作業的固定相容性承諾。環境選擇應以 Apple 官方 Xcode 系統要求 為準。

加入 iOS 專屬功能後，驗證要求會提高

共享程式碼能通過編譯，不代表整個 iOS 功能已經完成。以相機為例，程式可能在公共邏輯中正確處理「請求相機」這個動作，但真正的 iOS 端還要驗證：

  • 權限提示是否正常出現。
  • 使用者拒絕權限後，畫面是否能給出提示。
  • 應用程式返回前景後，狀態是否正確恢復。
  • 不同 iOS 裝置尺寸下，畫面是否被裁切。
  • 平台專屬程式碼是否能與共享模組正確溝通。

這時會看到 Framework 這個詞。它可以理解為「讓 Apple 平台使用共享邏輯的一個封裝檔」，不是單純把 Kotlin 原始檔拖到 Xcode 裡就完成。

學生也可能遇到通知、相機、檔案權限或系統分享等功能。它們都涉及 Apple 平台行為。只在 Windows 內檢查 Kotlin 編譯結果，無法替代 Xcode、模擬器或真機驗證。

若課程只要求學習共享邏輯，可以延後這一步。若作業評分包含 iOS 畫面或平台功能，就必須安排 Mac 時段，否則很可能在最後提交前才發現環境不足。

團隊作業、真機測試與提交是三個階段

小組可以用不同作業系統共同維護同一個 Kotlin Multiplatform 專案。Windows 成員負責共享邏輯和 Android 端，Mac 成員負責 iOS 建置與畫面確認。這種分工可行，但要先建立清楚的交付規則。

建議每次切換平台前執行：

git status
git add .
git commit -m "update shared logic"
git push

可能看到：

On branch main
nothing to commit, working tree clean

Mac 端再同步：

git pull
./gradlew build

這些命令不能消除平台差異，但能避免「程式碼尚未同步」被誤認為「Mac 環境故障」。團隊也應記錄 Kotlin、Gradle、Android Studio 和 Xcode 的版本，並把必要的設定檔變更寫在專案說明中。

學習、真機測試和正式發布應分開看：

  • 學習階段：Windows 可完成 Kotlin、Android 和共享邏輯。
  • 真機測試階段：需要 Mac、Xcode、已註冊的裝置，以及正確的團隊設定。Apple 的註冊裝置測試文件說明了這類流程。
  • 發布階段：還涉及簽名、封裝、提交和審查準備。可參考 Apple 的發布準備文件與測試版及正式發布流程。

初學者不必一開始就處理發布憑證。若目前只是課堂練習，先完成模擬器驗證已足夠。只有作業或專案明確要求真機展示，才需要進一步處理開發團隊、簽名和裝置設定。

Windows 與遠端 Mac 的雙軌選擇

沒有 Mac 的學生，不必在「完全放棄 iOS」和「立即買一台 Mac」之間二選一。可以先按照學習頻率分流。

若符合以下條件，選 Windows 主導

  • 目前重點是 Kotlin 語法。
  • 課程主要教 Android。
  • iOS 只出現在後續章節。
  • 尚未要求執行 iosApp 或檢查 iOS 畫面。

這時購買 Mac 的必要性不高。先把共享程式碼和 Android 基礎打好，通常比提早處理兩套工具鏈更有效率。

若符合以下條件，選 Windows 加遠端 Mac

  • 每隔一段時間才需要啟動 iOS Simulator。
  • 課程同時要求 Android 與 iOS 作業。
  • 需要偶爾打開 Xcode，確認 iOS 專屬功能。
  • 現有 Windows 電腦足以完成主要編輯工作。

這種安排的重點不是把所有工作搬到遠端，而是把 Mac 留給 Apple 平台才需要的步驟。可先參考 SFTPMAC 的 Mac 租用方案，確認適合的租用週期，再按課程安排使用時間。

若符合以下條件，才評估長期購買 Mac

  • 幾乎每次開發都要進行 iOS 除錯。
  • 需要長時間使用 Xcode 和模擬器。
  • 專案經常進行真機測試。
  • 遠端連線、檔案同步或螢幕操作已反覆打斷學習。

這不是「Mac 一定比較好」的結論，而是根據使用頻率作出的設備決策。偶爾驗證 iOS，短期使用遠端真實 Mac 可能更合理；每天進行 iOS 開發，長期設備才值得納入預算。

新手決策條件清單

可依照下面的條件直接分流，不必先購買設備再尋找使用場景：

  • 若目前只學 Kotlin 語法、Android 或 commonMain，則選 Windows。 先完成共享邏輯和 Android 練習，暫時不需要 Xcode。
  • 若課程偶爾要求執行 iosApp 或查看 iOS 畫面，則選 Windows 加遠端 Mac。 Windows 負責編輯，Mac 負責 Xcode、iOS Simulator 和結果確認。
  • 若每週都要調試 iOS 專屬功能，則先計算實際使用頻率，再評估長期 Mac。 只有當連線與同步反覆打斷流程，才有充分理由轉向自購設備。
  • 若作業要求真機展示，則準備 Mac、Xcode、裝置設定與簽名流程。 不要只以 Android 模擬器或共享程式碼編譯成功作為驗收結果。
  • 若目標只是產生一次 iOS 建置檔，則不要把一次性任務當成長期需求。 先使用可用的 Mac 環境完成驗證，再決定是否需要固定設備。
  • 若團隊已有成員負責 Apple 平台，則 Windows 成員可繼續處理共享邏輯。 但必須透過 Git 提交、同步和記錄重現步驟，不能假定兩邊環境完全相同。

Windows 與遠端 Mac 協作的五個操作步驟

第一步：確認課程真正要求。
把教材中的任務分成 Kotlin、Android、iOS Simulator、Xcode、真機和發布。不要只看課程名稱，直接找是否出現 iosApp、Xcode 或 iOS 裝置。

第二步：在 Windows 完成共享部分。
先建立專案、編寫 commonMain 邏輯，再執行 Android 端。把錯誤分成「程式碼錯誤」和「缺少 Apple 環境」兩類。

第三步：用 Git 固定交付點。
每次準備切換到 Mac 前提交變更。不要直接複製未整理的資料夾，也不要讓 Windows 和 Mac 同時修改同一份檔案後再互相覆蓋。

第四步：在 Mac 上先確認工具鏈。
登入 macOS，啟動 Xcode，確認專案能載入，再檢查 iOS Simulator 是否可選。若 Xcode 要求安裝元件，先完成安裝，再判斷 Kotlin 專案是否有問題。

第五步：先跑最小功能，再測平台功能。
先確認空白畫面或簡單頁面能啟動，再測試相機、通知或權限。這樣能分辨是建置問題、畫面問題，還是 iOS 專屬 API 問題。

第六步：完成課程後再評估設備。
記錄實際需要進入 Mac 的頻率。若只是偶爾驗證，保留雙軌；若每次作業都需要 Xcode，再考慮長期環境。

常見錯誤與回退方式

有些看似省事的方案，反而會讓初學者花更多時間排錯。

第一，不能把 Windows 上的 Android 模擬器當成 iOS Simulator。兩者不是同一個平台，也不能互相驗證 iOS 畫面。

第二，不能把雲端編譯結果當成完整開發體驗。編譯成功只回答「能否產生建置結果」，沒有回答「使用者點擊後是否正常」。

第三，不要為了課堂作業使用來源不明的 macOS 環境、共享開發者帳戶或規避學校設備管理的方式。這些做法可能造成權限、合規和資料安全問題，也不適合作為穩定學習路線。

若遠端 Mac 無法正常連線，先退回 Windows 完成共享邏輯，再將錯誤日誌、提交紀錄和重現步驟整理好。等 Mac 可用時一次驗證，比在兩台電腦之間反覆猜測更容易定位問題。

常見問題 FAQ

Windows 可以做 Kotlin Multiplatform iOS 開發嗎？

可以做共享程式碼和部分專案工作，但不能把 Windows 當成完整的 iOS 開發環境。iOS 建置、iOS Simulator、Xcode 除錯和真機流程都要進入 macOS。最穩妥的入門方式，是用 Windows 保持主要學習節奏，再以遠端真實 Mac 完成 Apple 平台驗證。

只寫共享程式碼需要 Xcode 嗎？

只寫 commonMain 的 Kotlin 邏輯時，通常不需要先安裝 Xcode。Windows 可處理語法、資料模型、測試和 Android 端工作。不過，一旦程式碼要被封裝成 Apple 平台 Framework，或課程要求執行 iosApp，就必須使用 macOS 與 Xcode 進行實際建置和檢查。

Windows 和 Mac 之間如何協作才不容易出錯？

建議使用 Git 作為唯一交付來源：Windows 完成共享邏輯後提交並推送，Mac 再拉取相同分支進行 iOS 建置。兩邊應固定工具版本，並避免用雲端硬碟直接覆蓋整個專案。每次切換後先執行最小建置，再測試 iOS 專屬功能。

學 Kotlin Multiplatform 是否必須一開始就買 Mac？

不必。若目前只學 Kotlin 或 Android，Windows 已能支援主要練習。若課程偶爾才要求 iOS Simulator，可以短期使用遠端 Mac。只有在頻繁 iOS 除錯、真機展示或提交應用程式時，才需要認真比較自購 Mac 和長期遠端使用的成本與便利性。

最後的選擇：先保留 Windows，再按需要補上 Mac

對學生而言，現有 Windows 電腦並不是障礙的全部。它可以完成 Kotlin、Android 和大部分共享程式碼；真正需要 Mac 的，是 iOS 建置、Xcode、iOS Simulator、真機測試與發布工具鏈。

若目前課程只是偶爾要求執行 iosApp，保留 Windows 作為主力，再租用 SFTPMAC 的遠端真實 Mac，通常比立即購買設備更容易控制學習成本。遠端方案的代價是連線品質、螢幕操作和檔案同步需要管理；自購 Mac 則有一次性設備成本、系統維護和閒置風險。可先從 SFTPMAC 的 Mac 遠端租用入口了解連線方式，再決定是否需要長期設備。

若課程已經進入每週 iOS 除錯、真機展示或正式提交，遠端操作一旦持續打斷流程，長期 Mac 環境才值得列入規劃。此時的判斷標準不是「哪個系統比較潮」，而是每週有多少工作必須進入 Xcode，以及這些工作是否已成為固定流程。