普通视图

发现新文章,点击刷新页面。
昨天以前iOS

StoreKit 知识总结

作者 charmson
2026年5月26日 12:10

一、什么是 StoreKit 配置文件

StoreKit 配置文件(.storekit)是 Apple 提供的本地测试环境配置文件,用于在 Xcode 中模拟 App Store 内购行为,无需连接真实的 App Store 服务器。

支持的产品类型

类型 说明
Consumable 消耗型,如游戏币
Non-Consumable 非消耗型,如解锁功能
Auto-Renewable Subscription 自动续期订阅
Non-Renewing Subscription 非自动续期订阅

创建方式

Xcode → File → New → File → StoreKit Configuration File
Edit Scheme → Run → Options → StoreKit Configuration(指定文件)

二、本地配置 vs 沙盒测试

对比项 StoreKit 配置(本地) 沙盒测试(Sandbox)
需要网络
需要 App Store Connect 配置
速度 更快 较慢
适合阶段 开发早期 上线前验证

三、清除本地购买记录(重置初始态)

方法一:Xcode 菜单(推荐)

Debug → StoreKit → Clear Purchased Products

清除后重新运行 App 即可,无需重启模拟器。

方法二:重置整个模拟器

Xcode → Window → Devices and Simulators
→ 选中模拟器 → Erase All Content and Settings

方法三:代码同步(仅供参考)

#if DEBUG
try await AppStore.sync()
#endif

四、正式上线后的工作原理

.storekit 配置文件只在开发阶段生效,打包上线后自动忽略。

用户点击购买
    ↓
StoreKit 框架(代码不变)
    ↓
请求发往 Apple 生产服务器
    ↓
Apple 处理支付,返回 Transaction
    ↓
App 验证收据 → 解锁内容

三种环境对比

环境 数据来源 购买记录存储
本地开发 StoreKit 配置文件(.storekit) 本地模拟器沙盒
沙盒测试 App Store Connect(测试环境) Apple 服务器(沙盒)
正式上线 App Store Connect(生产环境) Apple 服务器(生产)

关键点

  • .storekit 文件是"假数据源",上线后真实数据全部走 Apple 服务器
  • StoreKit 是框架(API) ,在三种环境下代码本身不变,变的是背后连接的服务器
  • 用户购买记录永久保存在 Apple 账户中,restore purchases 从 Apple 服务器拉取
  • 上线后需要对 Apple 服务器签发的收据进行验证(客户端或服务端)

Agent Loop 简介

作者 唐巧
2026年5月2日 08:10

一、一个反直觉的事实

先说一个看起来有点反常识的事:LLM 本身是无状态的

每次调用模型,本质上就是一次”文本补全”——你扔一段 prompt 进去,它根据这段 prompt 续写一段输出,然后整个过程结束。下一次再调用,模型对上一次的事一无所知。从机制上讲,它和 2020 年的 GPT-3 没有本质区别,都是一次性的补全器。

但 2024 年之后,我们看到的 Claude Code、Cursor Agent、各种 deep research 工具,明明可以连续工作几十分钟、调用几十个工具、修改几百个文件,看起来”自主”得不得了。

这两件事怎么对得上?

答案藏在外面那个 while 循环里。

Agent ≠ 模型
Agent = 模型 + Loop + Tools + Context 管理

模型本身没有变,变的是包在它外面的那层东西。这层东西现在常被称作 harness(脚手架),而 harness 里最核心的部件,就是 Agent Loop

这篇文章想回答三个问题:

  1. 这个 loop 长什么样?
  2. 它为什么这样设计?
  3. 它什么时候会失效?

二、最小可运行的 Agent Loop

把所有花哨的东西都剥掉,一个 Agent Loop 的本质大概是这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
messages = [{"role": "user", "content": user_input}]

while True:
response = llm(messages, tools=available_tools)
messages.append(response)

if response.stop_reason != "tool_use":
# 模型没要求调用工具,说明它认为任务结束了
return response.text

# 模型要求调用一个或多个工具
for tool_call in response.tool_calls:
result = execute(tool_call)
messages.append({
"role": "tool",
"content": result
})
# 进入下一轮,让模型看到工具结果,决定下一步

