Back to Details

axiom-build-debugging

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Build Debugging

构建调试

Overview

概述

Check dependencies BEFORE blaming code. Core principle 80% of persistent build failures are dependency resolution issues (CocoaPods, SPM, framework conflicts), not code bugs.
在质疑代码之前先检查依赖项。核心原则：80%的持续性构建失败是依赖解析问题（CocoaPods、SPM、框架冲突），而非代码bug。

Example Prompts

示例提问

These are real questions developers ask that this skill is designed to answer:
以下是开发者实际会提出的、本技能可解答的问题：

1. "I added a Swift Package but I'm getting 'No such module' errors. The package is in my Xcode project but won't compile."

1. "我添加了一个Swift Package，但出现了‘No such module’错误。该包已在我的Xcode项目中，但无法编译。"

→ The skill covers SPM resolution workflows, package cache clearing, and framework search path diagnostics
→ 本技能涵盖SPM解析工作流、包缓存清理以及框架搜索路径诊断

2. "The build is failing with 'Multiple commands produce' the same output file. How do I figure out which files are duplicated?"

2. "构建失败，提示‘Multiple commands produce’同一输出文件。我该如何找出哪些文件重复了？"

→ The skill shows how to identify duplicate target membership and resolve file conflicts in build settings
→ 本技能展示如何识别重复的目标成员资格并解决构建设置中的文件冲突

3. "CocoaPods installed dependencies successfully but the build still fails. How do I debug CocoaPods issues?"

3. "CocoaPods已成功安装依赖，但构建仍然失败。我该如何调试CocoaPods问题？"

→ The skill covers Podfile.lock conflict resolution, linking errors, and version constraint debugging
→ 本技能涵盖Podfile.lock冲突解决、链接错误以及版本约束调试

4. "My build works on my Mac but fails on the CI server. Both machines have the latest Xcode. What's different?"

4. "我的构建在本地Mac上可以运行，但在CI服务器上失败。两台机器都安装了最新版Xcode。差异在哪里？"

→ The skill explains dependency caching differences, environment-specific paths, and reproducible build strategies
→ 本技能解释依赖缓存差异、环境特定路径以及可复现构建策略

5. "I'm getting framework version conflicts and I don't know which dependency is causing it. How do I resolve this?"

5. "我遇到了框架版本冲突，但不知道是哪个依赖导致的。该如何解决？"

→ The skill demonstrates dependency graph analysis and version constraint resolution strategies for complex dependency trees
→ 本技能演示针对复杂依赖树的依赖图分析和版本约束解决策略

Red Flags — Dependency/Build Issues

预警信号——依赖/构建问题

If you see ANY of these, suspect dependency problem:
  • "No such module" after adding package
  • "Multiple commands produce" same output file
  • Build succeeds on one machine, fails on another
  • CocoaPods install succeeds but build fails
  • SPM resolution takes forever or times out
  • Framework version conflicts in error logs
如果出现以下任何一种情况，请怀疑是依赖问题：
  • 添加包后出现“No such module”错误
  • “Multiple commands produce”同一输出文件
  • 构建在一台机器上成功，在另一台失败
  • CocoaPods安装成功但构建失败
  • SPM解析耗时极久或超时
  • 错误日志中存在框架版本冲突

Quick Decision Tree

快速决策树

Build failing?
├─ "No such module XYZ"?
│  ├─ After adding SPM package?
│  │  └─ Clean build folder + reset package caches
│  ├─ After pod install?
│  │  └─ Check Podfile.lock conflicts
│  └─ Framework not found?
│     └─ Check FRAMEWORK_SEARCH_PATHS
├─ "Multiple commands produce"?
│  └─ Duplicate files in target membership
├─ SPM resolution hangs?
│  └─ Clear package caches + derived data
└─ Version conflicts?
   └─ Use dependency resolution strategies below
