Skip to content

mpwg/SwiftUIExamples

Repository files navigation

NavigationSplitView Examples

A comprehensive guide to SwiftUI architectural patterns with working examples of NavigationSplitView implementations.

⚠️ Disclaimer: This guide and documentation were created with assistance from GitHub Copilot. While we strive for accuracy, there may be errors or outdated information. Please verify critical information and test thoroughly in your own projects. Contributions and corrections are welcome!


🎯 TL;DR

Use MVVM for most apps. It balances simplicity, testability, and maintainability without excessive complexity.

Use MVVM-C if you have complex navigation flows or need ViewModels to be completely independent of navigation.

Avoid VIPER, TCA, and Redux unless you have specific requirements that justify the added complexity.


πŸ“Š Quick Recommendations

βœ… Recommended for Production

Pattern When to Use Why
MVVM 90% of production apps βœ… Best balance of simplicity and structure β€’ βœ… Easy to test β€’ βœ… Minimal boilerplate β€’ βœ… Works with SwiftUI's reactive model
MVVM-C Complex navigation, deep linking βœ… Clear navigation boundaries β€’ βœ… Reusable ViewModels β€’ βœ… Great for coordinator patterns

⚠️ Use With Caution

Pattern When to Use Why Be Careful
TCA Functional programming teams, high testability needs ⚠️ Steep learning curve β€’ ⚠️ External dependency β€’ ⚠️ Verbose boilerplate β€’ ⚠️ Overkill for most apps
Redux Web developers familiar with Redux ⚠️ Boilerplate overhead β€’ ⚠️ Not idiomatic SwiftUI β€’ ⚠️ Better alternatives exist (MVVM)
VIPER Large teams, enterprise apps ⚠️ Extremely verbose β€’ ⚠️ Slows development β€’ ⚠️ Over-engineered for most needs

πŸŽ“ Learning Only

Pattern Purpose
ViewOnly Learn SwiftUI basics, prototypes

πŸš€ Quick Start

πŸ‘‰ New here? Start with: Documentation/GETTING_STARTED.md

πŸ”§ Setting up TCA/Redux? See: SETUP.md

Running Examples

  1. Open SwiftUIExamples.xcodeproj in Xcode
  2. Run with ⌘R
  3. Select an implementation to explore

πŸ“‹ Pattern Comparison

Aspect ViewOnly MVVM ⭐ MVVM-C ⭐ TCA Redux VIPER MVC Clean MVI VIP Modular
Complexity Simple Moderate Moderate High Moderate Very High Simple Very High Moderate Very High Very High
Learning Curve Easy Moderate Moderate Steep Moderate Steep Easy Steep Moderate Steep Steep
Testability Poor Excellent Excellent Excellent Excellent Excellent Poor Excellent Excellent Excellent Excellent
Boilerplate Minimal Low Low High High Very High Minimal Very High High Very High High
Dev Speed Fast Fast Fast Slow Moderate Slow Fast Slow Moderate Slow Slow
Team Size 1-2 2-10 3-10 3-10 2-10 5+ 1-3 5+ 2-10 5+ 10+
Best For Learning Most apps Complex nav Functional teams Web background Enterprise UIKit/Legacy DDD/Domain Android teams Alt VIPER Multi-team
Dependencies None None None TCA library Optional None None None Optional None SPM
File Count ~10 ~15 ~17 ~12 ~15 ~20 ~8 ~25+ ~15 ~18 Varies
Status βœ… βœ… βœ… βœ… βœ… βœ… 🚫 Not for UI πŸ“‹ Planned πŸ“‹ Planned πŸ“‹ Planned πŸ“‹ Planned

⭐ = Recommended for production
βœ… = Implemented in this repo
πŸ“‹ = Planned / Reference only
🚫 = Not recommended for SwiftUI


πŸ“š Complete Documentation

Document Purpose Time
CONCEPTUAL_OVERVIEW.md Visual pattern comparison 15 min
ViewOnly_Architecture.md Simple pattern deep-dive 30 min
MVVM_Architecture.md Production pattern guide 45 min
MVVMC_Architecture.md Coordinator pattern guide 45 min
TCA_Architecture.md TCA pattern deep-dive 45 min
Redux_Architecture.md Redux pattern deep-dive 45 min
VIPER_Architecture.md Enterprise pattern guide 60 min
DATA_FLOW_EXPLANATION.md Data flow patterns 20 min

πŸŽ“ Learning Paths

New to SwiftUI?

  1. Start with ViewOnly pattern
  2. Learn @State, @Binding, and basic SwiftUI concepts
  3. Move to MVVM when ready for production

Building Production Apps?

  1. Study MVVM pattern (recommended)
  2. Implement with Models, ViewModels, and Views
  3. Add Coordinator (MVVM-C) if navigation becomes complex

Need Maximum Testability?

  1. Evaluate if MVVM is sufficient (usually is)
  2. Consider TCA only for functional programming teams
  3. Avoid VIPER unless working on large enterprise apps

πŸ—οΈ Project Structure

Examples/
Examples/
β”œβ”€β”€ ViewOnly/           # Simple pattern (learning)
β”œβ”€β”€ MVVM/              # ⭐ Recommended for most apps
β”‚   β”œβ”€β”€ Models/        # Pure data structures
β”‚   β”œβ”€β”€ ViewModels/    # Business logic (@Observable)
β”‚   └── Views/         # SwiftUI UI components
β”œβ”€β”€ MVVMC/             # ⭐ For complex navigation
β”‚   β”œβ”€β”€ Models/
β”‚   β”œβ”€β”€ ViewModels/    # Business logic only
β”‚   β”œβ”€β”€ Coordinators/  # Navigation logic
β”‚   └── Views/
β”œβ”€β”€ TCA/               # Functional architecture
β”œβ”€β”€ Redux/             # Unidirectional data flow
└── VIPER/             # Maximum separation

