苹果 2025 年 19 款产品将亮相 ｜ Swift 周报 issue 69

前言

本期是 Swift 编辑组自主整理周报的第六十九期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。

Swift 周报在 GitHub 开源，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。

事事如意是人生理想，事与愿违才是人生常态。如Swift社区一样，历过风风雨雨，方有春华秋实！👊👊👊

周报精选

新闻和社区：苹果 2025 年火力全开：19 款产品将亮相 阵容豪华

提案：本期提案暂无新内容更新

Swift 论坛：讨论帮助解决 SwiftPM 依赖问题

推荐博文：SwiftUI 开发当中的状态管理

话题讨论：

你支持工作上 4 休 3 吗？

上期话题结果

根据投票结果可以看出，一天一洗和其他，看情况的投票占比一样。想知道有多少和我一样中午健身洗一次，晚上打球再洗一次。

新闻和社区

美股异动丨苹果收跌 2.62%，在中国罕见打折卖 iPhone

2025 年 1 月 3 日

苹果( AAPL.US )周四收跌 2.62%，报 243.85 美元，为连续第四日下跌，股价创 2024 年 12 月初以来新低。消息面上，苹果公司面对手机市场竞争压力增加，罕见地为其新款 iPhone，为中国(内地)用户提供价格折扣优惠。

据苹果公司网站显示，中国用户透过特定支付方式购买 iPhone，可以在本周六至下周二( 4 日至 7 日)的四天内享受折扣，最高节省 800 元人民币。本次限时优惠适用于多款 iPhone 型号，包括最新的 iPhone 16 系列，售价 7999 元人民币起的 iPhone 16 Pro，和 9999 元人民币起售的 iPhone 16 Pro Max，最高可享 500 元人民币折扣。同时，iPhone 16 和 iPhone 16 Plus 可获得最高 400 元人民币减价。除此之外，旧款 iPhone 则提供 200 至 300 元人民币的折扣，MacBook 笔记型电脑和 iPad 平板电脑的价格也大幅下调。（来源：格隆汇）

苹果 2025 年火力全开：19 款产品将亮相 阵容豪华

2025 年 1 月 3 日

据报道，苹果公司在 2025 年将火力全开，预计发布多达 19 款新品，涵盖智能手机、平板、电脑笔电、穿戴设备、智能家居以及其他周边六大品类，几乎囊括了其所有产品线。这一消息无疑让广大果粉们兴奋不已，期待满满。

据悉，这些新品的处理器和关键芯片都将由台积电代工，而组装方面，鸿海将拿下多数订单。此外，苹果供应链上的其他企业如大立光、玉晶光、广达、仁宝、和硕、精元、臻鼎-KY、台达电等也将迎来新一波的拉货潮，预示着苹果新品的大规模生产和上市在即。

从新品发布的时间线来看，苹果在 2025 年上半年就将有一波新品陆续上市，包括 iPhone SE 4、智能家居控制中心、新款 MacBook Air、iPad 11、iPad Air 7 以及 iPad Air 的新键盘等。这些新品的推出，将进一步丰富苹果的产品线，满足不同消费者的需求。

而下半年，苹果还将推出更多令人期待的新品，如 Air Tag2、Mac Studio、Mac Pro、MacBook Pro、新 iPad Pro、Apple Watch 11 系列、Apple Watch Ultra 3、AirPods Pro 3、Vision Pro 2、HomePod 3、HomePod mini 2 以及备受瞩目的 iPhone 17 系列等。这些新品的问世，无疑将再次掀起一股苹果热潮。

其中最受关注的当属 iPhone 新品。据传，“史上最便宜的 AI iPhone”——iPhone SE 已经于近期开始生产，预计将在 2025 年 3 月面世，售价在 499-549 美元之间（约合 3642 元- 4008 元人民币），成为苹果 2025 年的首款人气产品。

按照惯例，iPhone 17 依然会在 9 月亮相，不仅摄像头模组将更换新造型，还将史上首次推出 Slim 超薄款机型（或称为 Air ），机身或将成为苹果史上最薄。

分析师普遍预测，iPhone 17 系列的备货量将轻松超越 9000 万部，远超 iPhone 16 系列的 8400 万- 8500 万部。这一预测无疑显示了市场对苹果新品的强烈期待和信心。

