SwiftUI Series 14｜Building settings pages with SwiftUI: from structural design to component reuse

The settings page is often underestimated because it doesn’t look like a “techy” page.

But precisely because it is typical enough, it is actually very suitable for testing the understanding of SwiftUI page organization:

• The page structure hierarchy is unclear
• Status ownership is stable or not
• Is component abstraction natural?
• Are the spacing and visual rhythm consistent?

So the settings page is a good basic question.

1. The real difficulty in setting up a page is how to maintain a stable structure among a large number of similar items.

The common elements of the settings page are very similar:

• title
• Explanatory text
• switch
• Enter the lower level page
• risky operations

If you don’t think about the levels in advance, it’s easy to write:

• Each line is a little different
• But there is no unified structure

Over time, this kind of page will become increasingly difficult to maintain.

2. The settings page is very suitable for clarifying the “row-level components” and “grouping structure” first.

If I write the settings page steadily, I usually think about two levels first:

• What does a row of setting items look like?
• How a group of setting items is organized

Once these two levels are clear, the page complexity will drop a lot. Because you won’t have to rethink the layout every time a new setting item is added.

3. The settings page can especially expose status ownership issues.

For example:

• Who owns a certain switch value
• Should it take effect immediately after clicking or confirm first?
• Some settings are local UI states or business states

If these are mixed together, the page will quickly grow all kinds of temporary logic. Therefore, the settings page seems simple, but it is actually very suitable for practicing “which states belong to the page and which states belong to the business object”.

4. Conclusion: The reason why the settings page is suitable for SwiftUI is that it looks simple on the surface, but in fact it is closer to it, which especially tests the sense of hierarchy.

To put it in shorter form, I would say:

The real value of using SwiftUI to write settings pages is to use it to learn three things: structural layering, component reuse, and state attribution.

Once these three things are established, many business pages will also become stable.