{
  "id": 1592870,
  "title": "Breaking Up Big SwiftUI Views the Right Way",
  "url": "https://urgent.news/2026/08/17/breaking-up-big-swiftui-views-the-right-way",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-17T23:28:32.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/emadbeyrami/breaking-up-big-swiftui-views-the-right-way-3m42"
  },
  "original_language": "en",
  "account": "When SwiftUI codebases grow, views can become unwieldy and difficult to manage. The initial approach to cleaning up these views is often to split the body into computed properties. For example, a 400-line view with a complex body can be refactored into smaller computed properties for header, content, and footer sections. While this makes the source code easier to read, it does not create a new View type or isolate the code in terms of dependencies and state.\n\nComputed properties only organize the source code, while separate View types can organize the view hierarchy, dependencies, state, and update work. Understanding the distinction between these two approaches is crucial for building maintainable and performant SwiftUI apps.\n\nSwiftUI's Observation system tracks the observable properties read during a view's body evaluation. A computed property does not create a separate view node in the hierarchy. Instead, the entire body of the parent view, including the computed properties, is evaluated together. Therefore, extracting a separate View type is essential when you want to establish narrower dependencies, isolate state, and improve performance.\n\nThe key concept to remember is that computed properties improve code readability, while separate View types organize the view hierarchy, dependencies, state, and update work. By using separate View types, you can create performance boundaries and isolate changes more effectively. Extracting a real View type changes the structure of your code, providing a new node in the hierarchy with its own identity and dependencies. This allows you to establish narrower dependencies and isolate state and work, making your code more maintainable and performant.",
  "summary": "Why computed properties help readability, what @ViewBuilder actually does, and when a separate View type matters Every SwiftUI codebase eventually grows a view nobody wants to open. Four hundred lines. A body that scrolls forever. Several layers of modifiers. State, navigation, sheets, animations, and business logic all living in the same place. The usual first attempt at cleaning it up is to…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}