此外，Mac 系列笔电与电脑都将搭载最强的M系列芯片，速度效能持续提升，成为另一大亮点，多年未更新的智能家居产品 HomePod 也将迎来更新，备受市场瞩目。

在穿戴方面，苹果将推出 Apple Watch 11 系列、Apple Watch Ultra 3、AirPods Pro 3 及 Vision Pro 2 等硬件，满足各种果粉的需求。(来源：新浪科技)

苹果积极响应“里斯法”：为 AirTag 新增警示标签

2025 年 1 月 3 日

美国消费品安全委员会（CPSC）昨日（1 月 2 日）发布公告，宣布和苹果公司达成协议，为保护儿童免遭误食而危及生命，将在 AirTag 的包装盒上添加警告标签，提醒消费者将纽扣电池放在儿童接触不到的地方。

这一举措是为了响应 2024 年 3 月生效的“里斯法”（Reese's Law），该法律旨在防止由纽扣电池引发的儿童伤害和死亡事件，以纪念 2020 年因误吞遥控器内纽扣电池而夭折的 Reese Hamsmith。CPSC 目前尚未明确该警告标签的适用范围是仅限美国还是全球通用。

考虑到大量已售出的 AirTag 并未印有此警告，苹果公司还在“Find My”应用程序中添加了安全提示。每次用户收到更换 AirTag 电池的提示时，都会显示关于纽扣电池危险性的警告信息。这一补充措施旨在最大程度地保障用户安全，特别是儿童安全。

苹果公司积极响应“里斯法”，通过在产品包装、电池仓和“查找”应用中添加警示信息，多管齐下强化 AirTag 电池安全，以防止儿童误食纽扣电池造成伤害。（来源：IT之家）

苹果公司将支付9500万美元：和解Siri窃听隐私集体诉讼

据 MacRumors 报道，苹果公司同意支付 9500 万美元现金，以和解一项关于 Siri 窃听隐私的集体诉讼。

该诉讼指控苹果在未经同意的情况下，通过 Siri 获取私人通信内容并将其分享给第三方。

诉讼的原告称，Siri 被无意间激活，并将该语音助手无意中听到的机密或私人谈话内容分享给了苹果公司。

这些泄露的录音片段，还会伴随着显示位置，联系方式和应用数据的用户数据等私人信息。

拟议中的和解协议要求苹果公司解决这些涉嫌侵犯隐私的行为，要求该公司在和解协议生效的六个月后确认已永久删除在 2019 年 10 月之前获取的 Siri 个人音频记录。

该和解已获得法院的初步批准，苹果公司目前依然否认有任何不当行为。

据悉，在 2019 年关于承包商意外收听 Siri 录音的丑闻之后，苹果就暂时暂停了其 Siri 评估计划，停止使用承包商，并提供了允许用户删除 Siri 录音并阻止其被收听的选项。

在后来的更新中，苹果还减少了 Siri 上传到服务器的内容。(来源：快科技)

提案

本期提案暂无新内容更新。敬请期待下期内容！

Swift论坛

1)讨论是否有可能为开源 Swift 组织一个“筹款”委员会？

在讨论是否可能成立一个“筹款”委员会来支持开源 Swift 项目时，文章探讨了目前的开源开发模式及其优劣势：

1、现状分析

• 开源 Swift 的开发目前主要由 Apple 资助，其余工作由志愿者在空闲时间完成。
• 核心工具链和 Apple 主导的大方向（如并发、~Copyable）得到良好支持，但一些小众功能或中间层基础设施（既非核心也非特定公司需求）常被忽视。
• 志愿者开发的库缺乏资金支持，常因无法持续投入而被放弃。

2、筹款难点

• 筹款需要计划、协调、跟进和市场推广技能，个人难以胜任。
• 目前，志愿者通常依赖 GitHub Sponsors 等方式筹资，但效果有限。

3、筹款委员会的可能性

• 将非 Apple 来源的筹资确立为社区目标。
• 为赞助商提供稳定的合作对象。
• 通过“徽章”标识、显示赞助商 Logo 或提供广告空间等方式激励资助。

4、建议和批评

• 建议：取消 $100 的开发者计划费用，这比筹资机制更易实施，且能惠及更多人。
• 批评：外部资助模式复杂，缺乏可靠性，赞助商可能随时改变主意，导致时间和资源浪费。

5、其他问题

• 开源项目的不稳定性（如分裂、专利纠纷）可能带来风险。
• Apple 有能力自主开发其需要的工具和库，依赖外部资助并非必需。

总结：尽管筹款委员会可能促进 Swift 社区的发展，但实际操作中存在许多障碍，与其尝试复杂的资助模式，不如直接降低开发者参与门槛，如取消$100费用。

2)讨论追溯符合 BitwiseCopyable

讨论了与 Swift Evolution 提案中有关 BitwiseCopyable 协议的相关内容，重点是无法让其他模块中的类型符合该协议的问题。文章指出在包装 C API（如使用 sysctl() 函数）时，若类型未标记为 BitwiseCopyable，可能会导致编译器警告，同时分析了解决此问题的潜在方法、对 Swift 现有行为的修改建议，以及处理 C 中可能影响按位可复制性的联合类型的考虑。

关键点：

1. 开发者无法让外部模块中定义的类型符合 Swift 的 BitwiseCopyable 协议。
2. 包装 C API（如 sysctl()）时，若类型未被识别为 BitwiseCopyable，可能会引发潜在的堆栈破坏问题。
3. 对 BitwiseCopyable 使用泛型类型约束可以消除编译器警告，但仅限于在安全实践中使用。
4. 无法为其他模块中定义的现有结构（如 kinfo_proc）添加 BitwiseCopyable 的符合性。
5. 文中提到，某些 C 类型的 BitwiseCopyable 推断基于其成员类型，这可能会在使用联合类型时带来复杂性。
6. 建议改进以处理导入的联合类型及其与 BitwiseCopyable 的符合性，并提出修改现有提案的必要性。
7. Swift 对导入类型的复杂处理反映出有必要重新定义关于 BitwiseCopyable 符合性的规则，以更好地支持 C 结构的使用。

3)讨论如何实现与并发兼容的作用域函数

讨论了在 Swift 中如何实现与并发兼容的作用域函数。以下是主要内容：

1、当前实现方法

• 采用继承调用者的隔离方式，同时决定如何处理非 Sendable 值（发送或转换为 Sendable）。
• 这种方法与 Franz Busch 在近期演讲中推荐的内容一致，修改建议也类似于 Ole 的提议。

2、标准库行为解释

• 标准库中的 TaskLocal.withValue 能成功编译，可能是因为其在 Swift 5 语言模式下编译，并未启用严格的并发检查。
• 相关证据可以从 cmake 配置文件中找到。

3、问题与工具链版本

• 讨论中提到的一些实现（如 @inheritsIsolation 属性）在最新编译器快照中无法正常工作，包括编译器探索器中也会出现问题。
• 当前编译器尚未提供语言功能，无法声明 withLog 函数与操作与调用者属于同一隔离域，因此无法实现通用的作用域函数。

4、可能的解决方案

• @inheritsIsolation 属性处于草案阶段，若投入使用，可实现目标功能。
• 现有的 @_inheritActorContext 功能类似，但在某些情况下会出现意外行为，不适合该用例。

4)讨论使用 WKWebView 的 evaluateJavascript 与 async let 时的并发警告

讨论了在 Swift 中使用 async let 和 WKWebView.evaluateJavascript 时遇到的并发警告及相关问题，重点包括类型约束、隔离检查和任务调度的影响。

1、问题描述

• 尝试用 Task(executorPreference: MainActor.shared) { … } 替代任务初始化器，但编译失败，提示 MainActor 不符合预期的 TaskExecutor 类型。
• 根本问题在于使用 Any 作为返回类型。由于不能跨 Actor 边界发送非 Sendable 类型，需在 async let 声明之前将其强制转换为 Sendable 类型。

2、深入分析

• Any 类型与 Actor 隔离：
• 如果调用方和被调用方均非隔离，则不会报错，即使返回值非 Sendable，因为没有跨越隔离边界。
• 同一 Actor 隔离的 async let：
• 当 async let 的声明和初始化表达式均在同一 Actor 隔离中时，async let 的核心功能（并发执行）被削弱。
• 隐式闭包为非隔离状态，任务会默认跳到并发执行器，这导致绑定的任务启动顺序不可预测。

3、设计模式建议

• 对于简单场景，应避免在同一 Actor 隔离中使用 async let。直接对函数进行 await 调用通常更合理。
• 如果 async let 必须使用，则应确保其声明与隔离边界处理一致，以避免非确定性行为。

4、讨论与结论