Documentation/
β”œβ”€β”€ GETTING_STARTED.md              # οΏ½ Start here
β”œβ”€β”€ CONCEPTUAL_OVERVIEW.md          # Pattern diagrams
β”œβ”€β”€ *_Architecture.md               # Detailed guides
└── IMPLEMENTATION_SUMMARY.md       # Technical reference

οΏ½ Key Decision Factors

Choose MVVM When

  • Building most iOS/macOS apps
  • Want testable code without excessive complexity
  • Working with small to medium teams
  • Need to ship features quickly
  • Want to stay close to SwiftUI's patterns

Choose MVVM-C When

  • Navigation logic is complex (deep linking, flow coordination)
  • ViewModels need to be navigation-agnostic
  • Building modular features that can be navigated differently
  • Need clear separation between business and navigation logic

Avoid Complex Patterns When

  • You don't have specific requirements justifying them
  • Team is small or inexperienced with the pattern
  • Speed of development is important
  • Maintaining simplicity is valued

οΏ½ Other Notable Patterns

These patterns are not implemented in this repository but are worth knowing about:

MVC (Model-View-Controller)

Status: 🚫 Not Recommended for SwiftUI

Key Characteristics:

  • Classic iOS pattern from UIKit era
  • Controller mediates between Model and View
  • In SwiftUI, leads to "Massive View Controllers" problem
  • SwiftUI's declarative nature makes traditional MVC awkward
  • State management becomes unclear with SwiftUI's reactive updates

Why not use it: SwiftUI's architecture naturally pushes away from MVC. MVVM is the spiritual successor and works much better with SwiftUI's reactive patterns.

Clean Architecture

Status: πŸ“‹ Advanced pattern to consider

Key Characteristics:

  • Domain-centric with concentric layers (Entities β†’ Use Cases β†’ Interface Adapters β†’ Frameworks)
  • Business logic completely independent of UI and frameworks
  • Strong separation of concerns with dependency inversion
  • Can combine with MVVM, VIPER, or other presentation patterns
  • Excellent for domain-driven design (DDD)

When to consider: Large enterprise apps with complex business rules that change independently of UI. Overkill for most apps.

MVI (Model-View-Intent)

Status: πŸ“‹ Niche alternative

Key Characteristics:

  • User actions are captured as "Intents"
  • Intents trigger Model updates
  • Model changes drive View rendering
  • Unidirectional data flow (similar to Redux/TCA)
  • Popular in Android development, less common in iOS

When to consider: If your team has Android experience or you prefer thinking in terms of user intent over actions.

VIP (View-Interactor-Presenter)

Status: πŸ“‹ Alternative to VIPER

Key Characteristics:

  • Clean Swift architecture pattern
  • Unidirectional data flow cycle: View β†’ Interactor β†’ Presenter β†’ View
  • No Router component (navigation handled differently)
  • Heavy use of protocols for testing
  • Less component separation than VIPER

When to consider: Alternative to VIPER if you prefer the VIP data flow cycle. Still has high complexity.

Modular/Feature Architecture

Status: πŸ“‹ Organizational strategy

Key Characteristics:

  • Organizes code by feature/domain rather than layer
  • Each module is a separate Swift Package with clear boundaries
  • Modules can use any internal pattern (MVVM, TCA, etc.)
  • Enables parallel team development
  • Improves build times and enforces separation

When to consider: Large apps with multiple teams. Can be combined with any presentation pattern. Adds significant project setup complexity.

Elm Architecture / TEA (The Elm Architecture)

Status: πŸ“‹ Functional alternative

Key Characteristics:

  • Functional programming pattern from Elm language
  • Model + Update + View structure
  • Pure functions and immutable state
  • Inspiration for Redux and TCA
  • Messages instead of Actions

When to consider: TCA is the iOS equivalent - use that instead unless you specifically need Elm's exact model.


πŸ“– Additional Resources

Apple Documentation

Pattern Libraries

Swift & SwiftUI Learning Resources

🌟 Essential Sites

  • Hacking with Swift - Paul Hudson's comprehensive free tutorials, articles, and projects. Features "100 Days of SwiftUI" challenge.
  • Swift by Sundell - In-depth articles, tips, and best practices by John Sundell. Excellent for intermediate to advanced developers.
  • Ray Wenderlich (Kodeco) - High-quality tutorials, books, and video courses. Well-known in the iOS community.
  • AppCoda - Beginner-friendly tutorials covering Swift and iOS development fundamentals.

πŸ“Ί Video Tutorials

  • CodeWithChris - YouTube channel with beginner-friendly Swift and SwiftUI tutorials.
  • Sean Allen - Swift, iOS development, and software engineering career advice.
  • Stewart Lynch - Practical SwiftUI tutorials and tips.
  • Kavsoft - Advanced SwiftUI animations and UI implementations.

πŸ“š Books & Courses

πŸŽ“ Interactive Learning

πŸ’¬ Communities

  • Swift Forums - Official Swift community forums.
  • r/SwiftUI - Active Reddit community for SwiftUI discussions.
  • r/iOSProgramming - General iOS development subreddit.
  • Swift.org - Official Swift language website with documentation and community resources.

License

MIT License - Use freely for learning and production.

About

Examples for SwiftUI

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages