tvOS 绝非 iPad 的放大版。本文是 Syncnext 播放器的工程实录，深入解析 Apple TV 开发的真实陷阱：从 Focus 焦点机制、严苛的存储限制，到 SwiftUI 填坑与 AVPlayer 深度调优，助开发者在 tvOS 平台上“活下来”

一、整体流程总览（先建立全局认知） Frida Hook = 三件事同时成立 ① 手机上运行 frida-server ② 电脑上安装 frida / frida-tools ③ 电脑 → 通过 US

这几天一口气刷完了 Netflix 出品的《黑白厨师》，感触颇深。没想到 Cooking 也能套上《鱿鱼游戏》的外壳：极简的规则，极端的赌注，有限的时间，封闭系统内的零和博弈。

在看之前，我对「温馨的烹饪」能否与「大逃杀美学」兼容是非常存疑的。但看完后不得不佩服，Netflix 不仅处理得很好，还在这场残酷的阶级叙事中，端出了一盘关于「人性」与「身份」的顶级料理。

机制：绝对真空里的「强制公平」

如果把《黑白厨师》看作一部韩剧，「机制」就是它最精彩的剧本。烹饪综艺最大的痛点在于：味觉是主观的，如何保证结果的公正与说服力？

节目组做了一个极其大胆的设定——蒙眼试吃。

当白钟元和安成宰蒙上眼睛，张嘴等待喂食时，这画面不仅充满了某种荒诞的宗教仪式感，更是一种暴力的强制公平。它强行抹去了「白汤匙」积累数十年的名声红利，把米其林三星主厨和外卖店老板拉到了同一条起跑线（味蕾）上。这种「在一个不公平的世界里创造一个残酷但公平的真空」，正是大逃杀题材最迷人的地方。

而评委的「双璧」设定，则是机制中另一个神来之笔。白钟元代表着「大众的味蕾」与「商业的敏锐」，追求直觉的爽感；安成宰则代表「精英的标准」与「技术的严苛」，追求意图的精准。两人的争论，实际上是将「好吃究竟有没有标准」这一哲学命题具象化了。这种价值观的碰撞，也是一大看点。

场景：感官的高压工厂

Netflix 的综艺有一种你一看就知道是「Netflix 出品」的质感。巨大的仓库、整齐划一的 40 个烹饪台、冰冷的不锈钢，当 40 名黑汤匙同时开火，那个画面不像厨房，更像是一个高压工厂或战场。为了满足 4K/HDR 的严苛画质，灯光采用了电影级的布光，甚至连声音设计都做到了极致——备菜的切剁声、炉火的轰鸣声，营造出一种 ASMR 般的沉浸感（一种让人头皮发麻、脊背发凉但又感到极度舒适和放松的生理反应）。这种极致的物理压迫感，会把屏幕前的观众也拉进去（所以一定要看高清的）。

玩家：艺术家与谋略家

如果说机制如剧本，厨师就是演员。除了对「厨艺」和「哲学」的考核，这档节目更深层地展现了「生存博弈」。

这就不得不提崔铉硕主厨。如果说其他人是在比赛做菜，那么崔铉硕更像是在「玩游戏」。在团队海鲜战中，他疯狂囤积扇贝让对手无材可用；在餐厅经营战中，他制定超高价策略，以极少的出餐量换取了最高的营业额。他敏锐地捕捉到了现代餐饮的残酷真相：厨艺好不等于会经营，商业头脑往往决定生死。

他的存在，打破了传统厨师的刻板印象，为节目注入了《鱿鱼游戏》的智斗感。

当然，这也是一个群像极佳的舞台。制作组显然精心挑选了那些拥有「鲜活、粗糙且充满生命力故事」的人。如果没有这些故事，这就是一场单纯的技艺展示；有了这些故事，菜品就有了灵魂。

核心人物：诗意与狂傲

最终的决战也是我心目中最好的结局，两位风格迥异的厨师，分别代表了烹饪的两个极端。

Edward Lee：寻找归途的诗人

看到 Edward Lee 的第一眼，就感觉到一种不一样的气质：说话不疾不徐，有一种淡淡的诗意。即使年过半百，依然像个少年一样在寻求突破。

