Fatbobman's Swift Weekly #152
When the Mac mini’s Price Is No Longer MiniLate last month, Apple released the new Mac mini and Mac Studio. Alongside the impressive performance upgrades, the noticeably higher prices were just as striking. Rising memory and storage costs are undoubtedly a major factor, but in the AI era, developers’ hardware needs are also quietly changing. More memory and more storage keep raising our idea of what counts as a “good enough” configuration—and pushing the price we actually pay even higher. Over the past few months, one of the biggest annoyances in my development work has been the constant noise of my MacBook Pro’s fans. For years, I would only really notice them under a handful of heavy workloads. But in the age of AI agents, having the fans running has become almost routine. Limited by the space inside a laptop and the size of its fans, the noise under sustained load also tends to be more noticeable—and more irritating—than on a desktop machine like the Mac mini. At the same time, I’ve realized that the MacBook no longer feels as indispensable to my workflow as it once did. Unless I have a specific need, a phone and a tablet are already enough for quite a few Vibe Coding scenarios on short trips. Even when I do need a laptop, a lighter and less powerful model would probably be more than sufficient. So I’ve started seriously considering moving my primary development environment from a MacBook Pro to a Mac mini or Mac Studio. That brings up another problem: for a primary development machine, memory capacity is a hard requirement. I have almost no need to run LLMs locally, but if I’m upgrading my computer, the new machine needs to offer meaningfully more than the 64GB I already have for the upgrade to feel worthwhile. That essentially rules out the M5 Pro Mac mini, leaving me with the M5 Max and M5 Ultra Mac Studio. Interestingly, the next memory tier above 64GB is 128GB on one and 96GB on the other, yet the final prices are remarkably close. One gives me more memory; the other, a more powerful chip. I’m not usually someone who struggles to make a choice, but this one has genuinely left me undecided. Meanwhile, OpenClaw’s popularity has drawn the attention of many consumers who previously had little interest in the Mac mini. OpenAI has also reportedly purchased tens of thousands of Mac minis and Mac Studios for reinforcement learning and training computer-use agents. AI-driven demand at one point grew far faster than Apple had anticipated. Combined with pressure on memory supply and advanced chip manufacturing capacity, this has kept the Mac mini and Mac Studio in short supply over the past few months. Even with the new generation now available, getting the exact configuration you want quickly is still not necessarily easy. The productivity gains brought by AI may not yet be fully visible across society, but its appetite for compute, memory, and storage resources is already showing up in the hardware market. From components to complete systems, a wide range of consumer hardware is facing new pricing pressure. The old upgrade cycle—waiting a few years and spending roughly the same amount for a substantially more powerful computer—seems increasingly difficult to sustain, at least for now. But there’s another side to the story: we can’t blame everything on rising prices. While AI is pushing hardware costs upward, it is also changing how we develop software and quietly raising our definition of what counts as a “good enough computer.” Hardware has become more expensive, but we’ve also started asking more of it. Hopefully, one day we’ll get back to a time when buying a Mac mini doesn’t require quite so much mental preparation. Previous Issue｜Newsletter Archive 📢 Sponsor Fatbobman’s Swift WeeklyPromote your product to Swift & iOS developers across: - Blog: 50,000+ monthly visitors Perfect for developer tools, courses, and services. Enjoyed this issue? Buy me a coffee ☕️ OriginalSwiftData: Optimization Starts with ModelingOnce the dataset grows large, SwiftData lists start to lag. This is one of the performance complaints I’ve heard most often over the past few years. Developers’ first instinct is usually to blame SwiftUI’s
Recent RecommendationsThe End of Swift TalkAfter ten years and 500 episodes, Chris Eidhof and Florian Kugler have announced the end of Swift Talk. Since its launch in June 2016, Swift Talk has accompanied Swift through nearly its entire journey toward maturity, while also witnessing SwiftUI grow from its introduction into a core UI framework for Apple platform development. Through a long series of deep and highly experimental episodes, the two explored Swift, SwiftUI, layout, animation, concurrency, and many lower-level topics rarely covered in conventional tutorials. They hope to make the complete archive of more than 500 episodes available to the community by the end of this year. For me, objc.io and Swift Talk have always occupied a very special place in the Swift community. Chris and Florian were rarely satisfied with simply telling developers how an API “should be used.” Instead, they would experiment, refactor, and sometimes even reimplement things to understand why a framework works the way it does. This approach to exploration has influenced many Swift developers, myself included. Thank you, Chris and Florian, for the time, knowledge, and curiosity you’ve contributed to the Swift community over all these years, and for the invaluable archive Swift Talk leaves behind. What’s new in Swift: August 2026 EditionSwift has published its August ecosystem update, curated by Simon Leeb and Dave Lester, covering noteworthy community projects, package updates, and Swift Evolution developments. What interests me most is Swift’s progress on the Web: Simon Leeb demonstrated a Full-Stack Swift on Cloudflare Demo, with Swift running in the browser through ElementaryUI and WebAssembly, a backend running on an edge worker, and message types shared between the two sides. From Embedded Swift and Wasm to an increasingly capable cross-platform toolchain, Swift continues to expand its reach beyond Apple platforms. At the language level, the recently accepted Iterable is also worth watching. OpenSwiftUI on ESP32-C3The Swift update above showed how Swift continues to push beyond the boundaries of Apple platforms, and a recent experiment by OpenSwiftUI developer Kyle Ye provides a very tangible example of that trend. After receiving an ESP32-C3 development device from TraeAI, Kyle completed his first Embedded Swift project: deploying an embedded version of OpenSwiftUI to this RISC-V-based microcontroller. On its 240 × 320 LCD, he built interfaces using familiar APIs such as The experiment uses Embedded Swift to compile native RISC-V code, with OpenSwiftUI handling view composition and layout before passing drawing through a thin rendering boundary to LVGL and the underlying hardware. In other words, a lean but complete UI pipeline has been established, from declarative views and layout calculation to state updates and final pixel output. Multiplatform Swift, with C++ dependencies via XCFramework, apt and vcpkgWhether a Swift application can truly become cross-platform often depends on whether its underlying C/C++ dependencies can make the journey as well. Harald Achitz uses his own ZeroMQ Swift bindings as an example to show how a Swift/C++ project targeting macOS, Linux, and Windows can organize its native dependencies: XCFrameworks on Apple platforms, system packages on Linux, and vcpkg to install ZeroMQ on Windows. Connecting two iOS simulators over BLECoreBluetooth is completely unavailable in the iOS Simulator, which has long made BLE app development and testing dependent on physical devices. While developing BLESwift 2.0, Kyle Browning took a different approach: instead of calling CoreBluetooth, the central and peripheral devices in the Simulator forward their operations over localhost TCP to
Reorder all the things in SwiftUISwiftUI has long lacked a general-purpose API for drag-to-reorder interactions in arbitrary containers, a limitation that was finally addressed after WWDC 2026. Alexander Logan introduces SwiftUI’s new reordering APIs. With APIs such as Building a sunburst diagram in Swift ChartsA Sunburst Diagram is a chart that uses concentric rings to represent hierarchical data—for example, moving from “Work” to “Development” and then to a specific project, with each outward ring representing a deeper level of detail. Matthaus Woolard demonstrates how to use Swift Charts’ ToolCoreDataBrowser: Quickly Inspect Local Data in the SimulatorWhen debugging Core Data or SwiftData apps, you typically need to locate the relevant data files buried deep within the Simulator’s directory hierarchy, then open them in a SQLite manager to inspect the data. CoreDataBrowser, developed by Csaba Turdesan, aims to simplify this process: after selecting the currently running Simulator, it automatically locates Core Data, SwiftData, and UserDefaults data sources in app containers and presents them together in a native macOS interface. CoreDataBrowser supports browsing tables and records, searching and highlighting matches, and attempting to decode certain binary data (BLOBs) as NSKeyedArchive, JSON, Property List, or UTF-8 text. The tool is tiny (2.5 MB), and its source code is publicly available. Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it. 当 Mac mini 的价格不再 mini上月底，苹果发布了新的 Mac mini 和 Mac Studio。除了强悍的性能更新，明显上涨的价格同样给人带来了不小的震撼。内存与存储成本上涨无疑是本轮涨价的重要原因，但在 AI 时代，开发者对硬件的需求也在悄然发生变化。更大的内存、更高的存储容量，不断推高我们心目中“够用配置”的标准，最终也让实际购买价格变得更加夸张。 过去几个月，开发中最让我头痛的一件事，是 MacBook Pro 风扇持续转动带来的噪音。过去多年的使用中，只有在少数高负载场景下，我才会明显意识到风扇的存在。但到了 AI Agent 时代，风扇常转几乎成了家常便饭。受限于机身空间和风扇尺寸，笔记本在持续高负载下产生的噪音，往往也比 Mac mini 这类桌面设备更容易让人感到不适。 与此同时，我发现 MacBook 在自己的工作流中似乎也没有以前那么不可替代了。除非有特殊需要，短途出差时，手机和平板已经足以应付不少 Vibe Coding 场景。即便仍然需要一台笔记本，一台更轻、配置更低的设备似乎也完全够用。因此，我开始认真考虑把主力开发设备从 MacBook Pro 转移到 Mac mini 或 Mac Studio 上。 问题随之而来：作为主力开发设备，内存容量必然是一道硬门槛。尽管我几乎没有运行本地 LLM 的需求，但既然是一次设备更新，新机器的内存至少应该明显高于当前的 64GB，才能让我感受到足够的升级价值。如此一来，采用 M6 或 M5 Pro 的 Mac mini 基本就被排除了，剩下的选择只有 M5 Max 和 M5 Ultra 的 Mac Studio。 有趣的是，两款机型在 64GB 之上的下一档内存分别是 128GB 和 96GB，而最终价格却相差无几。一个给更多内存，一个给更强芯片。即便我平时并不算有选择困难，这次也确实有些犯难。 与此同时，OpenClaw 的风行让不少原本并不关注 Mac mini 的消费者开始将目光投向这台小机器。据报道，OpenAI 也采购了数万台 Mac mini 和 Mac Studio，用于强化学习和 Computer-use Agent 的训练。AI 带来的需求增长一度远超苹果的预期，再加上内存供应和先进制程产能的压力，让 Mac mini 和 Mac Studio 在过去几个月一直处于供不应求的状态。新一代产品发布之后，想要尽快拿到自己心仪的配置，依然不是一件容易的事。 AI 带来的效率提升或许还没有在整个社会中充分显现，但它对算力、内存和存储资源的争夺，已经率先反映到了硬件市场。从零部件到整机，大量消费级硬件都在承受新的价格压力。过去那种隔几年用差不多的钱，就能买到一台明显更强电脑的更新节奏，至少在现阶段似乎越来越难维持了。 但更有意思的是，我们又不能把这一切完全归咎于涨价。AI 在推高硬件成本的同时，也改变了我们的开发方式，并悄悄抬高了我们对一台“够用电脑”的定义。硬件变贵了，我们想要的也更多了。 希望未来某一天，我们还能找回那个不用做太多心理建设，就能轻松选购一台 Mac mini 的时代。 如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。 原创SwiftData：优化从建模开始数据集一大，SwiftData 的列表就开始卡。这是这几年里我听到最多的性能抱怨。开发者的第一反应通常会指向 SwiftUI 的
近期推荐十年终章：Swift Talk 宣布停更 (The End of Swift Talk)在开始十年、完成 500 期节目后，Chris Eidhof 和 Florian Kugler 宣布 Swift Talk 正式结束。从 2016 年 6 月开始，Swift Talk 几乎完整陪伴了 Swift 走向成熟的过程，也见证了 SwiftUI 从诞生到逐渐成为 Apple 平台 UI 开发核心框架的这些年。两人通过一系列深入而又充满实验性的节目，探索了 Swift、SwiftUI、布局、动画、并发以及大量很难在普通教程中看到的底层问题。官方表示，希望在今年年底让完整的 500 多期节目归档能够继续提供给社区。 对我而言，objc.io 和 Swift Talk 一直是 Swift 社区中非常特别的存在。Chris 和 Florian 很少满足于告诉开发者一个 API “应该怎么用”，而是习惯通过实验、重构甚至重新实现，去追问框架为什么会这样工作。这种探索方式影响了许多 Swift 开发者，也包括我自己。感谢 Chris 和 Florian 这些年来为 Swift 社区投入的时间、知识与好奇心，也感谢 Swift Talk 留下的这份珍贵档案。 Swift 官方 8 月报 (What’s new in Swift: August 2026 Edition)Swift 官方发布了 8 月生态月报，由 Simon Leeb 和 Dave Lester 整理，汇总了近期值得关注的社区项目、Package 更新和 Swift Evolution 进展。其中最让我感兴趣的是 Swift 在 Web 方向上的推进：Simon Leeb 展示了一个 Full-Stack Swift on Cloudflare Demo，浏览器端通过 ElementaryUI 和 WebAssembly 运行 Swift，后端则运行在 edge worker 上，两端还能共享消息类型。从 Embedded Swift、Wasm 到越来越完善的跨平台工具链，Swift 的使用边界正在继续向 Apple 平台之外扩展。 语言层面，刚刚获批的 Iterable 也很值得关注。 在嵌入式设备上运行 OpenSwiftUI (OpenSwiftUI on ESP32-C3)上面的 Swift 月报展示了 Swift 正在不断突破 Apple 平台的边界，而 OpenSwiftUI 开发者 Kyle Ye 最近的一次尝试，则给这个趋势提供了一个很直观的例子。在收到 TraeAI 赠送的 ESP32-C3 开发设备后，Kyle 完成了自己的第一个 Embedded Swift 项目：将 OpenSwiftUI 的嵌入式版本部署到这块采用 RISC-V 架构的微控制器上，并在 240 × 320 的 LCD 上使用我们熟悉的 这个实验利用 Embedded Swift 编译原生 RISC-V 代码，由 OpenSwiftUI 负责视图组合和布局，再通过一个很薄的渲染边界将绘制交给 LVGL 和底层硬件。换句话说，从声明式 View、布局计算、状态更新到最终像素输出，一套精简但完整的 UI 链路已经建立起来。 Swift 跨平台实践：多平台下的 C++ 依赖管理 (Multiplatform Swift, with C++ dependencies via XCFramework, apt and vcpkg)一个 Swift 应用能否真正实现跨平台，很多时候取决于其背后的 C/C++ 依赖能否跟着跨平台。Harald Achitz 以自己的 ZeroMQ Swift bindings 为例，展示了一个同时支持 macOS、Linux 和 Windows 的 Swift/C++ 项目如何组织原生依赖：Apple 平台使用 XCFramework，Linux 使用系统 package，Windows 则通过 vcpkg 安装 ZeroMQ。 在 iOS 模拟器间实现虚拟蓝牙通信 (Connecting two iOS simulators over BLE)CoreBluetooth 在 iOS Simulator 中完全不可用，这让 BLE App 的开发和测试长期依赖真机。Kyle Browning 在开发 BLESwift 2.0 时换了一种思路：Simulator 中的中心设备（Central）和外围设备（Peripheral）不再调用 CoreBluetooth，而是通过 localhost TCP 将操作转发给运行在 Mac 上的
探索 SwiftUI 全新的任意容器拖拽排序 API (Reorder all the things in SwiftUI)SwiftUI 长期以来没有提供在任意容器中实现拖拽排序的通用 API，这个遗憾在 WWDC 2026 后得到了解决。Alexander Logan 介绍了 SwiftUI 新的 reordering API。通过 Swift Charts 进阶：如何绘制多层旭日图 (Building a sunburst diagram in Swift Charts)旭日图（Sunburst Diagram）是一种用同心圆环展示层级数据的图表，例如从“工作”到“开发”，再到某个具体项目，越向外代表越细的数据层级。Matthaus Woolard 展示了如何利用 Swift Charts 的 工具CoreDataBrowser：快速查看 Simulator 中的本地数据调试 Core Data 或 SwiftData 应用时，通常需要先在层层嵌套的 Simulator 目录中找到对应的数据文件，再用 SQLite 管理器打开并浏览数据。由 Csaba Turdesan 开发的 CoreDataBrowser 尝试把这个过程变得简单：选择当前启动的模拟器后，它会自动查找应用容器中的 Core Data、SwiftData 以及 UserDefaults 数据源，并通过原生 macOS 界面统一呈现。 CoreDataBrowser 支持查看表与记录、搜索并高亮匹配内容，也能对部分二进制数据（BLOB）尝试解析 NSKeyedArchive、JSON、Property List 和 UTF-8 文本。工具体量很小（2.5 MB），并且源码公开。 Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