• 当前的隔离检查逻辑较为保守，尚不足以支持某些模式，可能需要额外开销或改进语言功能。
• 对于所讨论的用例，直接使用 await 而非 async let 更符合最佳实践，避免了额外的复杂性与潜在问题。

5)讨论帮助解决 SwiftPM 依赖问题

讨论了在使用 Swift Package Manager (SwiftPM) 管理依赖时遇到的问题，主要包括依赖解析失败、模块构建错误以及潜在的解决方法。

1、问题描述

• 项目中存在命名相关的问题，但在过去的多个项目中，使用相同命名并未出现问题。
• 在 GitHub Actions 中复现了问题，错误信息指向一个缺失的头文件和无法构建的 Objective-C 模块 OpenAI。

2、可能原因

• 强制推送：作者怀疑在对仓库进行强制推送时可能导致了 SwiftPM 的配置或缓存出现问题。
• 模块映射文件：错误日志显示模块映射文件引用了一个不存在的头文件，可能与模块配置相关。
• 依赖解析：当依赖的模块发生更改时，可能需要手动解析依赖以确保成功构建。

3、解决尝试

• 修改了仓库名称以测试问题来源，但未解决问题。
• 使用本地的 Package.swift 文件来管理依赖，在某些情况下有效，但复杂的依赖解析可能需要在构建前手动处理模块变化。

4、对 CI 和测试的看法

• 在 CI/测试场景中使用 SwiftPM 是有效的，可以避免打开 Xcode，但需要解决模块间依赖问题。
• 通过终端管理模块/依赖，适合快速编辑和测试。

推荐博文

【iOS特性】3D Touch - 手搓Live Photo效果

摘要： 这篇博客介绍了如何在 iOS 中实现 3D Touch 手搓 Live Photo 效果。详细讲解了实现过程的四个主要步骤：从相册选取视频、截取视频首帧图片、合成 Live Photo、以及使用 PHLivePhotoView 展示效果。通过结合 Photos 和 PhotosUI 框架，实现了将普通视频转换为 Live Photo 的功能。文章提供了完整的示例代码和实现思路，对想要实现类似功能的 iOS 开发者具有参考价值。

SwiftUI 开发当中的状态管理

摘要： 摘要：这篇文章深入介绍了 SwiftUI 中的状态管理机制。文章首先解释了为什么需要状态管理，然后详细讲解了 SwiftUI 提供的五种主要状态管理工具：@State（用于局部状态）、@Binding（用于父子视图间状态共享）、@ObservedObject（用于观察外部对象）、@StateObject（用于视图内部状态对象管理）以及 @EnvironmentObject（用于全局状态共享）。最后通过底层原理分析，展示了 SwiftUI 如何通过响应式编程模型和 Combine 框架实现高效的状态管理。文章通过具体示例代码，为开发者提供了实用的 SwiftUI 状态管理指南。

iOS keychain

摘要： 文章首先阐述了 keychain 作为一种安全存储私密信息（如密码、证书等）的方式的特点，以及其在备份和应用间数据共享方面的作用。接着介绍了四个常用的操作方法：SecItemAdd（添加）、SecItemDelete（删除）、SecItemUpdate（修改）和 SecItemCopyMatching（查找）。文章还深入讲解了各种保护属性的使用、iCloud 同步机制，以及数据保护 API 的工作原理和不同保护等级的应用场景。通过具体的代码示例，为开发者提供了实用的 keychain 使用指南。

话题讨论

今年元旦放假，让很多人体验了一把“上 4 休 3”的快乐，来做个小调查：你支持工作上 4 休 3 吗？

1. 支持！多休一天太爽了！
2. 不支持，工作量又不会变少
3. 说不好，感觉不同工作的落实难度不一样
4. 我支持有啥用，我说了又不算...

关于我们

Swift社区是由 Swift 爱好者共同维护的公益组织，我们在国内以微信公众号的运营为主，我们会分享以 Swift实战、SwiftUl、Swift基础为核心的技术内容，也整理收集优秀的学习资料。

欢迎关注公众号:Swift社区，后台点击进群，可以进入我们社区的交流讨论群。希望我们Swift社区是大家在网络空间中的另一份共同的归属。

特别感谢 Swift社区 编辑部的每一位编辑，感谢大家的辛苦付出，为 Swift社区 提供优质内容，为 Swift 语言的发展贡献自己的力量。