Xcode 26.3 调试 iOS 27：从设备元数据报错到 GUI Run

封面为技术示意图，非实际运行截图。

升级 macOS 之前，使用 Xcode 26.3 对运行 iOS 27 的手机进行真机调试没有问题。升级到 macOS 27 后，同一台手机、相同手机系统下，真机调试却无法继续。设备仍能出现在 Xcode 中，但运行目标旁一直显示：

text 复制代码

Device doesn't have sufficient metadata to manage its symbols

最初排查的是 DeviceSupport，后面实际处理了三个问题：设备架构元数据、系统符号提取组件，以及 LLDB 加载符号时的兼容问题。处理后，原路径的补丁版 Xcode 26.3 已经完成 GUI Run、源码断点、单步和简单的 Objective-C 表达式求值。

同一台 Mac 还承担 Jenkins 打包，因此又把兼容修改迁到了独立 Xcode 副本。下文按最终布局介绍处理过程。

这是一份截至 2026 年 10 月的本机排障记录，涉及 Xcode 内部配置，适用范围以本文列出的版本和验证结果为限。文中的工程名、用户名和业务信息均已替换为通用示例。

当时的环境与三个阻塞

项目	本次环境
Mac 系统	macOS 27.0
调试工具	Xcode 26.3，构建号 17C529
工程使用的真机 SDK	iPhoneOS 26.2
手机系统	iOS 27.0.1，构建号 24A446
新版组件来源	本机安装的 Xcode 27.1 RC
原生代码	Objective-C、UIKit
调试器	Xcode 26.3 自带的 LLDB，版本 1703.0.236.103

后续出现的错误分别对应不同阶段：

阶段	本次观察	对应处理
设备元数据	GUI 提示符号管理所需的元数据不足	在 GUI 插件缓存中补入 `arm64e.x1`
系统符号提取	继续准备时出现 Code 908	更新副本内的 `dsc_extractor.bundle`
调试器附加	LLDB RPC 进程崩溃，栈涉及符号预加载和符号附带脚本	对指定副本关闭两项 LLDB 设置

表中的处理是本次排查得到的对应关系。相同的界面提示可能有其他原因，不能只看到错误文本就套用全部修改。

图 1：三个阻塞的排查顺序，处理项按最终副本布局归纳。

另外，Xcode 顶部的 Preparing Editor Functionality 描述的是编辑器准备状态，单凭这行文字无法判断手机调试环境是否就绪。本次采用的判断依据是设备错误是否消失、符号准备是否继续，以及实际能否附加调试器。

先把调试副本与 CI 工具链分开

最终保留了两套用途明确的安装：

text 复制代码

/Applications/Xcode-26.3.0.app
    Jenkins 使用的原安装

~/Library/Developer/Xcode-iOS27-Debug/
    Xcode-26.3.0.app
    Caches/
    start-xcode-debug.command

副本拥有自己的插件缓存。LLDB 初始化文件也检查实际加载路径，只有从副本加载的指定版本才应用兼容设置。

图 2：最终隔离布局，涵盖工具链入口、缓存和 LLDB 设置的生效范围。

如果从头实施，可以先准备一份来自 Apple、能够通过完整性校验的 Xcode 26.3，再建立副本。下面是同一 APFS 卷上的克隆示例，需要根据本机安装位置调整 clean_source，目标目录应当尚不存在：

sh 复制代码

set -e

clean_source="/Applications/Xcode-26.3.0.app"
debug_root="$HOME/Library/Developer/Xcode-iOS27-Debug"
debug_app="$debug_root/Xcode-26.3.0.app"
staging_app="$debug_root/Xcode-26.3.0.preparing"

codesign --verify --strict "$clean_source"
test ! -e "$debug_app"
test ! -e "$staging_app"

mkdir -p "$debug_root"
cp -cRp "$clean_source" "$staging_app"
mv "$staging_app" "$debug_app"

这里的 cp -c 使用 APFS 克隆，源文件和副本拥有独立的文件身份，后续写入副本不会直接改到源文件。跨文件系统时应使用普通独立复制，并预留足够空间。