Build failing?
├─ "No such module XYZ"?
│  ├─ After adding SPM package?
│  │  └─ Clean build folder + reset package caches
│  ├─ After pod install?
│  │  └─ Check Podfile.lock conflicts
│  └─ Framework not found?
│     └─ Check FRAMEWORK_SEARCH_PATHS
├─ "Multiple commands produce"?
│  └─ Duplicate files in target membership
├─ SPM resolution hangs?
│  └─ Clear package caches + derived data
└─ Version conflicts?
   └─ Use dependency resolution strategies below

Common Build Issues

常见构建问题

Issue 1: SPM Package Not Found

问题1：SPM包未找到

Symptom: "No such module PackageName" after adding Swift Package
❌ WRONG:
bash
undefined
症状：添加Swift Package后出现“No such module PackageName”错误
❌ 错误做法:
bash
undefined

Rebuilding without cleaning

不清理直接重建

xcodebuild build

**✅ CORRECT**:
```bash
xcodebuild build

**✅ 正确做法**:
```bash

Reset package caches first

先重置包缓存

rm -rf ~/Library/Developer/Xcode/DerivedData rm -rf ~/Library/Caches/org.swift.swiftpm
rm -rf ~/Library/Developer/Xcode/DerivedData rm -rf ~/Library/Caches/org.swift.swiftpm

Reset packages in project

重置项目中的包

xcodebuild -resolvePackageDependencies
xcodebuild -resolvePackageDependencies

Clean build

清理并构建

xcodebuild clean build -scheme YourScheme
undefined
xcodebuild clean build -scheme YourScheme
undefined

Issue 2: CocoaPods Conflicts

问题2：CocoaPods冲突

Symptom: Pod install succeeds but build fails with framework errors
Check Podfile.lock:
bash
undefined
症状：Pod安装成功，但构建时出现框架错误
检查Podfile.lock:
bash
undefined

See what versions were actually installed

查看实际安装的版本

cat Podfile.lock | grep -A 2 "PODS:"
cat Podfile.lock | grep -A 2 "PODS:"

Compare with Podfile requirements

与Podfile中的要求对比

cat Podfile | grep "pod "

**Fix version conflicts**:
```ruby
cat Podfile | grep "pod "

**修复版本冲突**:
```ruby

Podfile - be explicit about versions

Podfile - 明确指定版本

pod 'Alamofire', '~> 5.8.0' # Not just 'Alamofire' pod 'SwiftyJSON', '5.0.1' # Exact version if needed

**Clean reinstall**:
```bash
pod 'Alamofire', '~> 5.8.0' # 不要只写'Alamofire' pod 'SwiftyJSON', '5.0.1' # 必要时使用精确版本

**清理重装**:
```bash

Remove all pods

删除所有pods

rm -rf Pods/ rm Podfile.lock
rm -rf Pods/ rm Podfile.lock

Reinstall

重新安装

pod install
pod install

Open workspace (not project!)

打开workspace而非project！

open YourApp.xcworkspace
undefined
open YourApp.xcworkspace
undefined

Issue 3: Multiple Commands Produce Error

问题3：Multiple Commands Produce错误

Symptom: "Multiple commands produce '/path/to/file'"
Cause: Same file added to multiple targets or build phases
Fix:
  1. Open Xcode
  2. Select file in navigator
  3. File Inspector → Target Membership
  4. Uncheck duplicate targets
  5. Or: Build Phases → Copy Bundle Resources → remove duplicates
症状："Multiple commands produce '/path/to/file'"
原因：同一文件被添加到多个目标或构建阶段
修复方法:
  1. 打开Xcode
  2. 在导航器中选择该文件
  3. 文件检查器 → 目标成员资格
  4. 取消勾选重复的目标
  5. 或者：构建阶段 → 复制捆绑资源 → 删除重复项

Issue 4: Framework Search Paths

问题4：框架搜索路径

Symptom: "Framework not found" or "Linker command failed"
Check build settings:
bash
undefined
症状："Framework not found"或"Linker command failed"
检查构建设置:
bash
undefined

Show all build settings

显示所有构建设置

xcodebuild -showBuildSettings -scheme YourScheme | grep FRAMEWORK_SEARCH_PATHS