对于他而言，这不仅仅是比赛，更是一场「身份认同的寻根之旅」。作为一个在美国长大的韩裔，他的料理（如拌饭口味的冰淇淋）本身就在挑战「正统韩餐」的定义。决赛那道「辣炒年糕点心」是整季的高光时刻。当他用不熟练的韩文念出那封信，讲述「Edward 喜欢威士忌，但李均（他的韩文名）喝玛格丽」时，那种异乡人的孤独与对故土的深情，瞬间把我击穿。

那不勒斯美味黑手党（权圣晙）：专注的狂徒

如果 Edward 是水，权圣晙就是火。他身上体现的是年轻人的自信、狂傲，以及极致的专注。

在败者复活赛中，当所有人都在做咸口菜时，他独辟蹊径选择做甜品「栗子提拉米苏」。为了防止食材被拿走，他守在冷柜前啃巧克力的画面，有一种「认真的拙劲」。他选择 Edward Lee 战队时的果断，以及决赛前的放狠话环节，都展现了他极强的策略性和胜负欲：

“爱德华主厨，为了让你早点回家休息，今天我会速战速决。”

这种狂傲并不让人讨厌，因为他有与之匹配的实力。

---

我有时也会切换视角：假如自己是 Netflix 的决策者，面对这样一个项目，如何确保「基本能回本」（保底能力），同时又可能挣很多（其实就是价值投资）？对于白汤匙、黑汤匙、白钟元、安成宰，他们决定参与的动机是什么？杠杆点在哪儿？如果最后项目失败了，最可能是哪些地方出了问题？这样的思考也充满了乐趣。

关于好奇心的重要性，怎么强调都不为过。尤其是在工作了一段时间之后，好奇心往往最先被消磨：流程变得熟悉、问题开始重复、注意力被琐碎事务和压力不断切割，慢慢地，我们便不再追问「为什么」。

为了对抗这种精神熵增，我总结了一套简单易行的思维训练法。通过四种「角色扮演」模式，强制切换视角，外加一个通用框架作为辅助工具，帮助我们找回对世界的敏锐度。

---

1. ET 模式（外星人视角）：对抗「习以为常」

核心理念：去熟悉化（Vuja De）

我们常说 Déjà vu（既视感），即对陌生环境感到熟悉；而 ET 模式追求的是完全相反的状态——Vuja De（未视感）。即：面对最熟悉的事物，强迫自己把它当成第一次见到，甚至完全不理解其用途。

• 「火星人观察报告」：尝试描述一件日常小事，但不使用约定俗成的名词。以「开会」为例，如果剥离掉「会议」这个概念，在 ET 眼中看到的是：一群碳基生物围坐在一张木板旁，地位最高的雄性发出声波，其余低阶生物低头在发光的玻璃板上快速移动手指。洞察：这种视角的价值在于剥离了社会强加给事物的「功能固着」。当不再把「低效的会议」理所当然地看作「工作流程」，才更有可能发现其本质——比如「信息传递效率极低」，进而思考：为什么不直接进行脑电波传输（发文档）？
• 「为什么追问链」：因为 ET 从没见过地球的物品，所以一切都值得质疑。顺着这个逻辑链条深挖：为什么手机屏幕是长方形的？（为了适应手掌抓握）；为什么一定要手持？（因为要随时观看）；为什么一定要用眼睛看？（目前的信息交互受限于视觉）。这种像孩子一样的连续追问（比如我小时就很好奇，为什么大人们打招呼通常都是「饭吃了吗」），往往能带我们穿透表象，触达事物的底层逻辑或生理极限。

2. 福尔摩斯模式（侦探视角）：对抗「视而不见」

核心理念：观察而非仅仅「看见」

福尔摩斯有一句名言：「你只是在看，你没有在观察。」 (You see, but you do not observe.) 这个模式要求我们将模糊的现状清晰化，寻找因果链条和逻辑漏洞。

• 从废弃中寻找线索：最近在看《黑白大厨》时，注意到一个细节：评审白钟元注意到角落里有一碟被回收的、只吃了一半的牛肉。其他选手都没有注意到，他还拿起其中一块没被吃过的牛肉品尝，发现牛肉过于干柴。 这就是侦探视角——从被忽略的细节（剩菜）中反推过程（烹饪失误），进而挖掘出被掩盖的真相。
• 关注「沉默的证据」：除了看到的，还要关注没发生的。比如在福尔摩斯的《银色马》一案中，关键线索是「那只在晚上没有叫的狗」。因为狗没叫，所以牵走马的人一定是熟人。在工作中，如果能注意到「谁没有发声」、「哪个数据没有变化」，有时能发现比喧嚣表面更重要的信息。

