# 39 : New Challenges for Creators' Rights in the AI Era

Published on

Photo by Markus Winkler on Unsplash

Explore weekly Swift highlights with developers worldwide

Weekly Comment

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.


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

Dave Verwer & Sven A. Schmidt

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

Antoine van der Lee

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

Kenji Wada

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

Keith Harrison

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

Rand Fishkin

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.

Get weekly handpicked updates on Swift and SwiftUI!

Buy me a if you found this article helpful