就这么二十行。这就是 Claude Code、Cursor、几乎所有 coding agent 的核心。

拆解一下,里面只有四个动作:

  1. 模型推理:把当前 messages 丢给 LLM,让它产出下一步的 response
  2. 工具调用判断:如果 response 里有 tool_use,就执行;如果没有,循环结束
  3. 工具执行:在沙箱/真实环境里跑这个工具,拿到结果
  4. 结果回灌 context:把工具结果塞回 messages,进入下一轮

到这里,请允许我强调一个关键认知:

所谓”Agent 的自主性”,本质就是模型在每一轮看到更新后的 context,自己决定下一步。没有任何魔法。

不是模型变得”会规划”了,是循环让它有机会根据上一步的结果,再做一次补全。它的”思考”只发生在每一次模型调用的那一瞬间,loop 只是一遍遍把它叫醒,告诉它”环境又变了,你再看看”。

理解了这一点,后面所有的工程设计,都只是这个最小循环的变体。


三、Loop 的关键设计决策

最小循环能跑,但不够用。一旦把它放到真实场景里,会立刻撞到一堆问题:循环什么时候停?context 越涨越长怎么办?工具调用错了怎么办?要不要并行?

围绕这些问题做的工程取舍,决定了一个 Agent 框架的性格。下面是五个最关键的决策维度。

1. 终止条件:什么时候跳出 loop

最朴素的写法是”模型不再要求调用工具就停”,但这在生产里远远不够。常见的多重终止条件:

  • 模型主动 stop:response 里没有 tool_use,正常出口
  • 达到 max_iterations:硬性步数上限(比如 50 步),防止失控
  • 检测到循环:连续几次调用相同工具+相同参数,强制中断
  • 用户中断:Ctrl+C、关闭对话窗口
  • 预算耗尽:token 数或时间超限

每个出口背后都是一次工程权衡:上限太小,复杂任务做不完;上限太大,一旦模型卡住就烧钱。

2. Context 增长策略:长任务下怎么办

工具结果一律塞回 context,会带来一个朴素但致命的问题——context 是线性增长的

一个改 50 个文件的任务,可能要读 100 次文件,每次读取的内容都进 context。跑到一半,context 已经塞了几十万 token,模型注意力开始稀释,关键信息被淹没。

工程上有几种常见思路:

  • 全量回灌:最简单,短任务够用,长任务必崩
  • 滑动窗口:只保留最近 N 轮,老的丢掉,但可能丢关键信息
  • 摘要压缩:触发阈值后,让模型自己总结前面的内容,用摘要替换原文
  • 分层压缩:Claude Code 的 /compact 机制就属于这一类——保留最近上下文 + 历史摘要 + 关键信息(如已修改的文件列表)

这一项是目前差异最大的设计点。后面会看到 learn-claude-code 项目专门有一节叫 s06_context_compact,就是为了解决这件事。

3. 工具选择机制:模型怎么”选工具”

两种主流做法:

  • 原生 function calling:通过 API 把工具 schema 一并传给模型,模型在 response 里直接产出结构化的 tool_use 块。Claude、GPT、Gemini 都支持。优点是稳定,几乎不会出格式错误。
  • 提示词约定格式:在 system prompt 里告诉模型”想调用工具就输出 <tool>...</tool> 这样的 XML”,外层用正则解析。早期 ReAct 论文就是这么做的,胜在通用,任何模型都能用。

现在新项目基本都默认用 function calling,但提示词约定法在一些场景仍有价值——比如要让一个本地小模型当 agent,或者要做更细粒度的格式控制。

4. 错误处理:工具调用失败怎么办

工具会出错。文件不存在、API 超时、参数类型不对、权限不足……

两种处理思路,本质是信任谁

  • 塞回 context 让模型自我纠正:把 error message 当作普通的 tool_result 回灌,相信模型能看懂错误并调整。优点是灵活,模型常常能从”file not found”反推出”我应该先 ls 一下”。
  • 外层拦截:harness 直接处理特定错误类型,比如重试、降级、报警。优点是可预测。

实践里通常是混合策略:致命错误外层拦截,业务错误丢给模型。这件事的判断需要工程经验。

