SwiftUI Series 01｜The applicable boundaries of SwiftUI

When I first came into contact with SwiftUI, the most frequently asked questions were:

• Can it replace UIKit?
• Should all new projects use SwiftUI?
• Is the old project worth relocating?

These issues are of course important, but if the discussion is focused on “replacement” from the beginning, the judgment will often be made to an extreme. A more practical question would be:

What kind of page complexity is SwiftUI best at handling, and what kind of problems does it not necessarily dominate?

Only if this question is answered clearly first, will the subsequent “should it be used” and “to what extent” be used have practical significance.

1. The real power of SwiftUI is that it puts “how state changes are mapped into interfaces” in the first place

The default idea of UIKit is more like:

• view first
• Go and update the view again
• Then handle the synchronization relationship between multiple UI components

SwiftUI’s default idea is closer to:

• Pre-existing status
• Then describe “what the interface should look like in this state”

This means that it is naturally more suitable for pages where “the main complexity of the interface comes from state expression”. For example:

• Empty / loading / loaded / error switch to the obvious page
• form page
• Settings page
• Display details page
• A page where multiple widgets are linked together driven by a set of business statuses

Of course, these pages can be written in UIKit, but many synchronization relationships often need to be maintained manually. The advantage of SwiftUI is precisely that it makes it easier to express such relationships as a whole.

2. It is particularly suitable for business pages where “status is more important than interaction details”

The real difficulty with many business pages is:

• What is the current status?
• What to display in different states
• Which areas need to be changed together after a certain business action?

For example:

• Personal center
• Settings page
• Article details page
• Search results page
• Order details page

Such pages rarely require extreme levels of scrolling coordination or gesture design, but they do involve a lot of:

• Status switching
• Conditional display
• Component combination
• Partial refresh

These things are where SwiftUI comes most handy.

3. It is also very suitable for pages with “fast iteration and frequent UI changes”

This is very important in real teams.

Some pages do not have frequent product changes:

• Copywriting revision
• Structural changes
• Change the order of cards
• Change the display condition of a certain module

In such scenarios, the advantage of SwiftUI is often not just “less code”, but also the lower mental burden of modifying the UI structure. It is easier to treat the page as a state-driven structure tree to modify, rather than patching back and forth between many partial views.

So if the reality for a team is that “pages change frequently”, SwiftUI is often very attractive.

4. But SwiftUI is not naturally suitable for all “complex pages”

This is also the point that needs to be made clear most.

A common situation is that when you hear “SwiftUI is more modern”, you will subconsciously equate it with “all pages are more suitable”. But in real projects, the complexity of complex pages comes from different sources.

If the core difficulty of a page is:

• Extremely fine scrolling control
• Lots of low-level gesture coordination
• Very customizable animation timing
• Extremely demanding control over rendering and interaction details

Then SwiftUI may not be naturally easier.

is:

• Some abilities need to be circumvented
• Sometimes you have to mix UIKit
• Some underlying behaviors are more expensive to debug

Therefore, “the page is complex” is not a criterion in itself, the key is where it is complex.

5. A more practical judgment: Is the core difficulty of the page “status expression” or “underlying control”?

This is my most common method of judgment.

If the core difficulty of the page is:

• How to map multiple business states to the interface
• How to combine components naturally as the state changes
• How to keep the page structure clear

Then SwiftUI is often suitable.

If the core difficulty of the page is:

• How to accurately control underlying interactions
• How to coordinate complex scrolling behavior
• How to implement non-standard animation and layout behaviors

That UIKit tends to be more stable, or at least more “controllable”.

This judgment is not absolute, but it is practical enough in real projects. It can guide daily selection better than the question “Can SwiftUI replace UIKit?”

6. The most realistic strategy in old projects is usually “mixing according to boundaries”

If the project already has a mature UIKit structure, the most likely problem is “over-ideal migration imagination”.

In real projects, the more common and more stable path is usually:

• Use SwiftUI first for new pages
• Stable UIKit pages cannot be easily changed
• Mix it up when needed
• Do not pursue full migration in one go

Because migration costs themselves are business costs. If framework switching does not bring clear benefits and is just for the purpose of “unifying the stack”, it is likely that the gain will outweigh the loss.

7. A common misunderstanding: treating SwiftUI as “a syntax upgraded version of UIKit”

When I first learned this piece of SwiftUI, I was still asking these questions in my mind:

• Is this view only created once?
• When do I want to refresh manually?
• It’s not like UIKit where you just need to change it directly.

These doubts are normal, but if you stay at this point of view for a long time, it will be difficult to really use SwiftUI well. Because SwiftUI is a completely different way of organizing the interface.

It requires prioritizing thinking about:

• Who is responsible for the status?
• How to map this state to UI
• Is interface update part of the state flow?

Once you still use UIKit’s thinking, SwiftUI can easily end up becoming “seemingly declarative, but actually the logic is more confusing”.

8. Conclusion: Whether SwiftUI is suitable or not does not depend on whether it is new or not, but depends on the source of page complexity.

To put it in shorter form, I would say:

SwiftUI is most suitable for pages whose core complexity mainly comes from state expression, interface combination and frequency of iteration; and for those pages whose complexity mainly comes from underlying interaction and fine control, it may not be naturally dominant.

So the real practical judgment is:

• What’s so complicated about this page?
• Can SwiftUI achieve this kind of complexity?

Once this question is answered clearly, the selection is usually not too confusing.