**Fix in Xcode**:
1. Target → Build Settings
2. Search "Framework Search Paths"
3. Add path: `$(PROJECT_DIR)/Frameworks` (recursive)
4. Or: `$(inherited)` to inherit from project
xcodebuild -showBuildSettings -scheme YourScheme | grep FRAMEWORK_SEARCH_PATHS

**在Xcode中修复**:
1. 目标 → 构建设置
2. 搜索“Framework Search Paths”
3. 添加路径：`$(PROJECT_DIR)/Frameworks`（递归）
4. 或者：使用`$(inherited)`继承项目设置

Issue 5: SPM Version Conflicts

问题5：SPM版本冲突

Symptom: Package resolution fails with version conflicts
See dependency graph:
bash
undefined
症状：包解析因版本冲突失败
查看依赖图:
bash
undefined

In project directory

在项目目录中执行

swift package show-dependencies
swift package show-dependencies

Or see resolved versions

或查看已解析的版本

cat Package.resolved

**Fix conflicts**:
```swift
// Package.swift - be explicit
.package(url: "https://github.com/owner/repo", exact: "1.2.3")  // Exact version
.package(url: "https://github.com/owner/repo", from: "1.2.0")   // Minimum version
.package(url: "https://github.com/owner/repo", .upToNextMajor(from: "1.0.0"))  // SemVer
Reset resolution:
bash
undefined
cat Package.resolved

**修复冲突**:
```swift
// Package.swift - 明确指定
.package(url: "https://github.com/owner/repo", exact: "1.2.3")  // 精确版本
.package(url: "https://github.com/owner/repo", from: "1.2.0")   // 最低版本
.package(url: "https://github.com/owner/repo", .upToNextMajor(from: "1.0.0"))  // 语义化版本
重置解析:
bash
undefined

Clear package caches

清理包缓存

rm -rf .build rm Package.resolved
rm -rf .build rm Package.resolved

Re-resolve

重新解析

swift package resolve
undefined
swift package resolve
undefined

Dependency Resolution Strategies

依赖解析策略

Strategy 1: Lock to Specific Versions

策略1：锁定特定版本

When stability matters more than latest features:
CocoaPods:
ruby
pod 'Alamofire', '5.8.0'      # Exact version
pod 'SwiftyJSON', '~> 5.0.0'  # Any 5.0.x
SPM:
swift
.package(url: "...", exact: "1.2.3")
当稳定性比最新功能更重要时：
CocoaPods:
ruby
pod 'Alamofire', '5.8.0'      // 精确版本
pod 'SwiftyJSON', '~> 5.0.0'  // 任意5.0.x版本
SPM:
swift
.package(url: "...", exact: "1.2.3")

Strategy 2: Use Version Ranges

策略2：使用版本范围

When you want bug fixes but not breaking changes:
CocoaPods:
ruby
pod 'Alamofire', '~> 5.8'     # 5.8.x but not 5.9
pod 'SwiftyJSON', '>= 5.0', '< 6.0'  # Range
SPM:
swift
.package(url: "...", from: "1.2.0")              // 1.2.0 and higher
.package(url: "...", .upToNextMajor(from: "1.0.0"))  // 1.x.x but not 2.0.0
当你需要bug修复但不希望引入破坏性变更时：
CocoaPods:
ruby
pod 'Alamofire', '~> 5.8'     // 5.8.x但不包含5.9
pod 'SwiftyJSON', '>= 5.0', '< 6.0'  // 版本范围
SPM:
swift
.package(url: "...", from: "1.2.0")              // 1.2.0及以上
.package(url: "...", .upToNextMajor(from: "1.0.0"))  // 1.x.x但不包含2.0.0

Strategy 3: Fork and Pin

策略3：Fork并固定版本

When you need custom modifications:
bash
undefined
当你需要自定义修改时：
bash
undefined

Fork repo on GitHub

在GitHub上Fork仓库

Clone your fork

克隆你的Fork版本

git clone https://github.com/yourname/package.git
git clone https://github.com/yourname/package.git

In Package.swift, use your fork

