We have now finished a big, foundational step to creating a modern app with its persistence based on SQLite. It may seem a little weird that we took any entire episode to just set up some tables and a database, but we have already learned a bunch of valuable lessons:

• We have seen that we like to first-and-foremost design our database tables with our Swift data types in mind. This is because they are the interface to our data that we are going to be dealing with 99% of the time, and it allows us to take full advantage of everything Swift has to offer, such as enums for the finite enumeration of options.

• Then we saw how to create a connection to a database, and how sometimes we may want to do that to a live file stored on disk, but other times, such as in tests and previews, we may want to do that in-memory. That way multiple tests and previews do not trample on each other by writing to the same file on disk.

• And finally, we saw how to create the tables that represent our Swift data types, including how to set up a foreign key relationship that allows each reminder to belong to exactly one reminders list, and another relationship for allowing any number of tags to belong to any number of reminders.

These are all good concepts to be familiar with when building modern persistence into your app, we are going to leverage these concepts more and more as we progress through the app.

But we still haven’t actually gotten anything to display on the screen! And now it is time. We are going to start building out the views that can display the data in our database. We will show that our libraries come with a suite of tools that make it incredibly easy to query for complex subsets of data, and immediately display them in views. And further, any changes made to the database will cause the view to automatically update. And best of all? These tools are not relegated to only the view layer. They of course work in the view, but they also work in so many more places.

Let’s get to it!