3. 马尔科维奇模式（体验视角）：对抗「自我中心」

核心理念：深度沉浸与换位思考

概念源自电影《成为马尔科维奇》，主角通过一道暗门能直接进入马尔科维奇的大脑，透过他的眼睛看世界。在生活中，这个模式几乎随处可用。

比如在咖啡馆里，可以尝试切换视角：

• 作为店员：

  • 为什么选择这家店？
  • 需要哪些技能？
  • 如果跳槽，可能会去哪里？

• 作为老板：

  • 为什么选址在这里？
  • 与周围咖啡馆的差异是什么？
  • 收入、成本、利润结构大概如何？
  • 哪些地方还有改进空间？

看剧时同样适用。比如：如果我是《绝命毒师》里的老白，在被 Tuco 掳走、Tuco 又被杀之后，该如何解释自己的失踪，既合情合理，又不引起怀疑？

4. 爱迪生模式（实验视角）：对抗「光想不做」

核心理念：假设与验证

爱迪生代表的是实干派与实验精神。当对某个现象产生好奇，比如「为什么这类小红书帖子会火？」不只停留在分析。试着提出假设（可能是封面图夸张，也可能是标题引发焦虑），然后设计一个低成本的实验——发几篇不同风格的帖子去验证你的假设。在产品领域，这就是先做 Demo 验证可行性。唯有实验，才能将好奇心转化为确定的认知。

一个通用框架：3W2H

最后分享一个我自己经常使用的框架：3W2H。它是在黄金圈法则（Why–How–What）基础上的扩展，更适合日常思考。

以「电视」这个习以为常的物品为例：

• What（本质）：它是什么？是显示屏，还是家庭娱乐中心？
• Why（根源）：为什么我们需要电视？是为了获取信息，还是为了背景噪音？
• How（机制）：它的运作原理和组成是什么？
• How much（量化）：它的价格构成是怎样的？覆盖了多少人群？
• What if（假设）：如果世界上没有电视会怎样？有完美的替代品吗？

这套组合拳能迅速将一个单薄的概念拆解得立体而丰满，在短时间内建立对陌生领域的深度认知。

---

好奇心不仅是一种能力，更是一种对抗平庸的武器。当我们开启 ET 的眼睛，用福尔摩斯的大脑思考，钻进马尔科维奇的躯壳，并像爱迪生一样去动手实验时，原本枯燥乏味的世界就会立刻生动起来。

世界没有变，变的是我们看待世界的分辨率。希望这四种模式和工具，能帮你擦亮积灰的镜头，重新发现那个充满惊奇的「新世界」。

Capacitor + React 的 iOS 侧滑返回手势的问题，二级页面无法侧滑返回；能侧滑但上级页面预览是白屏/黑屏（看不到上一页内容）；自己实现手势会引入大量时序/兼容性的坑。

0️⃣ 🐼 序章：万劫谷的“失灵”现场 万劫谷，一个充满了陷阱和奇门遁甲的虚拟测试环境。 大熊猫侯佩正在谷中寻找他那四根宝贝竹笋的踪迹（它们现在安全地储存在 InlineArray 里），一路上他习惯

引子 在新深圳（Neo-Shenzhen）第 42 区阴雨连绵的夜晚，王代码（Old Wang）坐在全息屏幕前，手里捏着半截早已熄灭的合成烟草。作为一名在赛博空间摸爬滚打二十年的“数字清道夫”，他见过

**DTBluetoothProvider** 是一个跨平台的高级蓝牙服务封装库，提供了完整的蓝牙设备管理解决方案。该库**同时支持经典蓝牙（Classic Bluetooth）和低功耗蓝牙（BLE）

PolarisGuideKit：轻量、低侵入的 iOS 新手引导组件（遮罩挖孔 + Buddy View + 插件化） GitHub：https://github.com/noodles1024/Po

本期聚焦非 AI、纯手工带来的乐趣与实感，其他内容涵盖 Swift 嵌入式开发、CkSyncEngine 实战、Tab Bar 吐槽、大模型应用技巧等。由肘子的 Swift 周报呈现。

