1. Swift 开发 IDE 选型先想清楚这几件事做 Swift 开发这几年我被问得最多的问题之一就是你平时用什么 IDEVS Code 能不能写 SwiftAppCode 还值得用吗每次听到这种问题我都想先反问一句你主要在哪个平台上写 Swift、你的项目形态是什么、你更在意的是开箱即用还是高度可定制。因为 Swift 这门语言有个特点它不像 Java 那样有一套标准 IDE的共识也不像前端那样围绕 VS Code 形成统一生态。它的官方工具链、包管理机制和不同平台的支持度决定了 IDE 选型必须结合实际场景来判断。这篇文章不是要告诉你必须用 Xcode或者赶紧换 VS Code而是把我这些年实际用过、踩过坑、最后沉淀下来的一套选型和工作流经验整理出来。适合刚接触 Swift 的初学者也适合在 Apple 平台之外做 Swift 服务端或跨平台开发的人。我会把每个工具的优势、短板、关键配置和常见坑都讲清楚你照着抄就能少走很多弯路。1.1 为什么 IDE 选型会直接影响开发效率Swift 是一门强类型、协议导向、编译期检查非常严格的语言这就意味着编辑器对类型推断、泛型约束、协议遵循关系的解析能力会直接决定你的开发体验。好的 IDE 能在你敲下半个方法名时就给出精准补全能在你重构一个协议时自动联动所有实现能在你写错类型时立刻用红色波浪线提醒你。差的工具链在这些环节上卡你一下一天下来浪费的时间是非常可观的。举一个很直观的例子SwiftUI 开发中有个核心体验叫 Preview实时预览。你在 Xcode 里改一个视图的 padding几乎可以实时看到界面变化这种反馈循环对 UI 开发至关重要。但在 VS Code 里虽然也能编译运行 SwiftUI 项目Preview 却没有官方支持你只能借助第三方工具或者直接跑模拟器。所以如果你的主要工作就是写 iOS/macOS 的 SwiftUI 界面Xcode 几乎是绕不开的底座。反过来如果你写的是 Swift 服务端框架比如 Vapor或者在做跨平台的命令行工具那 Xcode 那套重量级的项目文件和管理方式反而会成为负担。IDE 选型本质上是在深度集成和灵活轻量之间做取舍。Xcode 深度绑定 Apple 生态但跨平台能力和可扩展性一般VS Code 靠插件生态打天下适配 Swift 的体验也在快速追赶AppCode 曾经是 JetBrains 家族里最接近智能 IDE标准的 Swift 工具但维护节奏放缓之后选它的人就越来越少了。没有完美的工具只有适合你当前工作流的工具。1.2 按场景选 IDE 的参考框架我一般把 Swift 开发者分成三类每一类我都会给出完全不同的 IDE 建议第一类主力做 iOS、iPadOS、macOS 等 Apple 平台应用开发的人。这类人我基本不劝直接 Xcode没有悬念。因为 App Store 提审、签名、真机调试、Profile 分析、SwiftUI Preview、Core Data 模型设计这些环节只有 Xcode 是端到端全部覆盖的。你当然可以在外部编辑器里写代码但最终你还是要回到 Xcode 来做签名、打包和提交与其来回切不如直接在里面干活。第二类做 Swift 服务端比如 Vapor、命令行工具、脚本或者用 Swift 做跨平台底层库的人。这类人我强烈建议试试 VS Code配合官方的 Swift 插件和 SourceKit-LSP体验已经非常接近主流语言了。VS Code 的跨平台属性、丰富的 Git 集成和终端体验对服务端开发特别友好。我在 Linux 上写 Vapor 服务时整个流程完全不需要 Xcode。第三类纯粹出于学习目的、或者在学校里写 Swift 作业的人。我也会推荐 VS Code因为它安装轻、上手快而且不会像 Xcode 那样动辄十几个 GB 的下载量吓跑新手。等真正要发布 App 了再切换去熟悉 Xcode 也不迟。下面这张表是我基于实际使用感受整理的选型速查你可以对照自己的情况快速判断使用场景推荐 IDE理由iOS/macOS 应用开发Xcode官方工具链、签名打包、Preview 全流程覆盖Swift 服务端 / 命令行VS Code轻量、跨平台、终端与 Git 集成好大型混合语言项目AppCode存量JetBrains 系重构能力出色但需注意兼容与维护状态学习 Swift 语法VS Code / Playgrounds安装快、零负担随写随跑离开 Xcode 写 UI暂无完美方案建议仍以 Xcode 为主这个框架不是死的我自己就见过在 Xcode 里写服务端、在 VS Code 里维护 iOS 项目的人每种组合都有它的道理。但如果你还没有形成自己的习惯按照这个框架入门是最省力的。2. 主流 IDE 横向对比Xcode、AppCode 与 VS Code聊完选型思路我们逐个看看目前主流的几个 Swift 开发 IDE 到底能干什么、不能干什么。我尽量说一些官方文档里不会写、但实际开发中一定会遇到的细节。2.1 Xcode官方工具绕不开的底座Xcode 是 Apple 官方的集成开发环境也是 Swift 这门语言真正的娘家。它的优势不在于某个单一功能而在于整个 Apple 开发流程的深度绑定。你用 Xcode 打开一个 iOS 工程从创建项目、配置签名、连接真机、运行调试、性能分析到最终归档上传 App Store Connect全部可以在一个窗口里完成。这种端到端的完整度目前没有任何其他工具能替代。Xcode 里最值得说道的功能是 SwiftUI Preview 和 Instrument。SwiftUI Preview 让你在写界面时不用每次跑到模拟器里看效果代码改完即时渲染配合实时预览还能调试不同尺寸和深色模式下的布局。Instrument 则是性能分析神器内存泄漏、CPU 峰值、网络请求耗时它都能以非常直观的时间线呈现。我第一次用 Instrument 定位到一个循环引用导致的内存持续增长问题时真是有一种原来如此的爽感。但 Xcode 的短板也很明显。首先是体积巨大完整安装需要十几个 GB对硬盘空间和网络带宽都是个考验。其次是它只支持 macOSWindows 和 Linux 用户完全没有办法用它。再者Xcode 的代码编辑体验其实不算顶级代码补全偶尔抽风索引构建在大项目里经常让人等到崩溃快捷键体系也比较封闭不像 VS Code 那样随便改。另外Xcode 自带的模拟器资源占用很高老款 Mac 跑起来风扇呼呼转。提示如果你用的是 MacXcode 安装后别忘了执行sudo xcode-select -s /Applications/Xcode.app来确保命令行工具指向正确的 Xcode 路径。这个设置不对swift、xcodebuild等命令经常会报SDK not found。2.2 AppCodeJetBrains 系的老牌选手AppCode 是 JetBrains 出品的 Objective-C / Swift IDE继承了 IntelliJ 家族强大的代码分析能力。如果你是从 Android Studio 或者 IntelliJ IDEA 转过来的AppCode 的界面和快捷键会让你倍感亲切。它的重构功能特别出色比如重命名一个方法它能精确识别所有调用点包括字符串形式的 selector而快速修复、代码检查、VCS 集成这些体验也确实比 Xcode 顺手。但我必须提醒一句JetBrains 官方已经在 2023 年宣布 AppCode 停止功能更新只做基本的兼容性维护。这意味它不会跟随每年新版 Xcode 的工具链做深度适配SwiftUI 的新特性支持也会逐渐滞后。你现在依然可以用它写 Swift 代码但如果你想用最新的 SDK 或 Swift 版本开发大概率会遇到定义跳转失效、代码补全缺漏这类问题。在我的实际体验里AppCode 更适合那种已经被 JetBrains 系工具彻底驯化的开发者。比如你同时要写 Swift 和 Kotlin Multiplatform 的共享逻辑AppCode 可以和 Android Studio 保持几乎一致的快捷键和操作习惯切换成本为零。但如果你是新入行的 Swift 开发者我建议还是别在 AppCode 上投入太多学习成本因为它的未来不明朗而 Xcode 和 VS Code 的生态都在肉眼可见地变好。2.3 VS Code轻量、灵活的新势力VS Code 其实不是传统意义上的IDE它是个编辑器但靠着插件生态硬生生把自己变成了事实上的全语言开发平台。在 Swift 领域微软和 Swift 官方社区合作维护的 Swift 插件已经相当成熟底层通过 SourceKit-LSP 实现语言服务。你用 VS Code 打开一个 SwiftPM 包代码补全、定义跳转、语法诊断、重构等核心功能都能正常工作体验已经接近 Xcode 的八成水平。VS Code 的优势是轻量、跨平台、可定制性强。在 macOS、Windows、Linux 上体验完全一致你不需要为了写 Swift 单独准备一台 Mac。它的终端集成和 Git 面板用起来非常顺滑配合command \ 随时呼出终端跑swift build或swift test整个反馈循环非常流畅。而且它启动速度快打开一个大型服务端项目也不会像 Xcode 那样索引半天。短板方面最明显的是没有官方的 SwiftUI Preview 支持。你可以在 VS Code 里写 SwiftUI 代码但想实时看界面就得自己跑模拟器或者借助一些第三方方案比如注入代码热重载。另外真机调试和签名相关的操作在 VS Code 里基本做不了这部分还是得回到 Xcode。所以我的结论是VS Code 非常适合 Swift 服务端、跨平台库和日常脚本但纯 iOS 应用开发建议还是以 Xcode 为主。2.4 其他选择CodeEdit、Neovim 等除了上面三个主流工具还有一些小众选项也值得知道。CodeEdit 是一个开源的 macOS 原生编辑器目标是做开源的 Xcode 替代品界面和操作逻辑都模仿 Xcode但目前还在比较早期的阶段插件生态和稳定性都有限适合尝鲜不适合作为日常工作主力。Neovim 则是另一类极端——如果你已经完全习惯了 Vim 的编辑模式配好 Swift 的 LSP 客户端后写 Swift 也能达到相当高的效率。我自己在写快速脚本时偶尔会直接在终端里用 Neovim 改文件因为不需要等待图形界面启动。但这类方案的学习曲线很陡峭不是所有人都能接受。我的建议是除非你本来就是 Vim 重度用户否则不要为了写 Swift 专门去折腾 Neovim。3. 从零搭建 Swift 开发环境以 VS Code 为例既然前面提到 VS Code 在跨平台和轻量场景里表现不错这里我就以它为例完整演示一遍从零搭建一个 Swift 开发环境的过程。这套流程我在 macOS 和 Linux 上都验证过Windows 上通过 Swift 官方安装包也能跑通只是个别路径会有差异。3.1 安装 Swift 工具链与依赖Swift 本身是开源语言官方提供了 macOS、Linux 和 Windows 的独立工具链安装包。如果你用的是 Mac我建议直接安装完整版 Xcode因为其中自带 Swift 编译器、LLDB 调试器和模拟器等全套工具。安装完 Xcode 后命令行里执行swift --version应该能看到类似这样的输出swift-driver version: 1.90.11 Apple Swift version 5.10 Target: arm64-apple-macosx14.0如果你在 Linux 上需要先安装一些依赖库然后从 swift.org 下载对应发行版的工具链压缩包解压后把路径写进环境变量。以 Ubuntu 为例大致步骤如下# 安装依赖 sudo apt-get install -y clang libicu-dev libcurl4-openssl-dev libssl-dev python3 # 解压工具链到指定目录 tar -xzf swift-5.10-RELEASE-ubuntu22.04.tar.gz -C /opt # 配置环境变量 export PATH/opt/swift-5.10-RELEASE-ubuntu22.04/usr/bin:$PATH export LD_LIBRARY_PATH/opt/swift-5.10-RELEASE-ubuntu22.04/usr/lib:$LD_LIBRARY_PATH # 验证 swift --version这里有一点想提醒大家Windows 上虽然 Swift 也能跑但官方支持的模块和第三方库数量比 Linux 少而且文件路径处理要特别注意大小写问题。如果你只是学习语法Windows 够用如果你想跑比较重的服务端框架建议还是用 Linux 或 macOS。3.2 VS Code 插件组合与配置工具链就绪后在 VS Code 里装四个核心插件基本就够了Swift官方扩展提供语言服务、调试配置生成、测试发现等能力CodeLLDB基于 LLDB 的调试器支持断点、变量查看和表达式求值SwiftFormat代码格式化保存时自动整理代码风格SwiftLint代码规范检查实时提示潜在问题和风格违规装完后建议再微调一下settings.json让体验更贴近实际需求{ editor.formatOnSave: true, swift.sourcekit-lsp.serverArguments: [--experimental-rename], debug.console.collapseIdenticalLines: false, files.exclude: { .build/: true }, swift.backgroundCompilation: true }这里重点解释几个配置项sourcekit-lsp.serverArguments里的--experimental-rename开启重命名重构能力能显著提升跨文件的符号重命名体验files.exclude把.build目录隐藏起来避免文件树被编译产物刷屏swift.backgroundCompilation让语言服务在后台持续编译可以更早暴露类型错误但也更吃 CPU老机器上建议关掉。调试配置这块只需要在launch.json里添加一个 Swift 可执行文件的调试目标CodeLLDB 插件会自动识别{ version: 0.2.0, configurations: [ { type: lldb, request: launch, name: Debug Swift, program: ${workspaceFolder}/.build/debug/MyExecutable, args: [], cwd: ${workspaceFolder} } ] }program路径要指向实际编译产物名字以package.swift里的可执行 target 为准。如果你要调试的是测试代码直接把program改成测试运行器路径或者用 VS Code 的测试面板直接点击调试测试用例。3.3 创建第一个 SwiftPM 工程一切就绪后我们创建一个全新的 SwiftPM 工程。在终端里执行mkdir MySwiftProject cd MySwiftProject swift package init --type executable swift runswift package init会根据--type参数生成不同的模板可执行程序是executable纯库是library测试代码则写在Tests目录下。生成后的目录结构大致如下MySwiftProject ├── Package.swift ├── Sources │ └── main.swift └── Tests打开Package.swift可以看到依赖声明文件它有点像一个项目说明书所有第三方库依赖都写在这里。比如我们要引入一个 JSON 解析库 SwiftyJSON只需要在dependencies和target里各加一段// swift-tools-version:5.9 import PackageDescription let package Package( name: MySwiftProject, dependencies: [ .package(url: https://github.com/SwiftyJSON/SwiftyJSON.git, from: 5.0.0) ], targets: [ .executableTarget( name: MySwiftProject, dependencies: [SwiftyJSON] ) ] )保存后再执行swift buildSwiftPM 会自动拉取依赖并编译。整个过程很干净不像 CocoaPods 那样需要额外安装 gem、生成 workspaces。这也是我特别推荐在跨平台项目上用 SwiftPM 的原因——它本身就是 Swift 官方的东西。4. 让 Swift 开发更顺手的库与工具链IDE 只是外壳真正让开发效率拉满的往往是那些围绕语言生态的工具链。这里我想重点聊三块代码生成、代码规范、依赖管理。这几样东西在热搜词里被反复提及比如 swiftgen 类似的 swift 库确实也是很多 Swift 开发者从入门到进阶时容易忽略的部分。4.1 代码生成帮手swiftgen 与同类库在 Swift 项目里图片资源、本地化字符串、字体、颜色这些资源在代码中使用时需要手动写常量字符串或类型名。比如UIImage(named: home_icon_selected)一旦资源名写错编译并不会报错运行时才会闪退。swiftgen 这一类代码生成工具解决的就是这个问题它扫描项目资源自动生成类型安全的访问代码让资源名变得可编译检查、可自动补全。swiftgen 是其中最出名的一个。它支持 Assets、Strings、Fonts、IB 等常见资源类型配置文件swiftgen.yml长这样input_dir: MyApp/Resources output_dir: MyApp/Sources/Generated xcassets: - inputs: - Assets.xcassets outputs: - templateName: swift5 output: Assets.generated.swift strings: - inputs: - Localizable.strings outputs: - templateName: structured-swift5 output: Strings.generated.swift配置完成后执行swiftgen命令就会生成Assets.generated.swift和Strings.generated.swift。之后代码里访问图片就变成了let image Asset.homeIconSelected.image let title L10n.Common.okButton这样的好处非常明显资源名错了编译直接报错重命名资源时只要重新生成代码所有引用点都会同步更新或报错提示不会再出现线上闪退才发现本地化 key 写错的尴尬。如果你觉得 swiftgen 的模板机制不够灵活还有几个同类库值得看看R.swift 的用法是给 image 等资源生成类似R.image.homeIconSelected()的访问方式集成方式偏 CocoaPodsSourcery 则更通用它通过扫描你的 Swift 源码来生成模板代码可以自动生成 Equatable、JSON 转换等样板代码。几个工具的核心思路都是从手工维护常量变成自动生成代码思想上是一致的。注意代码生成类工具生成的.generated.swift文件建议全部加入.gitignore或标注为只读不要手改。因为每次执行生成命令都会覆盖这些文件手改的内容会直接消失。我见过几次团队成员改了生成文件导致合并冲突的案例挺折腾的。4.2 代码规范与格式化SwiftLint、SwiftFormat团队开发时代码风格不统一是非常磨人的事。有人喜欢用self有人不喜欢有人缩进用两个空格有人用四个。这种事靠 Code Review 去人肉纠正效率太低正确做法是引入自动化工具。SwiftLint 是目前社区最主流的 Swift 代码规范检查工具它内置了大量规则默认配置已经能覆盖大多数常见问题。安装后可以写一个简单的.swiftlint.yml放到项目根目录disabled_rules: - trailing_whitespace - line_length excluded: - Pods - .build - Sources/Generated配置好之后在 CI 流程里加一条命令swiftlint lint --strict只要代码里有不符合规则的写法构建就会失败从源头上保证代码风格统一。SwiftFormat 则负责代码格式化和 SwiftLint 定位不一样。SwiftLint 是发现问题SwiftFormat 是自动改问题。在 VS Code 里装好 SwiftFormat 插件后我设置了保存时自动格式化从此再没有手工排过缩进。和它配合使用时我会在 SwiftFormat 配置里把某些规则和 SwiftLint 对齐避免两个工具互相打架。4.3 依赖管理SPM 与 CocoaPods 的取舍Swift 生态里现在有两套主要的依赖管理工具Swift Package ManagerSPM和 CocoaPods。SPM 是 Swift 官方出品从 Swift 3 开始逐步成熟到 Swift 5.9 以后已经可以比较顺滑地支持很多第三方库。CocoaPods 是老牌工具在 iOS 生态里有庞大的历史存量库。我的选型原则很简单新项目一律用 SPM老项目除非有必须用 CocoaPods 的库否则能迁就迁。表格对比如下维度SPMCocoaPods官方性Swift 官方集成无需额外安装独立工具需安装 Ruby Gem与 Xcode 集成原生支持打开工程自动解析需要生成.xcworkspace跨平台支持macOS / Linux / Windows 通用主要面向 Apple 平台二进制库支持通过 binaryTarget 支持通过预编译 framework 支持对项目结构侵入性低按 package 组织高需要 Podfile 管理SPM 唯一的短板是某些老库还没有提供 Package 支持这种情况你可以在 SPM 里通过.package(url:from:)直接指定 Git 仓库地址如果库本身没声明 Package.swift就还是得回去用 CocoaPods。我见过一个折中的做法主项目用 SPM某个必需的老库单独用 CocoaPods 引入但这种方式会带来两个依赖系统并存的管理复杂度非必要不建议这么搞。5. 常见问题与排查技巧实录工具链越复杂坑就越多。这一节我把自己和身边同事在实际开发中遇到过的典型问题整理出来每个都附上排查思路和解决方案。这些内容在官方文档里基本找不到但你真的会遇到。5.1 工具链找不到或版本不匹配有一个很典型的报错场景你在 VS Code 里写 Swift突然提示类似cannot determine path to tools.jar library for 17 (d:/app/java/jdk-17) ide的信息。这里要澄清一下这个报错其实不是 Swift 工具链的问题它通常是因为你的 IDE 环境同时集成了 Java 相关插件比如某些代码生成或语法检查插件依赖 JDK而插件配置里写死了 JDK 路径。和 Swift 本身没有关系。出现这种情况时你应该先检查 IDE 里 Java 插件的路径配置而不是去折腾 Swift 工具链。真正跟 Swift 相关的工具链问题更多是这种终端里执行swift能正常运行但 IDE 里编译报错unable to find sdk。这往往是因为xcode-select指向了错误的开发者目录。排查步骤是# 查看当前指向 xcode-select -p # 如果指向不对重新选择 sudo xcode-select -s /Applications/Xcode.app # 打印 SDK 路径确认 xcrun --show-sdk-path在 Linux 上则是 PATH 环境变量的问题。比如你明明把 Swift 安装到了/opt/swift但执行swift --version显示的还是旧版本一般是 PATH 顺序不对。把 Swift 的bin目录放在 PATH 最前面再用which swift确认一下就解决了。5.2 索引失效、代码跳转失灵VS Code 里用 SourceKit-LSP 写 Swift最烦的问题之一就是定义跳转失灵。你按F12想跳到某个方法的定义结果编辑器像没听见一样毫无反应。这种情况九成是语言服务的索引缓存坏了。我的处理流程是先打开命令面板CtrlShiftP或CmdShiftP执行Swift: Restart Language Server看看能不能恢复如果不行就删除项目根目录下的.build文件夹里和索引相关的缓存再重新执行swift build。有时候直接删整个.build反而更快代价只是需要重新编译所有依赖多花一两分钟而已。另一个技巧是检查sourcekit-lsp进程是否还在运行。有些时候 IDE 里莫名其妙补全变慢是因为后台进程崩溃了但界面没有提示。在终端里执行ps aux | grep sourcekit-lsp如果找不到进程重启 VS Code 基本能解决。5.3 真机调试与签名问题在 Xcode 里连接真机调试是比较常见的需求但新人在签名问题上卡住的比例非常高。最常见的一种是Failed to register bundle identifier或者Could not find developer disk image。前者往往是因为你的 Apple ID 没有对应的 App ID 权限或者 Bundle Identifier 和已有应用冲突解决办法是在 Signing Capabilities 面板里换一个不冲突的 ID并确认登录的开发团队正确。后者Could not find developer disk image通常出现在 Xcode 版本太老、而手机系统版本太新的情况。比如你还在用 Xcode 14但手机已经升级到 iOS 17Xcode 里没有对应的 Device Support 文件。这类问题的核心思路是让 Xcode 版本跟上系统版本或者手动下载匹配的开发者镜像文件放到 Xcode 的 DeviceSupport 目录。说实话每次看到这种报错我都劝人直接升级 Xcode一劳永逸。提示签名问题排查时先看 Xcode 右上角的 Team 是否已经选择再看 Signing Certificate 状态是否是正常的。很多时候只是你忘记在终端里执行sudo xcodebuild -license accept接受了许可协议导致 keychain 访问权限异常。5.4 热重载与预览不可用在 Xcode 里用 SwiftUI Preview 习惯之后切到 VS Code 写 UI 会觉得特别难受因为 VS Code 官方没有预览支持。这里分享两个我当时试过的方案。一个是 Inject 相关方案思路是为项目注入一个动态替换代码的机制你在模拟器里运行时修改某个 view保存后界面会自动刷新。优点是不用重新起模拟器缺点是需要对项目做一些额外配置而且并不是所有代码都能热替换比如修改了结构体定义时经常会失效。另一个更朴素的方案是我现在用得最多的在 VS Code 里写好代码然后用swift run在终端里跑起来配合模拟器或者直接在终端里看输出。从工程角度来说这种方式最稳定只是缺少实时的 UI 反馈。如果你专注 SwiftUI 界面开发我的建议依然是话说在前面直接用 Xcode别在两个工具之间反复横跳。6. 我日常使用的 IDE 工作流和一些个人体会写了这么多工具、配置和排错方法最后分享一点我个人的工作流和体会。很多人把 IDE 选型当作站队问题好像选了 Xcode 就不能用 VS Code用了 VS Code 就是看不起 Xcode。我的实际做法完全不是这样。我做 iOS 应用时主力是 Xcode。写 SwiftUI 界面、调预览、跑模拟器、连真机、看性能日志这套流程在 Xcode 里确实最顺畅。但遇到单纯改业务逻辑、重构一段比较庞大的服务端代码时我会把项目目录直接拖到 VS Code 里用它的多光标编辑、更好的 Git 面板和快速文件切换来处理效率会高很多。两个工具针对不同环节各取所长不冲突。做 Swift 服务端项目时我则几乎完全待在 VS Code 里。在 Linux 服务器上写 Vapor 接口用 SwiftFormat 在保存时做格式化用插件里的测试面板一键跑单测在集成终端里直接翻阅日志整条链路非常流畅。每当这时候我都会感慨Swift 真的已经不再只是iOS 的那门语言了它的工具链生态正在支撑起更广阔的场景。最后再分享一个小技巧无论你用哪个 IDE都值得花半小时把快捷键过一遍尤其是重命名符号跳转到定义快速打开文件切换终端这几个高频动作。IDE 真正的效率瓶颈从来不是某个高大上的功能而是你每天要做几百次的那些小操作。这些操作顺手了一天的开发节奏会舒服非常多。写这篇文章的时候我特意把当年刚学 Swift 时踩过的坑都翻出来回忆了一遍。从在 Windows 上折腾虚拟机跑 macOS到第一次在 VS Code 里跑通 SwiftPM 项目的兴奋再到后来被 Xcode 签名问题折磨到怀疑人生——这些经历让我深刻体会到工具永远只是手段搞清楚自己的需求、用对工具才是效率的关键。希望这篇东西能帮你少走几步弯路。