5. 并行 vs. 串行:单 Agent 还是多 Agent

单 Agent 的极致是一轮内并行调用多个工具。Claude 现在原生支持一次返回多个 tool_use 块,harness 并行执行后一次性把所有结果回灌。这能显著降低延迟。

更复杂的是多 Agent 协作:主 agent 派发子任务给子 agent,子 agent 独立 loop,结束后回报。这里立刻冒出一个新问题——路由:主 agent 怎么知道哪个子 agent 适合这个任务?是基于 metadata 标签匹配,还是让主 agent 读子 agent 的描述自己判断?这两种思路的优劣,是另一篇文章的话题了。


四、从 50 行到 1000 行:一个 Agent 是怎么长出来的

讲完抽象的设计维度,看一个具体的项目——开源项目 learn-claude-code

这个项目的好处是:它把一个 nano 版 Claude Code 的演化拆成了 12 个递进的 Python 脚本,每一步只引入一个新机制。从 s01 到 s12,代码从大约 50 行长到 1000+ 行。

读它,相当于把上一节的设计决策亲眼看一遍怎么落到代码里。

下面挑几个最关键的节点:

s01 Agent Loop:朴素的 while

1
2
3
4
5
6
while True:
response = model(messages, tools)
if response.stop_reason != "tool_use":
return response.text
results = execute(response.tool_calls)
messages.append(results)

这就是上一章伪代码的真实版本。50 行,能跑,能调用 bash 完成简单任务。这是一切的起点

s02 Tool Use:从一个工具到多个工具

引入 read_filewrite_filebashgrep 等多个工具。重点不在工具本身,而在 wire——怎么把工具 schema 注册给模型,怎么 dispatch 到真实函数。

到这里,agent 已经能完成”读文件、改文件、跑测试”这种基础编程任务了。

s03 TodoWrite:对抗”目标漂移”的第一道防线

一个有意思的设计:让 agent 自己维护一个 todo list。

为什么?因为长任务里,模型很容易跑偏。任务一大,model 在第 30 轮已经忘了第 1 轮的目标是什么。TodoWrite 工具强制 agent 在开工前把任务拆成清单,每完成一项划掉一项。

这本质上是用工具调用替代记忆——不指望模型记住,而是把目标固化成 context 里随时可见的状态。Claude Code 现在就是这么做的,效果非常显著。

s04 Subagent:什么时候该拆出去

主 agent 不是万能的。当一个子任务的 context 会污染主 agent 的判断(比如要读一大堆代码才能定位 bug),就该把它丢给子 agent。

子 agent 有自己独立的 loop、独立的 context,跑完只把结论返回给主 agent。这是用 context 隔离换取主 loop 的清晰

s06 Context Compact:长任务的生存策略

直接对应第三章讲的”context 增长策略”。当 messages 长度超过阈值,触发 compact:让模型把前面的对话总结成一段摘要,用摘要替换原始消息,保留最近几轮原文。

这是目前所有长任务 agent 的共同方案。没有 compact,agent 就走不远

s07–s12:再往后

任务系统、后台任务、多 agent 团队、worktree 隔离……每一层都是在同一个 loop 上叠加工程能力。但本质都没变:还是那个 while 循环


读完这个项目,最值得记住的是它的核心宣言:

The model is the agent. The code is the harness.
模型才是 Agent,代码只是脚手架。

这句话听起来像废话,其实暗藏一个反直觉的判断——你写的那一千行 harness 代码,不是在让 Agent “更聪明”,只是在帮模型别搞砸。模型本身已经具备 Agent 能力,harness 的工作是给它工具、管好上下文、防止失控。

Harness 越薄,说明模型越强。


五、Loop 的边界与失效模式

Agent Loop 不是银弹。在生产里,它会以几种典型方式翻车:

1. 上下文窗口爆炸

最常见。长任务跑到一半,context 涨到几十万 token,模型注意力被稀释,开始重复读同一个文件、忽略关键约束。Compact 是缓解,但不是根治——压缩本身也会丢信息。

2. 工具调用幻觉

