Modern SwiftUI: Introduction

In the past 3 episodes we explored some of SwiftUI’s newest tools for navigation, in particular NavigationStack and the navigationDestination view modifier. Those 3 episodes formed the capstone of a 12-part series of episodes where we cover SwiftUI navigation from first principles. In those episodes we were able to unify pretty much all forms of navigation into one single style of API.

It was all pretty incredible, and I’m betting that a lot of our viewers are really itching for us to move onto navigation for the Composable Architecture. It’s been a long time coming, and we have some amazing things to share for that soon, but it’s not time for that just yet.

We want to spend a little more time with vanilla SwiftUI because we feel there aren’t enough examples out there of applications written with best, modern practices. By this we mean an application that is decently complex in order to show off real world problems, built in a way that can be tested, built in a way that is modular, and using all of Swift’s powerful domain modeling tools.

Now of course we feel that the Composable Architecture is one of the best ways to create such applications, but we also know that many people do not want to use our library or possibly just can’t. So, we still think it’s worthwhile exploring how modern SwiftUI applications can be built.

To demonstrate all of this we are going to rebuild an application that Apple released a few years ago called “Scrumdinger.” It doesn’t get as much attention as the WWDC samples, such as the Fruta or Food Truck demo apps, and that’s a shame because it’s a fun little application with quite a bit of complex logic in it. We think it does a much better job of showing the problems that need to be solved in a real world app than Fruta or Food Truck.

After giving a quick demo of the application we are going to rebuild it from scratch using modern, best practices for building SwiftUI applications. Along the way we will find a number of deficiencies in Apple’s code that we will want to fix, but we are in no way judging the code. Apple’s code serves a very specific purpose, which is to introduce SwiftUI concepts to hundreds of thousands, if not millions, of developers. Given that lofty goal it is no surprise that they build their sample code in the most barebones way possible. But we still want to be able to show how to build applications in a way that scales with team size and application complexity.

Let’s begin.