Fatbobman's Swift Weekly #078
Do Not Market Driver-Assistance as Autonomous DrivingRecently, 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. OriginalSay Goodbye to dismiss: A State-Driven Path to More Maintainable SwiftUIIn SwiftUI development, the environment value Recent RecommendationsSwift 6.1 ReleasedSwift 6.1 is here! In this article, Holly Borla walks through the most anticipated updates. The release includes broader support for 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.
Cross Compiling SwiftBetter 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 SwiftAvoiding 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 Presenting an Inspector with SwiftUIIntroduced in iOS 17, iPadOS 17, and macOS 14, Creating an Image from an MKMapViewSwiftUI’s The Top 7 MCP-Supported AI FrameworksModel 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 ManagementIn 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 开发中，环境值 近期推荐Swift 6.1 发布Swift 6.1 正式发布！Holly Borla 在本文中介绍了多个令人期待的新特性。本次更新在语言层面带来了更广泛的 SwiftPM 引入 Package Traits，支持根据运行环境（如 Embedded 或 WebAssembly）配置不同的 API 和依赖，进一步增强跨平台能力。同时，SourceKit-LSP 现已默认开启后台索引，显著提升开发期间的响应速度与智能感知表现。 在测试方面，Swift Testing 推出了 Test Scoping Traits，使测试前后的上下文共享更加灵活易控；Swift-DocC 也改进了重载函数链接的歧义处理机制，提升文档的可维护性与可读性。
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，可通过扩展 在 SwiftUI 中应用 Inspector 组件 (Presenting an Inspector with SwiftUI)
将地图视图保存成图片 (Creating an Image from an MKMapView)虽然 SwiftUI 提供了 支持 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 个参赛名额，并为参赛者提供免费食宿与出行补助。
Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
