SwiftUI After 7 Years: A Story of Mediocrity: Will it ever stop feeling like a beta? — Yakov Manshin

Seven years after its blockbuster 2019 announcement, SwiftUI was supposed to be the mature, production-grade future of cross-platform UI development on all Apple platforms. Instead, SwiftUI feels like a perpetual beta, even in 2026. In this deep dive, I break down why the initial excitement has given way to deep professional frustration for senior engineers. I analyze the systemic issues with performance and layout predictability, the chaotic state of SwiftUI’s ever-changing data flow, and the frustrating lack of backward compatibility that forces developers into a nightmare of shims and workarounds.

Through real-world examples—including Apple’s own SwiftUI tutorial (which is broken) and a head-to-head performance comparison with UIKit (guess who wins)—I demonstrate how SwiftUI trades precise engineering for an illusion of convenience.

Beyond the code, this video explores a broader, more concerning shift in Cupertino: a transition away from the uncompromising craftsmanship of the original era of Cocoa, Aqua, and Auto Layout toward a modern corporate culture of “good enough” products. If you are tired of making excuses for broken features, fighting layout bugs, and doing Apple’s QA work for them, this perspective is for you.

Links

Landmarks (Apple’s broken SwiftUI tutorial)

Undocumented Self._printChanges() method (and other debugging tricks)

SwiftUI Only Makes It Easy to Develop Bad Apps

SwiftUI Group Still(?) Considered Harmful (another example of SwiftUI’s hidden gotchas)

Video Transcript

Intro

Okay, let’s get on with it.

This is going to be a longer piece about SwiftUI, what’s wrong with it, and why I don’t believe it’s getting better any time soon. The past seven years haven’t turned SwiftUI into a real, production-grade UI framework: It still suffers from long-standing issues with layout consistency and performance.

But you don’t have to take my word for it; you can see for yourself in Apple’s official, first-party SwiftUI tutorial. Just download the complete demo project at the link below and run it on your Mac.

I’ll get back to this particular case later in this video. But let’s start with a short retrospective.

SwiftUI was announced back in 2019—and to much fanfare. I was there and witnessed it myself. Apple promised to end the era of fighting Auto Layout and rebuilding the app every time you make the tiniest of change.

Instead, you were going to get declarative syntax, the single source of truth, built-in animation, instant previews, and cross-platform reusability of your code. To me, it sounded too good to be true.

As it turned out, it was.

By this point, the initial excitement hasn’t just faded. It’s given way to a growing sense of deep professional frustration.

And after seven years, the excuse that “SwiftUI is still a young framework,” well, it’s just dead. In this industry, seven years is like an eternity. It’s roughly the time between this and this, and it’s more than the time between the first iPhone and the iOS 7 redesign. By comparison, SwiftUI feels like it’s in a perpetual beta state. Every new feature comes with a fine-print footnote. Every layout fix breaks two more things you didn’t even touch. And honestly? I’m tired of making excuses for all this in my own projects.

Why SwiftUI Exists

But before we have a look at SwiftUI’s specific strengths and weaknesses—mostly weaknesses—let’s see why SwiftUI even exists.

It’s not so much that Apple wanted to give you great dev tools, but because it sort of had to. Apple had to respond to the pressure from the competition. By the mid-2010s, Facebook’s React became de facto standard on the web, and soon React Native and Google’s Flutter started their conquest of mobile platforms. Both frameworks are reactive and declarative.

From the perspective of any business, building native apps started to look less and less appealing. Instead, they could use the same codebase on iOS and Android while also borrowing components from their own websites.

I believe there was one more reason, and it is the Mac App Store. When was the last time you opened it? And when was the last time you installed a new native app on your Mac? Yeah, same thing here.

The iOS App Store was the key step in Apple’s transition to services business, thanks to its 30% fee on every transaction. But on the Mac, many apps only worked in the browser, or as web apps in Electron wrappers.

SwiftUI was supposed to solve both of these problems: keep developers within the native ecosystem to build new apps, and make it easier to port existing ones to the Mac.

Reactive data flows, declarative layout, and cross-platform support were the key selling points of SwiftUI. Did Apple deliver on them? Let’s have a closer look.

Data Flow

One of the biggest pain points that continues to bother senior engineers, myself included, is the data flow. On paper, the single source of...