软件系统的运行过程本质上是不可见的。绝大多数行为发生在内存与线程之中。在本机调试阶段，我们可以借助断点、内存分析、控制台等手段直接观察系统状态；而一旦进入生产环境，这些能力几乎全部

学车时我开的是手动挡，起初因为技术生疏，常搞得手忙脚乱，所以第一台车就直接选了自动挡。但开了几年，我开始追求那种完全掌控的驾驶感，于是又增购了一台手动挡。遗憾的是，随着交通日益拥堵，换挡的乐趣逐渐被疲惫抵消，最终这台车也被冷落。算起来，我已经快二十年没认真开过手动挡了，但内心深处，我仍会时不时地怀念那段“人车合一”的时光。

关于 Agent 模型的思维链，之前被几个高大上的词绕晕了，claude 提出 Interleaved Thinking（交错思维链），MiniMax M2 追随和推动标准化，K2 叫 Thinking-in-Tools，Deepseek V3.2 写的是 Thinking in Tool-Use，gemini 则是 Thought Signature（思考签名）。了解了下，概念上比较简单，基本是一个东西，就是定义了模型思考的内容怎样在 Agent 长上下文里传递。

是什么

在25年年初 deepseek 的轰炸下，思考模型大家都很熟悉了，在 Chatbot 单轮对话中，模型会先输出思考的内容，再输出正文。再早的 GPT-o1 也一样，只不过 o1 不把完整的思考内容输出。

在 Chatbot 进行多轮对话时，每一次思考的内容是不会再带入上下文的。每次到下一轮时，思考的内容都会被丢弃，只有用户 prompt 和模型回答的正式内容会加到上下文。因为在普通对话的场景下没必要，更倾向于单轮对话解决问题，长上下文会干扰模型，也会增加 token 消耗。

这些思考模型用到 Agent 上，就是下图这样，每次模型输出工具调用，同时都会输出 thinking 内容，思考应该调什么工具，为什么调，但下次这个思考内容会被丢弃，不会带入上下文：

Agent 的 loop 是：用户输入 → 模型输出工具调用 → 调用工具得出结果 → 模型输入下一步工具调用 → 调用工具得出结果 → …. 直到任务完成或需要用户新的输入。

这不利于模型进行多轮长链路的推理，于是 claude 4 sonnet 提出把 thinking 内容带入上下文这个事内化到模型，以提升 Agent 性能，上下文的组织变成了这样：

就这样一个事，称为 Interleaved Thinking，其他的叫法也都是一样的原理。

为什么要带 thinking

面向 Chatbot 的模型，倾向于一次性解决问题，尽量在一次 thinking 一次输出解决问题。

Agent 相反，倾向于多步不断跟环境( tool 和 user )交互解决问题。

Agent 解决一个复杂问题可能要长达几十轮工具调用，如果模型对每次调用工具的思考内容都抛弃，只留下结果，模型每次都要重新思考每一轮为什么要调这个工具，接下来应该调什么工具。这里每一次的重新思考如果跟原来的思考推理有偏移，最终的结果就会有很大的出入和不稳定，这种偏移在多轮下几乎一定会发生。

如果每一轮调用的思考内容都放回上下文里，每次为什么调工具的推理逻辑上下文都有，思维链完整，就大大减少了模型对整个规划的理解难度和对下一步的调用计划的偏差。

有没有带 thinking 内容，对效果有多大差别？MiniMax-M2 提供了他们的数据，在像 Tau 这种机票预订和电商零售场景的任务 benchmark 提升非常明显，这类任务我理解需要操作的步数更多（比如搜索机票→筛选过滤→看详情→下单→支付），模型在每一步对齐前面的思路很重要，同一个工具调用可能的理由随机性更大，每一步的思考逻辑带上后更稳定。

工程也能做？

这么一个简单的事，不用模型支持，直接工程上拼一下给模型是不是也一样？比如手动把思考内容包在一个标签(<think>)里，伪装成 User Message 或 ToolResult 的一部分放在里面，也能达到保留思考的效果。

很多人应该这样做过，但跟模型原生支持还是有较大差别。

工程手动拼接，模型只会认为这部分仍是用户输入，而且模型的训练数据和流程没有这种类型的用户输入和拼接，效果只靠模型通用智能随意发挥。