如果原 CI 安装已有历史修改，导致签名检查失败，应另外准备干净的来源。无需为了创建调试副本，先清理正在承担发布任务的安装。

让 GUI 使用副本自己的缓存

启动脚本保存为上面目录中的 start-xcode-debug.command：

zsh 复制代码

#!/bin/zsh
set -eu

# 只影响当前进程，不修改系统默认 Xcode。
debug_root="$(cd -- "$(dirname -- "$0")" && pwd -P)"
debug_app="$debug_root/Xcode-26.3.0.app"

if [[ ! -x "$debug_app/Contents/MacOS/Xcode" ]]; then
  print -u2 -- "找不到调试副本：$debug_app"
  exit 1
fi

export DEVELOPER_DIR="$debug_app/Contents/Developer"
exec "$debug_app/Contents/MacOS/Xcode" \
  -IDECacheRootDirectory "$debug_root/Caches" "$@"

赋予执行权限后，在终端运行：

sh 复制代码

chmod +x "$HOME/Library/Developer/Xcode-iOS27-Debug/start-xcode-debug.command"

"$HOME/Library/Developer/Xcode-iOS27-Debug/start-xcode-debug.command" \
  "$HOME/Projects/DemoApp/DemoApp.xcworkspace"

DemoApp 是脱敏占位名，使用时替换为自己的 workspace。

本机 macOS 上需要直接启动 Contents/MacOS/Xcode，脚本封装了这个入口。启动 Xcode 用终端，之后仍可在 GUI 中点击 Run 或按 Command-R。

IDECacheRootDirectory 是本次实测有效的内部参数。第一次启动副本后，实际生成的缓存位于：

text 复制代码

~/Library/Developer/Xcode-iOS27-Debug/Caches/26.3-17C529/Xcode/PlugInCache.xcplugincache

核对缓存中的插件路径后，确认它们指向副本，原共享缓存也没有被改写。这个检查很关键：仅仅复制一个 Xcode.app，无法证明缓存和初始化设置已经隔离。

补齐 GUI 需要的架构元数据

对比两版 Xcode 的 DVTFoundation.xcplugindata，26.3 中已有 arm64e，新版中增加了 arm64e.x1。该文件在 Xcode.app 中的相对路径是：

text 复制代码

Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/DVTFoundation.xcplugindata

本次在 26.3 的 GUI 插件缓存中补入了后者。

两版配置的表示方式也有差异。26.3 的既有 arm64e 使用 CPUType = 12 和 is64Bit = true；新版对应字段使用 CPUType = 16777228。因此，补充条目时沿用了旧版配置的表示方式：

json 复制代码

{
  "CPUType": "12",
  "id": "Xcode.Architecture.arm64e.x1",
  "sortPriority": "8",
  "point": "Xcode.Architecture",
  "canonicalName": "arm64e.x1",
  "analyticsEnum": "8",
  "CPUSubType": "12",
  "is64Bit": "true"
}

这些值应由实际版本对照确认，不能从本文推导出其他设备或其他 Xcode 版本也应使用相同条目。

操作时先退出副本，备份刚生成的 GUI 缓存，再在 DVTScanRecords 中找到已有 Xcode.Architecture.arm64e 的记录。将新条目追加到该记录的：

text 复制代码

plugInPlist → plug-in → extensions

本次保留了 Xcode 包内的原始 DVTFoundation.xcplugindata，修改范围限定为副本的 GUI 缓存。工程的 ARCHS 和 SDKROOT 也保持原值。

缓存是二进制 plist，包含日期字段。排查中曾遇到 Python plistlib 无法读取其中的极早日期，因此使用 Foundation 读写，保留原有日期对象。文末附有对应的小工具。

还有一个容易混淆的地方：PlugInCache.xcplugincache 与 PlugInCache-xcodebuild.xcplugincache 属于不同入口。本次验证的是 GUI 缓存中的修改，没有把它扩展到 CI 的命令行缓存。

