SwiftUI should become Open-Source

We have a running joke on the team. Whenever we’re fed up fighting a framework and can’t find workarounds, someone proposes sending one of us as an undercover intern to that framework’s team at Apple, to fix the bugs from within. Over the years this has targeted many things… iCloud, TextKit, UniversalTypeIdentifiers. Most recently, though, the jokes have mostly been about fixing SwiftUI.

Background

I won’t repeat all the things people are upset about with SwiftUI. But I want to highlight the timescale and two representative issues. SwiftUI shipped in 2019, seven years ago. At WWDC 2022, Apple put up this infamous claim during the State of the Union:

The best way to build an app is with Swift and SwiftUI

Here we are in 2026, right before another WWDC, four years and four major release cycles after that claim. How well does it hold today? In my opinion, we’re not even close. Modern SwiftUI can do a lot. But it’s still riddled with inexplicable bugs and weird limitations that prevent developers from building truly great experiences. Or at least, experiences that match system behavior. Two examples.

Example 1: On iOS, SwiftUI can’t autofocus a text field in an appearing sheet to bring up the keyboard in the same animation. Open Calendar to add an event, Mail to create a mailbox, or Pages to add a comment: The keyboard comes up in the same blink as the sheet. Awesome, you’re looking at a UIKit interface.

Now contrast that with creating a link in Notes or a new list in Reminders. You’re looking at SwiftUI interface. First the sheet, then the focus. Two animations, double the wait. Not horrible, but not delightful either.

The original iPhone SDK shipped this on day one. In your UIViewController you’d override viewWillAppear and call becomeFirstResponder on your text field to focus. Adding insult to injury, there’s a .defaultFocus API that’s been around and available on iOS for three years, but works only on macOS. You can hack your way around it with plain UIKit, but oh, do you have to jump through hoops!

Example 2: On macOS, drag & drop is essentially impossible to get right. Seven years in, we’re on the third major iteration of drag & drop in SwiftUI. First onDrag/onDrop, then draggable/dropDestination, and now dragContainer. Yet you still can’t have it all at once: reorder inside and drag out of the same view, plus drop validation when items may not be accepted, plus defining which drop operation (copy / move / link) a destination would cause. Let’s not dare to think of allowing Option to toggle between “move” and “copy”.

macOS has supported all of this for over 25 years. Drag & drop is the defining interaction of macOS. It’s the natural interaction for so many things on big screens. And yet there’s no hoop you could jump through to make it work in SwiftUI. Either you accept a laughable experience (like, every drag showing a (+) insertion indicator), or you revert to AppKit. No middle ground.

My hot take

These examples are not chosen accidentally. Keyboard focus and drag & drop aren’t minor details. They’re essential platform features, examples of things that make native apps better than websites. How can a UI technology be called “the best” when it fails to provide essentials that predate it by more than a decade? I have no inside knowledge of Apple. But from the outside, it sure looks like it just doesn’t care.

See, Apple is the (second) richest company in the world. If they wanted, they could fix anything. Yet they don’t. And I think it’s because they’re not invested. They are not invested because they don’t use SwiftUI themselves much. A few small apps and detail screens here and there, but none of the major ones. Think Finder, Mail, Pages, or Final Cut. SwiftUI looks great in demos and session videos, but it just doesn’t scale.

Maybe this is about to change in a few weeks. Maybe at WWDC26, Apple will announce “Snow SwiftUI”, a massive bug-fix release with zero new features. I haven’t given up hope. I’m still hoping. But it might as well not happen.

Meanwhile, I know people who are invested, who would likely be willing to help big time. To provide detailed feedback, to offer suggestions, to contribute code. Us developers! Those of us who believe in that slogan, want it to become a reality and would love to use SwiftUI end-to-end.

SwiftUI code is more expressive, more compact, and thus more understandable and manageable. It’s easy to forget the pains of auto layout, merging XIB files, implementing table view delegates, and manually redrawing views. Without SwiftUI, an app targeting both macOS and iOS needs its interface to be built twice, against the similar yet different AppKit and UIKit. SwiftUI’s declarative, data-driven, platform-independent design is how modern UIs should be built.

My suggestion

I believe Apple should tap into this invaluable resource of skilled developers with affection for its platforms and open-source SwiftUI. Sounds crazy. But is it? Swift has been open-source for years now, to great success. Let’s explore the thought, shall we?

If SwiftUI was open-source:

• Developers could self-diagnose issues and submit patches.
• Updates (and fixes!) could ship much more quickly than the operating systems.
• The framework could become more independent of OS releases, back-deploying new features where possible.
• Cross-platform efforts to bring SwiftUI to Linux, Android, or Windows — or wilder ones for websites and terminal apps — could gain major traction, massively expanding Swift’s reach.

But maybe most importantly, the framework would be less opaque, with real prospects for substantial improvements and contributions. This could help win back developer goodwill and trust lost over years of waiting for changes.

On the other hand, I don’t see many losses. Yes, right now, the code is a “secret” that would become open for others to copy and modify. But who would benefit most from that, if not Apple? SwiftUI is mostly a wrapper around other UI frameworks. A new, better way to program familiar interfaces. Yes, it’s the only API for fairly static interfaces like the watch, widgets, controls, and activities. But for apps, there’s nothing you can do in SwiftUI that you can’t with AppKit/UIKit — it’s the other way around. SwiftUI is so tightly coupled with Swift that it required the introduction of several new features to the language. An open-source SwiftUI could be Swift’s strongest showcase.

I’m probably missing something. However right now, I think it would be a smart move.