肘子的话
不久前，微软人工智能部门负责人在一次采访中发表了颇具争议的言论，他认为任何在开放网络上发布的内容都可被视为“免费软件”，任何人都可以复制和使用。不出意外，这一观点引起广泛批评，但人们仍十分担忧，这些拥有巨大影响力的科技巨头可能会试图从法律角度将其行为合法化，从而侵蚀原创作者的权利。
Rand Fishkin 最新的研究揭示了另一种数据使用模式。基于海量的数据，Fishkin 分析了 2024 年 Google 搜索行为，发现近六成的搜索流量流向了 Google 自身的服务体系。尽管这个比例令人惊讶，但相比生成式 AI 的做法，Google 的模式对内容创作者而言反而显得较为友好。在 Google 的模式下，原创内容至少还有机会获得点击和流量；而在生成式 AI 的回答体系中，即便提供了相关链接，由于 AI 已经对答案进行了汇总，能为原作者带来的流量往往十分有限，更遑论许多情况下 AI 的回答甚至不会包含数据源信息。
在数字世界中，我们的创作不可避免地会成为人类共同智慧的一部分。然而，当商业公司免费使用这些内容并从中盈利，同时还试图从法律层面剥夺个体对自己创作的所有权时，这无疑是不道德且危险的。越来越多的服务提供商在冗长的用户协议中加入了强制作者放弃版权或允许对内容进行 AI 训练的条款，甚至连付费用户也难以幸免。这种行为无异于饮鸩止渴，不仅会损害这些公司长期以来精心构建的信誉，更会逐步侵蚀互联网蓬勃发展的根基。
无偿分享是一种美德，但这不应成为剥夺创作者应有权利的借口。在 AI 时代，我们更需要在技术创新和权益保护之间找到平衡，共同营造一个尊重创新、保护权益的数字生态系统。
原创
Swifter and Swifty：掌握 Swift Testing 框架
自 Swift 语言诞生以来，XCTest 一直是绝大多数 Swift 开发者的首选测试框架。然而，由于其深植于 Objective-C 的根基，API 设计大量沿袭了该语言的传统，无法充分体现 Swift 的现代编程最佳实践。在某些方面，这甚至成为了发展的障碍。为了克服这些限制，苹果在 WWDC 2024 上正式介绍了由社区开发的 Swift Testing —— 一个专门为 Swift 语言设计的全新测试框架。这个框架已被集成到 Xcode 16 中，并被定位为官方首选的测试工具。在本文中，我们将深入探讨 Swift Testing 框架的特性、用法和其独特之处，分析它如何帮助开发者以更快（Swifter）的方式编写出更符合 Swift 编程习惯（Swifty）的测试代码。
近期推荐
Swift 6 中的数据竞争安全检查及其对包生态系统的影响 (Plotting a Path to a Package Ecosystem without Data Race Errors)
Swift 6 引入了编译时数据竞争安全检查功能，适用于选择使用 Swift 6 语言模式的代码。虽然各个模块可以逐步独立采用这种模式，但只有当所有模块都采用时，才能充分实现运行时数据竞争安全的益处。文章强调了开源包生态系统快速采用 Swift 6 语言模式的重要性，并介绍了 Swift Package Index 的新功能 “Ready for Swift 6” 页面，用于跟踪整个包生态系统在数据竞争安全方面的进展。
作者呼吁开发者采用 Swift 6 语言模式，指出这将有助于消除潜在的并发错误，提高代码的安全性和可维护性。文章还讨论了包兼容性与数据竞争安全的区别，为开发者在选择和评估包时提供了指导。
Swift 中的类型化 throws 功能解析及代码示例 ( Typed throws in Swift explained with code examples )
类型化 throws 是 Swift 6 引入的新功能，允许开发者明确定义方法可能抛出的错误类型。该功能为开发者带来了多项优势，包括使代码更可预测、提供编译时检查和增强自动完成功能等。Antoine van der Lee 通过具体的代码示例详细展示了如何使用这一功能，包括指定错误类型的方法以及在 do-catch 语句中处理类型化 throws。文章特别强调了这种方法对 SDK 开发的价值，以及它如何帮助开发者避免遗漏处理新增的错误情况，从而提高代码质量和可维护性。
使用 Xcode 的 Development Assets 实现 SwiftUI 预览 ( XcodeのDevelopment Assetsを使ってSwiftUIプレビューを実装する )
Development Assets 是 Xcode 中的一个功能，用于管理仅在开发过程中需要的资源和代码，这些资源不会包含在最终的发布版本中。在本文中，Kenji Wada 通过具体的代码示例展示了如何实现这些功能。作者强调了使用 Development Assets 的优点，包括提高代码可读性和可管理性、实时预览设计和布局，以及预览内容不会影响发布版本。文章特别指出了这种方法在分离测试数据和生产代码方面的优势，对 Swift 开发者在使用 SwiftUI 进行 iOS 应用开发时非常有帮助。
增强相机应用启动体验的简单技巧🪜 ( A simple trick to enhance your Camera App’s launch experience )
默认的 SwiftUI 应用启动屏幕优势会与应用的整体主题不一致，这一问题在始终使用深色界面的相机应用中尤为明显。JuniperPhoton 介绍了一种简单而有效的方法来解决这个问题，显著改善了应用的启动体验。文章详细说明了如何通过修改 Info.plist 文件来自定义启动屏幕的背景颜色，而非仅依赖 preferredColorScheme 修饰符。这种技巧确保应用在启动时呈现一致的深色背景，有效避免了屏幕闪烁现象，从而大幅提升了用户体验。
Xcode 16 中的显式构建模块功能探索 ( Xcode Explicitly Built Modules )
Xcode 16 引入了一项实验性功能——显式构建 Swift 模块，旨在解决此前隐式构建模块可能导致的构建任务阻塞问题。Keith Harrison 深入探讨了该功能的工作原理、启用方法和潜在优势，并通过对比构建时间线，生动展示了隐式和显式构建的差异。理论上，这项功能应能提高构建效率并减少调试器延迟。然而，作者在两个开源项目的实际测试中发现，显式构建略慢于隐式构建，且调试器性能改善不显著。文章不仅提供了详细的设置指南和性能对比数据，还强调了这一功能的实验性质，预示未来 Xcode 版本可能会有进一步优化。
值得注意的是，在当前 Xcode beta 版本中，启用此功能可能会导致某些模块无法在编译时被找到，使用时需谨慎。
2024 年零点击搜索研究：欧盟每 1000 次 Google 搜索中仅 374 次点击进入开放网络，美国为 360 次
Rand Fishkin 利用 Datos 公司的海量设备点击流数据，深入分析了 2024 年 Google 搜索行为，重点对比美国和欧盟的搜索模式。研究揭示，美国每 1000 次 Google 搜索中，仅有 360 次点击进入开放网络（即与 Google 服务无关的站点），欧盟略高，为 374 次。值得注意的是，零点击搜索（用户搜索后未点击任何结果）在美国占比 58.5%，欧盟则为 59.7%。
数据进一步表明，Google 自有服务吸引了大量流量，尤其在美国表现更为突出。尽管每位用户的搜索频率创下新高，但指向开放网络的点击比例却呈下降趋势。总体而言，Google 依然牢牢把控搜索市场。尽管欧盟的监管措施在一定程度上限制了 Google 的自我引流行为，但其影响仍然有限。