更新系统符号提取组件

元数据问题处理后，符号准备继续向前，但又遇到提取失败。使用的替换组件来自本机 Xcode 27.1 RC，在两套 Xcode 中的相对路径一致：

text 复制代码

Contents/Developer/Platforms/iPhoneOS.platform/usr/lib/dsc_extractor.bundle

这个组件参与读取 dyld shared cache，也就是系统动态库使用的共享缓存。开源工具 dyld-shared-cache-extractor 的作者说明也指出，它通过加载 Xcode 中的该组件处理共享缓存，组件版本会影响对新格式的支持。

这里引用的是组件作用和格式兼容性的背景；本次把它用于旧 Xcode 的效果，以实际调试结果为依据。

复制前退出副本，将原组件保存在 App 包外。以下变量沿用前文的副本路径，新版来源按本机安装调整：

sh 复制代码

set -e

debug_root="$HOME/Library/Developer/Xcode-iOS27-Debug"
debug_app="$debug_root/Xcode-26.3.0.app"
newer_app="/Applications/Xcode-27.1.0-Release.Candidate.app"
relative_file="Contents/Developer/Platforms/iPhoneOS.platform/usr/lib/dsc_extractor.bundle"
backup_dir="$debug_root/Backups/$(date +%Y%m%d-%H%M%S)"

mkdir -p "$backup_dir"
cp -p "$debug_app/$relative_file" "$backup_dir/dsc_extractor.bundle.original"
cp -p "$newer_app/$relative_file" "$debug_app/$relative_file"

codesign --verify --strict "$debug_app/$relative_file"
shasum -a 256 "$backup_dir/dsc_extractor.bundle.original" "$debug_app/$relative_file"

上述签名命令校验的是替换组件自身。替换后，整个 Xcode.app 的资源封印已经与原发行包不同，单个组件校验通过不能用来证明整套 App 完整性仍然通过。

本次保留了 26.3 的编译器、SDK 和 LLDB，也没有整体移植新版的 Framework。

限定 LLDB 兼容设置的生效范围

继续调试时，LLDB RPC 进程还发生过崩溃。两次崩溃栈分别涉及符号预加载和查找符号文件附带脚本，随后对本次调试环境关闭了两项设置：

text 复制代码

settings set target.preload-symbols false
settings set target.load-script-from-symbol-file false

第一项控制符号表是否提前加载，第二项控制是否加载符号文件携带的脚本资源。这些设置的含义见 LLDB Settings 文档。关闭它们会改变调试器行为，符号加载时机及依赖脚本的展示能力也可能受影响。

持久化配置使用 ~/.lldbinit-Xcode。LLDB 会优先查找面向宿主应用的初始化文件，Xcode 对应的文件名见 LLDB 配置文件文档。

早期配置只判断 LLDB 版本。创建同版本的独立副本后，这个条件不足以区分原安装和副本，因此增加了真实路径判断。下面三条 script 命令各自保持在同一行，追加前应先备份并核对已有配置：

text 复制代码

# 仅对独立副本的指定 LLDB 版本启用兼容设置。
script import lldb, os; _ios27_root = os.path.realpath(os.path.expanduser("~/Library/Developer/Xcode-iOS27-Debug/Xcode-26.3.0.app/Contents")) + os.sep
script lldb.debugger.HandleCommand("settings set target.preload-symbols false") if lldb.SBDebugger.GetVersionString().splitlines()[0] == "lldb-1703.0.236.103" and os.path.realpath(lldb.__file__).startswith(_ios27_root) else None
script lldb.debugger.HandleCommand("settings set target.load-script-from-symbol-file false") if lldb.SBDebugger.GetVersionString().splitlines()[0] == "lldb-1703.0.236.103" and os.path.realpath(lldb.__file__).startswith(_ios27_root) else None

本机对照检查的结果是：

LLDB 来源	`target.preload-symbols`	`target.load-script-from-symbol-file`
独立调试副本	`false`	`false`
原 Xcode 安装	`true`	`warn`

