阅读视图

发现新文章,点击刷新页面。

目前中国大陆唯一可以免费在 Xcode 中使用顶级大模型智能编程的方法

在这里插入图片描述

0.引子

现今,在中国大陆想要使用最强编程大模型在 Xcode 中实时交互的方法不多。

为了体验 Vibe Coding 的“畅快”打击感(或许还有等待间隙时的些许失落感),我们往往需要在 Cursor 和 Xcode 间无限切换,这多少有点让秃头小码农们有些不爽快!

在这里插入图片描述

况且第三方智能编程 IDE 与 Xcode 联合开发还有一个问题:就是从 Xcode 外部无法精确的感知和处理 Xcode 中的细枝末节。举个例子:宝子们见过 Cursor 为了修复 1 个 bug 却新产出 10 个 bug 的蛋疼壮观场面吗?

在这里插入图片描述

幸运的是,在 Xcode 最新正式版 26.4 中: 在这里插入图片描述

我们找到一种免费且非常简单就可以辅以超强编程大模型(gpt-5.4 或 gpt-5.3-codex 家族)的方法:

在这里插入图片描述

操作起来也非常简单,目前(2026.4.7号)并不需要付费 OpenAI 账号或绑定任何国际银行卡。

在这里插入图片描述

这样宝子们“足不出户”就可以在 Xcode 里享受氛围编程的乐趣了哦。

在这里插入图片描述

废话少叙,心动不如行动!

让我们马上开始操练起来,将 Xcode 打造为丝毫不输于 Cursor 的智能 IDE 吧!8-)


1.工欲善其事,必先利其器

首先,大家需要下载和安装 Xcode 26.4 正式版。

同时,必须保证我们可以访问到 ChatGPT 官网,否则还扯什么呢?

在这里插入图片描述

2.启用 Xcode 智能 Agent

运行 Xcode ,打开设置,进入 Intelligence 页面:

在这里插入图片描述

Xcode 26.4 支持先进最强的 2 个编程大模型智能体(Agents):ChatGPT Codex 和 Claude,不过目前后者在大陆无法登录,会提示:当前区域的服务不可用。

在这里插入图片描述

所以,我们只有“稍微”退而求其次一丢丢,来使用 gpt-codex 了。

点击 Codex 右侧的 Get 按钮,下载并安装 Agent 到本地,我们能看到只有 77MB,可谓相当“小鸟依人”:

在这里插入图片描述

接下来的一步就是进入 Codex 智能体(Agent)页面,登录 ChatGPT 账户即可:

在这里插入图片描述

如图所示,在登录了 gpt 账号之后,我们可以就可以恣意选择自己喜爱的 gpt 大模型啦:

在这里插入图片描述

不过据我观察,Xcode 智能 Agent 中的 gpt 编程大模型貌似有点缩水,少了不少强力模型哦(比如 GPT-5.3 Codex High 和 GPT-5.3 Codex Extra High 等):

在这里插入图片描述

但话又说回来,对于这免费的“飞来横福”,我们还要什么自行车呢?


注意:正如之前所说的,目前只需免费的 ChatGPT 账号即可,且不需要绑定任何银行卡。

但是,未来还能不能享用这“免费的午餐”,就有点世事难料了。


在这里插入图片描述

3. 测试

在上面各步骤都就绪之后,我们就可以找一个项目实际在 Xcode 中小试身手了。

下面,打开宝子们最爱的项目,先让 Xcode Agent 为我们总结一番吧:

在这里插入图片描述

当然,在 Xcode 里编程智能体做的不仅仅是做个总结那么“弱智”,我们还可以让它直接分析 Xcode 中拥有的一切:

在这里插入图片描述

现在,直接在 Xcode 中用 AI 来修正编译错误不再是梦想了:

在这里插入图片描述在这里插入图片描述

这样做可以最大化利用 Xcode 丰富的上下文来让 AI 充分考虑和修正问题,避免了外部智能 IDE(比如 Cursor、Qoder 等)无必要的切换和折腾。