模型有时会编造不存在的工具,或者给真实工具传错误参数(比如发明了一个本不存在的 flag)。这件事在小模型上尤其严重。缓解办法是收紧 tool schema 的描述、用 function calling 而不是提示词约定,以及在 harness 里做参数校验。

3. 死循环

模型反复调用同一个工具拿同样的结果,不收敛。常见于”修一个 bug 但根本没想清楚”的场景:跑测试 → 失败 → 改一行 → 跑测试 → 失败 → 改回来。需要在 harness 里检测这种模式并强制中断。

4. 目标漂移

多轮之后忘了原始任务。前面提到的 TodoWrite 是一种缓解,更激进的做法是定期”自检”:让 agent 每隔 N 轮 reflect 一次,对照原始目标审视当前进展。

工程上常见的缓解组合是:context 压缩 + 工具白名单 + step budget + 显式 reflection 节点。每一项都不彻底,但叠在一起能撑很久。


六、Agent Loop 是临时方案,还是终极形态

最后留一个开放问题。

回看现在所有的 Agent 框架——Claude Code、Cursor、LangGraph、OpenClaw、learn-claude-code——本质都在围绕同一个 while 循环做工程优化。终止条件、context 压缩、子 agent、todo 管理……每一项都是因为模型本身做不到,所以 harness 替它做

但模型还在变强。

Claude 已经支持 extended thinking——模型在一次调用里能做更长的内部推理。原生的 tool use 在每一代都更稳。multi-step 的 planning 能力肉眼可见地在涨。

那么一个不那么好回答的问题是:

当模型本身具备足够长的推理链和原生工具使用能力时,外部那个 while 循环还需要存在吗?

也许某一天,你只需要一次 API 调用,模型在内部就完成了全部规划、工具调用、上下文管理。harness 被吸收进了模型本身。我们今天精心设计的这些 loop 控制机制,会变成一段历史。

也可能不会。也许 harness 永远存在——因为外部环境永远是 harness 的边界,模型再强,也需要一个东西替它和真实世界对接。

不知道。但这就是现在做 Agent 最有意思的地方:你不知道自己写的这一千行 harness 代码,到底是产品的核心资产,还是即将过时的过渡方案

唯一确定的是,所有故事的开头,都还是那个最朴素的 while 循环。


参考项目:shareAI-lab/learn-claude-code,一个把 Claude Code 拆成 12 个递进版本的开源教学项目。建议从 s01_agent_loop.py 开始读。

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

2026年4月7日 09:52

在这里插入图片描述

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 踩坑适配

2026年3月27日 17:36

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

作者 songgeb
2026年3月13日 08:07

深入理解代替单纯记忆

问题背景

  • 在开发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

参考

VSCode 插件全部无法激活?一次从日志到根源的排查记录

作者 wyanassert
2026年3月3日 16:34

VSCode 插件全部无法激活?一次从日志到根源的排查记录

引言

某天,你像往常一样打开 Visual Studio Code,却发现所有已安装的插件都失效了——代码补全没了、Git 信息不见了、主题也变回了默认。更诡异的是,重装软件、清理缓存、升级版本……常规手段统统无效。插件市场明明显示已安装,但就是无法激活。这究竟是怎么回事?

最近我就遇到了这样的棘手问题,经过一番抽丝剥茧,终于揪出了幕后黑手——一个看似无害的 GitBlame 扩展。下面我将完整还原整个排查过程,希望能为遇到类似问题的朋友提供一份实用的“避坑指南”。


第一阶段:基础排查(全军覆没)

当所有插件都无法激活时,首先排除环境因素:

  • 检查 VSCode 位置:确保 Visual Studio Code.app 位于“应用程序”文件夹,而非“下载”或桌面(权限问题会导致插件加载失败)。
  • 清理缓存与配置文件
    1
    2
    3
    rm -rf ~/.vscode
    rm -rf ~/Library/Application\ Support/Code
    rm -rf ~/Library/Caches/com.microsoft.VSCode
  • 彻底重装:删除上述所有文件后,从官网下载最新版重装。

然而,这一套组合拳下来,问题依旧。看来不是简单的缓存损坏。


第二阶段:启用“侦探模式”——挖掘日志

