swiftui-ssot

Enforce Single Source of Truth for SwiftUI state management.

3|Updated Sep 29, 2025
One-click install
npx skills add https://github.com/xtone/ai_development_tools --skill swiftui-ssot
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: swiftui-ssot
Source: https://github.com/xtone/ai_development_tools/tree/main/ios_development/skills/swiftui-ssot
Command: npx skills add https://github.com/xtone/ai_development_tools --skill swiftui-ssot

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

SwiftUI apps often suffer from duplicated or inconsistent state across views. This Skill provides a structured SSOT (Single Source of Truth) framework to centralize state ownership, ensure unidirectional data flow, and guide architects and reviewers in selecting the right property wrappers and patterns.

Core Features & Use Cases

  • SSOT framework for state ownership, derived state, and one-way data flow in SwiftUI.
  • Guidance on selecting property wrappers (@State, @Binding, @StateObject, @ObservedObject, @EnvironmentObject) based on ownership.
  • Review checklists and anti-patterns to fix state duplication and promote maintainable architectures.
  • Reference material in references/ssot.md with practical examples and edge cases.

Quick Start

Review references/ssot.md to understand the SSOT pillars, then apply the recommended patterns by lifting shared state to a common owner and preferring bindings over duplicate local state.

Frequently Asked Questions about swiftui-ssot

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage SwiftUI state ownership to prevent duplicated or inconsistent data across views?

To prevent duplicated or inconsistent state in SwiftUI, establish a Single Source of Truth by lifting shared state to a common owner. This enforces unidirectional data flow and keeps view architectures maintainable.

When should I use @StateObject vs @ObservedObject in SwiftUI view hierarchies?

Use @StateObject when the view owns and initializes the object's lifecycle, and @ObservedObject when referencing an externally owned object. This wrapper selection enforces a Single Source of Truth and prevents accidental state duplication.

What is the best way to pass shared state down the SwiftUI view tree without duplicating it?

The best way to pass shared SwiftUI state without duplicating it is using @EnvironmentObject for dependency injection down the view tree, combined with @Binding to connect child views back to the single source of truth.

How do I review SwiftUI pull requests for state management anti-patterns?

Review SwiftUI pull requests for state management anti-patterns by applying an SSOT review checklist. Verify that property wrappers match ownership boundaries, shared state is lifted to a common parent, and data flow remains unidirectional.

Why does my SwiftUI view update incorrectly when using @ObservedObject instead of @StateObject?

Using @ObservedObject where @StateObject is needed causes incorrect SwiftUI view updates because the view does not own the object's lifecycle. This breaks the Single Source of Truth, leading to duplicated state and unexpected data loss.