A few days ago, the Epic Games v. Apple case reached a critical milestone. The court ruled that Apple had willfully violated the permanent antitrust injunction issued in 2021. While Apple superficially allowed developers to use third-party payment channels, in practice it maintained its original monopoly position through high commissions, deliberate user-experience friction, and intimidating warning screens. The court not only approved Epic’s motion to enforce the injunction but also took the rare step of referring Apple’s behavior to the U.S. Attorney’s Office for the Northern District of California, to investigate potential criminal contempt of court charges.
Through the iPhone and App Store, Apple has built formidable commercial barriers, transforming from a once unique and proudly innovative company into the type of tech giant it once sought to avoid becoming. As Apple’s market size and influence expanded, its focus naturally shifted from innovation toward protection and defense of its established market position. This is hardly surprising—once an enterprise reaches sufficient scale, the stable returns from preserving market dominance often outweigh the uncertain gains from continuous innovation.
Whether the App Store’s commission rates are reasonable ultimately hinges on the actual value and services it provides to developers. For smaller, particularly independent developers, despite the relatively high commission rate, the App Store offers a stable global payment infrastructure, a trustworthy distribution platform, and convenient promotional tools, making steady revenues achievable. However, large technology firms with their own extensive promotional channels and user bases understandably find it difficult to accept such substantial revenue cuts merely for App Store distribution. This has been at the heart of Apple’s conflicts with developers and regulatory authorities in recent years.
It is foreseeable that this court decision will accelerate global regulatory and legislative scrutiny, potentially marking the end of Apple’s era of easily extracting hefty “toll fees.”
Apple has consistently struggled to escape its hardware-centric development path, lacking sufficiently compelling internet and cloud services to offer truly convincing added value to its ecosystem developers. Many developers deeply invested in the Apple ecosystem naturally gravitate towards Apple’s first-party APIs and services. Furthermore, Apple is entirely capable of enhancing its ecosystem attractiveness by providing more efficient and stable cloud services, richer and more accessible large-scale AI model APIs, or even highly competitive AI cloud computing services. Such improvements would enable Apple to gain developers’ acceptance and generate revenue in ways developers genuinely appreciate. Unfortunately, Apple has yet to do so.
This judgment serves not only as a wake-up call regarding Apple’s arrogance toward court rulings but also highlights the inevitable repercussions stemming from its long-term lack of empathy and its condescending attitude towards its developer ecosystem. Hopefully, this lesson will prompt Apple to genuinely reassess its ecosystem strategies, abandon its defensive mindset, and adopt a more proactive, open, and inclusive approach toward the developer community. By fully leveraging its technological and service advantages, Apple can rebuild developers’ trust and enthusiasm for collaboration. Only then can the App Store return to the right track, establishing a prosperous, sustainable ecosystem that genuinely benefits developers, users, and platform owners alike.
Original
Using equatable() to Avoid the NavigationLink Pre-Build Pitfall
NavigationLink is a component SwiftUI developers love. By ingeniously combining the behavior of Button with navigation logic, it dramatically simplifies code. Unfortunately, in certain scenarios, using it the wrong way can create serious performance issues and make your app sluggish. This article analyzes the cause of the problem and offers a practical—albeit slightly mysterious—solution: adding the equatable() modifier to optimize performance.
Recent Recommendations
What’s New in Swift 6.1?
I’ve previously recommended several excellent articles covering new features in Swift 6.1. However, Paul Hudson’s overview still surfaced a few details I had overlooked. One such feature is Metatype Keypaths, which is exactly what I needed for my current project—it allows accessing static properties via key paths, overcoming the limitation of instance-only access. Another example is #expect(throws:), which I had been using in tests without realizing it was newly added in Swift 6.1. Its refined API makes error handling clearer and reduces the complexity of nested closures.
Protecting Mutable State with Mutex in Swift
While actor remains one of the preferred ways to protect shared mutable state, it’s not always ideal—particularly when you want to avoid introducing asynchronous code. Swift 6 introduces a new Mutex type, a modern synchronization primitive better suited to Swift’s concurrency model. In this article, Donny Wals offers a detailed explanation of how to use Mutex and highlights scenarios where it can be a more appropriate and lightweight alternative:
Mutexis blocking, ideal for quick, synchronous state access.- It doesn’t require asynchronous handling, so it preserves stack structure.
Mutexconforms toSendableand integrates smoothly with Swift 6 concurrency.
Important Note: Thanks to reader Kai for this feedback. While
MutexandwithLock(as discussed in the article) are appropriate tools, exposing the protected state via separategetandsetcomputed properties still carries a risk of data races. Specifically, an operation likecounter.count += 1will actually result in thegetaccessor being called (acquiring and then releasing the lock) followed by thesetaccessor being called (again acquiring and releasing the lock). This means the read, modify, and write steps are not performed atomically under a single lock, creating the risk of data races. A safer approach is to provide a method that completes the entire read-modify-write operation atomically within a single lock (such as the article’s originalincrement()method or an interface likewithValuefrom the swift-concurrency-extras library), rather than exposing separate read and write accessors.
Keep Downloading with a Background Session
Since iOS 7, developers have been able to use URLSession’s background session type to support resumable downloads—even if the app is suspended or terminated. Despite advances in Swift 6, Apple still hasn’t introduced async/await support for this functionality. In this comprehensive article, William Boles explains how background sessions work and why they’re fundamentally incompatible with async/await. In short: background sessions rely on system daemons (nsurlsessiond) to manage transfers outside the app’s lifecycle, whereas async/await depends on an in-process task tree. The two are architecturally incompatible.
Dependency Container on Top of Task Local Values in Swift
Swift’s @TaskLocal property enables implicit context sharing across a task and its child tasks. While it’s not frequently used, it provides an elegant way to inject state in asynchronous contexts. In this article, Majid Jabrayilov demonstrates how to build a lightweight dependency injection container using Task Local values—perfect for scenarios that require dependency isolation without global singletons.
Notably, Swift 6.1 introduces Test Scoping Traits, which also rely on
@TaskLocalunder the hood. They work well in testing scenarios to build isolated and predictable async environments.
Deep or Not Too Deep
Deep Linking is essential for creating seamless user experiences, enabling attribution tracking and context restoration. As mobile systems evolved, so too has the implementation of deep linking. In this in-depth article, Kyryl Horbushko thoroughly reviews the evolution and native solutions for deep linking across iOS and Android, and offers a detailed walkthrough of implementing deferred deep links and attribution using AppsFlyer. A great reference worth bookmarking.
Oscillating Glowing Strings with Metal and SwiftUI
As always, Uladzislau Volchyk returns with another eye-catching SwiftUI + Metal experiment. This time, he builds a glowing, oscillating button using colorEffect and custom shaders. The animation also incorporates SwiftUI techniques like spatialWrap and haptic feedback, enhancing both visual richness and interactive feel.
Tools
Chord Provider
ChordPro is a text-based markup format for aligning chords with lyrics. Nick Berendsen’s Chord Provider is a native, open-source ChordPro file editor and viewer built specifically for macOS. Written entirely in Swift 6 and SwiftUI without third-party dependencies, it’s a great reference project for macOS developers—it demonstrates best practices in managing DocumentGroup, working with CoreAudio, and using SwiftUI’s layout system. For guitar players, it’s also a clean and intuitive desktop companion.
NSAlchemy - Useful macOS Controls for SwiftUI
Despite SwiftUI’s increasing macOS support, many essential controls are still missing. To bridge this gap, Joshua J. Root created NSAlchemy, a library that wraps various AppKit components for SwiftUI use. The current version includes components like HSlider, VSlider, CircularSlider, LevelIndicator, PathControl, ComboBox, Checkbox, AcceleratorButton, ContinuousButton, SearchField, and SegmentedControl. Ideal for building more complete, native-feeling macOS apps with SwiftUI.
VS2X - Convert VS Code Themes to Xcode
Compared to Xcode, VSCode boasts a more vibrant theme ecosystem and a highly active customization community. To help Xcode users tap into this variety, Wei Wang (onevcat) created an online tool that converts your favorite VSCode themes into Xcode-compatible formats. The project was fully generated by AI, and its source code is open-sourced. For clear-cut, purpose-driven tools like this, AI is already showing impressive practical potential.