想用 Xcode 与本地大模型“双剑合璧”来协同编程的宝子们,请移步如下链接观赏精彩的内容:


看到这,不知宝子们心动了吗?

在这里插入图片描述

要不要一起来借助 Coding Intelligence 来试试 Xcode 的氛围编程呢?8-)

若有任何与本文相关的配置问题,请宝子们毫不犹豫的私我哦!

感谢观赏,下次再会吧!

在这里插入图片描述

关于Xcode26.4 踩坑适配

Xcode26.4 踩坑适配

不建议升级Xcode 26.4,Xcode底部控制台无法使用po命令;

iOS 26.4模拟器启动加载巨缓慢,建议保持26.3.1。

随着 Xcode 26.4 正式版发布,编译器对私有头文件访问链式比较语法C++标准库特化的校验规则进一步收紧,导致 iOS 开发中常用的 AFNetworking、YYText、WCDB 三个主流第三方库出现编译报错/警告。本文针对这三类问题提供修复方案,帮助开发者快速完成 Xcode 26.4 适配。

一、AFNetworking:私有头文件访问报错

报错信息

Use of private header from outside its module: 'netinet6/in6.h'

问题原因

Xcode 26.4 强化了模块私有头文件的访问权限校验,AFNetworking 源码中直接引入了系统私有头文件 <netinet6/in6.h>,违反了 Xcode 的模块访问规则,触发编译报错。

解决方案

直接注释掉AFNetworking 中引入该私有头的代码行,无需其他修改即可解决。

  1. 找到 AFNetworking 中包含 #import <netinet6/in6.h> 的文件(通常为AFURLSessionManager.m或核心头文件);
  2. 注释该行代码:
// #import <netinet6/in6.h>
  1. Clean 项目缓存,重新编译即可。

二、YYText:链式比较语法错误

报错信息

Chained comparison 'X < Y < Z' does not behave the same as a mathematical expression

问题原因

Xcode 26.4 编译器对链式比较语法做了严格校验:X < Y < Z 在 OC/C 语言中并非数学意义的连续比较,而是先计算X<Y得到布尔值(0/1),再用该值与 Z 比较,逻辑完全错误。编译器会强制抛出警告,影响编译流程。

解决方案

前半段比较逻辑添加括号,明确运算优先级,修复语法歧义。

代码修改
[self _insideComposedCharacterSequences:line position:position block: ^(CGFloat left, CGFloat right, NSUInteger prev, NSUInteger next) {
    if (isVertical) {
-        position = fabs(left - point.y) < fabs(right - point.y) < (right ? prev : next);
+        position = (fabs(left - point.y) < fabs(right - point.y)) < (right ? prev : next);
    } else {
-        position = fabs(left - point.x) < fabs(right - point.x) < (right ? prev : next);
+        position = (fabs(left - point.x) < fabs(right - point.x)) < (right ? prev : next);
    }
}];
  1. 按上述代码添加括号;
  2. 重新编译,错误自动消失。

三、WCDB:C++标准库特化报错

报错信息

'is_integral' cannot be specialized: Users are not allowed to specialize this standard library entity

报错文件:Tag.hpp

报错截图

问题原因

Xcode 26.4 升级了底层 Clang/LLVM 编译器,严格遵循 C++标准规范:禁止开发者手动特化std::is_integral等标准库实体,WCDB 旧版源码的 Tag.hpp 文件触发了该规则限制。

解决方案

官方暂未提供修复方案,推荐两种任选其一

方案 1:其他开发者提交的修复 PR(源码修改)

直接应用 WCDB 其他开发者针对该问题的修复 PR,一键修复源码:

  • PR 地址:#1540
  • 操作:拉取 PR 代码替换本地 Tag.hpp 文件,重新编译即可。
方案 2:脚本打包 XCFramework(推荐)

使用 WCDB 官方脚本打包为xcframework,绕过源码编译的规则限制:

  1. 进入 WCDB 源码根目录;
  2. 执行官方打包脚本:
# 路径:/tools/version/build_xcframework.sh

