Fatbobman's Swift Weekly #078
Do Not Market Driver-Assistance as Autonomous Driving
Do Not Market Driver-Assistance as Autonomous Driving
Recently, a fatal accident involving a new electric vehicle brand, resulting in three deaths, has once again sparked concerns about so-called "autonomous driving" capabilities. According to currently available information, the vehicle's "autonomous driving" system failed to recognize a construction zone despite clear warning signs posted along the route, providing an alert only 2–3 seconds before impact. This left the driver with an extremely short window to react.
From a regulatory standpoint, the driver still bears primary responsibility for accidents unless mechanical issues unrelated to driver input are proven, regardless of whether the "autonomous driving" system was activated. Yet, as more accidents become associated with these "autonomous" systems, one must question whether the exaggerated marketing of "autonomous driving" by automotive manufacturers plays a role in these incidents.
Over the past couple of years, a notable phenomenon has emerged: many consumers outside the technology sector have largely acquired their understanding of AI concepts and technical terminology through the promotional events and sales materials of automakers touting "autonomous driving." Terms like "end-to-end" and "TOPS" suddenly turned vehicles—originally transportation tools—into the prime showcase of high technology, making "autonomous driving" capabilities a key factor in consumers' purchasing decisions.
However, given the current state of technology and legal preparedness worldwide, even achieving Level 5 autonomy (with most current models remaining between Levels 2 and 3), the so-called "autonomous driving" systems should strictly be described as "driver-assistance." This is not merely a matter of technological limitation but involves critical legal implications regarding liability. Automakers are well aware of this distinction, often providing disclaimers and fine-print warnings buried deep within their manuals and marketing materials. Despite this, "driver-assistance" has already been widely replaced by the term "autonomous driving" in broader advertising.
Due to continual exaggerated marketing, consumers are unconsciously losing their sense of driving responsibility, mistakenly believing that "autonomous driving" is inherently better and safer. Although certain "autonomous systems" indeed offer helpful assistance, they are far from capable of fully replacing human judgment, particularly in complex or unconventional traffic situations.
It is particularly troubling that automakers typically showcase their highest-end configurations when demonstrating "autonomous" capabilities, neglecting the reduced computing power, fewer sensors, and lower-quality cameras installed in mid- to lower-tier models. Even worse, some manufacturers fail to adequately adapt their algorithms to these reduced hardware configurations, inevitably leading to computation errors and delayed decisions, significantly increasing accident risks.
Terms such as "intelligent" or "autonomous" inherently carry ambiguity, easily misleading consumer perception regarding safety. Given the proven potential for such terms to distort consumer judgment, clear legal guidelines should urgently be introduced to restrict their marketing usage and impose strict penalties on exaggerated claims. Until the law explicitly shifts ultimate responsibility away from drivers, all driving assistance systems, no matter their marketing, must be categorized strictly as "driver-assistance." Consumers should also clearly understand that no automaker today will assume legal responsibility for faults in these "smart systems," and moreover, proving system defects remains beyond the practical ability of ordinary consumers.
Do not market driver-assistance as autonomous driving!
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.
Original
Say Goodbye to dismiss: A State-Driven Path to More Maintainable SwiftUI
In SwiftUI development, the environment value dismiss is widely favored for its flexibility and adaptive behavior. It smartly handles dismissing views according to their context, making it the go-to tool for many developers. However, convenience can come at a cost. Overusing dismiss may introduce subtle bugs, testing difficulties, and hidden stability issues. This article explores why we should be cautious with dismiss and introduces a more robust and reliable state-driven management approach.
Recent Recommendations
Swift 6.1 Released
Swift 6.1 is here! In this article, Holly Borla walks through the most anticipated updates. The release includes broader support for nonisolated, smarter type inference for withTaskGroup, and a more convenient way to interoperate with Objective-C using @objc @implementation. Trailing commas are now supported in more syntax contexts like function parameters, generic definitions, and closure capture lists, making code generation and maintenance simpler.
SwiftPM introduces Package Traits, allowing packages to adapt APIs and dependencies based on runtime environments like Embedded or WebAssembly, further enhancing cross-platform capabilities. Meanwhile, SourceKit-LSP now enables background indexing by default, improving responsiveness and code intelligence during development.
In testing, Swift Testing introduces Test Scoping Traits, making pre- and post-test context control more flexible. Swift-DocC also improves ambiguous overload link handling, enhancing documentation readability and maintainability.
Swift 6.1 is available via Xcode 16.3 or can be installed independently on macOS and Linux using swiftly.
Cross Compiling Swift
Better cross-compilation capabilities are essential for Swift’s future in multi-platform ecosystems. In this article, Khan Winter shares his deep dive into compiling Swift apps on macOS for deployment on Gentoo Linux. He outlines two primary approaches: local cross-compilation with Static Linux SDK and Swiftly, and traditional Docker-based builds. The post also points out the current confusion and inconsistency around toolchain and SDK configuration.
Modern URL Construction in Swift
Avoiding optionals when constructing URLs in Swift is a common goal for many developers. In this long-awaited return article, John Sundell presents modern practices for both static and dynamic URL creation. For static URLs, extending URL.init(staticString:) simplifies forced unwrapping, and the new Swift 5.9 macro #staticURL(...) provides compile-time validation. For dynamic URLs, APIs introduced in iOS 16 like appending(component:) and appending(queryItems:) offer safer alternatives to string interpolation. These practices improve readability and safety in common use cases like networking and file paths.
Presenting an Inspector with SwiftUI
Introduced in iOS 17, iPadOS 17, and macOS 14, Inspector is a SwiftUI component for displaying detailed information about selected content. While it adapts its presentation based on platform and context, this flexibility also adds learning complexity. In this article, Antonella Giugliano walks through a variety of scenarios, demonstrating Inspector in action and explaining how to control its visibility via InspectorCommands and keyboard shortcuts.
Creating an Image from an MKMapView
SwiftUI’s ImageRenderer API is great for rendering images from views, but it doesn’t always meet all needs. Patrick McConnell encountered this limitation while exporting a MapView. His article details how he embedded an MKMapView using NSViewRepresentable in a macOS app and used view hierarchy inspection to capture a complete map image, including paths, overlays, and annotations. The post explains why annotations are typically excluded and offers a stable workaround using extensions to both NSView and MKMapView.
The Top 7 MCP-Supported AI Frameworks
Model Context Protocol (MCP) is becoming the de facto standard for connecting LLMs to external tools through a unified and efficient context injection method. In this article, Amos Gyamfi introduces seven leading MCP-compatible AI frameworks, including OpenAI Agents SDK, LangChain, Chainlit, Agno, Upsonic, and Mastra. Each is accompanied by example code showing how to embed MCP tools into agentic workflows, greatly enhancing extensibility and maintainability. While the code is Python- and TypeScript-based, the concepts offer valuable insights even for Apple developers.
SwiftUI Craftsmanship: State Management
In SwiftUI, everything is driven by state. In this article, Danny Bolella takes the guiding principle of "minimal state" and explores how to simplify and modularize complex state management. By analyzing dependencies and relocating state to subviews, the article shows how to keep UI both responsive and readable. The article avoids prescribing a specific architecture, instead focusing on foundational SwiftUI state handling techniques applicable across patterns.
且勿将辅助驾驶宣传成智能驾驶
不久前，某个造成三人死亡的交通事故因为涉及某新锐电动汽车品牌再度引发了人们对“智能驾驶”功能的质疑。在目前披露的有限资料中，至少可以确认的是，“智能驾驶”系统未能在相当长的一段行驶距离中判断出当前的路段正在施工（沿途有施工警示标志），只在撞击前2-3秒前给予了警示。这意味着，在系统报警后，驾驶者只有极短的反应时间。
从当前的法规角度来说，无论是否启用“智能驾驶”功能，对于事故所造成的后果在没有其他汽车机械结构问题的情况下，仍主要由驾驶人本人来承担。但随着越来越多事故与“智能驾驶”相关联，我们不得不质疑：这难道真的和这些汽车厂商对于“智能驾驶”的过分夸大宣传无关吗？
这一两年，有一个值得注意的现象：很多非从事科技行业的普通消费者了解 AI 概念、专业名词的渠道相当程度来自于这些提供“智能驾驶”的汽车厂商的发布会和销售渠道。从“端到端”到 TOPS，似乎一夜之间，主要作为交通工具的车辆成为了高科技的最佳载体，“智能驾驶”功能成为了消费者购买车辆的重要参考因素。
事实上，无论是从当前的科技发展水平还是各个地区的法律准备来看，即使发展到了 L5 阶段（现阶段大多数车型仍处在 L2 至 L3 之间），所谓的“智能驾驶”仍应被定义为“辅助驾驶”。这不仅关乎系统能力的局限性，更涉及最终责任划分的法律问题。各个车厂很清楚这一点，因此你可以在它们提供的各种说明、手册、宣传资料（角落中，用小字标注）看到它们给出的警示。但在更广泛的宣传渠道上，“辅助驾驶”一词早已被“智能驾驶”所代替。
随着各种对“智驾”的持续宣传，消费者在不知不觉中就丧失了对驾驶安全的责任感，产生了“智驾”更好、更安全的错觉。即使某些“智能系统”确实有着不错的辅助功能，但它们远未达到可以完全替代人类驾驶员判断的程度，尤其是在复杂、非常规的交通环境中。
尤其值得警惕的是，许多厂商在宣传“智能驾驶”能力时，只展示高端配置下的最佳表现，却忽视了中低端车型在算力、摄像头、传感器等方面的减配情况。更严重的是，有些厂商并未针对不同配置对算法进行差异化适配，导致低配车型的“智能系统”极易出现计算失误和决策延迟的问题，这直接加剧了交通事故风险。
实际上，“智能”、“自动”本身就是极易产生误解的模糊概念。当这些模糊的营销词汇已明显误导消费者的驾驶安全认知时，必须尽快出台明确的法律规范，限制相关用语的宣传范围与频率，并对夸大宣传进行严厉处罚。只要法律明确最终责任人仍是驾驶者本人，那么所有驾驶系统无论如何宣传，都应被严格限定在“辅助驾驶”的范畴之内。同时，消费者也应明确认识到，现阶段没有车厂会为所谓“智能系统”的问题承担法律责任。更何况，普通消费者根本不具备就“智能系统”的缺陷进行有效举证的能力。
且勿将辅助驾驶宣传成智能驾驶！
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
原创
远离 dismiss，拥抱状态驱动
在 SwiftUI 开发中，环境值 dismiss 因其灵活、自适应的特性备受开发者青睐。它能够根据当前视图的上下文智能执行关闭操作，让许多开发者将它作为首选工具。然而，便捷的背后往往隐藏着风险。频繁使用 dismiss 可能在应用程序中埋下隐患，引发测试难题乃至难以追踪的稳定性问题。本文将分析我们为何应谨慎对待 dismiss，并介绍更加健壮可靠的状态管理方案。
近期推荐
Swift 6.1 发布
Swift 6.1 正式发布！Holly Borla 在本文中介绍了多个令人期待的新特性。本次更新在语言层面带来了更广泛的 nonisolated 支持、更智能的 withTaskGroup 类型推导，以及更便捷的 @objc @implementation，进一步强化与 Objective-C 的互操作能力。在语法便利性方面，尾随逗号现已支持用于函数参数、泛型定义、闭包捕获列表等结构，简化了代码生成与维护流程。
SwiftPM 引入 Package Traits，支持根据运行环境（如 Embedded 或 WebAssembly）配置不同的 API 和依赖，进一步增强跨平台能力。同时，SourceKit-LSP 现已默认开启后台索引，显著提升开发期间的响应速度与智能感知表现。
在测试方面，Swift Testing 推出了 Test Scoping Traits，使测试前后的上下文共享更加灵活易控；Swift-DocC 也改进了重载函数链接的歧义处理机制，提升文档的可维护性与可读性。
Swift 6.1 可通过 Xcode 16.3 获取，也可使用 swiftly 工具在 macOS 与 Linux 上独立安装。
Swift 的跨平台编译 (Cross Compiling Swift)
提升跨平台编译能力，是 Swift 向全平台生态迈进的重要一步。Khan Winter 在开发 Discord Bot 和 Bluesky Bot 的过程中，深入探索了将 Swift 应用从 macOS 编译部署至 Gentoo Linux 的两种路径：一是借助 Static Linux SDK 与 Swiftly 工具实现的本地交叉编译，二是使用 Docker 容器完成传统的跨平台构建。文章不仅展示了详细的工具链配置与部署脚本，也指出了当前 toolchain 与 SDK 配置上的不一致和易混淆问题。
Swift 中的现代 URL 构造方式 (Modern URL Construction in Swift)
在 Swift 中构造 URL 时避免处理 Optional 一直是开发者关注的问题。John Sundell 在这篇久违的回归文章中，分享了静态与动态 URL 构造的现代实践：对于静态 URL，可通过扩展 URL.init(staticString:) 简化强制解包流程，结合 Swift 5.9 引入的宏功能，还可实现编译期校验的 #staticURL(...)；对于动态 URL，则推荐使用 iOS 16 起提供的 appending(component:) 和 appending(queryItems:) 等 API，替代传统字符串拼接方式，提升代码的安全性与可读性。这些改进让我们能以更简洁、可靠的方式构造 URL，适用于网络请求与文件路径等场景。
在 SwiftUI 中应用 Inspector 组件 (Presenting an Inspector with SwiftUI)
Inspector 是 iOS 17、iPadOS 17 与 macOS 14 中引入的 SwiftUI 组件，常用于展示与选中内容相关的详细信息。它会根据平台与上下文以不同形式呈现，这是其灵活性的体现，也为开发者带来了额外的理解成本。在本文中，Antonella Giugliano 通过多个代码示例，详细演示了 Inspector 在各种使用场景下的表现，并介绍了如何通过 InspectorCommands 实现快捷键控制其显示。
将地图视图保存成图片 (Creating an Image from an MKMapView)
虽然 SwiftUI 提供了 ImageRenderer API 用于将视图转换为图片，但在某些场景下并不能满足需求。Patrick McConnell 在尝试导出 MapView 时就遇到了这个问题。本文分享了他在 macOS 项目中，通过 NSViewRepresentable 嵌入 MKMapView，并借助视图层级探索，找到一种可行方案，最终成功生成包含路径、图层与标注的完整地图图像。文章不仅解释了为何标注无法直接渲染成图像，还提供了对 NSView 与 MKMapView 的扩展代码，实现了当前地图状态的稳定导出。
支持 MCP 的七个 AI 框架 (The Top 7 MCP-Supported AI Frameworks)
Model Context Protocol（MCP）正逐步成为连接 LLM 与外部工具的行业标准，提供了一种统一、高效的上下文注入方式。在本文中，Amos Gyamfi 系统梳理了七个支持 MCP 的主流 AI 框架，包括 OpenAI Agents SDK、LangChain、Chainlit、Agno、Upsonic、Mastra 等，并通过详实的示例代码演示了如何将 MCP 工具集成进代理式（agentic）工作流，显著提升 AI 应用的扩展性与可维护性。尽管示例代码基于 Python 与 TypeScript，仍为苹果生态开发者提供了参考思路。
SwiftUI 状态管理 (SwiftUI Craftsmanship: State Management)
在 SwiftUI 中，一切皆由状态驱动。本文中，Danny Bolella 以“最小状态”作为指导原则，探讨了如何在复杂界面中实现状态管理的简化与分层：通过识别状态间的依赖关系，将状态分离到对应的子视图中，不仅提升了代码可读性，也让 UI 保持响应性与可维护性。
AdventureX 2025
AdventureX 2025 将于 2025 年 7 月 23 日至 27 日在中国杭州举行。本届活动将创造中国黑客松规模的新纪录，提供 800 个参赛名额，并为参赛者提供免费食宿与出行补助。
活动 报名通道