Don't hold your breath for UIKit's deprecation

SwiftUI might be the future—but the past isn’t going anywhere just yet.

Ever since Apple introduced SwiftUI in 2019 much has been said about UIKit being dead. "Eventually it will die too" is a phrase I have said, eagerly waiting for the perfect day where all views will be easily readable and avoid boilerplate.

This kind of shift has happened before. In 2014 Apple introduced Swift, its current main programming language for developing apps for their platforms (and more). Swift has steadily replaced Objective-C, the then preferred language for all things Mac/iPhone/iPad.

Like Swift before it, SwiftUI brings such a fresh way of writing and thinking about your code that Apple platforms developers eagerly adopted it. Swift was positioned as a replacement from the start, and adoption took over Obj-C by 2018.

It's not a stretch then to expect the new UI framework to take over the old, right? It's right in the name: Swift... SwiftUI. A perfect marriage.

Enter WWDC 2025. Another year, a fresh new coat of paint for all platforms, surely Apple will have so much new stuff ready for their SwiftUI supporters.

Take out the new look and visionOS stuff and, for those who are all in on SwiftUI like me, all we've got is a native WebView, TextEditor now supporting rich text editing and (not even mentioned here) a new SF Symbol animation so icons can look like they're drawing themselves.

Then you go take a look at the videos covering the UX redesign and the new material (Liquid Glass). What's your expectation? Only the latest code gets that, right? Maybe as an incentive so people move on to SwiftUI? Incorrect.

Even AppKit, the Mac UI framework that harkens all the way back to the NeXTSTEP days, gets all the goodies. What gives?

A change of perspective is in order. If SwiftUI is not entirely replacing UIKit and AppKit like Swift did with Objective-C, what is the right mental model for thinking about Apple's new UI framework?

That's the question I posed on the company #wwdc channel after seeing all those things during this year's Dub Dub. Then colleague Chris Stroud came in with this banger:

[Quoting my question:] "it all depends on what you the dev wants to achieve"

Yep!

If you consider SwiftUI as (kind of) a declarative wrapper atop UIKit/AppKit, it becomes more challenging to imagine UIKit and AppKit fully going away. Think about the other frameworks involved, like Core Animation and Metal. Different problems require leveraging APIs at varying depths of the iceberg.

For example, over time, we got more UIKit-based animation APIs and needed to use Core Animation directly far less (UIViewPropertyAnimator comes to mind). Still, sometimes it is necessary to dig that deep to achieve a desired effect, and we are still capable of doing so. The frequency of that need lessens as higher-level frameworks become more effective.

I could not put it more eloquently than Chris did. If we think of Apple's UI technologies like an iceberg, you can get a lot done fast with SwiftUI, but not all. Need more? Dive deeper.

Same goes for the Mac. SwiftUI will get you mostly there with windows, buttons, scroll views and text fields. Need UndoManager for your TextEditor? UIKit. Precise mouse event handling? Call AppKit.

"Different problems require leveraging APIs at varying depths of the iceberg."

This change in the way I think of SwiftUI has greatly helped ease the implied question of "Is Apple letting us down by being slow with this migration?". UIKit is older, more verbose, and often messier. But there’s a depth to it—a richness that reflects the very nature of how it was designed: imperative, flexible, and hands-on.

SwiftUI, on the other hand, trades control for clarity. It’s declarative, elegant, and opinionated. That difference in nature explains a lot about what each framework is good at—and why neither is going away soon.

Imperative v. declarative

The usual overview goes: UIKit is an imperative framework while SwiftUI is a declarative one. It's easy to forget what that means, but basically in UIKit you tell the computer exactly what you want on screen and how to do it. You put a label inside a container, you set layout constraints on every view so they're positioned correctly. You're the boss and worker of the screen's canvas.

SwiftUI on the other hand holds much more power and opinion over what is presented and how it's done. Sure you can massage it with infinite .frame and .ignoresSafeArea modifiers, but in exchange for it being easier to get off the ground with much less code you need to understand what each view modifier does in what situation and in what order.

I bet that change from a world of putting the brushes in the dev's hands and letting them get wet with paint to a world of turning that dev into more of an informed instructor to the painter is a challenge to get right for Apple. Being too prescriptive of your UI requires deep consideration of said UI and, most important of all, its API, the way you expose these building blocks.

Calling SwiftUI a wrapper might give the impression that it's less than. But it's so fun! Abstractions let you focus on what you actually want to do an not on how to get there. My lesson learned here it that it's better to view the toolbox we have as that, a set of tools at our disposal, not an old engine we need to keep running.

In the end, SwiftUI isn’t here to destroy UIKit. It’s here to let us write better UIs faster—when it can. When it can’t? Well, that’s what the rest of the iceberg is for.