List

What a SwiftUI list does

A List is a SwiftUI container that presents rows of data in a scrolling, table-like layout. It is designed for collections of identifiable items, so SwiftUI can diff updates efficiently and refresh only the rows that changed. That makes it the standard choice for structured, row-based interfaces such as settings screens, menus, and item browsers.

How List manages row content

List is more than a visual wrapper around repeated views. It gives each row a stable identity, which lets SwiftUI reconcile inserts, deletions, reordering, and selection state without rebuilding the entire interface. This is why List behaves differently from a plain stack of rows: it is built for data-driven rendering, not just static layout.

Because of that identity model, List works best when each element can be uniquely identified and the underlying data source is treated as the source of truth. If the identity is unstable or duplicated, row updates can appear inconsistent, selection may drift, and animations can look wrong even when the UI compiles correctly.

Interactions supported by List

SwiftUI adds common table-style interactions directly to List, including selection, swipe actions, disclosure navigation, and contextual row behavior. These interactions are important because they make the list not just a display surface, but a control surface for working with structured data.

The practical effect is that List often becomes the point where users inspect, modify, and navigate collections. In app design, that means row affordances need to match the data model carefully. A list that is visually tidy but interaction-poor can create friction, while an over-animated or over-complex list can obscure the meaning of each row.

When to use List instead of a custom container

List is strongest when the interface is inherently collection-oriented and benefits from platform conventions, automatic row handling, and built-in scrolling behavior. It is usually the right fit for master-detail screens, preference panes, and any screen where items are expected to change over time.

A custom container is often better when the layout is highly bespoke, when every row must be composed manually, or when the design depends on visual structure that does not fit a table-like presentation. In other words, List optimizes for consistency and productivity, while custom layouts optimize for exact visual control.

Practitioner Guidance

What to watch for: Choose List when the data naturally behaves like a mutable collection with row-level identity, selection, and navigation. If your rows are not uniquely identifiable, or if you need highly custom spacing and composition, you may need a different container or a tighter data model.

Practitioner takeaway: The quality of a SwiftUI List depends less on the widget itself than on the stability of the data behind it.

Related resources from NHI Mgmt Group

• What breaks when CI/CD pipelines can list tables with long-lived credentials?
• Who should own unsubscribe and suppression list governance?
• How should organisations respond when a jurisdiction is added to the FATF grey list?
• What do security teams get wrong about posture reports that list hundreds of findings?