模型原生支持，训练时就可以针对这样规范的上下文训练，有标注大量的包含思考过程的 trajectory 轨迹数据训练，响应的稳定性必然会提升，这也是 Agent 模型的重点优化点之一。

签名

上述工具调用的 thinking 内容带到下一轮上下文，不同的模型做了不同额外的处理，主要是加了不同程度的签名，有两种：

thinking 内容原文，带签名校验

claude 和 gemini 都为 thinking 的内容加了签名校验，带到下一轮时，模型会前置判断思考内容有没有被篡改。

为什么要防 thinking 内容被篡改？毕竟 prompt 也可以随便改，同样是上下文的 thinking 内容改下也没什么。

主要应该是篡改了模型的 thinking 内容会打乱模型的思路，让效果变差，这也是需要避免的。

另外模型在训练和对齐时，已经默认 thinking 是模型自己的输出，不是用户随意的输入，这是两个不同类型的数据，如果实际使用时变成跟Prompt一样可随意篡改，可能有未知的安全问题。

不过国内模型目前没看到有加这个签名校验的。

thinking 内容加密

claude 在一些情况下不会输出自然语言的 thinking 内容，而是包在redacted_thinking里，是一串加密后的数据。

而 gemini 2.5/3.0 的 Agent 思维链没有明文的 thinking 字段，而是 thought_signature，也是一串加密后的数据。

用这种加密的非自然语言数据，一个好处是，它可以是对模型内部更友好、压缩率更大的数据表述方式，也可以在一些涉及安审的场景下内容不泄露给用户。

更重要的还是防泄漏，这就跟最开始 GPT o1 不输出所有思考内容一样，主要是为了不暴露思考过程，模型发布后不会太轻易被蒸馏。

最后

目前 claude 4 sonnet、gemini 3 在 Agent 工具调用的场景下，都强制要求带工具调用的思考内容和签名，这个链路正常是能很大程度提升整体的推理执行效果，是 Agent 多步骤推理的必需品。

但目前 Agent 模型的稳定性还是个问题，例如在某些场景下，业务逻辑明确需要下一步应该调工具 A，但模型思考后可能就是会概率性的调工具B，在以前是可以直接 hack 替换调工具调用，或手动插入其他工具调用，没有副作用。

但在思维链这套机制下比较麻烦，因为没法替模型输出这个工具调用的思考内容，一旦打破这个链，对后续推理的效果和稳定性都会有影响。

可能模型厂商后续可以出个允许上层纠错的机制，例如可以在某个实际告诉函数工具选择错误，重新思考，原生支持，弥补模型难以保障稳定的不足。

**进制（Number System）**，也称为**数制**或**进位计数制**，是一种表示数值的方法。它定义了： - **基数（Base）**：表示该进制使用多少个不同的数字符号 - **位权（P

蓝牙技术（Bluetooth）是一种短距离无线通信技术标准，由蓝牙技术联盟（Bluetooth Special Interest Group, Bluetooth SIG）制定和维护。其名称来源于..

在 Swift 并发系统（Swift Concurrency）诞生之前，iOS 开发者的日常被回调（Callbacks）、代理（Delegates）和 Combine 填满。我们用这些工具来处理应用中

这次的新政细化了隐私合规规则，堵住了一些规则漏洞，进一步保护用户隐私。对于大部分开展正规业务的开发者来说，无需特别的改动。后续可按渠道平台（华为、小米等）要求，做进一步调整

**物联网通信协议**是指在物联网系统中，用于实现`设备之间`、`设备与云端之间`数据传输和通信的标准化规则和约定。这些协议定义了`数据格式`、`传输方式`、`错误处理`、`安全机制`等技术规范，确保

老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

文章

🐎 我们如何使用 Codex 在 28 天内构建 Android 版 Sora

@Crazy：本篇文章简略的讲述了 OpenAI 的工程师团队是如何利用 CodeX 在 28 天内开发 Sora 的 Android 版本，主要可以分为以下四个部分