./build_xcframework.sh \
  --scheme WCDBObjc \
  --configuration Release \
  --platforms ios ios-simulator \
  --output ./wcdb_xcframework
🧩 Creating XCFramework for WCDBObjc ...

[cmd] xcodebuild -create-xcframework -archive /Users/fjl/GitHub/wcdb/./wcdb_xcframework/archives/WCDBObjc-ios.xcarchive -framework WCDBObjc.framework -archive /Users/fjl/GitHub/wcdb/./wcdb_xcframework/archives/WCDBObjc-ios-simulator.xcarchive -framework WCDBObjc.framework -output /Users/fjl/GitHub/wcdb/./wcdb_xcframework/xcframeworks/WCDBObjc.xcframework

xcframework successfully written out to: /Users/fjl/GitHub/wcdb/wcdb_xcframework/xcframeworks/WCDBObjc.xcframework

✅ Created XCFramework: /Users/fjl/GitHub/wcdb/./wcdb_xcframework/xcframeworks/WCDBObjc.xcframework

⏱ Total elapsed time: 1 min 7 sec (67 s)
  1. 用生成的 xcframework 替换项目中原有 WCDB 的集成方式;
  2. Clean 项目后编译,问题彻底解决。

参考链接:WCDB Tag.hpp 报错官方 issue


适配总结

  1. AFNetworking:注释私有头引入行,解决模块访问权限问题;
  2. YYText:链式比较加括号,修复编译器语法校验;
  3. WCDB:合并官方 PR 或脚本打包 xcframework,解决 C++标准库特化限制。

完成以上修改后,清理 Xcode 缓存(Cmd+Shift+K),即可适配 Xcode 26.4,正常编译运行。

总结

  1. 三个第三方库的报错均由 Xcode 26.4编译器规则升级导致,修复无需改动业务代码;
  2. AFNetworking、YYText 为轻量代码修改,WCDB 推荐用官方脚本打包方案,稳定性更高;
  3. 适配后务必清理项目缓存,避免编译缓存残留问题。

Buildable Folder & Group & Folder Reference in Xcode

深入理解代替单纯记忆

问题背景

  • 在开发iOS项目时,希望将一堆图片资源放入Main Bundle中,但又不希望资源在Bundle的最顶层目录中,希望自定义目录
  • 但一时想不到该如何解决,于是想到FolderGroup等概念
  • 经过简单搜索后,发现Xcode对于这两个概念的定义还是有些差异的
  • 于是继续查阅学习了一番,编写本文,方便后续查阅和分享

本文提到的内容,参考的Xcode版本为26.0(17A324)和26.3(17C529)

Buildable Folder

  • Buildable Folder是自Xcode 16(2024年6月)引入的概念,初衷是为了减少代码管理中的冲突问题
  • 后续新建的工程或者新建Folder时,默认都是Buildable Folder

官方原文如下:

Minimize project file changes and avoid conflicts with buildable folder references. Convert an existing group to a buildable folder with the Convert to Folder context menu item in the Project Navigator. Buildable folders only record the folder path into the project file without enumerating the contained files, minimizing diffs to the project when your team adds or removes files, and avoiding source control conflicts. To use a folder as an opaque copiable resource, the default behavior before Xcode 16, uncheck the Build Folder Contents option in the File Inspector.

Buildable Folder如何降低代码冲突

  1. 先添加1个普通Group--BuildableFolderTest,project文件的变化如下所示: image.png

  2. 然后向BuildableFolderTest Group中添加ABC.swift文件后,project文件的变化如下: image.pngimage.png

    这说明Group目录下的文件,都要在project文件中进行记录

  3. 继续,将BuildableFolderTest Group通过Convert to Folder选项转为Folder(Buildable Folder)后,project文件的变化如下: image.pngimage.png

  4. 然后再向BuildableFolderTest这个Folder中添加DEF.swift文件后,发现project文件没有任何变化

所以,project文件仅记录了Folder自身,至于目录中的文件是不会记录在project文件中,所以会减少因团队多人同时修改Project文件导致的代码冲突

Apply to Each File vs Apply Once to Folder

当创建Folder(Buildable Folder)后,选中Folder,在File inspector中会看到有个Build Rule,有两个选择:Apply to Each FileApply Once to Folder,默认是Apply to Each File

image.png

Apply Once to Folder

Apply Once to Folder开启后,project文件是什么样?

image.pngimage.pngimage.png

当开启该模式时,通过查看目录下的每个文件可以看出,文件是没有Target归属的概念的。同样,在该目录下创建新文件也不需要选择Target

再配合Xcode Buildable Folders中所提到的To use a folder as an opaque copiable resource, the default behavior before Xcode 16, uncheck the Build Folder Contents option in the File Inspector.

其实,Apply Once to Folder就是Xcode 16之前的Folder,之前叫Folder Reference (在Xcode 16之前,创建Folder时,官方名称就叫做Folder Reference)

  • Folder Reference一般是用作资源包,目录下不包含源代码
  • 另一个Folder Reference重要作用是可以在Bundle中自定义目录

Buildable Folder vs Folder Reference

Buildable Folder顾名思义,其中的内容是由编译系统参与的

  • 所以Buildable Folder中可以放源代码文件,并可以参与编译,打包到最终可执行文件中;也可以制定源文件的Target
  • Folder Reference则保留老的逻辑,不参与编译,用作资源包,即使放入源代码文件也无法选择Target,只能当做普通文件资源处理

Create Group with Folder

同样是在Xcode 16开始的另一个变化是,创建Group时由原来的不自动创建磁盘物理目录(Folder)变为自动创建。当然,仍可以创建没有FolderGroup,原文如下:

Create groups with associated folders by default when using the New Group and New Group from Selection commands in the Project Navigator. To create a group without a folder, hold the Option key in the context menu to reveal the New Group without Folder variant of the command.

[Group without Folder] vs [Group] vs [Folder(Buildable Folder)] vs [Folder Reference]

特性 Group without Folder Group Buildable Folder Folder Reference
Project Navigator 图标 image.png image.png image.png image.png
是否对应磁盘目录 ❌ 不必须 ✅ 必须 ✅ 必须 ✅ 必须
工程结构是否可与磁盘不同 ✅ 可以 ❌ 基本一致 ❌ 必须一致 ❌ 必须一致
.pbxproj 是否记录每个文件 ✅ 会 ✅ 会 ❌ 不会 ❌ 不会
新增文件是否修改 .pbxproj ✅ 会 ✅ 会 ❌ 不会 ❌ 不会
Git 冲突概率
是否参与编译系统
是否自动编译源码 ✅(自动发现目录中的源码)
Bundle 中是否保留目录结构 ❌ 通常不会 ❌ 通常不会 ❌ 通常不会 会保留(如果被加入 Bundle)
默认是否进入 Bundle ❌ 否 ❌ 否 ❌ 否 仅在选中 Target 时自动加入
典型用途 逻辑分组 常规项目结构 源码目录 资源目录
  • 当前(Xcode 26),默认的Group和Folder组合是Group with Folder + Buildable Folder。这可能也意味着这两项是日常最常用的

回答开始的问题

  • 既然是想打包资源放入Bundle,并自定义目录,那必然是Folder Reference

参考

iOS设备崩溃日志获取与查看

1)如何从 iPhone 获取崩溃日志

路径:设置 → 隐私与安全性 → 分析与改进 → 分析数据
这里的崩溃日志通常是 .ips 文件。

.ips 原始内容示例(节选):

{"app_name":"hello","timestamp":"2026-02-28 15:05:24.00 +0800","app_version":"1.0","bundleID":"com.example.hello","bug_type":"309","os_version":"iPhone OS 26.3 (23D127)","incident_id":"2B7A2F77-7F64-42DA-A184-AA496AD61AAC"}
{
  "modelCode" : "iPhone18,3",
  "captureTime" : "2026-02-28 15:05:24.5689 +0800",
  "procName" : "hello",
  "bundleInfo" : {"CFBundleShortVersionString":"1.0","CFBundleVersion":"1","CFBundleIdentifier":"com.example.hello"}
}

