Modern SwiftUI

This week we finished our ambitious, 7-part series exploring modern, best practices for SwiftUI development. In those episodes we rebuilt Apple’s ”Scrumdinger” application, which is a great showcase for many of the problems one encounters in a real life application. Every step of the way we challenged ourselves to write the code in the most scalable and future-proof way possible, including:

1. We eschew plain arrays for lists and instead embrace identified arrays.
2. All of navigation is state-driven and concisely modeled.
3. All side effects and dependencies are controlled.
4. A full test suite is provided to test many complex and nuanced user flows.

…and a whole bunch more.

To celebrate the conclusion of our “Modern SwiftUI” series, we have released a blog post every day this week, detailing a different aspect of building SwiftUI applications using modern, best practices. Check them all out here:

• Modern SwiftUI: Parent-child communication
• Modern SwiftUI: Identified arrays
• Modern SwiftUI: State-driven navigation
• Modern SwiftUI: Dependencies
• Modern SwiftUI: Testing

A call to action!

We hope that you find some of the topics discussed above exciting, and if you want to learn more, be sure to check out our 7-part series on “Modern SwiftUI.”

We do have a favor to ask you. While we have built the Standups application in the style that makes the most sense to us, we know that some of these ideas aren’t for everyone. We would love if others fork the Standups code base and rebuild it in the style of their choice. We even have a dedicated repo with the codebase ready to go. 😁

Don’t like to use an ObservableObject for each screen? Prefer to use @StateObject instead of @ObservedObject? Want to use an architectural pattern such as VIPER? Have a different way of handling dependencies? Please show us!

We will collect links to the other ports so that there can be a single place to reference many different approaches for building the same application.