SwiftUI 4 Is Production-Ready. For Some of You.

WWDC ended a week ago and the SwiftUI conversation in every iOS engineering Slack I'm in has shifted. The right question is no longer "is it ready." The right question is which surfaces in your app are appropriate for SwiftUI 4 and which UIKit code is going to outlive the decade. For greenfield surfaces, SwiftUI 4 is the default. For existing UIKit codebases above a hundred thousand lines, the right move is mixed-mode adoption, not rewrite. Anyone telling you to "go all-in on SwiftUI" right now hasn't shipped a large iOS app.

For the first time since SwiftUI shipped in 2019, the headline features feel load-bearing. NavigationStack and NavigationSplitView, announced at WWDC and landing in the iOS 16 betas, replace the broken-by-default navigation. The new Layout protocol replaces GeometryReader hacks. Swift Charts is a real native charting framework. UIHostingConfiguration makes UICollectionView and UITableView cells cleanly host SwiftUI views.

What WWDC 2022 actually changed

I am not going to recap Apple's "What's new in SwiftUI" session at length. The session is good. The compact summary is that SwiftUI 4 is the first version where the framework has the primitives you need to build a full app rather than a feature surface. NavigationStack is the headline. The Layout protocol is the underrated one. Swift Charts is a separate framework but it ships alongside SwiftUI and answers the "what about graphs" question that has dogged every SwiftUI adoption discussion since 2019.

Majid Jabrayilov wrote the bullish read the day after the keynote. His line is the one I keep seeing quoted: SwiftUI is now "a full-featured UI framework that we can use daily." That is the right framing for greenfield surfaces. It is the wrong framing for an existing 500k-LOC iOS app, but greenfield isn't the harder case. Mixed-mode is.

The deeper change in WWDC 2022 isn't any specific API. It's that Apple stopped hedging. The 2020 and 2021 SwiftUI updates felt like the framework was still finding itself. WWDC 2022 felt like the framework knew what it was. That confidence is reflected in the APIs: NavigationStack is opinionated about how navigation should work. Layout is opinionated about how custom containers should compose. The 2019-2021 "here are some primitives, figure it out" energy is mostly gone.

The pre-WWDC baseline

Before you decide whether SwiftUI 4 is ready, it's worth remembering what the baseline was. Three weeks before WWDC, Michael Tsai aggregated a chorus of senior iOS engineers cataloguing SwiftUI complaints. Marco Arment's line in that piece is the one I keep coming back to: "For every hour SwiftUI's niceness has saved me, I've probably lost two more hours to the slow and buggy tooling."

That was the consensus three weeks ago. Tsai's post-WWDC followup yesterday shows the same engineers updating in real time. Some warmed up to SwiftUI 4 immediately. Some are still skeptical because Apple's own first-party SwiftUI surfaces (Settings, Shortcuts) ship with polish problems that suggest the framework still isn't quite there for high-fidelity native UI. Both reactions are correct. The framework moved. The bar moves with it.

Jesse Squires wrote the cleanest "is SwiftUI ready" assessment back in 2021. His recommendation was to use SwiftUI for "auxiliary non-critical UI" and stay in UIKit for the load-bearing parts of an app. SwiftUI 4 doesn't invalidate that take. It moves the boundary. More surfaces are now SwiftUI-appropriate than were a year ago. Many surfaces still aren't.

The "go all-in" argument and why it loses

Every June, someone publishes a take that this is finally the year to rewrite the app in SwiftUI. Every June, it is the wrong take for any team with a real existing codebase.

The arithmetic is unforgiving. A mature iOS app at a 100+ engineer org is somewhere between 500k and 2M lines of code, organized into hundreds of modules, supported across two or three OS versions, shipping multiple times a week. A SwiftUI rewrite is a multi-year effort that doesn't ship a user feature and competes for headcount with everything else on the roadmap. Even if you decide to do it, you can't pause feature work. So you're maintaining UIKit and writing SwiftUI in parallel, and the engineers who knew the UIKit code well are now also responsible for the SwiftUI replacement. Your most senior engineers spend the year on a migration. Your velocity drops. Your team retention takes a hit because the senior engineers wanted to ship product.

The right play is mixed-mode. SwiftUI for new surfaces, UIKit for existing, with a deliberate bridge layer between them.

The mixed-mode pattern

Mixed-mode adoption is not "use SwiftUI when you feel like it." It is a specific architectural pattern with deliberate seams. The teams that get this right tend to share a few rules.