2)如何将 .ips 转成可查看的崩溃日志

.ips 文件复制到 Mac(如桌面),直接双击
系统会用 控制台(Console) 打开,并自动转成可读格式(Translated Report)。

转换后示例(节选):

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Incident Identifier: 2B7A2F77-7F64-42DA-A184-AA496AD61AAC
Process: hello [1056]
Identifier: com.example.hello
Version: 1.0 (1)
OS Version: iPhone OS 26.3 (23D127)

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Triggered by Thread: 0

Thread 0 Crashed:
0   libswiftCore.dylib   _assertionFailure(...)
1   hello.debug.dylib    ViewController.click(_:)

说明:这是一个 Demo 在真机调试运行时产生的崩溃日志,符号信息完整,不需要额外 dSYM 符号化也能直接看到具体崩溃代码位置(如 ViewController.click(_:))。

Xcode 垃圾清理

一、可清理目录总览

场景 目录 是否可删 影响 建议
模拟器数据 ~/Library/Developer/CoreSimulator 可删 模拟器数据会被清空 不用模拟器时可重点清理(如 devices
真机调试符号 ~/Library/Developer/Xcode/iOS DeviceSupport 可删(建议选择性) 删掉后下次连接对应 iOS 版本会自动重建 删除不用的设备版本,常用版本保留
打包归档 ~/Library/Developer/Xcode/Archives 可删 会失去历史归档(.xcarchive) 先保留线上版本再清理
构建缓存 ~/Library/Developer/Xcode/DerivedData 可删 下次打开/编译变慢,需要重新索引与构建 优先清理(最直接释放缓存空间)

二、分项说明

1) 模拟器(CoreSimulator)

  • 路径:~/Library/Developer/CoreSimulator
  • 说明:包含模拟器设备数据。
  • 结论:可以删除;如果基本不用模拟器,可删除 devices 目录内容来释放较大空间。

2) 真机(DeviceSupport)

  • 路径:~/Library/Developer/Xcode/iOS DeviceSupport
  • 说明:真机调试时生成的设备符号文件。
  • 结论:建议选择性删除不用的设备版本;常用设备版本保留,避免频繁重建影响调试效率。

3) 打包(Archives)

  • 路径:~/Library/Developer/Xcode/Archives
  • 说明:Xcode 打包归档历史。
  • 结论:可以删除,但要先确认是否需要保留线上版本的归档记录。

4) 项目缓存(DerivedData)

  • 路径:~/Library/Developer/Xcode/DerivedData
  • 说明:构建缓存与索引。
  • 结论:建议优先清理;能快速释放缓存空间。代价是后续首次编译和索引会变慢。

三、实操建议(个人整理)

  1. 优先清理DerivedData(快速释放缓存空间)。
  2. 选择性清理iOS DeviceSupport(删除不用的设备/系统版本,常用的保留)。
  3. 按需清理CoreSimulator(尤其不用模拟器时)。
  4. 补充清理:过期 Archives(先保留可回滚版本)。
  5. 清理前先确认:
    • 是否有线上紧急回滚需要的归档;
    • 哪些真机系统版本仍在日常调试;
    • 是否有正在使用的模拟器环境数据需要保留。

四、快速命令(可选)

先看大小再删,避免误操作。

# 查看各目录体积
sudo du -sh ~/Library/Developer/CoreSimulator \
  ~/Library/Developer/Xcode/iOS\ DeviceSupport \
  ~/Library/Developer/Xcode/Archives \
  ~/Library/Developer/Xcode/DerivedData

# 删除 DeviceSupport
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

# 删除 Archives
rm -rf ~/Library/Developer/Xcode/Archives/*

# 删除 DerivedData(谨慎)
rm -rf ~/Library/Developer/Xcode/DerivedData/*

五、一句话总结

Xcode 清理的核心是:优先清理 DerivedData 释放缓存;DeviceSupport 只删不用的设备版本,常用版本保留;再按需处理模拟器与旧归档。

❌