執行模擬器沒有問題,但不知道怎麼交出可測試的 iOS App? 最快解法:先檢查專案,再用 Product > Archive 建立封存,最後依老師要的成果匯出或上傳;沒有相容 Mac 時,程式碼可在其他電腦準備,但最終 iOS 建置仍要進入真實或遠端 Mac。

這篇教學適合誰

這篇文章寫給剛完成第一個 SwiftUI 專案、準備把成果交給老師或同學測試的學生。

如果你只有 Windows 或 Chromebook,也可以先在本機整理程式碼與素材,再用遠端 Mac 完成 Xcode 建置。若你已經能執行模擬器,卻分不清 Debug、Archive、匯出檔案和 TestFlight,下面的時間線可以避免你一開始就處理不需要的發布設定。

先確認你真正要交的成果

打包前不要先急著處理憑證。學生作業常見的交付要求其實不同:老師可能只收原始碼,也可能要看執行截圖、安裝檔,或邀請同學進行測試。先問清楚成果形式,能避免把課堂作業誤做成完整上架流程。

<
交付目標你要完成的工作暫時不必處理的部分學生適合度評分
只交原始碼整理專案、提交程式碼與素材、附上執行說明匯出安裝檔、TestFlight高
課堂展示確認模擬器或測試裝置能執行,準備截圖或影片正式分發流程高
交給同學測試Archive 後依需求匯出測試版本,確認安裝方式不必要的 App Store 上架步驟中高
準備 TestFlightArchive、簽署、上傳至 App Store Connect,再邀請測試者與課堂無關的商店頁面整理中
Apple 的官方分發說明把「建立 Archive」列為後續匯出或分發前的重要步驟;因此,能在模擬器按下 Run,不等於已經產生可交付版本。你可以先閱讀 [Apple 對 App 分發前準備的說明](https://developer.apple.com/documentation/Xcode/preparing-your-app-for-distribution),再依課程要求決定做到哪一層。

**提醒:**「我要交一個可以安裝的檔案」和「我要交一份可以被老師檢查的專案」不是同一件事。先確認交付物,通常比先研究簽名設定更省時間。

打包前的專案檢查

1. 保留一份可回復的版本

先複製專案資料夾,或將目前可執行的狀態提交到版本控制系統。Archive 過程中若遇到 Bundle Identifier、資源或簽署問題,你就能回到最後一個可執行版本,而不是在同一份檔案上反覆修改。

請同時確認:

  • Swift 檔案、圖片、字型與本地化資源都已納入專案。
  • 專案開啟後沒有顯示遺失檔案或套件。
  • 課程要求的 Scheme 已被選取。
  • App 顯示名稱、版本號與圖示不是測試期間留下的暫時內容。
  • 你知道專案的 Bundle Identifier,且沒有誤用同學或其他專案的識別字串。

2. 先在模擬器完成基本建置

先選取課程指定的 Scheme,再用模擬器執行一次。這一步的目的不是證明 App 已經可以發布,而是快速排除語法錯誤、資源缺失和 Swift Package 無法解析等問題。

可以用下面這張表判斷下一步:

<
目前症狀通常代表的問題層級下一個動作
紅色編譯錯誤程式碼或套件尚未通過建置先修正錯誤,再重新執行
App 能啟動但圖片消失資源沒有正確加入 Target檢查資源的 Target Membership
模擬器正常,Archive 失敗可能是設定、簽署或封存目標問題打開建置記錄,閱讀第一個失敗項目
顯示 Bundle Identifier 或簽署錯誤身分、團隊或分發資格不符合依帳號權限與官方文件檢查,不要套用陌生憑證
Scheme 不見或選錯目前建置目標不是課程專案回到 Scheme 管理與專案設定確認
Scheme 可以理解成「這次要用哪一套建置規則」。它會決定建置哪個 Target、使用哪種設定,以及執行或封存時採用的方案。若你不確定 Scheme 的作用,可參考 [Apple 的 Scheme 設定文件](https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project)。

從 Run 切換到 Archive

Run 比較像課堂草稿:你按下執行後,Xcode 會把目前的 Debug 建置結果送到模擬器或測試裝置。Archive 則像老師要收的交付檔:它會把專案整理成可在 Archives organizer 中繼續匯出或分發的封存項目。

因此,Xcode 27 怎麼打包 iOS App 的關鍵不是多按一次 Run,而是完成一次成功的 Archive。

3. 選定建置方案與目標

在 Xcode 中確認:

  1. 開啟正確的 SwiftUI 專案。
  2. 選取課程使用的 Scheme。
  3. 將執行目標改為適合 Archive 的裝置選項,而不是只針對某一個模擬器。
  4. 確認版本號、Bundle Identifier、團隊設定與圖示。
  5. 先執行一次普通建置,確認沒有新的錯誤。
Xcode 版本、macOS 版本和可用 SDK 之間必須相容。不要只因為看到「Xcode 27」就直接在舊系統上反覆安裝;請以 [Apple Xcode 系統要求頁面](https://developer.apple.com/xcode/system-requirements) 的最新資料核對你的環境。

4. 執行 Product > Archive

完成檢查後,從選單執行 Product > Archive。封存需要時間,期間不要因為畫面暫時沒有變化就重複操作。

成功時,你應該能在 Archives organizer 看到新的封存項目。若沒有成功,請依序做三件事:

  • 打開 Report navigator 或建置記錄。
  • 找出第一個真正造成失敗的錯誤,而不是只看最後一行摘要。
  • 判斷它屬於程式碼、資源、Scheme、Bundle Identifier,還是簽署問題。
Apple 也提供了 [常見 Archive 問題排解文件](https://developer.apple.com/documentation/technotes/tn3109-resolving-common-archiving-issues)。不要把「再按一次 Archive」當成排錯方法,因為同一個設定錯誤不會靠重試自行消失。

依測試目的匯出成果

Archive 成功後,先在 Archives organizer 選取剛建立的封存項目,再選擇 Distribute App。這時不要只看按鈕名稱,而要回到第一張表:你究竟是要交檔案、讓同學測試,還是準備 TestFlight。

<
使用情境適合的方向交接前必查項目學生適合度評分
只交原始碼提交專案與版本紀錄專案可開啟、素材齊全、附執行說明高
交付測試檔依註冊裝置或課程規定匯出檔案完整、安裝方式清楚、版本號正確中高
讓多人測試透過 TestFlight 的測試流程App 記錄、上傳狀態、測試者邀請方式中
準備正式發布依 App Store Connect 流程處理簽署、商店資料與審查要求低,通常超出課堂需要
如果老師只要「可以看成果」,不一定需要 TestFlight。若老師明確要求可安裝檔,則要先確認指定的測試裝置是否已註冊,以及課程帳號是否具備對應權限。Apple 對註冊裝置與匯出 App 的限制,請以 [官方裝置分發說明](https://developer.apple.com/documentation/xcode/distributing-your-app-to-registered-devices) 為準。

「簽署」可以先理解為替 App 加上可驗證的身分,讓系統知道這個建置結果由哪個團隊產生,以及它能以哪種方式分發。不要使用別人提供的憑證、私鑰或共享 Apple Account;Apple 對憑證類型有正式說明,可參考 Certificates overview。

若走 TestFlight,還需要在 App Store Connect 建立對應的 App 記錄。這不是每份課程作業都需要的步驟;只有在老師或測試流程明確要求時才進行。相關帳號與 App 記錄條件可查看 Apple 建立 App 記錄的官方說明,測試流程則以 TestFlight 官方概覽 為準。

**經驗:**如果你只想讓一位同學看功能,先問清楚對方要「影片、原始碼、可安裝檔,還是 TestFlight」。每多做一層分發,就會多一層簽署、帳號或裝置條件。

沒有本地 Mac 時的雙軌流程

沒有 Mac 並不代表你不能開始寫 iOS App。你可以在 Windows 或 Chromebook 上整理 Swift 程式碼、撰寫說明、管理 Git 提交與準備圖片;但 Xcode 的 iOS 編譯、Archive 和後續匯出,仍要在相容的真實 Mac 環境完成。

建議採用下面的順序:

5. 本地整理專案資料

將專案、資源、套件資訊和 README 放在清楚的資料夾中。不要只把某一個 Swift 檔案上傳,因為 SwiftUI 專案通常還依賴專案設定、資源目錄和 Target 資訊。

6. 進入遠端 Mac

若你使用遠端 Mac,圖形化遠端桌面適合開啟 Xcode、選擇 Scheme、查看模擬器與操作 Archives organizer。SSH 則適合檢查檔案、查看 Git 狀態或執行你已經理解的命令。

SSH 和遠端桌面是連線方式,不是 iOS 建置工具。你仍然需要在遠端 Mac 上開啟相容的 Xcode,並實際完成建置與 Archive。

你可以先從 MACGPU 的遠端 Mac 方案頁面了解可用的操作方式,再依學校規定和專案敏感程度判斷是否適合使用。不要把私人憑證、私鑰或不應分享的帳號資料放進不受你控制的環境。

7. 先做最小驗證任務

不要一開始就上傳整學期的專案。先完成這個最小任務:

  • 遠端 Mac 能開啟專案。
  • Xcode 能找到正確的 Scheme。
  • 專案能完成一次普通建置。
  • 專案能完成一次 Archive。
  • Archives organizer 能看到封存項目。
五項都通過後,再處理匯出或 TestFlight。若第二項就失敗,問題通常在檔案、套件或 Xcode 環境;若只有 Archive 失敗,才進一步查看簽署、建置目標和分發設定。

提交前的驗收清單

提交前,請逐項勾選。這份清單的目的,是把「我這台電腦能跑」和「老師拿到後真的能使用」分開。

  • [ ] 已確認老師要的是原始碼、執行截圖、測試檔或 TestFlight。
  • [ ] 已保留一份可回復的專案版本。
  • [ ] SwiftUI 專案能在指定 Scheme 下完成普通建置。
  • [ ] 專案中的圖片、字型、套件與必要資源都已同步。
  • [ ] 已確認 Bundle Identifier、版本號、App 名稱和圖示。
  • [ ] 若需要可分發版本,已成功完成 Product > Archive。
  • [ ] Archives organizer 中能看到本次封存項目。
  • [ ] 匯出檔案或上傳結果已實際確認,不只停留在按鈕完成。
  • [ ] 已寫清楚老師或同學如何安裝、執行或測試。
  • [ ] 沒有分享 Apple Account、憑證、私鑰或來源不明的安裝檔。
最後區分三種結果:自己在 Xcode 中能執行,只代表本機建置成功;模擬器能執行,不代表實體裝置能安裝;同學能安裝,也不代表 TestFlight 或 App Store 發布已完成。提交說明應明確寫出你實際驗證到哪一層。

新手 FAQ

Xcode 27 的 Archive 檔案應該在哪裡建立?

先選好能正常編譯的 Scheme,再把執行目標改為可封存的裝置選項,最後從 Product 選單執行 Archive。成功後,封存項目會出現在 Archives organizer;如果 Archive 失敗,應先查看建置記錄與錯誤內容,不要連續重試或直接修改簽署設定。

SwiftUI 專案要怎麼匯出給老師測試?

先確認老師要的是原始碼、可安裝檔,還是 TestFlight 邀請。只交原始碼時,提交專案與必要資源即可;需要測試時,才從 Archives organizer 選擇 Distribute App,再依裝置註冊或 TestFlight 的要求處理簽署、版本與檔案交接。

沒有 Mac,還能完成 iOS App 打包嗎?

你可以在 Windows 或 Chromebook 上撰寫程式、整理素材與提交 Git 紀錄,但 iOS 專案的 Xcode 編譯、Archive 與匯出仍要進入相容的 Mac 環境。若沒有本地 Mac,可以使用你有權限操作的遠端 Mac;先用小專案驗證能開啟、編譯和封存,再決定是否繼續。

Run 和 Archive 在 Xcode 裡有什麼不同?

Run 是把目前的 Debug 建置結果送到模擬器或測試裝置,適合檢查畫面與功能;Archive 則是建立可供後續匯出或分發的封存版本。模擬器能執行,只代表目前建置可跑,不代表專案已具備交付所需的簽署、版本與分發設定。

課程只要求提交 iOS 專案,哪些打包步驟可以省略?

先看老師指定的交付物。如果只收原始碼,可以省略匯出與 TestFlight;如果要看可執行成果,至少要確認專案能編譯,並寫清楚測試方式;只有在需要分享安裝版本或進行外部測試時,才需要進一步處理 Archive、簽署與分發。

根據交付期限選擇環境

如果你目前使用 Windows 或學校電腦,直接在本機準備程式碼的優點是檔案熟悉、修改方便;缺點是無法直接使用 Xcode,最後仍要另找相容的 Mac。macOS 虛擬機則可能遇到系統相容、圖形效能、磁碟空間和學校設備權限等限制,也不適合拿來源不明的映像檔處理課程專案。

如果你只是臨時完成一次課程打包,而且不需要實體 iPhone、長時間重負載或固定的本地開發環境,遠端 Mac 通常更直接:你可以保留原本的 Windows 或 Chromebook 作為編輯端,只在需要 Xcode、Archive 和匯出時使用 Mac。完成「能開啟、能編譯、能封存」的最小驗收後,再到 MACGPU 的 Mac 使用方案查看是否符合你的週期與權限需求。

若你接下來會長期進行 iOS 開發、需要接駁實體裝置,或每天都要使用本地 Xcode,購買一台自己管理的 Mac 可能更合適;若只是完成一次作業、短期測試或暫時缺少 Mac,先租用遠端 Mac 會比為單一課程立即購買硬體更容易控制成本與交付風險。