这里的默认值来自本次实测，其他版本应重新检查。若此前一直使用 ~/.lldbinit，还要核对新增宿主专用文件后，原有初始化内容是否仍按预期加载。

独立副本启动时遇到的 Gatekeeper 问题

迁移副本时又出现了一个与设备无关的故障：Xcode 和它内部的 LLDB 启动后被系统终止。日志中能看到：

text 复制代码

Terminating process due to Gatekeeper rejection

系统设置里的"仍要打开"没有完成有效操作。单独检查 LLDB 可执行文件的签名虽然通过，整套副本仍存在修改过的资源；即使一次重新评估返回接受，原副本实际运行时仍被拒绝。

最终有效的处理顺序是：

在调试副本中临时恢复原始 Apple 资源，移出历史额外资源，直到完整性校验通过。
从这份干净副本创建新的 APFS 克隆，先使用不带 .app 后缀的暂存目录，复制完成后再改为正式路径。
对新的干净副本执行 gktool scan，本机返回允许运行。
启动干净副本并确认窗口和 LLDB 正常，再迁回兼容文件，重新验证启动。

本次从通过完整性校验的副本重新克隆，完成评估后再迁回兼容文件。迁回文件后的副本包含自定义修改。

系统级 Gatekeeper 保持启用，没有关闭 SIP，也没有重新签名整套 Xcode。Apple 的 Resolving Gatekeeper Problems介绍了签名完整性、评估工具和嵌入式命令行工具的相关行为；本文的具体恢复过程属于本机实验记录。

GUI 调试结果与 Jenkins 隔离检查

原路径补丁版完成了以下真机验证：

在 Xcode GUI 中 Run，成功安装、启动并附加调试器。
命中 main.m 的源码断点，连续单步执行。
变量面板显示 argc = 1 和 appDelegateClassName = @"AppDelegate"。
执行 po appDelegateClassName 返回 AppDelegate。
继续执行后，App 保持运行。

这组结果证明该组合能够完成基本的 Objective-C 真机调试。调试过程中，系统 ASTContext 和部分 Objective-C 类型信息仍有警告。

迁入独立副本后，重新确认了 GUI 启动、LLDB 设置、私有缓存路径和组件来源。

针对 Jenkins，本次恢复了原安装被替换的提取器和原共享 GUI 缓存，并检查：

xcode-select -p 仍指向原 /Applications 安装。
本机使用的 xcodes installed 26.3.0 仍解析到原安装。
Jenkins 任务配置与迁移前保存的哈希一致。
原路径读取的 Release 构建设置仍使用原工具链、SDK 26.2 和 arm64。
原路径的 LLDB 不会命中副本专用的初始化条件。

这些检查用于核对工具链选择和本次改动的隔离范围。

后续维护与回退

GUI 缓存可能被 Xcode 重建。架构条目丢失后，需要通过启动脚本重新生成副本缓存，退出 Xcode，再核对路径并补入条目。副本缓存中带有插件绝对路径，不能直接把原安装的旧缓存复制过去。

停用方案时，可以退出副本，恢复副本内备份的提取器和私有缓存，再移除 .lldbinit-Xcode 中本次增加的条件设置。其他已有配置应保留。CI 继续使用原安装，无需跟着切换。

回到最初的 DeviceSupport 问题，这次真正需要补齐的是 GUI 能识别的架构信息、能处理新格式的符号提取器，以及能够继续工作的 LLDB 加载路径。按失败阶段逐步验证，才最终走到了源码断点，而 DeviceSupport 目录是否存在只提供了其中一部分线索。

附：为 GUI 缓存追加架构条目的工具

下面代码只适用于前文确认过的缓存结构。它要求恰好找到一条含 arm64e 的记录，并拒绝重复添加。输入、输出使用两个文件，成功检查输出后再替换缓存。

整理本文时，已用缓存备份验证：除新增条目外，Foundation 解析后的其余数据与输入一致；重复添加和无效输入都会停止写入。

保存为 cache_patch.m：

