Counting from its debut in 2019, SwiftUI is approaching its seventh year. It has long shed its initial growing pains and gradually become one of the foundational skills for developers in the Apple ecosystem. However, SwiftUI’s closed-source nature also means that many of its underlying mechanisms remain opaque. While developers can certainly feel its expressive advantages when using it, it’s often difficult to trace the root cause once a problem occurs. This characteristic also puts SwiftUI at a bit of a disadvantage in the era of AI-assisted programming—compared to technologies that have long been exposed in community discussions, source codes, and documentation, the high-quality materials available for large models to reference are ultimately limited.
Because of this, the community has always hoped to replicate SwiftUI through open-source projects: on the one hand, to give this excellent design a chance to run on more platforms; on the other hand, to gain a better understanding of SwiftUI’s internal mechanisms through the replication process. In recent years, the most highly-watched project in this regard is undoubtedly OpenSwiftUI. Driven continuously by the community, it has already filled in some of the core implementations of SwiftUI and made experimental explorations on platforms outside the Apple ecosystem. Although it obviously still has a long way to go to reach its goal, it remains one of the most important gateways for developers today to understand SwiftUI’s internal mechanisms.
Actually, besides the community, some companies—even very large ones—have also conducted in-depth research and replication of SwiftUI over the past few years. Last week, ByteDance open-sourced their SwiftUI replication project, DanceUI.
I first heard about this project in 2022. What surprised me the most at the time wasn’t “someone is replicating SwiftUI,” but rather, “why is ByteDance doing this?” Later, after communicating with the developers involved in this project, I roughly understood their motives: on one hand, they wanted to gain stronger control when introducing declarative development into their massive product ecosystem; on the other hand, they hoped to grasp key capabilities like runtime, dependency graphs, and host integration in their own hands by studying excellent frameworks like SwiftUI. Compared to OpenSwiftUI, DanceUI looks less like a community-driven replica and more like a sample of reverse-engineering SwiftUI driven by practical engineering needs.
More importantly, over the past few years, DanceUI has already entered production environments in some product modules within ByteDance. This means it is clearly not just an experimental toy, but a set of development tools that have withstood a certain level of testing in terms of performance and stability. For SwiftUI developers, it therefore provides another gateway to understanding SwiftUI.
Of course, such projects shouldn’t be over-glorified. They are not SwiftUI itself, nor do they represent Apple’s official implementation. Projects like OpenSwiftUI, which are strongly research- and compatibility-oriented, naturally have clear boundaries; while projects like DanceUI carry an obvious background of large-tech internal engineering and practical application. Neither should be treated as the sole source of “SwiftUI truth.”
However, this does not prevent them from being excellent learning materials. None of them are SwiftUI, yet they can all help us get closer to it. Diving into SwiftUI by following open-source projects is essentially not about finding an “open-source alternative,” but rather using these projects to train our own way of understanding SwiftUI.
Recent Recommendations
Interface Segregation Principle In IOS: How To Prevent A Protocol From Becoming A Prison
Many developers have likely experienced a similar trajectory: a carefully designed small protocol in the early stages of a project gradually evolves into an unwieldy “monster” as team collaboration and business requirements grow. Pawel Kozielecki illustrates this through a progressively bloated UserService, showing how fat protocols introduce testing overhead, hidden coupling, and significant refactoring costs. Beyond proposing a practical approach based on smaller protocols and incremental migration, the article highlights a deeper issue: the real danger often lies not in a single flawed design decision, but in a series of seemingly reasonable “let’s just add this here for now” choices.
In the era of AI-assisted programming, this problem can be further amplified. Large models tend to infer semantics from file and protocol names, and vague or overly broad naming naturally attracts more loosely related responsibilities. Clear, precise, and restrained naming is no longer just a matter of style—it increasingly defines system boundaries.
Animating Strikethroughs in SwiftUI
How would you animate a strikethrough or underline in SwiftUI Text? A common first instinct is to use an overlay with Shape. However, this approach struggles with Dynamic Type and multi-line text. Ashli Rankin presents a more systematic solution: leveraging the TextRenderer API introduced in iOS 17 to access Text.Layout internals (lines, glyphs, etc.), and using a progress value accumulated across lines to draw a continuous, animatable strikethrough. By conforming to Animatable, SwiftUI can smoothly interpolate state changes.
An interesting detail: TextField does not use the same rendering pipeline as Text, so TextRenderer cannot be applied directly. The workaround involves overlaying a transparent Text (for rendering the animation) on top of a real TextField, combined with a custom Layout to enforce consistent wrapping width, ultimately resolving multi-line alignment issues.
Checking accessibility with SwiftUI Previews
SwiftUI Previews are typically used to verify UI layout, but they can also help validate certain aspects of accessibility during development. Rob Whitaker outlines several practical approaches: using Xcode Canvas to quickly toggle light/dark mode, orientation, and Dynamic Type, or defining specific environments via Preview Traits.
The article also highlights some private environment properties available only in Previews (such as increased contrast, reduced motion, or inverted colors), which can be enabled via underscored key paths. These must be restricted to #if DEBUG to avoid leaking private APIs into production builds.
A UIKit Project’s SwiftUI Migration: A Practical Retrospective
Yusuke Hosonuma reflects on his experience working on a UIKit + RxSwift + Coordinator project and gradually migrating most of its UI to SwiftUI over the course of a year. Rather than focusing on implementation details, the article centers on real-world engineering trade-offs: how a small team, with minimal communication and almost no documentation, can maintain long-term evolvability through continuous delivery, incremental replacement, and intentionally simple design.
The author also offers grounded reflections on common practices, such as being cautious with protocol abstraction, EnvironmentObject, premature generalization, and the urge to “clean up everything” during migration. This is less a technical guide and more a realistic retrospective on team practices and engineering judgment.
Cancelling SwiftUI Animations: What Actually Works (And Why)
Stopping an in-flight repeatForever animation in SwiftUI is not as straightforward as it seems. Using .none or disabling animations via Transaction only affects new animations, not those already running in the rendering system. Codelaby provides a working solution: defining a custom CustomAnimation that returns nil from animate (signaling immediate completion), and using shouldMerge to take over the current animation, effectively cancelling it.
SwiftUI performs interpolation based on state changes and animation functions. “Stopping” an animation is essentially replacing it with a new state transition that takes control, rather than interrupting the existing animation.
Tools
Swift Institute: Rebuilding the Swift Ecosystem as a Solo Effort
An astonishing project discovered by chance. Over the past nine months, Coen ten Thije Boonkkamp has made nearly 9,800 commits, single-handedly building a Swift ecosystem of almost 300 packages across three layers: primitives, standards, and foundations. The goal is to realize his proposed Modern Swift Library Architecture: dependencies flow downward, integration happens outside core types, and “test what you own, trust what you import.”
One person, one idea, explored and validated with AI. Whether it ultimately succeeds or not, this is exactly the kind of exploration that demonstrates the real value of AI.
swift-ast-lint: Writing Swift Lint Rules in Swift
Developed by Ryu, swift-ast-lint is not another SwiftLint, but a custom linting infrastructure built on SwiftSyntax. It is designed for teams that need AST-level rules, filling the gap where regex-based approaches fall short.
The project supports scaffolding, parameterized rules, path filtering, and --fix auto-correction. It is well-suited for enforcing architectural constraints, code organization, and module boundaries—areas where regex is unreliable. While not ideal for out-of-the-box use, it is a strong option for teams with established conventions who want to formalize them as tooling.
As AI-assisted development becomes more common, the real value may lie not only in generation, but in how we encode and enforce team constraints.
Event
Swift Craft 2026
Swift Craft is a community-driven iOS / Apple platform developer conference taking place May 18–20 in Folkestone, UK. The schedule is already available, covering topics across Swift, SwiftUI, and application architecture.
Compared to larger conferences, Swift Craft focuses more on small-scale, in-depth discussions and emphasizes a strong community atmosphere. One notable detail is the venue: Leas Cliff Hall, perched on a seaside cliff with floor-to-ceiling windows overlooking the English Channel—an environment that naturally enhances the overall experience.
The organizers are offering a discount code FBM26 (£50 off Indie tickets) for readers of this newsletter. If you’re considering attending a developer event in Europe, you can check the details via the Swift Craft tickets page.