SwiftUI Series 05｜Correct usage of NavigationStack and page jump

When you use NavigationStack for the first time, you will think it is the SwiftUI version of the navigation container:

• Click
• push a page
• That’s pretty much it

But in real projects, the real troublesome part of navigation is always:

• The page will jump
• Whether the jump status and business status are consistent
• Whether the path can still remain correct when deep linking, returning, and re-entering the page

In other words, what NavigationStack really has to deal with is not just interface switching, but the navigation state itself.

1. The navigation problems of many projects in the past essentially came from “jump actions scattered everywhere”

In the UIKit era, a very common way of writing is:

• Push directly in a button
• Present directly in a callback
• When a ViewModel calls back, it jumps through the delegate

Of course it will work in the short term, but the problem is that the navigation logic will become more and more scattered. Hard to answer:

• Why are you on this page?
• What state should you return to after returning?
• After a certain business is completed, it will jump to two levels.

SwiftUI’s NavigationStack gives a better chance: Change the “current navigation path” from implicit action to explicit state.

2. The most important thing about NavigationStack is the path

When I first learned this piece of content NavigationStack, I just stared at:

• NavigationLink
• navigationDestination

Of course you need to know these, but what really should be understood first is:

Navigation can be expressed as a state path in SwiftUI.

This means no longer just “jumping on click”, but maintaining:

• What pages are in the current path?
• Which business status corresponds to which destination
• How should the path change after a certain operation?

Once viewed from this perspective, navigation ceases to be just a UI event and starts to become part of the state flow.

3. Many navigations are messed up because the business status and routing status are not aligned.

To give a very common example:

• User selects an article
• The article details page should appear
• How to exit the details page after deleting an article?

If you just understand navigation as “click to enter”, then many subsequent questions will start to get confusing:

• How to restore the path when a deep link comes in
• How to adjust the path after data failure
• What state the list should remain in when returned

So the really difficult thing about navigation is that it should not exist independently of the business state.

A more stable idea is:

• Navigation path and business status are mutually interpretable
• Why you are currently on this page can be explained clearly from the status.

4. NavigationLink is very convenient, but once the project is complex, you cannot rely on it to express all navigation

NavigationLink is particularly suitable for direct, partial and simple jumps, such as:

• Click on the list for details
• Set page feed settings

But if the project is complex, if all navigation relies on scattered NavigationLink, you will soon encounter:

• Paths are difficult to manage uniformly
• Deep links are difficult to access
• Certain process jumps are no longer simply click-driven.
• The return path is disconnected from the business status

This is why it is more suitable for taking on local entrances and is not suitable for carrying the navigation strategy of the entire application alone.

5. A more practical idea: design the “page destination” as a value that can be explained by the business

One of the root causes of many project navigation accidents is:

• Jumps are just written as a bunch of UI actions
• No reasonable destination model is formed

A more stable method is usually to let the path carry “which destination the current business wants to go to.”

For example:

• articleDetail(id: String)
• userProfile(id: String)
• settings

This way navigation feels more like states rather than a disjointed collection of actions. Its benefits are:

• Paths can be reconstructed
• Deep links are more natural
• Testing and debugging are also easier to describe

6. The most common bad smell in real projects: View, ViewModel, and routing actions are intertwined with each other

A lot of SwiftUI navigation code ends up looking like this:

• Write part of NavigationLink in View
• The ViewModel secretly decided to jump again
• A certain service callback triggers a navigation state change

In the end no one can tell clearly:

• Who is the real owner of the navigation
• Which state determines the current path
• Is a certain return action a user behavior or a business behavior?

Once the navigation enters this state, the cost of adding a deep link or adding a recovery path will increase significantly.

7. A practical judgment: Is the current page “because I clicked in” or “because the status determines that it should be here”

This is something I often ask myself.

If a page appears, it can only be interpreted as:

• Because I just clicked a button

That usually means the navigation is still too action-driven.

A more ideal explanation should be:

• because the current path state contains it
• because the current business context dictates that it should be displayed

This difference is important. The former is more like a temporary action, the latter is more like a maintainable navigation state.

8. Conclusion: What NavigationStack really allows to manage is not just jumps, but path status.

To put it in shorter form, I would say:

NavigationStack The really important thing is that it allows navigation to be more naturally closed from “scattered click actions” to “manageable path state”.

Therefore, the correct way to open the page jump is not just to write NavigationLink, but to allow the navigation status and business status to explain each other. Only in this way, the navigation will not become more and more confusing as the project becomes more complex.