苹果斥资 15 亿美元加码卫星通讯 ｜ Swift 周报 issue 65

前言

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

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

好运藏在实力里，也藏在你不为人知的努力里。像Swift社区那样，越努力就越幸运！👊👊👊

周报精选

新闻和社区：苹果斥资15亿美元加码卫星通讯，持股消息令全球星暴涨近40%

提案：Nonescapable类型提案通过审查。

Swift 论坛：讨论关于 Modern Swift 的主动反馈

推荐博文：Swift 并发初步

话题讨论：

双十一你还会抢东西吗？

新闻和社区

苹果向投资者发出警告:未来新产品无法达到iPhone的利润水平

2024 年 11 月 6 日

根据苹果公司最新向美国证券交易委员会提交的 10-K 文件，苹果公司提醒投资者，公司新产品可能无法复制 iPhone 的利润水平。

由于公司进入人工智能（AI）和虚拟现实（VR）等新市场，未来推出的新产品可能无法达到 iPhone 的盈利水平。

在这些新兴市场中，苹果不仅面临来自其他公司的激烈竞争，同时也需要克服技术上的诸多挑战，这些因素可能会影响新产品的市场接受度和盈利能力。

鉴于这些风险，苹果可能需要在战略上进行调整，以适应不断变化的市场环境和消费者需求。苹果目前正加大对人工智能的投入，力图在该领域缩小与谷歌等竞争对手的差距。

苹果近年来不断拓展产品线，推出了 Apple Watch、iPad、MacBook 等新品。虽然这些产品在各自领域取得了不错的成绩，但与 iPhone 相比，它们的利润水平较低。未来，苹果将继续拓展新品类，如 AR/VR 设备、智能家居等，这些产品的利润水平可能无法达到 iPhone 的高度。（来源：科技世界网）

苹果在欧盟又有麻烦了，消息称欧盟计划再次向他们开出罚单

2024 年 11 月 6 日

11 月 6 日消息，据外媒报道，在年初因在第三方音乐服务上的反垄断行为而被欧盟处以 20 亿美元罚款的苹果，在欧盟可能再次被开出罚单。

从外媒的报道来看，欧盟计划对苹果未遵守数字市场法案而处以罚款，监管机构认为苹果未能在允许应用程序开发商引导用户在 App Store 之外购买更便宜的产品方面，做出足够的改变。

目前还不清楚欧盟会在何时向苹果开出罚单，但外媒认为可能会在欧盟竞争专员玛格丽特•维斯塔格离任前，她将在11月离任，不过外媒也认为可能推迟至今年年底开出。

除了处罚的时间，罚款的金额目前也还不确定。根据欧盟数字市场法案，他们最高可以处以苹果全球年营收 10% 的罚款，如果按最高比例处罚，罚款就将会相当高。苹果上周发布的财报显示，他们在截至 9 月 28 日的 2024 财年营收 3910.35 亿美元，10% 就高达 391 亿美元。

就外媒的报道来看，欧盟对苹果未遵守数字市场法案的调查已有一段时间。在今年 6 月份，欧盟就曾表示苹果违反了数字市场法案的反操纵规则，欧盟当时是认为应用程序开发商应能够告知用户其他购买选择，引导他们接受优惠，并允许他们在 App Store 之外进行购买。

在欧盟认为苹果违反数字市场法案的反操纵规则之后，苹果也曾做出改变。他们在 8 月份就修改了 App Store 中的相关规则，以满足欧盟监管机构的要求。

在 8 月份修改规则之后，苹果开始允许欧盟的开发者通过沟通和推广引导用户到 App Store 外购买，与苹果此前的规定相比是重大放松，开发者因此无需选择苹果的新开发者条款或支付核心技术费用，就可以给予折扣和交易，但在修改规定之后，苹果要求开发者报告外部购买交易，并支付初始获取费和商店服务费。（来源：TechWeb）

消息称苹果已在北京上海深圳苏州设立显示屏研发实验室

2024 年 11 月 5 日

11 月 5 日，继上月中旬外媒披露其在深圳新设的应用研发实验室已正式运营后，短短数月间，苹果再次出手，于深圳及其他多座城市增设显示屏研发实验室。

据最新报道，苹果此举旨在深化本土化战略，通过在国内四座城市部署显示屏研发力量，加速推进供应链多元化进程，同时有效控制成本，增强在全球市场的竞争力。

