導航 Swift 開發：超越 Xcode 日常束縛的工作流程

部分 Swift 開發者的情緒很明顯：雖然 Xcode 對於 Apple 生態系統來說是不可或缺的，但日常使用它來編寫代碼可能會讓人感到沉重。原始的 Hacker News 文章簡潔地捕捉到了這種挫折感，將 Xcode 描述為開發者被迫下載且通常需要每天使用的「怪獸」。這引發了一個常見的問題：在不持續與 Xcode 互動的情況下，構建 Swift 應用程式有哪些可行的工作流程？

本文深入探討開發者所採用的策略和工具，以盡量減少對 Xcode 的依賴，同時綜合社群的見解，並承認完全脫離 Apple 整合開發環境的固有挑戰。

不可避免的依賴：為什麼 Xcode 揮之不去

儘管渴望擺脫 Xcode，但對於許多類型的 Swift 開發來說，完全逃離通常是不切實際的，甚至是可能的。幾個核心組件和流程仍然與 Xcode 或其底層工具鏈緊密耦合。

正如一位評論者所指出的：

It's nearly impossible to get away from Xcode entirely. You will always need the simulator and probably some entitlement / asset tools.

這突顯了 Xcode 存在感強烈的關鍵領域：用於測試的 iOS/macOS simulator，以及管理 app entitlements 和 assets 的工具。此外，構建流程本身也經常在背後偷偷依賴 Xcode 的 command-line tools。

I feel like most Xcode free-swift setups still secretly depends on xcodebuild for anything real.

這表明，即使開發者使用替代編輯器或構建腳本，xcodebuild——Xcode 用於構建專案的命令列介面——也經常在幕後被調用。這意味著，雖然直接與 Xcode GUI 可能會減少，但它提供的底層層級結構仍然至關重要。

替代編輯環境與 AI 輔助

對於實際的代碼編寫和編輯，開發者已成功採用了一系列工具，從 Xcode 的內建編輯器轉向其他選擇。

傳統文本編輯器

許多開發者利用功能強大、通用型的文本編輯器，這些編輯器提供廣泛的自定義和語言支持。例如，Emacs 被引用為 Swift 開發的可行選項，就像它對許多其他程式語言一樣。Swift.org 的文件本身也提供了設置開發環境的資源，表明非 Xcode 編輯器是一條被認可的途徑。

現代代碼編輯器

除了傳統編輯器，更新、更輕量級的代碼編輯器也正受到關注。一位開發者提到使用 Zed 來閱讀源代碼，表明在某些任務中，比起 Xcode，更偏好其速度和介面。

AI 驅動的開發

或許其中一個更前沿的方法涉及將 AI 助手整合到工作流程中。一位用戶描述使用 Claude Code / Codex 來處理大部分的編碼工作，有效地將代碼生成甚至一些調試錯誤的任務交給 AI，同時仍使用像 Zed 這樣的獨立編輯器進行源代碼審查。

使用 Swift Package Manager (SPM) 進行模組化開發

為了將核心應用程式邏輯與 Xcode 互動最小化，一種常見的策略是利用 Swift Package Manager (SPM)。SPM 允許開發者定義和管理依賴項，使其成為代碼模組化的理想選擇。

建議的工作流程如下：

  1. 將核心邏輯開發為一個 SPM Package：使用偏好的編輯器將應用程式的大部分代碼寫成一個獨立的 Swift Package。
  2. 創建一個極簡的「Xcode Shell App」：創建一個僅包含必要 assets、preview assets 和 plist 文件的極簡 Xcode 專案。這個專案沒有實際的應用程式代碼。
  3. 整合 SPM Package：將步驟 1 中開發的核心邏輯作為本地或 GitHub 倉庫依賴項包含在這種極簡的 Xcode shell app 中。

這種方法允許開發者將大部分時間花在他們選擇的構建工具中，專注於 SPM package 內的核心業務邏輯，並僅在需要其特定工具的最終組裝、構建和部署流程中與 Xcode Xcode 互動。

特殊工具與跨平台替代方案

除了通用策略，一些特定的工具和框架提供了替代的開發範式。

xcede

一位評論者提到了名為 xcede 的設置，表明存在專門的工具來簡化或簡化或替換部分 Xcode 工作流程。雖然細節不多，但這類工具通常旨在為特定用例抽象掉 Xcode 的複雜性。

跨平台框架 (Tauri)

對於不嚴格要求與 Apple 特定框架進行深度整合的應用程式，跨平台解決方案提供了一條完全不同的路徑。Tauri 2，結合 Rust 和 webview，被建議作為一種在不接觸 Apple 框架或 Xcode 的情況下實現「原生感」應用程式的方法。這對於旨在實現更廣大的平台兼容性，且願意為其 UI 層使用 Swift/Apple-native 生態系統之外的工具的開發者來說特別相關。

結論

雖然由於 Xcode 與 simulator、entitlements 和底層構建系統的深度整合，完全放棄 Xcode 進行 Swift 開發的夢想在很大程度上仍難以實現，開發者已找到有效的方法來最小化其日常使用。通過採用替代的代碼編輯器、利用 AI 助手、並通過 Swift Package Manager 進行專案的模組化，開發者可以將主要的開發體驗從 Xcode 的 GUI 轉向其他工具。對於那些願意探索 Apple 原生框架之外的領域，跨平台解決方案也提供了一種構建原生感應用程式的開發途徑。最終，目標並非一定要消除 Xcode，策略性地將其整合到一個優先考慮開發者舒適度和效率的工作流程中才是關鍵。

Sources