Weekly Comment
New Challenges for Creators' Rights in the AI Era
Recently, the head of Microsoft's AI department made a controversial statement in an interview, suggesting that any content published on the open web could be considered "free software" and could be copied and used by anyone. Unsurprisingly, this view has been widely criticized, but people remain deeply concerned that these highly influential tech giants might attempt to legalize their behavior from a legal standpoint, thereby eroding the rights of original creators.
Rand Fishkin's latest research reveals a different pattern of data usage. Based on massive data, Fishkin analyzed Google search behavior in 2024 and found that nearly 60% of search traffic flows to Google's own service ecosystem. Although this proportion is surprising, compared to the practices of generative AI, Google's model appears to be more creator-friendly. Under Google's model, original content at least has a chance to receive clicks and traffic; whereas in the response system of generative AI, even if relevant links are provided, the traffic that can be brought to the original author is often very limited due to AI's summarization of answers, not to mention that in many cases, AI responses don't even include source information.
In the digital world, our creations inevitably become part of humanity's collective wisdom. However, when commercial companies use this content for free and profit from it, while simultaneously attempting to legally deprive individuals of ownership over their own creations, it is undoubtedly unethical and dangerous. More and more service providers are adding clauses in their lengthy user agreements that force authors to waive copyrights or allow their content to be used for AI training, and even paid users are not exempt. This behavior is akin to drinking poison to quench thirst; it not only damages the carefully built reputation of these companies but also gradually erodes the foundation on which the internet has flourished.
Sharing without compensation is a virtue, but it should not be an excuse to deprive creators of their rightful entitlements. In the AI era, we need to find a balance between technological innovation and rights protection, working together to create a digital ecosystem that respects innovation and protects rights.
Previous Issue|Newsletter Archive
If you appreciate my work and want to promote your product to the Swift and iOS developer community, sponsoring my platform could be an excellent opportunity for you.
Your support through Patreon, or Buy Me a Coffee helps keep this newsletter and blog running. Thank you for finding this content helpful!
Originals
Swifter and Swifty: Mastering the Swift Testing Framework
Since the inception of the Swift language, XCTest has been the preferred testing framework for the majority of Swift developers. However, deeply rooted in Objective-C, its API design heavily borrows from the traditions of that language, failing to fully reflect the modern best practices of Swift programming. In some respects, this has even become a barrier to further development. To overcome these limitations, Apple officially introduced Swift Testing at WWDC 2024—a new testing framework specifically designed for the Swift language. This framework has been integrated into Xcode 16 and positioned as the official testing tool of choice. In this article, we will delve into the features, usage, and unique aspects of the Swift Testing framework, analyzing how it helps developers write test codes faster (Swifter) and more in line with Swift programming habits (Swifty).
Recent Selections
Plotting a Path to a Package Ecosystem without Data Race Errors
Swift 6 introduces compile-time data race safety checking functionality, applicable to code that opts to use the Swift 6 language mode. While individual modules can gradually and independently adopt this mode, the full benefits of runtime data race safety are only realized when all modules have adopted it. The article emphasizes the importance of rapid adoption of the Swift 6 language mode across the open-source package ecosystem and introduces the new "Ready for Swift 6" page on the Swift Package Index, which tracks the progress of the entire package ecosystem in terms of data race safety.
The authors urge developers to adopt the Swift 6 language mode, pointing out that this will help eliminate potential concurrency errors and improve code safety and maintainability. The article also discusses the distinction between package compatibility and data race safety, providing guidance for developers when selecting and evaluating packages.
Typed throws in Swift explained with code examples
Typed throws
is a new feature introduced in Swift 6 that allows developers to explicitly define the types of errors a method may throw. This feature brings multiple advantages to developers, including making code more predictable, providing compile-time checks, and enhancing autocomplete functionality. Antoine van der Lee demonstrates in detail how to use this feature through specific code examples, including methods for specifying error types and handling typed throws
in do-catch
statements. The article particularly emphasizes the value of this approach for SDK development, and how it helps developers avoid overlooking new error cases, thereby improving code quality and maintainability.
Implementing SwiftUI Previews using Xcode's Development Assets
Development Assets is a feature in Xcode used to manage resources and code needed only during the development process, which are not included in the final release version. In this article, Kenji Wada demonstrates how to implement these features through specific code examples. The author emphasizes the advantages of using Development Assets, including improving code readability and manageability, real-time preview of design and layout, and ensuring preview content doesn't affect the release version. The article particularly points out the benefits of this method in separating test data from production code, which is very helpful for Swift developers using SwiftUI for iOS app development.
A simple trick to enhance your Camera App's launch experience
The default launch screen of SwiftUI applications often doesn't align with the overall theme of the app, a problem particularly noticeable in camera apps that consistently use a dark interface. JuniperPhoton introduces a simple yet effective method to solve this problem, significantly improving the app's launch experience. The article details how to customize the launch screen's background color by modifying the Info.plist
file, rather than relying solely on the preferredColorScheme
modifier. This technique ensures the app presents a consistent dark background at launch, effectively avoiding screen flickering and greatly enhancing the user experience.
Xcode Explicitly Built Modules
Xcode 16 introduces an experimental feature — explicitly built Swift modules, aimed at resolving the issue of build task blocking that may occur with implicitly built modules. Keith Harrison delves into the working principles of this feature, how to enable it, and its potential advantages, vividly demonstrating the differences between implicit and explicit builds through timeline comparisons. In theory, this feature should improve build efficiency and reduce debugger delays. However, in actual tests on two open-source projects, the author found that explicit builds were slightly slower than implicit builds, and debugger performance improvements were not significant. The article not only provides detailed setup guides and performance comparison data but also emphasizes the experimental nature of this feature, indicating potential further optimizations in future Xcode versions.
It's worth noting that in the current Xcode beta version, enabling this feature may result in some modules not being found during compilation, so caution is advised when using it.
2024 Zero-Click Search Study: For every 1,000 EU Google Searches, only 374 clicks go to the Open Web. In the US, it’s 360
Utilizing massive device clickstream data from Datos, Rand Fishkin conducted an in-depth analysis of Google search behavior in 2024, focusing on comparing search patterns in the US and EU. The study reveals that in the US, only 360 out of every 1,000 Google searches result in clicks to the open web (sites unrelated to Google services), while in the EU, it's slightly higher at 374. Notably, zero-click searches (where users don't click any results after searching) account for 58.5% in the US and 59.7% in the EU.
The data further indicates that Google's own services attract a large amount of traffic, especially prominent in the US. Despite search frequency per user reaching new highs, the proportion of clicks directed to the open web shows a declining trend. Overall, Google maintains a firm grip on the search market. Although EU regulatory measures have to some extent limited Google's self-preferencing behavior, their impact remains limited.
肘子的话
创作者权利在 AI 时代的新挑战
不久前,微软人工智能部门负责人在一次采访中发表了颇具争议的言论,他认为任何在开放网络上发布的内容都可被视为“免费软件”,任何人都可以复制和使用。不出意外,这一观点引起广泛批评,但人们仍十分担忧,这些拥有巨大影响力的科技巨头可能会试图从法律角度将其行为合法化,从而侵蚀原创作者的权利。
Rand Fishkin 最新的研究揭示了另一种数据使用模式。基于海量的数据,Fishkin 分析了 2024 年 Google 搜索行为,发现近六成的搜索流量流向了 Google 自身的服务体系。尽管这个比例令人惊讶,但相比生成式 AI 的做法,Google 的模式对内容创作者而言反而显得较为友好。在 Google 的模式下,原创内容至少还有机会获得点击和流量;而在生成式 AI 的回答体系中,即便提供了相关链接,由于 AI 已经对答案进行了汇总,能为原作者带来的流量往往十分有限,更遑论许多情况下 AI 的回答甚至不会包含数据源信息。
在数字世界中,我们的创作不可避免地会成为人类共同智慧的一部分。然而,当商业公司免费使用这些内容并从中盈利,同时还试图从法律层面剥夺个体对自己创作的所有权时,这无疑是不道德且危险的。越来越多的服务提供商在冗长的用户协议中加入了强制作者放弃版权或允许对内容进行 AI 训练的条款,甚至连付费用户也难以幸免。这种行为无异于饮鸩止渴,不仅会损害这些公司长期以来精心构建的信誉,更会逐步侵蚀互联网蓬勃发展的根基。
无偿分享是一种美德,但这不应成为剥夺创作者应有权利的借口。在 AI 时代,我们更需要在技术创新和权益保护之间找到平衡,共同营造一个尊重创新、保护权益的数字生态系统。
如果您发现这份周报或我的博客对您有所帮助,可以考虑通过 爱发电,Buy Me a Coffee 支持我的创作。
原创
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 的自我引流行为,但其影响仍然有限。