New surfaces are SwiftUI by default. Greenfield features, settings screens, onboarding flows, modal sheets, anything that doesn't have to integrate with the existing navigation stack. Greenfield is where SwiftUI 4 unambiguously wins.

Existing UIKit code stays UIKit. Specifically: the navigation stack, the main feed, anything performance-sensitive (collection views with thousands of cells, anything with complex gesture interaction), and anything with deep UIKit-specific behavior (accessibility customization, focus management, dynamic type at the edges). You can host SwiftUI cells inside UICollectionView with the new UIHostingConfiguration. You probably shouldn't rewrite the collection view itself.

The bridge layer is explicit. UIHostingController wrappers, UIViewRepresentable for the rare reverse direction, a clear convention for how SwiftUI views receive their dependencies (environment, view-models, navigation), a clear pattern for how SwiftUI surfaces escape into UIKit for things like haptic feedback, biometrics, or system sheets that SwiftUI doesn't expose cleanly.

The team agrees on the bridge first. Half-a-dozen engineers each inventing their own hosting pattern is the worst outcome. Decide on the pattern once, write it down, enforce it in review. This is platform work, not feature-team work.

The internal-framework question

If you have an internal declarative UI framework, like the SliceKit framework we use at Reddit, the WWDC 2022 update forces a question. Do you keep investing in the internal framework or do you redirect that effort toward SwiftUI?

I wrote a couple of months ago about why SliceKit exists in the first place: the testability story, the explicit composition model, the ability to run on older iOS versions where SwiftUI couldn't go. The first two reasons are still valid. SwiftUI 4 still doesn't have the testing story I want for a 100+ engineer team writing thousands of unit tests. The third reason matters less than it did. iOS 13 is now four versions back. The deployment-target floor is rising.

My read for any team running an internal declarative framework is the same as the mixed-mode read for SwiftUI vs. UIKit. The internal framework continues to own the surfaces it's already on, because the migration cost of replacing it is high and the marginal benefit is small. New surfaces, especially settings and onboarding flows, are reasonable candidates for SwiftUI. The internal framework's investment moves toward composition and testing primitives, not toward replicating SwiftUI features that SwiftUI now does well. Some of what the internal framework was for is becoming redundant. That's a win, even if it feels like a loss to the team that built the framework.

I should stress-test my own bias here. What would have to be true for the right answer to be "wind the internal framework down on a two-year horizon" instead? Three things. The testing story would have to close, with SwiftUI exposing the kind of view-model and snapshot testing primitives that internal frameworks were built to provide. The deployment-target floor would have to rise to a version where the framework's compatibility advantages disappear. And the team that built and maintained the framework would have to want to move on to something else. None of those three is true today. Two of them could be true by 2024. If you build internal frameworks, plan for that horizon, not for permanence.

What I'd put on a Q3 plan

If I were running a 100-engineer iOS team this week:

Greenlight SwiftUI for greenfield surfaces. Stop treating it as experimental. The framework can carry production weight on the right surfaces.

Document the mixed-mode pattern. Bridge layer, dependency injection convention, where each technology lives. One page in the engineering wiki, owned by the platform team.

Pick a flagship greenfield surface for the next quarter. Something visible, something the team will learn from. Settings or onboarding is usually the right starting place because the requirements are simple and the surface area is bounded.

Don't sign up for a rewrite. When the rewrite proposal comes (and it will), the answer is "not this year." Maybe not ever. The right migration is incremental, surface by surface, on the schedule of the work that's happening anyway.

Pay attention to the build-time and modularization infrastructure. SwiftUI 4 makes new surfaces faster to build but doesn't fix your monolithic build graph. The platform investments are the same investments either way.

Where I land

WWDC 2022 is a real inflection for SwiftUI. The framework is finally usable for full apps, not just feature surfaces. The mistake to avoid is reading "production-ready" as "ready to replace UIKit." Those are different claims. Greenfield is ready. Mixed-mode is the right architectural answer for everyone with a substantial existing app, which is most of us.

The teams that adopt SwiftUI 4 deliberately, with named patterns and bridge layers, are going to ship faster on new surfaces and avoid the rewrite trap. The teams that treat "should we adopt SwiftUI" as a single yes-or-no decision are going to make it badly either way.

It's not "should we adopt." It's "for which surfaces." Answer that question and the rest gets easier.