普通视图

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

老司机 iOS 周报 #354 | 2025-10-13

作者 ChengzhiHuang
2025年10月12日 19:46

ios-weekly
老司机 iOS 周报,只为你呈现有价值的信息。

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

新手推荐

🐎 Understanding Deflate

@xiaofei86:本文通过手工解码一个 gzip 文件,简单探究了其压缩算法 Deflate 的工作机制,Deflate 结合了 LZ77 算法与 Huffman 编码,通过用 “复制指令” 替代重复片段实现无损压缩。作者以字符串 "TOBEORNOTTOBEORTOBEORNOT" 为例,先解析 gzip 文件头尾结构,再根据 Deflate 规范逐位还原压缩块内容,实现了从 24 字节到 16 字节的压缩。感兴趣的同学可以阅读更多文章了解 ~

文章

🐢 Code along with the Foundation Models framework

@Cooper Chen:这篇文章介绍了 Apple 在 WWDC 2025 推出的 Foundation Models 框架,展示了如何在 iOS 与 macOS 应用中直接调用系统内置的大语言模型,实现真正的 on-device AI。通过一个“旅行行程生成器”的示例,作者带你一步步完成从文本生成到结构化输出的全过程,深入展示 Apple Intelligence 的开发潜力。

主要亮点包括:

  • 隐私与安全:模型完全在设备上运行,无需上传数据或调用云端接口。
  • 结构化输出:利用 @Generable 让模型直接生成 Swift 类型的数据,而非普通文本。
  • 提示优化技巧:通过 instructions、示例(one-shot)提升输出质量与稳定性。
  • 流式响应:实时展示生成过程,让用户体验更自然流畅。
  • 工具调用(Tool Calling):让模型能主动调用外部函数或服务,融合实时数据与智能生成。

这篇文章不仅是一份技术指南,更是 Apple 对 AI 未来方向的实践展示。
它强调 隐私优先、系统原生、开发高效 的理念,是每位希望深入了解 Apple Intelligence 的开发者必读之作。

🐎 Enabling enhanced security for your app

@Damien:这篇文章介绍了如何在 Xcode 中为应用启用增强安全性的方法,包括启用地址空间布局随机化(ASLR)、栈保护、堆保护、整数溢出检查和缓冲区溢出检查等编译器安全功能,以防御常见漏洞并提升应用抗攻击能力。

🐕 How to install Xcode 26's Metal Toolchain on CI/CD

@Barney:我来帮您获取并总结这篇文章的内容。这篇文章介绍了 Xcode 26 不再默认包含 Metal 工具链的问题及解决方案。在本地开发时可通过 Xcode 偏好设置安装,但在 CI/CD 环境(包括 Xcode Cloud)中需要使用 xcodebuild 命令行工具手动下载和安装。文章提供了具体的脚本代码,建议在 Xcode Cloud 中作为 post clone 脚本运行。

工具

swift-profile-recorder

@Smallfly:Swift Profile Recorder 是一款「进程内」采样分析器,专为受限容器环境而生:不需要 CAP_SYS_PTRACE,就能在 Linux 与 macOS 上抓取 on-CPU 与 off-CPU 样本,定位真实的性能瓶颈。你只需以 Swift 包集成并启用内置服务器,即可用一次 curl 拿到已符号化的 Linux perf 格式数据,直接拖到 Speedscope / Firefox Profiler 或用 FlameGraph 生成火焰图。集成轻量、开销可控,特别适合线上 Kubernetes/Docker 场景的故障排查与持续优化。

内推

重新开始更新「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)

老司机 iOS 周报 #353 | 2025-09-29

作者 ChengzhiHuang
2025年9月28日 12:02

ios-weekly
老司机 iOS 周报,只为你呈现有价值的信息。

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

文章

🐢 We Need to Talk About Observation

@Smallfly:这篇文章深度探讨了 Swift 观察机制的新旧范式更迭,从 ObservableObject + Combine 的旧时代到 @Observable 宏 + Observations 结构体的新生态,揭示了迁移过程中的关键挑战与设计考量。核心内容包括:

  • 旧范式的价值:回顾 @Published + Combine 在对象间观察(如 UserCoordinatorSyncEngine)的简洁性——自动管理订阅生命周期、支持跨对象响应,为复杂业务逻辑提供低耦合解决方案。
  • 新范式的突破与局限:分析 @Observable 宏在 SwiftUI 集成(属性访问优化、嵌套支持)的优势,同时指出 withObservationTracking(单次触发需递归调用)与 Observations 结构体(任务生命周期管理复杂)在非 UI 场景的不足——订阅取消需手动管理 Task、对象弱引用易出错。
  • 迁移建议:强调选择方案时需超越 UI 层考量,关注业务逻辑中对象间观察的实际需求,避免因新特性的「表面简洁」忽略生命周期管理的潜在风险。