在Package.swift中使用你的Fork版本

.package(url: "https://github.com/yourname/package", branch: "custom-fixes")
undefined
.package(url: "https://github.com/yourname/package", branch: "custom-fixes")
undefined

Strategy 4: Exclude Transitive Dependencies

策略4：排除传递依赖

When a dependency's dependency conflicts:
SPM (not directly supported, use workarounds):
swift
// Instead of this:
.package(url: "https://github.com/problematic/package")

// Fork it and remove the conflicting dependency from its Package.swift
CocoaPods:
ruby
undefined
当某个依赖的子依赖发生冲突时：
SPM（不直接支持，需使用变通方法）:
swift
// 不要这样做：
.package(url: "https://github.com/problematic/package")

// 应该Fork该仓库并从其Package.swift中移除冲突的依赖
CocoaPods:
ruby
undefined

Exclude specific subspecs

排除特定子规格

pod 'Firebase/Core' # Not all of Firebase pod 'Firebase/Analytics'
undefined
pod 'Firebase/Core' // 不使用完整的Firebase pod 'Firebase/Analytics'
undefined

Build Configuration Issues

构建配置问题

Debug vs Release Differences

Debug与Release差异

Symptom: Builds in Debug, fails in Release (or vice versa)
Check optimization settings:
bash
undefined
症状：Debug模式下构建成功，Release模式下失败（反之亦然）
检查优化设置:
bash
undefined

Compare Debug and Release settings

对比Debug和Release设置

xcodebuild -showBuildSettings -configuration Debug > debug.txt xcodebuild -showBuildSettings -configuration Release > release.txt diff debug.txt release.txt

**Common culprits**:
- SWIFT_OPTIMIZATION_LEVEL (-Onone vs -O)
- ENABLE_TESTABILITY (YES in Debug, NO in Release)
- DEBUG preprocessor flag
- Code signing settings
xcodebuild -showBuildSettings -configuration Debug > debug.txt xcodebuild -showBuildSettings -configuration Release > release.txt diff debug.txt release.txt

**常见原因**:
- SWIFT_OPTIMIZATION_LEVEL（-Onone 与 -O）
- ENABLE_TESTABILITY（Debug模式为YES，Release模式为NO）
- DEBUG预处理器标志
- 代码签名设置

Workspace vs Project

Workspace与Project

Always open workspace with CocoaPods:
bash
undefined
使用CocoaPods时始终打开workspace:
bash
undefined

❌ WRONG

❌ 错误做法

open YourApp.xcodeproj
open YourApp.xcodeproj

✅ CORRECT

✅ 正确做法

open YourApp.xcworkspace

**Check which you're building**:
```bash
open YourApp.xcworkspace

**检查当前构建的是哪个文件**:
```bash

For workspace

针对workspace

xcodebuild -workspace YourApp.xcworkspace -scheme YourScheme build
xcodebuild -workspace YourApp.xcworkspace -scheme YourScheme build

For project only (no CocoaPods)

仅针对project（无CocoaPods时）

xcodebuild -project YourApp.xcodeproj -scheme YourScheme build
undefined
xcodebuild -project YourApp.xcodeproj -scheme YourScheme build
undefined

Pressure Scenarios: When to Resist "Quick Fix" Advice

压力场景：何时抵制“快速修复”建议

The Problem

问题背景

Under deadline pressure, senior engineers and teammates provide "quick fixes" based on pattern-matching:
  • "Just regenerate the lock file"
  • "Increment the build number"
  • "Delete DerivedData and rebuild"
These feel safe because they come from experience. But if the diagnosis is wrong, the fix wastes time you don't have.
Critical insight Time pressure makes authority bias STRONGER. You're more likely to trust advice when stressed.
在截止日期压力下，资深工程师和同事会基于模式匹配提供“快速修复”建议：
  • “只需重新生成锁文件”
  • “增加构建编号”
  • “删除DerivedData然后重建”
这些建议看起来安全，因为它们来自经验。但如果诊断错误，修复会浪费你本就紧张的时间。
关键洞察：时间压力会强化权威偏见。当你感到压力时，更可能信任他人的建议。

