# Sdk Integration

> 使用 pod-maker 将 SDK Framework 制作为本地私有 Pod，接入目标 iOS 工程并完成依赖安装与构建验证。仅在用户明确要求集成 SDK 时调用。

- Skill: `didi/sdk-integration` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add didi/sdk-integration`
- Raw SKILL.md: https://api.skillmd.com/api/skills/didi/sdk-integration/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: didi (https://skillmd.com/u/didi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/didi/sdk-integration

---


# SDK 集成闭环

把 `pod-maker` 视为制作规则的单一来源，完成“识别 SDK → 制作 Pod → 下载 Framework → `:path` 接入 → 构建验证”的闭环。本 Skill 的完成态是本地私有 Pod 已接入当前工程；Git、Tag 与私有 Specs 发布属于用户另行指定的交付动作。

## 1. 锁定工程、工具和输入

1. 以包含目标 `Podfile` 和 `.xcodeproj` 或 `.xcworkspace` 的目录作为宿主工程根；若存在多个候选，依据用户指定的工程或 Target 选择。选择会改变接入目标时，先向用户确认。
2. 使用 `rg --files` 定位 `pod-maker/makePod.sh`。要求同目录同时存在 `init.sh`、`README.md` 和 `templates/downloadSDK.sh.template`。
3. 完整读取该 `pod-maker` 的 `README.md`、快速接入指南、`makePod.sh` 与下载脚本模板，以当前文件行为为准。
4. 读取宿主 `Podfile`、`Podfile.lock`、工程 Target、最低 iOS 版本和 `git status --short`；保留所有无关改动。
5. 从现有 `pod-maker.json`、SDK 交付文件和工程声明中建立 SDK 清单。每项必须解析出 `podName`、Framework 基础名称、稳定的 HTTPS zip 地址和最低 iOS 版本。下载地址、目标 Target 或 SDK 对应关系无法从工程中确定时，返回 `needs_input` 并只询问缺失值。

完成标准：宿主根、唯一 Pod Maker、目标 Target、配置路径和每个 SDK 的四项必需值均已确定，且待修改文件与用户已有改动已列清。

## 2. 生成并校验制作配置

1. 优先维护 Pod Maker 旁已有的批量 JSON；没有配置时运行 `init.sh <config-path>` 生成模板，再替换全部占位值。
2. 多个 SDK 参数一致时使用 `defaults`；仅把真实差异留在各 `pods[]` 中。将 `outputDirectory` 设为宿主工程内稳定、可用相对路径表达的位置。
3. 使用系统 Ruby 解析 JSON，并逐项检查：Pod 名称唯一、Framework 名称与 zip 内名称对应、URL 使用 HTTPS、最低版本兼容宿主工程、五个 `podLibCreateAnswers` 与当前 CocoaPods 提问顺序一致。
4. 检查输出目录中的同名 Pod。新配置会覆盖已有目录时，先展示影响并取得明确授权；获得授权后才在 `makePod.sh` 的覆盖提示中输入 `y`。

完成标准：JSON 可解析、没有 `PodName*` 或 `example.com` 占位值、SDK 清单逐项对应配置，且所有覆盖动作均已获得授权。

## 3. 制作并准备每个私有 Pod

1. 确认 `pod --version`、`/usr/bin/ruby --version`、`curl --version` 和 `unzip -v` 可运行。
2. 从 Pod Maker 目录执行 `./makePod.sh <config-path>`，记录成功、失败和跳过清单。失败项必须修复或返回 `needs_input`；只有与当前配置一致的既有 Pod 才可接受为跳过项。
3. 对每个 Pod 验证 `<PodName>.podspec`、`pod-config.json`、`downloadSDK.sh` 和 `.gitignore`；确认 podspec 的 `prepare_command`、`vendored_frameworks`、公开头文件、资源路径及最低 iOS 版本都指向同一个 Framework。
4. 因为本流程使用 `:path`，在每个 Pod 根目录执行 `bash downloadSDK.sh`。确认 `Framework/<FrameworkName>.framework/Info.plist`、主二进制和 Headers 存在；SDK 声明包含 bundle 时同时确认资源存在。
5. 让生成 Pod 的 `Framework/` 保持在 `.gitignore` 中；提交状态只包含配置、Pod 包装文件和宿主接入改动。

完成标准：制作汇总没有失败项；每个 SDK 都有结构完整的私有 Pod 和已下载、名称规范化的 Framework。

## 4. 以本地私有 Pod 接入宿主

1. 在正确 Target 中为每个 SDK 添加或更新一条声明：

   ```ruby
   pod 'PodName', :path => 'relative/path/to/generated/PodName'
   ```

   `:path` 指向包含 podspec 的 Pod 根目录，并相对 `Podfile` 解析。沿用该 Target 已有的 `inhibit_warnings`、`modular_headers` 等约定，不凭空增加编译选项。
2. 同名声明已存在时原位更新路径和选项；每个 Target 只保留一条有效声明。保留已有 `source`、`post_install` 和无关依赖。
3. SDK 之间存在显式依赖时，以 SDK 文档、现有 podspec 或链接错误证据为依据补充依赖；所有被当前二进制引用的私有 Pod 必须出现在解析结果中。
4. 在宿主根执行 `pod install`。检查 `Podfile.lock` 中每个私有 Pod 的 `EXTERNAL SOURCES` 均解析到预期本地目录，并确认生成的 workspace 包含 Pods 工程。

完成标准：Podfile 中声明唯一且路径有效，`pod install` 成功，锁文件解析到本次生成的全部私有 Pod。

## 5. 验证真实 Target

1. 使用 `xcodebuild -list` 从生成的 workspace 读取 scheme；选择与目标应用 Target 对应的共享 scheme。
2. 至少执行一次禁用签名的 Debug 构建。优先使用 SDK 支持的模拟器目标；只有 SDK 不包含模拟器架构时改用 generic iOS device，并明确记录该限制。
3. 检查构建日志不存在缺失头文件、未定义符号、Framework 路径或 bundle 资源错误。工程已有 SDK 调用入口时，同时验证对应源码仍能编译。
4. 复查 `git diff` 和 `git status --short`，确认没有改写用户无关文件，也没有把下载的 Framework 加入版本控制。

完成标准：真实应用 Target 构建成功，或返回包含失败命令、首个根因和所需输入的 `needs_input`。`pod install` 成功不能替代 Target 构建成功。

## 6. 交付结果

报告：宿主 Target、Pod Maker 路径、配置路径、生成的 Pod/Framework 清单、Podfile 接入位置、`pod install` 与构建结果、保留的用户改动。仅在上述五个完成标准全部满足时使用状态 `integrated`；其余使用 `needs_input`，不得把“已生成 Pod”表述为“已完成接入”。