objectivec 复制代码

#import <Foundation/Foundation.h>

int main(int argc, const char *argv[]) {
    @autoreleasepool {
        if (argc != 3) {
            fprintf(stderr, "用法：cache_patch 输入缓存 输出缓存\n");
            return 2;
        }

        NSError *error = nil;
        NSData *input = [NSData dataWithContentsOfFile:@(argv[1])
                                              options:0 error:&error];
        if (!input) {
            fprintf(stderr, "读取失败：%s\n", error.description.UTF8String);
            return 3;
        }

        id parsed = [NSPropertyListSerialization propertyListWithData:input
            options:NSPropertyListMutableContainersAndLeaves
            format:NULL error:&error];
        if (![parsed isKindOfClass:NSMutableDictionary.class]) return 3;

        NSMutableDictionary *root = parsed;
        id records = root[@"DVTScanRecords"];
        if (![records isKindOfClass:NSArray.class]) return 4;

        NSMutableDictionary *target = nil;
        NSUInteger matches = 0;
        for (id record in records) {
            if (![record isKindOfClass:NSDictionary.class]) return 4;
            id plist = record[@"plugInPlist"];
            if (![plist isKindOfClass:NSDictionary.class]) continue;
            id plugin = plist[@"plug-in"];
            if (![plugin isKindOfClass:NSDictionary.class]) continue;
            id extensions = plugin[@"extensions"];
            if (![extensions isKindOfClass:NSMutableDictionary.class]) continue;
            if (extensions[@"Xcode.Architecture.arm64e"]) {
                target = extensions;
                matches++;
            }
        }

        if (matches != 1) {
            fprintf(stderr, "匹配数量为 %lu，停止写入\n",
                    (unsigned long)matches);
            return 4;
        }
        if (target[@"Xcode.Architecture.arm64e.x1"]) {
            fprintf(stderr, "已存在目标条目，无需重复添加\n");
            return 5;
        }

        target[@"Xcode.Architecture.arm64e.x1"] = @{
            @"CPUType": @"12",
            @"id": @"Xcode.Architecture.arm64e.x1",
            @"sortPriority": @"8",
            @"point": @"Xcode.Architecture",
            @"canonicalName": @"arm64e.x1",
            @"analyticsEnum": @"8",
            @"CPUSubType": @"12",
            @"is64Bit": @"true"
        };

        NSData *output = [NSPropertyListSerialization dataWithPropertyList:root
            format:NSPropertyListBinaryFormat_v1_0 options:0 error:&error];
        if (!output || ![output writeToFile:@(argv[2])
                                   options:NSDataWritingAtomic error:&error]) {
            fprintf(stderr, "写入失败：%s\n", error.description.UTF8String);
            return 6;
        }
        puts("已生成补丁缓存");
    }
    return 0;
}

在保存源码的目录中编译。这里显式指定工具链和 SDK 路径，避免依赖当前终端的默认选择：

sh 复制代码

set -e

compiler_dir="/Applications/Xcode-26.3.0.app/Contents/Developer"
sdk_path="$(DEVELOPER_DIR="$compiler_dir" xcrun --sdk macosx --show-sdk-path)"

DEVELOPER_DIR="$compiler_dir" xcrun --sdk macosx clang \
  -isysroot "$sdk_path" -fobjc-arc -framework Foundation \
  cache_patch.m -o cache_patch

确认副本已经退出，再对自己的独立缓存运行：

sh 复制代码

set -e

cache="$HOME/Library/Developer/Xcode-iOS27-Debug/Caches/26.3-17C529/Xcode/PlugInCache.xcplugincache"
backup="$cache.$(date +%Y%m%d-%H%M%S).bak"

cp -p "$cache" "$backup"
./cache_patch "$cache" "$cache.patched"
plutil -lint "$cache.patched"
mv "$cache.patched" "$cache"

如果工具提示已经存在条目，停止这组命令即可。缓存结构、构建号或设备架构与本文不同，也应先重新对照，避免把内部配置当成跨版本固定接口。