常规手段无效,就需要让 VSCode 自己“开口说话”。打开 帮助切换开发人员工具(或 Cmd+Option+I),在 控制台(Console)输出(Output) 面板中寻找线索。

果然,一条醒目的红色错误映入眼帘:

1
2
ERR Extension 'TME.continuecode CANNOT USE these API proposals 'extensionRuntime'. 
You MUST start in extension development mode or use the --enable-proposed-api command line flag

这里出现了一个陌生的扩展 TME.continuecode,它试图使用 提案 API(Proposed API)——这是 VSCode 内部开发中的接口,普通扩展无权调用。这种错误可能导致扩展半激活,甚至阻塞整个扩展宿主进程。

同时,日志中还发现了两个 CMake 扩展的冲突警告:

1
WARN [twxs.cmake]: 无法注册“cmake.cmakePath”。此属性已注册。

多个扩展争夺同一配置项,虽不致命,但加剧了环境的不稳定性。

初步行动:移除问题扩展

1
2
rm -rf ~/.vscode/extensions/tme.continuecode-*
rm -rf ~/.vscode/extensions/twxs.cmake-*

重启 VSCode 后,TME.continuecode 的错误消失了,但……扩展宿主依然无响应!日志中只剩下:

1
INFO Extension host (LocalProcess pid: 12485) is unresponsive.

看来凶手不止一个。


第三阶段:终极排查法——禁用所有扩展,逐个启用

当错误日志无法直接定位时,就要用最原始也最有效的方法:控制变量法

1. 以禁用所有扩展的模式启动

1
code --disable-extensions

启动后,VSCode 响应迅速,所有内置功能正常。这证实问题 100% 出在某个第三方扩展上

2. 二分法逐个启用扩展

退出纯净模式,正常打开 VSCode(此时所有扩展仍处于禁用状态)。然后进入扩展面板,每次启用一个扩展,重启观察是否复现无响应。这个过程需要耐心,但能精确锁定目标。

经过几轮测试,当启用 GitBlame 后,扩展宿主再次卡死。卸载该扩展,一切恢复如初。


第四阶段:真相大白

GitBlame 是一个提供 Git 逐行注释(blame)信息的扩展,功能简单但实用。但是十小时前这个插件更新后, 导致了问题.

替代方案

  • GitLens:功能强大且持续维护的 Git 工具,不仅能显示 blame,还提供丰富的仓库浏览功能。
  • Git History:轻量级替代品,专注于文件历史和逐行注释。

安装 GitLens 后,一切功能正常,再无卡顿。


总结:排查思路回顾

  1. 基础检查:确保 VSCode 安装位置正确,清理缓存。
  2. 日志分析:打开开发者工具,查看控制台和“扩展宿主”输出,寻找显式错误。
  3. 处理明显错误:如提案 API 滥用、扩展冲突,先移除可疑扩展。
  4. 禁用所有扩展:用 code --disable-extensions 确认问题是否由扩展引起。
  5. 二分法逐个启用:定位具体肇事扩展。
  6. 寻找替代或更新:对于老旧扩展,果断换用维护活跃的同类工具。

一些有用的命令

用途 命令
以最大日志级别启动 code --log trace --verbose
禁用所有扩展 code --disable-extensions
使用临时用户数据目录 code --user-data-dir ~/Desktop/vscode-temp
删除指定扩展 rm -rf ~/.vscode/extensions/扩展名-*

心得

  • 日志是第一生产力:遇到诡异问题,先看日志,往往能直接定位。
  • 老旧扩展是定时炸弹:长期未更新的扩展可能与新版 VSCode 不兼容,尽量选用维护活跃的替代品。
  • 控制变量法永不过时:当错误信息模糊时,通过排除法缩小范围是最可靠的手段。

希望这次分享能帮助你快速解决类似的插件故障。如果你也有过奇葩的排查经历,欢迎留言交流!

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

作者 iOS日常
2026年2月28日 17:14

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 垃圾清理

作者 iOS日常
2026年2月27日 17:42

一、可清理目录总览

场景 目录 是否可删 影响 建议
模拟器数据 ~/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 只删不用的设备版本,常用版本保留;再按需处理模拟器与旧归档。

❌
❌