Red Flags — STOP Before Acting

预警信号——执行前请暂停

If you hear ANY of these, pause 5 minutes before executing:
  • ❌ "This smells like..." (pattern-matching, not diagnosis)
  • ❌ "Just..." (underestimating complexity)
  • ❌ "This usually fixes it" (worked once ≠ works always)
  • ❌ "You have plenty of time" (overconfidence about 24-hour turnaround)
  • ❌ "This is safe" (regenerating lock files CAN break things)
Your brain under pressure Trusts these phrases because they sound confident. Doesn't ask "but do they have evidence THIS is the root cause?"
如果你听到以下任何说法，请先暂停5分钟再执行：
  • ❌ “这看起来像是...”（模式匹配，而非诊断）
  • ❌ “只需...”（低估复杂度）
  • ❌ “这通常能解决问题”（曾经有效≠始终有效）
  • ❌ “你有足够时间”（对24小时周转时间过度自信）
  • ❌ “这很安全”（重新生成锁文件可能会破坏现有配置）
压力下的大脑特点：会信任这些听起来自信的表述，而不会问“但他们有证据证明这是根本原因吗？”

Mandatory Diagnosis Before "Quick Fix"

执行“快速修复”前必须先诊断

When someone senior suggests a fix under time pressure:
当资深人员在时间压力下提出修复建议时：

