Fatbobman's Swift Weekly #081
Fatbobman's Swift Weekly #081The Chrome Paradox: Could DOJ’s Antitrust Remedy Create OpenAI’s Next Monopoly?
The Chrome Paradox: Could DOJ’s Antitrust Remedy Create OpenAI’s Next Monopoly?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. Previous Issue｜Newsletter Archive If you appreciate my work and want to promote your product to the Swift and iOS developer community, sponsoring my blog & newsletter could be an excellent opportunity for you. OriginalBuilding Type‑Safe, High‑Performance SwiftData / Core Data ModelsSwift’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 ProjectsRecent RecommendationsHow to Make NSImage Sendable in SwiftSwift 6 introduces stricter concurrency checks, requiring types used across threads to conform to Create a Fully Custom About Window for a Mac App in SwiftUIWith 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 LegacySwift’s The Marvelous Peculiarities of SwiftMany 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.
Using the Share Sheet to Share Content in a SwiftUI AppThe 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 ToolsFully Native Cross-Platform Swift AppsLike 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.
SharingGRDB: A Fast, Lightweight Replacement for SwiftDataWith 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.
Chrome 会成为 OpenAI 的下一个目标？美国司法部（DOJ）与谷歌之间的反垄断诉讼近期取得了重大进展。法院认定，谷歌通过将其广告服务器与广告交易平台捆绑销售，以及操控广告拍卖机制等行为，排挤了竞争对手，损害了出版商和消费者的利益。作为补救措施的讨论之一，美国司法部正在考虑建议强制谷歌出售其 Chrome 浏览器，并终止与设备制造商的默认搜索引擎协议。继传闻将以 30 亿美金收购 WindSurf 后，OpenAI 在上述判决之后立刻表达了对 Chrome 的收购兴趣。 如今的浏览器，无论从功能还是规模上来说，都与成熟的操作系统不相上下。市场上看似存在多种不同名称的浏览器，但事实上，很大一部分都基于相同的 Chromium 内核。自该项目启动以来，谷歌一直承担着主要的开发和维护工作。截至 2024 年，Chrome 系浏览器的市场份额已超过 65%，形成了事实上的浏览器标准。 推动谷歌持续投入 Chrome（Chromium）开发的核心动力，来自于其搜索广告模式的商业闭环：更好的浏览体验 → 更多的网络查询 → 更精准的结果投放 → 更高的广告收入。正是在这个内因驱动下，谷歌才不惜投入大量人力和资金发展 Chrome。如果 Chrome 被从谷歌剥离出来，很难想象谷歌还有动力继续支持 Chromium 的开发。对于 Chrome 这种级别的产品来说，仅仅从谷歌挖走一批人才远远不足以维持其目前的发展速度与质量。 更值得深思的是：假设有一家具备维护 Chromium 项目能力的公司接手 Chrome，我们又如何确保它不会利用 Chrome 的巨大影响力建立新的垄断壁垒？不让其利用 Chrome 获取产品之外的商业价值，这家公司又何来继续投入的动力？历史诸多因反垄断而拆分失败的案例历历在目，这恰恰暴露了反垄断执法的两难处境：拆分易，防垄断难。 反垄断机制的核心本应是确保市场竞争的公平性，防止具备垄断地位的公司利用其优势地位打压竞争者。对于谷歌垄断地位的认定，我认为是无可厚非的。然而，推动其剥离 Chrome，真的是解决问题的正确方向吗？或者说，这真能带来更健康的市场环境吗？ 坦率地讲，即使 Chrome 最终被迫出售，OpenAI 也绝非一个理想的收购方。这并非我个人的忧虑，网络上已有大量用户表达了对 OpenAI 收购 Chrome 的不安。尽管当前 AI 大模型公司如日中天，但其产品主要仍面向企业或专业领域，尚未真正深入普通消费者的日常生活。因此，它们急需一种能快速触达普通用户并深入绑定的载体，以构建更广泛且牢固的用户联系。 将 ChatGPT 与 Chrome 融合，的确能迅速提升 OpenAI 在普通用户中的影响力。但与此同时，也极可能催生一种前所未见的新型垄断——一个融合先进 AI 技术与海量用户数据入口的超级平台。浏览器不仅是用户进入互联网的门户，更是个人数据的重要入口，而这种结合的影响将远超我们当前的想象。尽管谷歌也具备这种能力，但其广告盈利模式制约了它将 AI 与搜索进行完全整合。 作为一个 90% 时间都使用 Safari 的开发者，我完全赞同对大公司滥用市场优势地位的有效制约，但我并不认为从谷歌中简单地剥离 Chrome 是明智之举，更不希望看到它落入另一个可能建立新型垄断的公司手中。市场真正需要的并不是简单的拆分与重组，而是建立更加开放且具备健康竞争的生态环境。这才是反垄断执法与科技创新之间应当追求的平衡之道。 如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。 原创构建类型安全、高效的 SwiftData/Core Data 模型Swift 强大的类型系统使我们能够创建语义明确且安全的数据模型。然而，当面对 SwiftData 或 Core Data 时，我们常因底层存储机制的限制，而不得不在类型表达上做出妥协。这种妥协不仅模糊了领域模型的本意，也为应用的稳定性埋下隐患。本文将探索如何在数据持久化的约束下，通过巧妙的类型封装和转换，构建兼具类型安全、语义明确与高效性能的数据模型。 【Tip】解决在 Monorepo 项目中 SwiftLint 配置文件无效近期推荐让 NSImage 支持并发安全传递 (How to Make NSImage Sendable in Swift)Swift 6 对并发编程引入了更严格的检查，要求跨线程使用的类型必须是安全可发送的（Sendable）。但 用 SwiftUI 自定义 macOS App 的 About 窗口 (Create a Fully Custom About Window for a Mac App in SwiftUI)随着 SwiftUI 在 macOS 上能力的增强，许多专为该平台设计的视图修饰器被引入。本文中，Natalia Panferova 详细介绍了如何使用 SwiftUI 构建一个完全自定义的“关于”窗口，并展示了如何应用新特性，如调整工具栏、启用拖动、设置半透明背景、控制窗口按钮、限制窗口大小和关闭位置复原。通过这些步骤，开发者可以全面掌控基于 SwiftUI 的 macOS 窗口外观与行为，使其更好融入应用整体设计。 优雅地解决 Swift 错误处理的历史遗留问题 (Swift Error Handling Done Right: Overcoming the Objective-C Error Legacy)Swift 的 摩诃不思议的 Swift很多人觉得现代强类型语言的设计趋同，只要掌握一门便能快速上手另一门。但实际上，即使是相似概念，不同语言间也存在着巨大的差异。Xheldon 在拥有丰富 TypeScript 经验的前提下，学习 Swift 时依然屡屡感到震惊。本文记录了他从注释、可选绑定、集合类型、控制流、闭包、枚举、结构体与类、协议、泛型等各个方面，遇到的 Swift 特有设计与理解过程。
用 SwiftUI 原生集成系统分享面板 (Using the Share Sheet to Share Content in a SwiftUI App)分享面板（Activity View）列出了用户在当前上下文中可以执行的一系列操作。早期 SwiftUI 版本需要借助 UIKit 才能调用分享功能，而从 iOS 16 开始，SwiftUI 提供了原生的 ShareLink 组件，大幅简化了实现流程。Gabriel Fernandes Thomaz 和 Tiago Gomes Pereira 在本文中介绍了 🪜 iOS 开发补完计划资深 iOS 开发者 13 在转型成为全职内容创作者后，计划推出新的专栏：「iOS 开发补完计划」。与传统教程不同，这个专栏将专注于那些即使借助 AI 也难以习得、但对成功开发和上架 App 至关重要的观念、知识与经验。13 希望通过这个专栏，弥补资深开发者与新手之间长期存在的知识断层。在本文中，他详细列出了计划中可能覆盖的数十个主题，包括商业观念、学习方法、开发环境、技术基础、用户体验、产品思维、AI 工具应用、开发者社群、职场心法，以及身心健康等，旨在帮助更多初学者少走弯路，高效成长。 工具用 Swift 打造真正原生的跨平台应用 (Fully Native Cross-Platform Swift Apps)很多开发者和我一样，都希望能够使用 SwiftUI 来构建真正的跨平台应用（包括 Android）。Skip 让这一梦想更进一步：通过将 SwiftUI 代码映射到 Android 平台的 Jetpack Compose，Skip 实现了业务逻辑和 UI 代码的双向共享，兼顾了开发效率与原生体验。开发者可以直接在 Xcode 中编写、调试 Swift 代码，同时在 iOS 和 Android 模拟器上同步运行和测试应用。Marc Prud'hommeaux 在本文中详细介绍了开发环境的搭建流程、项目结构（如 SkipFuseUI 和 SkipFuse 模块）、与 Kotlin 互通的机制，以及如何结合 Swift 和 Android 的生态资源。目前 Skip 仍处于技术预览阶段，但已有实际应用如 Skip Notes 成功在双平台应用商店上线。
轻量且高性能的 SwiftData 替代方案 (SharingGRDB: A Fast, Lightweight Replacement for SwiftData)随着 SharingGRDB 新版本发布，Point-Free 也同步更新了详细文档，其中与 SwiftData 的 对比章节 尤为值得关注。相较于 SwiftData，SharingGRDB 带来了更低的系统版本支持、更全面的 SQLite 能力、基于编译时的查询检查机制，以及更好的运行性能。如果你更偏好 SQL 风格、基于关系数据库的数据组织设计、追求干净、可控且高效的持久化体验，SharingGRDB 将是一个极具吸引力的选择。
求贤招募 Swift（visionOS）开发者。base 杭州。（详情见下图）
Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