苹果公司此次在深圳及其他城市设立显示屏研发实验室，是其在中国科技领域布局的重要一步。这一举措不仅有助于苹果公司进一步拓展在中国的研发网络，还将推动其在全球市场的竞争力。通过在四座城市部署显示屏研发力量，苹果公司将能够更好地整合本土资源，优化供应链管理，降低生产成本，提高产品竞争力。（来源：观点网）

苹果斥资15亿美元加码卫星通讯，持股消息令全球星暴涨近40%

2024 年 11 月 2 日

当地时间周五，美国低轨道卫星通讯公司全球星（Globalstar）发布公告称，公司大客户苹果公司通过注资、承诺购买服务等方式，向公司承诺投资 15 亿美元。

受该消息影响，全球星周五开盘后涨幅一度超过 40%，市值接近 27 亿美元。

总的来说，苹果与全球星的交易一共分为两大部分。首先，苹果斥资 4 亿美元，收购公司 20% 股权，这笔交易 11 月 5 日前后完成。按照最新的市值，苹果已经处于盈利的状态。

另一笔钱是 11 亿美元的“基础设施预付款”，按季度支付，主要用于扩展全球星的卫星服务网络。全球星也会拿这笔钱偿还 13% 票息的 2.32 亿美元优先级票据。

作为交换，全球星表示，将继续把约 85% 的卫星互联网传输容量提供给苹果。

新的资金将有助于全球星购买新卫星和升级地面基础设施。目前公司正在运营 31 颗卫星，同时已经订购至多 26 颗卫星，用于补充和升级低轨道卫星网路。

过去几年里，随着低轨卫星商业化的进展，各家手机厂商纷纷推出了依托于卫星互联网的紧急联络服务。

苹果在 2022 年 9 月的 iPhone 14 上首发“紧急 SOS ”服务——在开通这项服务的地区（主要是欧美和日本），当用户处于既没 Wi-Fi 信号又没蜂窝网络的荒郊野岭时，通过连接头顶上的卫星向紧急服务人员发送求救短讯。随着 iOS 系统的迭代，增添了与朋友、家人互发信息和共享位置等功能。

除了全球星以外，低轨道卫星市场还有 SpaceX、AST SpaceMobile、铱星移动通讯、Lynk Global、回声星通讯等。

在苹果加码押注卫星互联网业务的同时，也带出了一个老问题：手机卫星服务怎么赚钱？

2022 年发布这项功能时，苹果曾经表示这项服务将免费提供两年——意味着首批用户本应在今年底开始付费，但苹果已经把免费期延长至 2025 年。

这意味着如何给卫星互联网通讯订价，会是一个棘手的问题。考虑到这种服务的初衷是在危及生命的状况下求救，怎么定价都会显得不太合适。一种可能的破局思路，是继续维持紧急求助服务的免费，同时对定位、发送非紧急短信进行收费。

提案

通过的提案

SE-0446 Nonescapable类型 提案通过审查。

Swift论坛

1. 提议修改和读取访问器

内容大概

Swift 团队在讨论访问器的改进，特别是针对 yield-once 协程访问器，建议使用“borrow”和“mutate”作为新名称，以实现对象属性的临时、直接访问。该提案详细探讨了这些新术语与传统“read”和“modify”访问器之间的区别。

1. 新访问器命名的目的：

• 提出用“borrow”和“mutate”描述基础的访问器，涉及就地访问并可能更改对象的部分（如属性），使对象保留所有权并临时提供借用访问权限。
• 这与现有的“read”和“modify”访问器不同，后者用于一次性协程，在操作期间只会短暂地将被访问的实体实现出来。“read”和“modify”表示有开始和结束的操作，允许临时访问而不转移所有权。

2. 词汇和语义上的差异：

• Swift 团队仔细考虑了词汇，旨在避免混淆。虽然“read”和“modify”更接近临时操作，不转移所有权，而“borrow”和“mutate”更准确地描述了直接、基于组件的访问，而不转移所有权。
• 这些术语避免了与现有术语“get”和“set”同义，后者暗示更直接的完成式交易，即所有权或值被直接交付。

3. 功能性和未来应用场景：

• 团队强调，这些新的访问器“borrow”和“mutate”旨在作为基础概念，与 Swift 未来的组件化访问模式对齐。
• 团队表示，这些新名称还希望解决未来可能的情况，例如“投影访问器”（设计用于借用字段而不转移所有权），并澄清目前该提案中不包含异步访问器（异步 read/modify），但未来可能会考虑。

4. 提案的时间安排：