Step 1: Ask (Don't argue)

步骤1：询问（不要争论）

"I understand the pressure. Before we regenerate lock files,
can we spend 5 minutes comparing the broken build to our
working build? I want to know what we're fixing."
“我理解当前的压力。在重新生成锁文件之前，
我们能否花5分钟对比一下失败的构建和正常的构建？我想明确我们要解决的问题是什么。”

Step 2: Demand Evidence

步骤2：要求提供证据

  • "What makes you think it's a lock file issue?"
  • "What changed between our last successful build and this failure?"
  • "Can we see the actual error from App Store build vs our build?"
  • “你为什么认为这是锁文件的问题？”
  • “上次成功构建和这次失败之间发生了什么变化？”
  • “我们能否对比App Store构建和本地构建的具体错误？”

Step 3: Document the Gamble

步骤3：记录风险

If we try "pod install":
- Time to execute: 10 minutes
- Time to learn it failed: 24 hours (next submission cycle)
- Remaining time if it fails: 6 days
- Alternative: Spend 1-2 hours diagnosing first

Cost of being wrong with quick fix: High
Cost of spending 1 hour on diagnosis: Low
如果我们尝试‘pod install’：
- 执行时间：10分钟
- 得知修复是否失败的时间：24小时（下一次提交周期）
- 修复失败后剩余时间：6天
- 替代方案：先花1-2小时诊断问题

快速修复错误的成本：高
花1小时诊断的成本：低

Step 4: Push Back Professionally

步骤4：专业地提出反对

"I want to move fast too. A 1-hour diagnosis now means we
won't waste another 24-hour cycle. Let's document what we're
testing before we submit."
“我也想快速推进。现在花1小时诊断，能避免我们浪费24小时的迭代时间。在提交之前，我们先记录下要测试的内容吧。”

Why this works

为什么这有效

  • You're not questioning their expertise
  • You're asking for evidence (legitimate request)
  • You're showing you understand the pressure
  • You're making the time math visible
  • 你没有质疑他们的专业能力
  • 你要求的是证据（合理请求）
  • 你表明自己理解当前的压力
  • 你清晰地展示了时间成本对比

Real-World Example: App Store Review Blocker

真实案例：App Store审核受阻

Scenario App rejected in App Store build, passes locally.
Senior says "Regenerate lock file and resubmit (7 days buffer)"
场景：App在App Store构建中被拒绝，但本地构建通过。
资深人员建议：“重新生成锁文件并重新提交（有7天缓冲时间）”

What you do

你的选择

  1. ❌ WRONG: Execute immediately, fail after 24 hours, now 6 days left
  2. ✅ RIGHT: Spend 1 hour comparing builds first
  1. ❌ 错误做法：立即执行，24小时后失败，剩余6天时间
  2. ✅ 正确做法：先花1小时对比构建差异

Comparison checklist

对比清单

Local build that works:
- Pod versions in Podfile.lock: [list them]
- Xcode version: [version]
- Derived Data: [timestamp]
- CocoaPods version: [version]

App Store build that fails:
- Pod versions used: [from error message]
- Build system: [App Store's environment]
- Differences: [explicitly document]
本地正常构建：
- Podfile.lock中的Pod版本：[列出版本]
- Xcode版本：[具体版本]
- Derived Data：[时间戳]
- CocoaPods版本：[具体版本]

App Store失败构建：
- 使用的Pod版本：[来自错误信息]
- 构建系统：[App Store的环境]
- 差异：[明确记录]

After comparison

对比后

  • If versions match: Lock file isn't the issue. Skip the quick fix.
  • If versions differ: Now you understand what to fix.
Time saved 24 hours of wasted iteration.
  • 如果版本一致：锁文件不是问题，跳过快速修复
  • 如果版本不同：现在你知道该修复什么了
节省的时间：24小时的无效迭代

When to Trust Quick Fixes (Rare)

何时可以信任快速修复（罕见情况）

Quick fixes are safe ONLY when:
  • You've seen this EXACT error before (not "similar")
  • You know the root cause (not "this usually works")
  • You can reproduce it locally (so you know if fix worked)
  • You have >48 hours buffer (so failure costs less)
  • You documented the fix in case you need to explain it later
只有满足以下所有条件时，快速修复才是安全的：
  • 你之前见过完全相同的错误（不是“类似”）
  • 你知道根本原因（不是“这通常有效”）
  • 你可以在本地复现该错误（这样你能知道修复是否有效）
  • 你有超过48小时的缓冲时间（这样失败的成本更低）
  • 你记录了修复内容，以便后续需要解释

In production crises, NONE of these are usually true.

在生产危机中，这些条件通常都不满足。

Testing Checklist

测试清单

When Adding Dependencies

添加依赖时

  • Specify exact versions or ranges (not just latest)
  • Check for known conflicts with existing deps
  • Test clean build after adding
  • Commit lockfile (Podfile.lock or Package.resolved)
  • 指定精确版本或版本范围（不只是最新版）
  • 检查与现有依赖的已知冲突
  • 添加后测试清理构建
  • 提交锁文件（Podfile.lock或Package.resolved）

When Builds Fail

构建失败时

  • Run mandatory environment checks (xcode-debugging skill)
  • Check dependency lockfiles for changes
  • Verify using correct workspace/project file
  • Compare working vs broken build settings
  • 执行强制环境检查（xcode-debugging技能）
  • 检查依赖锁文件的变更
  • 验证使用了正确的workspace/project文件
  • 对比正常构建与失败构建的设置

Before Shipping

发布前

  • Test both Debug and Release builds
  • Verify all dependencies have compatible licenses
  • Check binary size impact of dependencies
  • Test on clean machine or CI
  • 测试Debug和Release两种构建
  • 验证所有依赖的许可证兼容
  • 检查依赖对二进制包大小的影响
  • 在干净的机器或CI上测试

Common Mistakes

常见错误

❌ Not Committing Lockfiles

❌ 不提交锁文件

bash
undefined
bash
undefined

❌ BAD: .gitignore includes lockfiles

❌ 错误做法：.gitignore包含锁文件

Podfile.lock Package.resolved

**Why**: Team members get different versions, builds differ
Podfile.lock Package.resolved

**原因**：团队成员会安装不同版本的依赖，导致构建结果不一致

❌ Using "Latest" Version

❌ 使用“最新”版本

ruby
undefined
ruby
undefined

❌ BAD: No version specified

❌ 错误做法：不指定版本

pod 'Alamofire'

**Why**: Breaking changes when dependency updates
pod 'Alamofire'

**原因**：依赖更新时可能引入破坏性变更

❌ Mixing Package Managers

❌ 混合使用包管理器

Project uses both:
- CocoaPods (Podfile)
- Carthage (Cartfile)
- SPM (Package.swift)
Why: Conflicts are inevitable, pick one primary manager
项目同时使用：
- CocoaPods（Podfile）
- Carthage（Cartfile）
- SPM（Package.swift）
原因：不可避免会出现冲突，请选择一个主要的包管理器

❌ Not Cleaning After Dependency Changes

❌ 依赖变更后不清理构建

bash
undefined
bash
undefined

❌ BAD: Just rebuild

❌ 错误做法：直接重建

xcodebuild build
xcodebuild build

✅ GOOD: Clean first

✅ 正确做法：先清理

xcodebuild clean build
undefined
xcodebuild clean build
undefined

❌ Opening Project Instead of Workspace

❌ 打开Project而非Workspace

When using CocoaPods, always open .xcworkspace not .xcodeproj
使用CocoaPods时，请始终打开.xcworkspace而非.xcodeproj

Command Reference

命令参考

bash
undefined
bash
undefined

CocoaPods

CocoaPods

pod install # Install dependencies pod update # Update to latest versions pod update PodName # Update specific pod pod outdated # Check for updates pod deintegrate # Remove CocoaPods from project
pod install # 安装依赖 pod update # 更新到最新版本 pod update PodName # 更新特定pod pod outdated # 检查可更新的依赖 pod deintegrate # 从项目中移除CocoaPods

Swift Package Manager

Swift Package Manager

swift package resolve # Resolve dependencies swift package update # Update dependencies swift package show-dependencies # Show dependency tree swift package reset # Reset package cache xcodebuild -resolvePackageDependencies # Xcode's SPM resolve
swift package resolve # 解析依赖 swift package update # 更新依赖 swift package show-dependencies # 显示依赖树 swift package reset # 重置包缓存 xcodebuild -resolvePackageDependencies # Xcode的SPM解析命令

Carthage

Carthage

carthage update # Update dependencies carthage bootstrap # Download pre-built frameworks carthage build --platform iOS # Build for specific platform
carthage update # 更新依赖 carthage bootstrap # 下载预构建框架 carthage build --platform iOS # 为特定平台构建

Xcode Build

Xcode Build

xcodebuild clean # Clean build folder xcodebuild -list # List schemes and targets xcodebuild -showBuildSettings # Show all build settings
undefined
xcodebuild clean # 清理构建文件夹 xcodebuild -list # 列出scheme和目标 xcodebuild -showBuildSettings # 显示所有构建设置
undefined

Real-World Impact

实际效果

Before (trial-and-error with dependencies):
  • Dependency issue: 2-4 hours debugging
  • Clean builds not run consistently
  • Version conflicts surprise team
  • CI failures from dependency mismatches
After (systematic dependency management):
  • Dependency issue: 15-30 minutes (check lockfile → resolve)
  • Clean builds mandatory after dep changes
  • Explicit version constraints prevent surprises
  • CI matches local builds (committed lockfiles)
Key insight Lock down dependency versions early. Flexibility causes more problems than it solves.
之前（依赖调试全凭试错）：
  • 依赖问题：2-4小时调试
  • 清理构建未被一致执行
  • 版本冲突让团队措手不及
  • 依赖不匹配导致CI失败
之后（系统化依赖管理）：
  • 依赖问题：15-30分钟（检查锁文件→解决）
  • 依赖变更后必须执行清理构建
  • 明确的版本约束避免意外
  • CI构建与本地构建一致（提交了锁文件）
关键洞察：尽早锁定依赖版本。灵活性带来的问题比它解决的问题更多。

Resources

资源

Docs: swift.org/package-manager, /xcode/build-system
GitHub: Carthage/Carthage
Skills: axiom-xcode-debugging
History: See git log for changes
文档：swift.org/package-manager, /xcode/build-system
GitHub：Carthage/Carthage
相关技能：axiom-xcode-debugging
历史记录：查看git log获取变更信息