文章以开发者视角对比新旧机制的工程实践差异,为理解 Swift 观察体系演进提供了务实的参考。

🐕 Xcode Migrations: From Stone Age to AI Mastery

@Barney:这篇文章讲述了 Qonto 团队如何将 Xcode 升级从三周噩梦转变为一天自动化流程。
背景: 60+ iOS 工程师团队面临 Xcode 升级瘫痪开发流程的问题,依赖管理冲突和构建失败频发。
核心改进:

  • 架构优化:移除 CocoaPods,统一使用 Swift Package Manager
  • 自动化监控:Swift 构建的 Xcode Release Checker,CI 监控版本发布并 Slack 通知
  • 沟通策略:建立迁移门户和可视化时间线,团队理解度从 33% 提升至 90%
  • CLI 工具:Swift 自动化迁移流程,包括分支创建、构建清理、版本更新等
  • AI 集成:构建 Swift MCP 工具和 Xcode Migrator AI 助手,提供 24/7 技术支持

效果: 迁移时间从 21+ 天缩短至 5 天(75% 减少),60+ 工程师零工作中断。通过持续改进理念,将最大痛点转化为竞争优势,目标进一步缩短至 1 小时。

🐢 iOS Rendering Documentation

@Kyle-Ye: 这份文档深入剖析了 iOS 渲染系统的底层架构,详细阐述了从 UIView 到 CALayer、CAContext 再到 FBSScene 的完整渲染管道。文档特别解释了 Front Board Scene (FBS) 的工作机制以及 CAContext 的 contextID 如何用于跨进程 IPC 通信。内容涵盖了层级合成模型、场景管理、渲染同步、动画协调等核心概念,为理解 iOS 图形系统提供了前所未有的技术深度。对于需要进行系统级渲染研究、性能优化或底层拦截开发的高级 iOS 开发者来说,这是一份极其宝贵的参考资料。

🐎 Should you opt-in to Swift 6.2 ’ s Main Actor isolation?

@DylanYang:Xcode26 为工程带来了新的 actor 隔离默认配置值,允许全局的代码默认运行在 main actor 上。作者通过一些 demo 讲述了启动此配置后能帮助我们简化大量的标记 @mainactor 的代码,降低了并发代码的复杂度。同时作者建议大部分情况下可以默认开启此配置,并通过 @Concurrent 标记来让特定代码去后台线程运行。感兴趣的开发者可以阅读本文详细了解下开关带来的实际影响。

🐎 Flutter 官方 LLM 动态 UI 库 flutter_genui 发布,让 App UI 自己生成 UI

@Crazy:现今在开发者领域 AI 已经进入了日常开发的方方面面,AI 生成 UI 也是大模型落地的一个方面,Flutter 官方更是开发了一个可以利用大模型动态生成 UI 的库,该库用“受控、可组合、可回传状态”的运行时 UI 替代文本,显著提升 AI 交互质量,并且与主流 LLM 框架的顺滑对接。但是更新也更加频繁,UI 的更新消耗也是很大的。该库主要的五个概念分别为 :UiAgent、Widget Catalog、AiClient、GenUiManager、GenUiSurface。关于具体的生成,可以看文章中的实例与图片演示。文章中提到的 Filebase 与 Gemini,都是由 Google 开发的,对国内开发者都不是很友好。

内推

重新开始更新「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)

老司机 iOS 周报 #352 | 2025-09-22

作者 ChengzhiHuang
2025年9月21日 19:57

ios-weekly
老司机 iOS 周报,只为你呈现有价值的信息。

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

新闻

🌟 🐕 Swift 6.2 正式发布

@kemchenj:随着 Swift 语言本身走向成熟,每年的更新慢慢的已经不是集中在语言功能上,投入了更多的精力到工具链和生态建设上。