• 该提案并不面向 Swift 6.1，尽管团队仍在继续讨论，以期在 Swift 的未来版本中进一步完善这些访问器的行为和命名。

2. 讨论Task 和 MainActor.assumeIsolated 的等价性

内容大概

讨论围绕 Swift 中的 Task 和 MainActor.assumeIsolated 方法的使用和文档的解释不足展开。用户认为，现有文档对这两个方法的描述虽然基本清晰，但在关键点上有所欠缺。例如，MainActor.assumeIsolated 的描述略显模糊，似乎仅涉及验证，而未明确指出它会在 MainActor 上执行操作。

用户指出，Task 方法能够创建并在当前 actor 上运行非抛出操作，但相关机制的解释在 Swift 的文档中缺乏统一性。用户希望能有一份简洁、结构清晰的文件，概述隔离、actor 和异步概念，而不必频繁查阅分散的资料。

他们还提到，现有的并发文档通常缺乏吸引力，重要信息散落在各个提案中，术语不统一且细节不足，增加了理解难度。用户建议，改进文档应首先建立一致的术语，并提供一份简洁的叙述，清晰解释并发机制的工作原理及其用法。这种优化文档的过程尽管耗时繁重，但能有效提升开发者的理解。

3. 讨论使用手动构建的 5.10.1 在 6.0.1 上构建 lib/liblldb.so.17.0.0 时出现问题

内容大概

用户在尝试用手动构建的 Swift 5.10.1 版本编译 Swift 6.0.1 时遇到问题，无法成功构建 lldb-server 和 lib/liblldb.so.17.0.0，因为缺少符号。用户描述了编译过程，使用了 swift/utils/build-script --preset=buildbot_linux,no_test，但怀疑 Swift 5.10.1 的构建不完整，可能导致链接错误。

一位回复者建议，如果用户的 /usr/bin/ld 是 lld，需要在构建脚本中设置 LLVM_USE_LINKER=lld 变量，以确保 LLVM、lldb 和其他组件使用 lld，从而调整链接行为。并建议通过修改 swift/utils/build-presets.ini 文件来添加一个新的预设，以便在编译时启用该设置。

另外，回复者提供了在 Gentoo 系统上编译 Swift 6.0.1 的示例预设，并建议用户参考 buildbot_linux,no_assertions,no_test 预设，以禁用断言和测试项，简化构建过程。回复者还表达了愿意提供进一步帮助的意愿。

4. 讨论原始标识符

内容大概

这篇 Swift 提案（SE-0451）评论中表示，提案的主要逻辑是合理的，允许描述性和程序生成的标识符，将对 Swift 语言有益。尽管提案已简化了对标识符中特殊字符的处理，但用户指出它在实现生成任意标识符的目标上仍存在不足：

1. 提案的局限性：

• 当前提案不支持转义字符，也禁止仅包含操作符字符的标识符，因此无法完全适用于某些编程场景，如将文件名（可能包含换行符或操作符）转换为标识符。
• 由于此限制，代码在合成标识符时仍需绕开 Swift 的语法规则，导致可能需要额外的转义方案，从而增加负担。

2. 改进建议：

• 用户建议 Swift 中引入一种通用的转义机制，以便任何字符串都能成为标识符，且标识符的内容不会影响语义。
• 例如，希望允许 foo\nbar() 等类似标识符，并能使用 Int.+ 指代常规标识符 +。

3. 支持该提案的理由：

• 用户认为，虽然提案不完美，但它为未来的改进奠定了基础，特别是在测试命名、枚举和代码生成中具有实际价值。
• 提案还获得其他开发者支持，他们认为它对工具链的额外负担是可控的，同时会显著提升开发体验。

4. 对未来改进的建议：

• 提案中还建议，未来可以通过社区贡献或一个小型工具包来减轻代码生成中的转义困难。此工具包可以包含禁用字符集的查询功能，判断字符串是否为合法的原始标识符，并提供基本的字符串转换为合法标识符的方法。这些功能可以作为未来方向来探讨。

5. 讨论关于 Modern Swift 的主动反馈

内容大概

用户分享了在 Swift 中开发项目 SwiftClaude 的一些经验和反馈，特别是现代 Swift 特性如结构化并发、可变参数泛型和 SwiftSyntax 的使用。以下是主要反馈内容：

1. 正确的函数隔离模式：

