The U.S. Department of Justice (DOJ) and Google have recently made significant progress in their antitrust litigation. The court found that Google had disadvantaged competitors and harmed publishers and consumers by tying its ad server to its ad exchange platform and manipulating the auction process. As one potential remedy, the DOJ is considering requiring Google to divest its Chrome browser and terminate its default search-engine agreements with device manufacturers. Following rumors of OpenAI’s $3 billion bid for WindSurf, OpenAI immediately expressed interest in acquiring Chrome once the ruling was announced.
Today’s browsers, in terms of capability and scale, rival mature operating systems. Although multiple brands appear to compete, many are actually built on the same Chromium engine. Since its inception, Google has shouldered the bulk of Chromium’s development and maintenance. As of 2024, Chrome-based browsers command over 65 percent of the market, making Chrome the de facto industry standard.
Google’s sustained investment in Chrome (Chromium) is driven by its closed-loop advertising model: a better browsing experience → more searches → more precisely targeted ads → higher ad revenues. It is this very cycle that motivates Google to pour vast resources into Chrome. If Chrome were spun off, it is hard to imagine what would motivate Google to continue supporting Chromium’s development. For a product of Chrome’s scale, merely poaching some of Google’s talent would be far from sufficient to maintain its current pace and quality of innovation.
Even more troubling is this: if another capable company were to take over Chrome, how could we ensure it wouldn’t exploit Chrome’s enormous influence to erect new barriers to entry? If it is prohibited from leveraging Chrome for non-browser commercial gains, what incentive would remain for it to invest in the platform? Historical examples of antitrust-driven breakups that failed to preserve genuine competition are plentiful, exposing the paradox at the heart of antitrust enforcement: splitting is easy; preventing new monopolies is hard.
At its core, antitrust policy should ensure fair market competition and prevent dominant firms from abusing their advantage to stifle rivals. Google’s monopoly position is rightly subject to scrutiny. Yet, is forcing the divestiture of Chrome truly the right solution? Will it genuinely foster a healthier market environment?
Frankly, even if Chrome were forced to be sold, OpenAI would hardly be an ideal buyer. My concern is shared by many online: there is widespread unease about OpenAI acquiring Chrome. Although AI foundation-model companies currently enjoy extraordinary growth, their offerings remain primarily aimed at enterprise and professional users; they have not yet deeply penetrated everyday consumer life. Thus, they urgently need a vehicle that can rapidly reach ordinary users and forge deeper engagement.
Integrating ChatGPT with Chrome would undoubtedly boost OpenAI’s visibility among everyday users. However, it would also risk creating a novel, unprecedented monopoly: a super-platform combining state-of-the-art AI capabilities with a massive gateway to user data. A browser is not only the portal to the internet but also a critical hub for personal data collection—and the ramifications of such an integration would far exceed our current imagination. While Google could achieve similar integration, its ad-driven business model inherently limits the extent to which it can fully embed AI into the search and browsing experience.
As a developer who spends 90 percent of my time in Safari, I fully support effective measures to curb market abuse by tech giants. But I do not believe that simply carving Chrome out of Google is the most prudent course, nor do I welcome seeing it fall into the hands of another potentially monopolistic entity. What the market truly needs is not mere breakups and reshuffling, but the cultivation of a more open ecosystem characterized by healthy competition. That is the balance we must strike between antitrust enforcement and technological innovation.
Original
Building Type‑Safe, High‑Performance SwiftData / Core Data Models
Swift’s powerful type system empowers us to create semantically explicit and safe data models. Yet when we move to SwiftData or Core Data, the constraints of their underlying storage mechanisms often force us to compromise on type expressiveness. Those concessions blur our domain models’ intent and plant hidden seeds of instability. This article explores how, within the restrictions of persistence layers, we can leverage ingenious type wrappers and conversions to build data models that are simultaneously Type-safe, semantically clear, and highly efficient.
【Tip】Fixing SwiftLint Configuration Not Working in Monorepo Projects
Recent Recommendations
How to Make NSImage Sendable in Swift
Swift 6 introduces stricter concurrency checks, requiring types used across threads to conform to Sendable. However, NSImage doesn’t meet this requirement. In this article, Khoa Pham provides three approaches: forcibly marking it with @unchecked Sendable, converting it into a Sendable-friendly format like PNG data or CGImage, or safely managing it through an Actor wrapper.
Create a Fully Custom About Window for a Mac App in SwiftUI
With the growing capabilities of SwiftUI on macOS, many platform-specific view modifiers have been introduced. In this post, Natalia Panferova details how to build a fully custom “About” window using SwiftUI and showcases new features like toolbar customization, draggable backgrounds, translucent window materials, window button controls, size constraints, and restoration behavior settings. These techniques help developers fully control the appearance and behavior of SwiftUI-based macOS windows for a more integrated app design.
Swift Error Handling Done Right: Overcoming the Objective-C Error Legacy
Swift’s Error protocol is bridged to Objective-C’s NSError, which often results in vague error messages like (YourError error 0) unless you manually implement LocalizedError. Due to its optional properties, it’s easy to overlook necessary declarations. Cihat Gündüz proposes an improvement: a Throwable protocol that enforces a clear userFriendlyMessage for each error type. Combined with his ErrorKit, this approach dramatically enhances the clarity, controllability, and localization of error messages while keeping Swift’s native error-handling flow.
The Marvelous Peculiarities of Swift
Many believe that once you master one modern strongly typed language, others come easily. Yet, even among seemingly similar concepts, there are vast differences between languages. Xheldon shares his experience learning Swift after extensive work with TypeScript — and the surprises he encountered. This article documents Swift’s unique designs across areas such as comments, optional binding, collection types, control flow, closures, enums, structs and classes, protocols, generics, and more.
More than just comparing language features — it’s a refreshing new way to appreciate Swift.
Using the Share Sheet to Share Content in a SwiftUI App
The Share Sheet (Activity View) provides users with actions relevant to their current context. In early SwiftUI versions, developers had to rely on UIKit to present it. From iOS 16 onwards, SwiftUI introduced the native ShareLink component, greatly simplifying the sharing workflow. Gabriel Fernandes Thomaz and Tiago Gomes Pereira explain the basics of using ShareLink, including sharing URLs, customizing labels and previews, and extending it to support custom data types via the Transferable protocol — helping apps better integrate with the system share experience and improving user interactions.
Tools
Fully Native Cross-Platform Swift Apps
Like many developers, I’ve long wished to use SwiftUI to build truly cross-platform apps — including Android. Skip brings this vision closer to reality: by mapping SwiftUI code onto Jetpack Compose on Android, Skip enables sharing both business logic and UI code across platforms while retaining native performance and experience. Developers can write and debug Swift directly in Xcode and run apps simultaneously on iOS and Android emulators. Marc Prud’hommeaux provides a detailed guide to setting up the environment, project structure (including the roles of SkipFuseUI and SkipFuse modules), Kotlin interoperability, and leveraging Swift and Android ecosystems. Although Skip is still in technical preview, real-world apps like Skip Notes have already launched successfully on both app stores.
Meanwhile, the Swift community is actively pushing forward official Swift support on Android — you’re welcome to follow and participate via the Swift Forums’ Android section.
SharingGRDB: A Fast, Lightweight Replacement for SwiftData
With the new release of SharingGRDB, Point-Free has also updated the documentation, particularly the comparison with SwiftData section, which is well worth a read. Compared to SwiftData, SharingGRDB offers lower deployment targets, complete access to SQLite features, compile-time query validation, and better runtime performance. If you prefer SQL-style data modeling, relational database structures, and prioritize clean, controllable, and efficient persistence — SharingGRDB is a very attractive choice.
Note: At present, neither SharingGRDB nor its underlying GRDB library offers a mature cross-device sync solution like SwiftData/Core Data. Please evaluate carefully based on your project needs.