更加平易近人的 Concurrency

  • 默认使用 @MainActor,减少显式的 isolation 标记
  • 更加直观的 async 函数,默认在 caller 的上下文里执行,让 class 类型里可以用更简洁直观的方式去实现没有数据竞争的逻辑
  • 新增 @concurrent 函数注解,把任务派发到全局任务池

前两个功能都是可以手动开启和关闭的,由于前面两个功能开启后,非 actor 环境下的 async 函数全部都会派发到 @MainActor 执行,导致主线程负载变大,所以新增 @concurrent 可以制定任务派发到全局线程。这几套组合拳下来大大加强了 Concurrency 的易用性。

安全的系统级编程功能

  • InlineArray:固定大小的内联数组
  • Span:可以理解为类型安全的 Buffer 类型
  • 嵌入式 Swift:新增全套 String / InlineArray / Span API
  • C++ 互操作:可以通过 header 标注混合使用两个语言里的 Span 的类型

工具链

  • VSCode 插件更新
  • 更加细化的编译警告控制
  • 更快的 Macro 编译速度(通过下载预编译的 swift-syntax 包)
  • 优化 async 调试功能的体验和稳定性

核心库更新

  • Subprocess:一套全新的 Swift 原生进程接口
  • Foundation:NotificationCenter 新增一套类型安全,拥抱 Concurrency 的接口
  • Observation:提供更加易用的 async sequence 接口
  • swift-testing:新增 API 提高测试代码的表达能力

更多详细信息请查看原文。

文章

🌟 🐢 KMP on iOS 深度工程化:模块化、并发编译与 98% 增量构建加速

@JonyFang: 本文主要介绍了 Bilibili KMP 在 iOS 工程化的一些深度改造,达成模块化、并发编译与 98% 增量构建加速的目标。主要通过对 Kotlin/Native 编译管线的深度拆解与重构,系统性地解决了其在模块化、编译并发和增量构建方面的核心瓶颈。

在构建系统与编译速度上 :实现了 Parallel Compilation,将每个 Kotlin 模块独立编译为 .a 文件,在一些日常的底层修改的场景下最终产物编译耗时降低 98% 。这充分释放了 Bazel 的高并发优势,结合可靠的 remote cache 机制达到 Never clean build 的预期。

在编码与跨语言交互上:摆脱了 KMP 默认的“大一统”框架模式。通过为每个 Kotlin 模块生成独立的 Clang module ,并以 @ObjCExport 注解精确控制导出,实现了真正的模块化。

在调试与工程化上:通过修复 source-map 路径和实现可靠的 implementation_deps ,保证了跨语言调试的稳定性和构建的确定性,解决了社区方案中的常见痛点。

也推荐几篇前几期的相关阅读:

🐎 Automating Github Action Workflows For Swift

@Damien:作者重启搁置的 ActionBuilder 项目,通过扫描 Package.swift 实现零配置生成 GitHub Actions tests.yml,借 Swiftly 自动识别 Swift 版本并调度 Linux/macOS runner,对 iOS 等 Apple 平台则调用 Xcode 构建且已适配 Swift 6.0-6.2,未来将以轻量 CLI 取代插件,可直接嵌入 Xcode build phase 随编译自动更新工作流。

🐕 认知负荷才是关键

@zhangferry:编程领域有很多指导性的理论知识,但这些业界的实践,为什么并非总是有效呢?基于这个问题本文引出认知负荷这个概念:认知负荷是指开发者为了完成一项任务需要动多少脑子。从人的视角出发,以是否便于理解来衡量代码好坏,并给出了以下 4 个降低认知负荷的原则:

  • 模块设计:不应一味的强调小方法,小模块,这会导致过多的接口和代码关联,增加认知负荷。深方法,深模块,一定程度把复杂度限定在特定范围,整体维护成本更低。

  • 架构选择:不应为体现技术水平采用过于复杂的架构,易懂、易理解的架构才更合适。文中还建议在架构评审时可以让初级开发者参与,以识别过于复杂的设计。

  • 抽象和代码组织:不应过于追求 DRY(不要重复自己),而大量使用设计模式,微服务等,少量的重复比不必要的依赖更好。

  • 心智模型:传统推崇的心智模型(领域驱动设计 DDD)有其优势,但副作用是会引入很多主观理解,这个基础之上开发的代码往往会有更高的认知负荷。好的代码应该便于理解,而不是追求优雅和复杂。

延伸的几种观念,可能只看名称你就能知道个大概了:「可能是时候停止推荐《代码整洁之道》」、「小型函数的弊端」、「为什么我讨厌“框架”」、「设计牺牲」

