iOS apps developed in Xcode 7 and the iOS SDK have a specific lifecycle. This movie demonstrates the basics of that lifecycle according to Apple's documentation for Swift and Xcode 7. See how the app works, where the starting of the program resides, and which objects are controlling the app flow behind the scenes.
- Up to this point, all of our code has been written in the view controller class, but there's also this class in your default projects called app delegate. Let's talk about what this class is for and what purpose it serves in your iOS development. You'll notice a few things when you go to that class. It has an @UIApplicationMain callout. It's a subclass of UIResponder, and it implements a protocol for UIApplicationDelegate. Also, it has a variable called window, and it has some built-in methods that up to this point, we haven't done anything with.
Notice that they all have something to do with the application: applicationWillTerminate, applicationDidBecomeActive, applicationWillEnterForeground. And if you read these comments, you can see what the purpose of these methods are. And if you read the comments, you can see what these methods are supposed to do or, rather, what events they're supposed to handle. So to understand this, the easiest way I thought is to go straight to Apple and to look at their App Programming Guide for iOS. So at Apple's App Programming Guide, they explain in Figure 2-1 on this page the key objects in an iOS app.
Now, they're actually grouped by the model, which is the data, the controller, and the view. We talked about model-view-controller previously. The model represents your data. The view represents your visual objects. The controller connects the model and the view. And if you look at this diagram, you can see that in action. So what's actually going on behind the scenes in an iOS app? At the core of it is this UIApplication object. Now, if you look at the color of the background and look at the chart, this is a system object.
When you're developing for iOS, there's one UIApplication instance. That's your app. But you actually don't subclass UIApplication. Instead, you use delegation. You have an application delegate class that's a custom object, see it's green there, and that handles all of the events in your application. So the UIApplication's handling this event loop, like the app's opening and closing, and it's sending that information to whoever its delegate is, which in this case is usually your app delegate class.
Your app delegate has an instance of a UIWindow. You can think of the UIWindow as the entire screen, the entire visual area for your application. You usually do not interact with the UIWindow. The UIWindow has views and UI objects, and those are the things that we interact with, and those are connected to a view controller. These are blue, indicating that they're either system or custom objects. And then your view controller or your application delegate can interact with your documents, and the documents can grab the data objects.
Now this model area can be created really however you want. It can be a SWIFT file. It can be a plist file. It could be any other type of data that you want, but this is referenced from your view controller or your application delegate. Now this chart may look confusing, and if it is, you really don't have to worry about it. I'm just showing you this so that you understand what's going on behind the scenes. And if you want to read more about it, you can just come to this page, and you can read what Apple has to say and get more details.
All you need to know as a developer is that the application delegate is where you're going to handle your application-wide events and that your view controller is going to be your primary source for interacting with your model objects and also interacting with your views. You don't have to interact with the UIWindow. In most apps that you develop, you probably won't even have to reference it once. So, just like we've been doing before, we're primarily going to develop our views and UI objects in our storyboards, and we're going to write most of the code in our view controller or other view controller subclasses that we might create, and those are going to interact with our model objects.
Interested in developing for Apple Watch or Apple TV? Get a sneak peek in Chapter 9. The course wraps up with a look at the submission process for the App Store.
- Installing Xcode and the iOS SDK
- Creating a simple iOS app
- Creating a basic interaction with a button
- Choosing an object as a first responder
- Creating a user interface with Interface Builder and Auto Layout
- Working with sliders and progress bars
- Creating views to show images and web pages
- Developing responsive layouts with size classes
- Understanding the iOS architecture
- Loading data in table views
- Transitioning between views
- Developing for the iPad, Apple Watch, and Apple TV
- Submitting apps to the App Store