Weekly Comment
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.
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](https://swiftology.io/collections/type-driven-design/?issue=056&utm_source=fatbobman weekly issue 56&utm_medium=email&utm_campaign=fatbobman weekly) 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.