SwiftUI is the future of iOS — and the future arrived quietly

Nobody sent a memo. There was no morning where SwiftUI stopped being the interesting-but-risky option and became the obvious one. It happened the way infrastructure shifts always happen: gradually, and then in retrospect.

If you are starting an iOS app today and reaching for UIKit out of caution, the caution is now the risk.

What actually changed

The early argument against SwiftUI was never about the idea. Declarative interfaces had already won on the web. The argument was about readiness — missing controls, unpredictable layout, a list that could not do the one thing your designer wanted.

Three things quietly fixed that:

• The gaps closed. The controls people used to drop to UIKit for are there now, and they behave.
• Apple's own apps moved. That is the signal that matters. Frameworks Apple ships against are frameworks Apple fixes.
• Interop stopped being painful. Wrapping a UIKit view is a few lines, so "SwiftUI cannot do X" became "SwiftUI hosts X" — a footnote, not a decision.

Why it makes better apps, not just faster ones

The productivity story gets all the attention — less code, live previews, no more hunting a constraint conflict at 11pm. True, and not the interesting part.

In UIKit, state and screen are two things you keep in sync. In SwiftUI, the screen is a function of the state. Whole categories of bug simply stop existing.

The bugs that vanish are the ones users actually report: the toggle that shows the wrong value after you background the app, the row that keeps a stale label after a refresh, the button still spinning after the request finished. Those are all synchronisation bugs. Remove the synchronisation and you remove the bugs.

You also get the things teams usually promise and postpone, largely for free:

• Dynamic Type that genuinely reflows instead of clipping.
• Dark mode as a consequence of using semantic colours, not a second design pass.
• VoiceOver that mostly works before anyone has audited it, because the structure is declared rather than assembled.

Accessibility stops being a line item you cut and becomes something you would have to work to break.

What it still cannot do

Anyone selling you SwiftUI without this section is selling you something:

• Very large collections with heavy per-cell work still reward UIKit's precise control over reuse.
• Deep text editing — a real rich-text editor — still means TextKit underneath.
• Bleeding-edge layout occasionally needs a UIKit escape hatch, and that is fine. Reaching for one is not a failure.
• Older OS support. If you must support several versions back, some of the nicest APIs are not available to you yet.

So what should you do

New app? SwiftUI, with UIKit available where you need it. You will ship sooner and support it more cheaply.

Existing UIKit app? Do not rewrite it. Nobody thanks you for a rewrite. Build the next screen in SwiftUI, host it in what you have, and let the codebase migrate one feature at a time.

The future arrived quietly. It is fine to arrive quietly too.