• 用户分析了 Swift 中使用结构化并发的三种方式：普通的 async 函数、Actor 隔离函数以及可选的 Actor? 隔离函数。
• 最初用户尝试将所有类型标记为 Sendable，但最终认为不标记所有类型反而更适合项目需求（因为 SwiftClaude 中有很多不可传送的类型）。
• 用户指出，isolated Actor? 隔离可能是一个反模式，因为它不能保证数据安全，且容易导致崩溃。因此在 SwiftClaude 中，他们只使用非可选的 isolated Actor 以避免潜在问题。

2. withObservationTracking 的强大之处：

• 用户对 withObservationTracking 的功能表示赞赏，尤其是在将 @Observable 类型属性暴露为 AsyncSequence 时，帮助统一了异步和 SwiftUI 数据处理。
• 用户建议改进 withObservationTracking，在对象析构时也能触发 onChange，以便更好地跟踪对象的生命周期。

3. 重塑 Codable：

• 为实现 SwiftClaude 的功能，用户创建了自己的序列化系统，因为 Codable 类型中的 init(from:) 无法提供静态数据形状推断。
• SwiftClaude 使用自定义的 ClaudeToolInput 系统和可变参数泛型，以确保每个 ToolInput 类型都有静态已知的结构。用户可以利用这些信息生成 JSON 模式，从而实现与 Claude API 的交互。
• 用户希望 Swift 未来能提供更静态化的 Codable 类型，以便更直观地了解编码/解码流程。

推荐博文

Swift 并发初步

摘要： 这篇文章介绍了 Swift 并发编程的基础概念，特别是随着 Swift 5.5 引入的异步/并发特性，如何简化并发编程并确保程序的安全性和高效性。以下是其中几个重要概念和要点的总结：

1. 同步和异步：同步操作会阻塞当前线程直到完成，而异步操作允许线程在等待期间执行其他任务。异步操作能避免UI卡顿，但使用回调可能导致代码复杂和错误难以处理。

2. 串行和并行：串行操作按顺序执行，异步操作也可以串行执行；并行操作则可以同时执行多个任务，通过使用多个线程来提高效率。

3. 异步函数：Swift 5.5 引入了 async 和 await，使得异步操作像同步操作一样书写，简化了回调地狱和错误处理。

4. 结构化并发：通过 Task 和 async let 等方式，Swift 提供了任务树和并发任务管理，确保任务之间的正确顺序和资源共享安全。

5. actor 模型：解决了并发中共享资源的安全问题，通过 actor 确保多个任务不会同时修改同一数据，避免数据竞争。

这些概念结合起来，帮助开发者简洁、高效地编写并发代码，减少潜在的错误和复杂性。

iOS 12 Swift KVO 崩溃排查

摘要： 这篇文章主要分析了 iOS 12 中使用 Swift KVO 导致的崩溃问题。通过崩溃堆栈的分析，发现崩溃与 KVO 相关的 __old_unswizzled_keyPathsForValuesAffectingValue 方法调用触发了 fatalError。崩溃原因是由于方法交换（method swizzling）未能完全执行，导致未替换的原方法被调用，引发崩溃。文章详细解释了 KVOKeyPathBridgeMachinery 和 NSObject 之间的交换逻辑，并通过排查发现，Swift KVO 的某些调用未成功触发方法交换，尤其是在多线程环境下执行时更容易发生崩溃。

文章建议修复方案为删除相关的 Swift KVO 调用，尤其是避免在 iOS 12 上使用 Swift KVO。崩溃的激增被认为是由于近期的代码优化将 KVO 操作从主线程移到子线程，增加了多线程冲突的概率。

介绍 Swift Testing. Traits

摘要： 这篇博客介绍了 Swift Testing 框架中的强大特性——traits（特性） 系统。traits 允许通过注解的方式灵活地控制测试行为。文中首先展示了如何使用 disabled 和 enabled 特性来跳过或有条件地运行测试，如基于功能标志来启用或禁用特定测试。此外，还介绍了组合多个特性以满足特定条件的使用方法，并展示了 bug 特性，可以为被跳过的测试关联一个特定的 bug 标识或 URL。

接着，文章解释了 timeLimit 特性，帮助限制测试的执行时间，避免资源消耗过多。作者还介绍了 tagging（标签） 功能，允许通过为测试或测试套件添加标签来组织测试，例如通过 crucial 标签标记关键测试，方便在 Xcode 的 Test Navigator 中按标签运行和筛选测试。

话题讨论

双十一你还会抢东西吗？

1. 会
2. 不会

欢迎在文末留言参与讨论。

关于我们

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

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