Fatbobman's Swift Weekly #056
Reflections on the Pixelmator Acquisition
Weekly Comment
Reflections on the Pixelmator Acquisition
Recently, Pixelmator officially announced its upcoming integration with Apple, pending final regulatory approval. They assured that their flagship products—Pixelmator Pro, Pixelmator for iOS, and Photomator—will remain largely unchanged in the near term.
As a boutique development team deeply rooted in the Apple ecosystem, Pixelmator has distinguished itself with its high value proposition and user-friendly business model. In today's subscription-dominated market, they have maintained a one-time purchase pricing strategy while continuing to provide update support, demonstrating rare product integrity. Although their feature set may not rival Adobe's product suite, Pixelmator pioneered AI-assisted processing capabilities years ago. If these technologies were to merge with iOS's native Photos app, it would significantly enhance system-level image processing capabilities. We can anticipate that at the upcoming WWDC 25, the Photos app will likely receive another major update, which would be a welcome improvement for the currently criticized iOS 18 Photos app user experience.
For average users, this acquisition is undoubtedly good news—they'll enjoy better system services without additional costs. However, for third-party developers dependent on the Apple ecosystem, such acquisitions might raise concerns.
The annual WWDC is not just a showcase of new technologies; it's also a moment when many small and medium-sized developers anxiously review their business viability. The expansion of system functionality often means market compression for certain third-party applications. Take Apple's weather app after the Dark Sky acquisition as an example: while some users feel it hasn't fully matched Dark Sky's professional standards, its information volume, timeliness, and interface performance adequately meet most users' needs, effectively eliminating the market space for weather applications.
Looking at Apple's creative tools history, from FinalCut to Logic Pro, many heavyweight software products came through acquisitions and maintained strong product quality. Pixelmator is likely to become the newest member of this product matrix. In recent years, Apple has gradually abandoned professional-oriented products like Shake and Aperture, focusing instead on serving the mass market. Considering the flourishing era of social media and short-form video, this strategic adjustment proves wise.
However, this strategic shift reveals a thought-provoking phenomenon: Apple appears to be deliberately avoiding direct competition with professional domain giants while squeezing the market share of small and medium-sized developers. Whether intentional or not, this could impact third-party developers' innovation motivation in the long run.
As a technology company centered on hardware sales, Apple's dedication to building a stronger ecosystem moat is understandable. However, we shouldn't overlook that numerous third-party developers are equally important builders of this moat. They are ecosystem allies who deserve more understanding and support, rather than being treated as sacrificial lambs for market expansion. Perhaps while strengthening its ecosystem, Apple needs to continuously examine its relationship with these innovators and find a more balanced path forward.
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!
Originals
Starting with Project Refactoring: Sharing Five Swift Modules
Five years ago, I began learning Swift with a simple wish: to develop an app that would help me manage my medical checkup data and assist with post-surgery health monitoring. It's been four years since the release of Health Notes 2.0. Recently, revisiting the project's code (95% of which was written four years ago), I find it hard to look at — honestly, I think it's poorly written. This September, I made up my mind to completely refactor the app. During this process, an idea occurred to me: why not extract some of the functional modules and give back to the community by open-sourcing them? In this article, I'll introduce several utilities I've open-sourced over the past two months.
Recent Selections
Apple is Killing Swift
Jacob Bartlett’s article sparked extensive discussions in the community. He argues that under Apple’s control, Swift has become increasingly complex and opaque, deviating from Chris Lattner’s original vision, with a growing focus on commercial motives. Despite the concerning situation, Bartlett believes that with appropriate adjustments, Swift still has the potential to return to a design philosophy centered around simplicity and usability, gradually evolving into a general-purpose programming language rather than being limited to Apple’s closed ecosystem.
Everything has two sides. With the support of resources from a large company, a new programming language can rapidly gain traction. However, this also risks overly centralized control and reduced community involvement. Examples of such cases in history are numerous. For Swift’s future, if Apple can adjust its approach, it will not only maintain the unique advantages of the Apple ecosystem but also help Swift expand into broader application fields, achieving more sustainable growth.
KWDC24 Technical Talk: Three Major Challenges and Solutions in iOS Performance Optimization
Recently, Dai Ming was invited to speak at KWDC24 (Korea Worldwide Developers Conference 2024) in Seoul, where he presented on the three major challenges of iOS performance optimization and their solutions. This article provides a systematic overview of his talk, covering areas such as memory diagnostics and optimization, app launch performance optimization, and package size reduction.
The author also shares his experiences and insights from attending the conference in Seoul. Known for his clear and engaging style, Dai Ming’s presentations and articles are always accompanied by hand-drawn technical illustrations, making complex concepts intuitive and accessible for readers.
Understanding Actors in Swift
The actor model, first introduced by Carl Hewitt in 1973, has profoundly influenced the development of concurrency in programming languages. Swift introduced the Actor type in version 5.5 as a core solution for concurrent programming, marking a significant step forward in concurrency safety.
In this article, Natascha Fadeeva provides a systematic introduction to the principles, usage, and considerations of Swift actors. As more developers begin adopting Swift 6 development patterns, the importance of actors has become increasingly prominent. They not only reduce the cognitive load of concurrent programming but also offer developers an elegant and safe way to manage concurrency, making it much easier to write robust concurrent code.
AnchoredRelativeFormatStyle: The Hidden Replacement for Date RelativeFormatStyle
RelativeFormatStyle provides developers with a straightforward way to create relative time text representations, but it has a significant limitation: it relies on Date() as an implicit base for the current time (making it non-pure). This adds complexity to testing and previews and can lead to unnecessary performance costs.
In this article, Alejandro Martinez introduces a lesser-known alternative—AnchoredRelativeFormatStyle. This API allows developers to explicitly specify two dates when formatting, with the target date as its anchor, effectively solving the issues caused by implicit reliance on the current date.
Making Illegal States Unrepresentable
In state modeling, the ideal approach is to retain only valid states required by the system, eliminating all illegal states from the model. This concept, widely used in functional programming, centers on the idea of “making illegal states unrepresentable.”
In this article, Alex Ozun demonstrates, with examples, how to use Swift’s type system as a primary tool to represent valid states and prevent the code from reaching unexpected state branches.
This article is the latest in Alex Ozun’s Type-Driven Design with Swift series. Through this series, the author aims to shift readers’ mindset toward type-driven design and bring more attention to this principle within the Swift community.
Problematic Swift Concurrency Patterns
Many developers encounter various complex issues when working with Swift’s strict concurrency model. Some errors can be resolved by following Xcode’s prompts, yet often without a full understanding of the underlying causes.
In this article, Matt Massicotte identifies several common issues in Swift concurrency, such as “split isolation” across domains, unnecessary use of Task.detached, over-reliance on explicit priorities, misuse of MainActor.run, stateless actors, and improper use of Non-Sendable types. Massicotte emphasizes that developers should exercise judgment based on specific scenarios rather than blindly following “best practices” when dealing with complex concurrent code.
Open-Source Libraries
HandySwiftUI
Cihat Gündüz accumulated a wealth of practical APIs while developing multiple Swift applications, such as TranslateKit, FreemiumKit, and CrossCraft. He combined these tools and utilities into a standalone open-source library, HandySwiftUI. As the name suggests, HandySwiftUI aims to provide more convenience for SwiftUI developers and accelerate the development process. Recently, Gündüz also wrote two articles that delve into the core functionalities of HandySwiftUI, making it easier for developers to take full advantage of this tool.
ProtobufKit
Kyle Ye is the founder and main developer of the OpenSwiftUI project. Since SwiftUI internally uses Protobuf to handle binary data, he developed a lightweight Swift solution, ProtobufKit, to better parse this data and achieve compatibility with SwiftUI’s internal protocols. This code has now been separated into an independent library, designed to help more developers simplify Protobuf serialization in Swift projects.
肘子的话
Pixelmator 并购背后的思考
近日，Pixelmator 官方宣布即将加入苹果，目前正在等待监管部门的最终审批。他们承诺，旗下主打产品——Pixelmator Pro、iOS 版 Pixelmator 以及 Photomator 在短期内将不会发生重大变化。
作为深耕苹果生态的精品开发团队，Pixelmator 以其高性价比和用户友好的商业模式在市场上独树一帜。在订阅制盛行的今天，他们仍坚持买断制的定价策略，并持续为用户提供更新支持，展现了难得的产品情怀。虽然在功能深度上无法与 Adobe 系列产品比肩，但 Pixelmator 早在数年前就率先引入了 AI 辅助处理功能。如果这些技术能够与 iOS 原生照片应用融合，将极大提升系统级图像处理能力。可以预见，在即将到来的 WWDC 25 上，照片应用很可能再次迎来重大更新，这对当前备受诟病的 iOS 18 照片应用交互体验来说无疑是一针强心剂。
对普通用户而言，这次并购无疑是个好消息——能够在不增加支出的情况下享受更优质的系统服务。然而，对依托苹果生态发展的第三方开发者来说，这种并购案例却可能引发担忧。
每年的 WWDC 不仅是开发者了解新技术的盛会，也是很多中小开发者战战兢兢检视自身业务存续的时刻。系统功能的扩张往往意味着某些第三方应用的市场空间被挤压。以苹果收购 Dark Sky 后推出的新版天气应用为例，尽管部分用户认为其未能完全达到 Dark Sky 的专业水准，但其信息量、及时性和界面表现已足以满足大多数用户需求，这实际上扼杀了天气类应用的市场空间。
纵观苹果的创意工具发展史，从 FinalCut 到 Logic Pro，许多重量级软件都是通过并购而来，且保持着不俗的产品力。Pixelmator 很可能成为这个产品矩阵中的新成员。近年来，苹果逐渐放弃了针对专业用户的 Shake、Aperture 等产品，转而专注于服务大众市场。考虑到自媒体与短视频时代的蓬勃发展，这一战略调整堪称明智之举。
然而，这种战略转向也带来了一个值得深思的现象：苹果似乎在刻意规避与专业领域巨头的正面竞争，转而挤占中小开发者的市场份额。无论这是否出于战略考量，长远来看都可能影响第三方开发者的创新积极性。
作为一家以硬件销售为核心的科技公司，苹果致力于构筑更强大的生态护城河无可厚非。但不应忽视的是，众多第三方开发者同样是这道护城河的重要建设者。他们是生态系统的盟友，理应得到更多的理解与支持，而非被当作市场扩张的牺牲品。或许苹果在增强生态体系的同时，也需要不断审视与这些创新者的关系，找到一个更平衡的发展之道。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
原创
从项目重构说起：五个 Swift 模块分享
五年前，我开始学习 Swift 时怀着一个简单的愿望：开发一款 App 来管理自己的体检数据，协助术后的健康监护。【健康笔记】从 2.0 版本发布至今已有四年。近期重读这个项目的代码（其中 95% 是四年前写就），总觉得难以面对 —— 坦白说，我认为写得很差。今年九月，我下定决心对这个 App 进行彻底重构。在这个过程中，我萌生了一个想法：何不将其中一些功能模块提炼出来，以开源的方式回馈社区？本文将介绍这两个月来我开源的几个工具库。
近期推荐
苹果正在扼杀 Swift (Apple is Killing Swift)
Jacob Bartlett 的这篇文章在社区引发了广泛讨论。他指出，Swift 在 Apple 的控制下逐渐变得复杂且不透明，已偏离 Chris Lattner 的初衷，越来越多地受到商业动机的影响。尽管现状令人担忧，但 Bartlett 认为，Swift 仍有机会通过适当调整回归简洁和易用的设计理念，从而逐步成为通用编程语言，而不仅仅是局限于 Apple 的封闭生态系统。
万物皆有两面。在大公司的资源支持下，一门新兴语言可以迅速崛起，但这同时也可能带来控制权的过度集中，社区的参与感随之减弱。历史上，这样的例子不胜枚举。对于 Swift 的未来，苹果若能调整心态，不仅不会削弱 Apple 生态的独特优势，反而能推动 Swift 向更广泛的应用领域拓展，实现更长远的发展。
KWDC24 技术分享 —— iOS 性能优化的三大难点及其解决方案
近期，戴铭应邀参加了在首尔举办的 KWDC24（Korea Worldwide Developers Conference 2024），并就 iOS 性能优化的三大难点及其解决方案进行了深入的技术分享。本文是对分享内容的系统整理，主要涵盖以下几个方面：内存问题的诊断与优化、App 启动性能优化以及包体积优化。
作者还记录了在首尔参会期间的见闻与感受。作为技术布道者，戴铭的演讲和文章最显著的特点是图文并茂 —— 他总会为读者准备大量亲手绘制的技术插图，让复杂的概念变得直观易懂。
了解 Swift 中的 actor (Understanding actors in Swift)
Actor 模型由 Carl Hewitt 于 1973 年首次提出，这一突破性的并发计算模型此后深刻影响了诸多编程语言的发展。Swift 语言在 5.5 版本中引入了 Actor 类型作为其并发编程的核心解决方案，标志着 Swift 在并发安全领域迈出了重要的一步。
在本文中，Natascha Fadeeva 系统地介绍了 Swift Actor 的原理、使用方法和注意事项。随着越来越多的开发者开始采用 Swift 6 的开发模式，Actor 的重要性日益凸显 —— 它不仅能显著降低并发编程的心智负担，更为开发者提供了一种优雅且安全的方式来处理并发问题，使得编写健壮的并发代码变得非常简单。
AnchoredRelativeFormatStyle：Date RelativeFormatStyle 的隐藏替代方案 (AnchoredRelativeFormatStyle: The Hidden Replacement for Date RelativeFormatStyle)
RelativeFormatStyle 为开发者提供了一种简洁的方式来生成相对时间的文本表示，但它存在一个显著的局限：依赖 Date() 作为当前时间的隐式基准（ 不是纯函数 ）。这不仅增加了测试和预览的复杂性，还可能导致不必要的性能开销。
在本文中，Alejandro Martinez 介绍了一个鲜为人知的替代方案—— AnchoredRelativeFormatStyle。这个 API 允许开发者在格式化时显式指定两个日期，并以目标日期作为其锚点，从而有效解决了对当前日期的隐式依赖带来的问题。
让非法状态无法表示 (Making Illegal States Unrepresentable)
在状态建模中，理想状态是仅保留系统所需的有效状态，将所有非法状态从模型中剔除。这一方法广泛应用于函数式编程，其核心理念是“让非法状态无法在代码中表示”。
在本文中，Alex Ozun 通过示例代码演示了如何使用 Swift 的类型系统作为首选工具来表示合法状态，从而避免代码进入意外状态的分支。
本文是 Alex Ozun Type-Driven Design with Swift 系列的最新一篇。作者希望通过这个系列，改变读者的 Swift 编程思维方式，引导 Swift 社区更多地关注类型驱动设计的原则。
Swift 并发中的常见问题模式 (Problematic Swift Concurrency Patterns)
在 Swift 严格并发模式中，许多开发者可能会遇到各种复杂问题，有些错误尽管可以根据 Xcode 提示解决，却往往难以彻底理解原因。
在本文中，Matt Massicotte 梳理了 Swift 并发中的一些常见问题，例如隔离域的混用（“Split Isolation”）、不必要的 Task.detached、过度依赖显式优先级、误用 MainActor.run、无状态 actor、以及 Non-Sendable 类型的误用等。Massicotte 强调，在处理复杂的并发代码时，开发者应根据实际场景作出判断，而非盲目依赖“最佳实践”。
开源库推荐
HandySwiftUI
Cihat Gündüz 在开发多个 Swift 应用（例如 TranslateKit、FreemiumKit 和 CrossCraft）的过程中，逐渐积累了丰富的实用 API，并将这些工具和便捷 API 整合成一个独立的开源库：HandySwiftUI。正如库名所示，作者希望该库能够为 SwiftUI 开发者提供更多便利，加速开发流程。此外，作者最近还撰写了两篇文章深入介绍 HandySwiftUI 中的核心功能，便于开发者更好地利用这个工具。
ProtobufKit
Kyle Ye 是 OpenSwiftUI 项目的发起人和主要开发者。由于 SwiftUI 内部使用 Protobuf 处理二进制数据，他开发了一个轻量级的 Swift 方案：ProtobufKit，以实现与 SwiftUI 内部协议的兼容，从而更好地解析这些数据。如今，这部分代码已被独立成库，旨在帮助更多开发者简化 Swift 项目中的 Protobuf 序列化操作。