Weekly Comment
DeepSeek: Achieving More with Less
DeepSeek’s new model is undoubtedly one of the brightest stars in the tech world recently. With incredibly low training costs, they have developed an AI system that rivals the performance of leading large models. Based on personal experience, DeepSeek’s V3 and R1 are more than sufficient to meet the needs of most scenarios. Surprisingly, the training cost is merely a few million dollars—a figure that has sparked widespread industry attention and skepticism. Some practitioners even regard this claim as “cognitive warfare”, finding it hard to believe. However, its API pricing, which is just a fraction of mainstream models, strongly validates its training efficiency. What’s even more admirable is that DeepSeek has open-sourced its training methods and inference mechanisms. This move is likely to catalyze the emergence of more low-cost, high-quality AI models, providing users with affordable and excellent AI services.
However, whether DeepSeek’s success will prompt industry giants to adjust their model development strategies remains a profound question. Since OpenAI demonstrated the potential of large language models (LLMs) through a “more is more” approach, the AI industry has almost universally adopted the creed of “resources above all.” Capital, computational power, and top-tier talent have become the ultimate keys to success. Today, the AI industry has evolved into a capital-driven frenzy. Regardless of a product’s profitability, simply announcing the purchase of large quantities of GPUs can significantly boost a company’s stock price. In an environment focused on “faster and bigger,” most practitioners have been swept away by this trend.
In such a landscape, innovation is often diluted by vast resources. When industry leaders focus primarily on how to spend money, breakthroughs like those achieved by DeepSeek, leveraging limited resources, become exceptionally valuable. Perhaps it is precisely the scarcity of resources that has driven them to explore alternative paths and achieve remarkable results. As the Chinese proverb goes, “It’s easy to go from frugality to extravagance, but hard to return from extravagance to frugality”. For major AI companies accustomed to high investments and large-scale resource allocation, it will undoubtedly be challenging to shift their mindset in the short term. Even if DeepSeek’s methods provide some inspiration, without fundamental changes in philosophy, these companies will struggle to achieve sustained and significant progress in reducing training costs.
I sincerely hope that as DeepSeek gains more resources in the future, it can continue to maintain its efficiency in utilizing limited resources and avoid being burdened by increasing abundance. DeepSeek’s success is not only a triumph of technology but also a victory for the spirit of open-source—a success unshackled by capital and one that truly deserves recognition and celebration.
Previous Issue|Newsletter Archive
If you appreciate my work and want to promote your product to the Swift and iOS developer community, sponsoring my platform could be an excellent opportunity for you.
Your support through Patreon, or Buy Me a Coffee helps keep this newsletter and blog running. Thank you for finding this content helpful!
Recent Selections
How to Check if a Modifier Key Is Pressed When Clicking on a Menu Bar Item in macOS Apps
Experienced macOS users might have noticed that holding down certain modifier keys (e.g., Option) while opening an app menu triggers different menu options. In this article, Pol Piella Abadia explains how to detect such behaviors in both AppKit and SwiftUI, demonstrating how to show or hide different menu contents based on user input. While this is a subtle feature, it adds a professional touch to your app's user interactions.
Using 2 Editors Because Xcode Is Dumb
Before Xcode 16, developers could easily drag and drop a local version of a library into a project and modify the library's code while working on the project. However, this convenient workflow was deprecated in Xcode 16, replaced by manually configuring local dependencies (e.g., ../../PACKAGE_NAME/
). This change introduced several issues, such as failing to sync file changes, inability to run local library tests, and restrictions on opening the library and project in two Xcode windows simultaneously. Christian Tietze critiques this adjustment and suggests using an alternative editor alongside command-line tools to improve efficiency and flexibility.
Creating a Reusable Action Menu Component in SwiftUI
Many SwiftUI developers integrate components like Sheet
, confirmationDialog
, or contextMenu
directly into their main view code. While this is convenient, it often results in code that's hard to maintain or reuse. In this article, Peter Friese shares techniques for building a reusable action menu component by extracting view code, creating custom modifiers, and using LabelStyle
and PrimitiveButtonStyle
to customize both style and behavior. This approach not only simplifies code but also significantly improves reusability and UI consistency, enhancing development efficiency and the user experience in SwiftUI projects.
Reducing Motion of Animations
Apple's Human Interface Guidelines remind developers that excessive or unnecessary animations can distract users or cause discomfort. In this article, Keith Harrison discusses how to respect the "Reduce Motion" accessibility setting and provides practical code examples. Harrison emphasizes principles such as avoiding gratuitous animations, ensuring animations are not the sole means of conveying information, and being cautious with large or high-frequency motions. He also demonstrates how to use .accessibilityReduceMotion
in SwiftUI to detect user preferences and disable or adjust animations accordingly, creating a more user-friendly experience.
Observing Properties on an @Observable Class Outside of SwiftUI Views
While the Observation framework primarily supports SwiftUI, developers can also observe property changes in @Observable
classes outside of views by using withObservationTracking
. Donny Wals explores techniques and considerations, such as achieving didSet
semantics, optimizing code reuse, and addressing @Sendable
limitations in Swift 6. Wals highlights the challenges of using Observation outside SwiftUI and suggests that for reliable property observation, especially in Swift 6 language mode, the more mature Combine
framework remains a better choice.
Announcing Tuist Registry
While Swift Package Manager (SwiftPM) manages dependencies directly from source repositories without a centralized registry, this decentralized approach introduces challenges:
Storage and efficiency: Cloning a package downloads the entire Git history, wasting disk space.
Non-deterministic builds: Version tags in Git repositories can be reassigned, leading to inconsistent builds.
Availability risks: Moving or deleting a Git repository breaks dependent builds.
Speed bottlenecks: Projects with extensive history take longer to clone.
To address these issues, Tuist recently announced Tuist Registry, a service based on the Swift Package Registry proposal SE-0292. It allows developers to download only the required source archives, bypassing Git history, thus improving efficiency and saving time and disk space. This enhancement makes local development and CI/CD pipelines more efficient and reliable.
In this article, Marek Fořt provides a detailed overview of Tuist Registry’s benefits and guides developers on how to use this powerful tool.
肘子的话
DeepSeek:花小钱办大事
DeepSeek 推出的新模型无疑是近期科技界最耀眼的明星。他们以极低的训练成本,打造出了性能不逊于当前主流大模型的 AI 系统。从个人使用体验来看,DeepSeek 的 V3 和 R1 在相当多的场景下足以满足我的需求。令人惊讶的是,其训练成本仅为数百万美元,这一数字引发了业内的广泛关注和质疑。一些从业者甚至将此视为“认知作战”,难以置信。然而,其 API 定价仅为主流模型的几十分之一,这无疑是对其训练高效性的最佳佐证。更令人钦佩的是,DeepSeek 选择开源其模型的训练方法与推理机制,这一举措有望推动更多低成本、高质量的 AI 模型涌现,为用户带来优质且价格亲民的 AI 服务。
然而,DeepSeek 的成功能否促使行业巨头调整模型发展路线,却是一个值得深思的问题。自 OpenAI 用“大力出奇迹”的方式证明 LLM 的潜力以来,AI 行业几乎全盘接受了“资源至上”的信条:资金、算力与顶尖人才成为制胜法宝。如今,AI 产业已演变为一场资本的狂欢盛宴。无论产品是否盈利,只要宣布购买了大量显卡,公司的股价就能水涨船高。在“求快、求大”的行业风潮下,大多数从业者已深陷其中,难以自拔。
在这样的环境中,创新往往被巨额资源所稀释。当行业领导者将注意力集中在如何花钱时,像 DeepSeek 这样以有限资源实现突破的做法显得尤为珍贵。或许正是因为资源的稀缺,他们才得以另辟蹊径,寻找全新的技术路径。中国有句古语:“从俭入奢易,从奢入俭难”。那些习惯于高投入、大规模资源配置的头部 AI 企业,在短期内转变思维模式无疑是困难的。即使 DeepSeek 的方法能够提供一些启发,但如果没有彻底的理念变革,这些企业在降低训练成本上将难以取得持续的显著进展。
我也衷心希望 DeepSeek 在未来获得更多资源后,能够保持对有限资源的高效利用,不被丰沛的资源所累。DeepSeek 的成功不仅是技术的胜利,更是开源精神的胜利,是一次未被资本裹挟的成功,也是真正值得期待的成功。
如果您发现这份周报或我的博客对您有所帮助,可以考虑通过 爱发电,Buy Me a Coffee 支持我的创作。
近期推荐
如何在 macOS 应用中检测点击菜单栏图标时是否按下了修饰键 (How to Check if a Modifier Key Is Pressed When Clicking on a Menu Bar Item in macOS Apps)
有一定经验的 macOS 用户或许已注意到,在打开应用菜单的同时按下某些修饰键(例如 Option),会触发与平时不同的菜单选项。本文作者 Pol Piella Abadia 详细介绍了如何在 AppKit 和 SwiftUI 中检测这一行为,并通过简单的实现来展示或隐藏不同的菜单内容。尽管这是个细节功能,却能为你的应用增添更专业的交互体验。
用两个编辑器开发,因为 Xcode 太蠢了 (Using 2 Editors Because Xcode Is Dumb)
在 Xcode 16 之前,开发者可以方便地将某个库的本地版本拖入项目中,并在开发项目的同时直接修改库代码。然而,这一便捷操作在 Xcode 16 中被废弃,取而代之的是需要手动配置的本地依赖路径(如 ../../PACKAGE_NAME/
)。这一变更导致了诸多不便,例如文件变更后无法自动同步、无法运行本地库的测试,以及无法同时在两个 Xcode 窗口中打开库和项目。Christian Tietze 对此调整表示不满,并建议开发者使用另一款非 Xcode 编辑器搭配命令行工具进行开发,以提高效率和灵活性。
在 SwiftUI 中创建一个可重用的操作菜单组件 (Creating a Reusable Action Menu Component in SwiftUI)
许多 SwiftUI 开发者习惯将 Sheet
、confirmationDialog
或 contextMenu
的实现直接嵌入主视图代码中,这虽然方便,但会导致代码难以维护和复用。Peter Friese 在本文中分享了通过提取视图代码、创建自定义 Modifier、使用 LabelStyle
和 PrimitiveButtonStyle
定制样式与行为的方式,来构建一个可重用的操作菜单组件。这种方法不仅简化了代码,还显著提高了组件的复用性和 UI 设计的一致性,为 SwiftUI 项目带来了更高的开发效率和更优的用户体验。
减少动画的动态效果 (Reducing Motion of Animations)
Apple 的 Human Interface Guidelines 提醒开发者,动画的滥用可能会导致用户分心或身体不适。在本文中,Keith Harrison 探讨了如何适配辅助功能中“减少动态效果”的设置,并提供了实用的代码示例。Harrison 强调了以下原则:不要仅为了添加动画而添加动画;动画不应是传递关键信息的唯一方式;要特别留意大幅度或高频率的动画效果。他还展示了如何在 SwiftUI 中利用 .accessibilityReduceMotion
检测设置状态,并根据用户需求禁用或调整动画,从而实现更友好的用户体验。
在 SwiftUI 视图外观察 @Observable 类的属性 (Observing Properties on an @Observable Class Outside of SwiftUI Views)
虽然 Observation 框架主要为 SwiftUI 提供支持,但开发者也可以通过 withObservationTracking
在视图之外观察 @Observable
实例的属性变化。Donny Wals 在文中详细讨论了相关技术要点,包括如何实现 didSet
效果、优化代码复用,以及在 Swift 6 中处理 @Sendable
限制等问题。Wals 指出,Observation
在 SwiftUI 之外的使用存在诸多局限性,尤其是在 Swift 6 的语言模式下,建议优先采用更成熟的 Combine
框架进行可靠的属性观察。
Tuist Registry 上线 (Announcing Tuist Registry)
Swift Package Manager(SwiftPM)尽管无需依赖中心化的包注册服务,而是直接从源代码库管理依赖,但这种去中心化的机制也带来了一些副作用:
存储和效率问题:克隆一个包时会下载完整的 Git 历史,导致磁盘空间浪费。
非确定性构建:Git 仓库的版本标签可能被重新分配,造成构建结果不一致。
可用性风险:如果依赖的 Git 仓库被移动或删除,后续构建将失败。
速度瓶颈:对于历史记录较大的项目,克隆仓库的速度会明显变慢。
为了解决这些问题,几天前 Tuist 宣布了全新的服务 —— Tuist Registry。该服务基于 Swift Package Registry 提案 SE-0292 实现,允许开发者直接下载所需版本的源码归档文件,而无需下载整个 Git 历史。这一改进显著提升了依赖解析的效率,节省时间和磁盘空间,使得本地开发和持续集成(CI)更高效、更可靠。
在这篇文章中,Marek Fořt 详细介绍了 Tuist Registry 的优势及其使用方法。