🐢 阿权的开发经验小集

@阿权:阿权的日常开发小集,记录了日常开发中踩过的大小坑,内容主要涵盖 Git、iOS、Swift、Xcode 等方面问题的总结。按需搜索,说不定有意外的惊喜。

🐕 iOS26 Runtime Changes:Concurrent mutation of nonatomic properties

@ChengzhiHuang:对于 NSObject 的 property 是 nonatomic 的对象类型时,多线程的 set/get 会存在线程安全问题(非对象一样存在问题,只是不会崩溃),一个简单的修改方案是改为 atomic,注意这个只对一般对象有效。如果是 NSMutableDictionary 等容器对象,还需要考虑对其容器内内容的修改也要注意线程安全,一般得加锁解决;更极端需要多个属性同时保持同步则也得加锁。问题不仅在 property 中存在,全局变量也一样存在问题。具体可以参考我们推荐过的 头条稳定性治理:ARC 环境中对 Objective-C 对象赋值的 Crash 隐患

在 iOS 26 以前,一般概率发生的崩溃崩溃的栈顶也在 objc_retain/objc_release 中;在 iOS 26 及之后,则如果发生这种线程安全问题,栈顶函数不变的情况下,会有明确的 EXC_BAD_ACCESS(KERN_INVALID_ADDRESS) 地址为 0x400000000000bad0 让这种情况更容易被辨识。

当然这也会带来一定的副作用,由于实现方式是通过 objc_storeStrong 方法中插入汇编,实现在调用 objc_retain 前,将 0x400000000000bad0 写入 x1 ,再正常调用 objc_retain 方法(正常 objc_retain 只接收一个参数,因此只需要 x0 即可)。因此原本偶现的问题,概率是会被放大的(以前即使有问题,但也有概率不崩溃),因此 iOS 26 的崩溃率对大部分应用来说会上升。稳定性同学要面临年末指标上涨的压力了,毕竟 iOS 26 的覆盖率会快速提升。

但从更长的视角来看,在 iOS 26 暴露了更多问题后,开发者修复后,后续的新版本对低 OS 的用户也带来体验的提升,所以总体我还是偏正常得看待这个 feature 的,等于苹果开启了对一类问题的线上 TSan ,并且对性能的影响微乎其微。短期的阵痛后带来的是更长期的体验提升。美中不足的就是如果这项 feature 能像 malloc 的一些开关(malloc stack logging 等),能让开发者自主控制按一定比例开启就更好了,能有更多时间修复以及控制对升级到 iOS 26 用户的影响。

更具体的一些细节可以看链接。

🐕 How to disable Liquid Glass

@Cooper Chen:在 iOS 26 中,苹果推出了全新的 Liquid Glass 设计系统,为界面带来了更透明、流动的视觉体验。但如果你的 App 还没做好适配,用户可能会遇到界面错乱的问题。作者在文章中给出了一个简洁的解决方案:通过在 Info.plist 中新增键值 UIDesignRequiresCompatibility = YES,就能让应用暂时保持旧版设计,避免因 Liquid Glass 引发的兼容性 bug。不过要注意,这只是临时方案,苹果计划在 iOS 27 移除该选项。也就是说,开发者需要尽快着手适配 Liquid Glass,以确保用户体验的连贯性和未来的稳定性。对于想稳妥过渡到新系统的团队来说,这是一个既务实又必须关注的技巧。

设计

🐕 marioaguzman Design Guidelines layout marioaguzman Design Guidelines toolbar

@含笑饮砒霜:这两篇文章系统阐述了 macOS 应用在窗口布局和工具栏设计上的核心规范与实践原则:在窗口布局上,需要遵循中心均衡、对齐、留白和视觉平衡的原则,合理安排常规、小型和迷你控件的位置与间距,并通过空白、分隔线或分组框组织控件,确保界面简洁一致;在工具栏设计上,应基于用户的心智模型挑选并排序常用功能,合理区分全局与界面项,正确处理侧边栏和检查器的切换,注意标题、副标题、溢出优先级与居中项的使用,同时结合不同样式(统一、紧凑、扩展、偏好)以及底部栏、附加栏和系统内置特殊控件,实现美观、直观且高效的用户体验。

内推

重新开始更新「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)

What's Changed

Full Changelog: #351...#352

❌
❌