1. 在 Codex 在整个代码库中创建和维护大量 AGENT.md 来引导新的开发工程师，减少重复的沟通和模版代码，增加测试量，让团队专注于架构、用户体验、系统性变更和最终质量。
2. 利用项目的整体规则，编写部分具有代表性的端到端功能。通过将 Codex 指向具有代表性的功能，让 AI 在一个标准范围内工作，提高 AI 的生成准确性与工作效率。
3. 在编写代码前使用 Codex 进行规划，利用相关文件并总结该功能的运作原理，即了解 CodeX 是如何从 API 到用户界面的生成过程，并且在生成后进行对应的架构纠正，利用这种可分享的动态策略让 CodeX 生成更加符合架构的代码。
4. 同时运行多个 Codex 会话，一个会话负责回放，一个负责搜索，一个负责错误处理，还有一个则负责测试或重构。多会话会大大提高整体开发效率，并让开发人员处在审核的位置上，而不是开发的位置上。

最后是利用 CodeX 的上下文来让他发挥到最佳水平，也可以跨平台进行上下文分析，但没有上下文就是盲目猜测。

🐕 Tracking renamed files in Git

@Barney：本文聚焦 Git 不直接追踪文件重命名的核心特性，解析其通过文件内容相似度启发式算法推测重命名的逻辑。为确保历史追踪准确，核心建议将重命名单独提交，推荐借助 git mv 命令（暂存重命名操作、保留文件编辑未暂存状态）实现。同时提供替代脚本方案，解决无法使用 git mv 时，重命名与编辑同步进行导致的追踪难题，助力高效管理文件版本历史。

🐕 Replay

@Smallfly：这篇文章介绍了 Swift 生态中解决网络测试痛点的工具 Replay，通过记录与重放真实 HTTP 流量，为测试提供高效、稳定的解决方案。核心亮点包括：

• 痛点解决：针对网络测试慢、依赖第三方服务不稳定、手动维护 JSON 响应文件易过时的问题，Replay 实现「记录一次，永久重放」，避免测试受网络波动影响。
• 技术优势：采用行业标准 HAR（HTTP Archive）格式存储流量，兼容浏览器开发者工具、Charles 等工具；结合 Swift 6.1 的 TestScoping 协议与包插件，实现声明式测试配置。
• 工作流程：首次运行测试时提示记录，后续自动使用本地 HAR 文件，测试速度从分钟级降至秒级。
• 灵活配置：支持过滤敏感数据、自定义请求匹配规则，并提供内联存根功能，适配错误处理等边缘场景。

文章通过代码示例与实践建议，展示了 Replay 如何让网络测试更可靠、高效，是 Swift 开发者优化测试流程的实用参考。

🐎 Flutter 官方正式解决 iOS 26 上的 WebView 有点击问题

@david-clang：对于 Flutter WebView 在 iOS 26 点击失效和触摸穿透的问题，官方技术文档详细阐述了问题原因和解决方案，最终方案是 Flutter Engine + iOS embedder 新增 “同步 hitTest 回调” 能力，将手势决策从“异步协同”改为“同步拦截”，在触点处直接判断是否应拦截手势，从根本解决 WebView、AdMob 等 PlatformView 的手势冲突问题。

因为底层的重构方案还需要上层插件进行适配，官方又合入了个无需插件适配的临时方案作为补充：在 FlutterPlatformViews.mm 中实现了针对 WKWebView 手势识别器的递归搜索和“重启”机制，并在 blockGesture 中针对 iOS 26+ 启用了这个机制。

代码

React Native for macOS

@EyreFree：微软 react-native-macos 仓库值得关注！作为 Facebook React Native 的开源分支（MIT 许可），它支持用 React 快速构建原生 macOS 应用，兼容 macOS 11+。具备声明式 UI、组件化开发、热重载等优势，还能跨 iOS、Android 复用代码，配套完善文档与贡献指南，更新维护活跃，是 macOS 原生应用开发的高效选择，感兴趣的同学可以试试。

Skills Public

@含笑饮砒霜：这是一个聚焦于 SwiftUI UI 设计模式的代码仓库，核心围绕 SwiftUI 框架提供各类实用的 UI 实现方案、设计最佳实践和代码示例，面向 iOS/macOS 等平台开发者，旨在解决 SwiftUI 开发中常见的 UI 构建问题、统一设计范式。适合 iOS/macOS 开发者（尤其是 SwiftUI 初学者 / 进阶者），可作为 SwiftUI UI 模式的参考手册，快速复用成熟的设计和代码方案，避免重复踩坑。

内推

重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）