Your First iOS & SwiftUI App: An App from Scratch

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

You can unlock the rest of this video course, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now

We've made some great progress with Bullseye. We've created the basic user interface and we've added some code to print out the value of the slider when the user taps the button. At this point, we have all the pieces in place in order to write the core gameplay logic but the question is, where should that code go? Our first thought might be, well let's just stick it in content view, after all, that's where all the rest of the code is, right? And for a small, simple app like Bullseye that might actually work out just fine. But what if your app grows and you start adding tons more features like you do for most apps? You'll find that in practice if you put all your code inside a single view soon your view will become a massive mess of what we programmers like to call spaghetti code. It becomes a massive file and it's hard to find what you're looking for to fully understand what it's doing. This makes it hard to make changes or to fix things. Without introducing bugs, it also becomes hard or impossible to test. This leads me to a concept called app architecture. This is just a fancy term to describe the strategy you use for organizing your code. Putting all of your code into one file is a strategy that's technically an app architecture. It's just not a very good one. One of the best practices of app architecture is called the single responsibility principle. That means that you should think about how to organize your app into multiple classes and structs where each class or struct has one and only one real job. For example, you might have a struct whose job is to parse a file, another whose job is to authenticate a user and one whose job is to perform a difficult calculation. Each class or struct takes care of a specific part of the program. In a full-blown app you'll have many different classes or structs, 10, even hundreds. We already have one struct in our app, content view. Its job is to display the user interface for the app. Asking it to worry about the gameplay logic in addition to that would be violating the single responsibility principle because now content view would have more than one job. We want our classes and structs to be lazy, so instead it would be better to create a new struct that handles all of the gameplay and we could call it game, for example. The game Struct could have data like the current random target the user is aiming for, the current round and the total score. The game struct could also have methods like one to calculate the points based on the user's guess or a method to start a new round. As you learned earlier in this course, content view is an example of a view struct. On the other hand, objects like a game that are responsible for your app's data are commonly called models. When you're thinking about app architecture, you also need to think about how these objects are connected and how they communicate. In this case, we want our views to have an instance of the game model as a property, the view structs can then interact with their models whenever they need to interact with the app's data. For example, the view could ask the model for the current random target or to calculate the points for the current round. Notice that the arrow only goes one way. We don't want the models to call methadone or even know about the views. This makes the models more independent and more reusable and testable. By following the single responsibility principle our bullseye code will become a lot cleaner. It'll be easier for someone looking at our code to understand it. It'll be easier to add new features and make changes and as you'll learn in the next part of this course it'll be easier to test. The strategy we sketched out here is an example of an extremely simple app architecture, we have a view that handles the user interface and a model that handles the gameplay logic. You should consider this level of separation into views and models as the bare minimum for an app architecture. But this is only the beginning. You can go a lot further with more advanced app architectures, such as the popular or model view, view model app architecture. The subject of app architecture goes quite deep and it can get contentious. Programmers love arguing about architecture. We have entire books and video courses just on app architecture. But for now, for your first app the important thing to remember is this number one rule we covered today, give each class or struct you create a single responsibility.