The App Life Cycle

If someone asked us to point to the first line of our app, what would we say? Unlike old C programs—or even the Objective-C that we used prior to iOS 8—there’s no command-line friendly main function that kicks off our execution. If we think back to where started, we had just two classes: AppDelegate and ViewController, along with Main.storyboard. Clearly, we’re not driving this car; we’re a passenger. So let’s start by getting a sense of where iOS is taking us when our app starts up and when we get an opportunity to tell the driver where we’re going.

For a Swift app, iOS creates a UIApplication object to set up the app’s runtime environment: its use of the display, its ability to handle touches and rotation events, and so forth. This object is also how we can interact with the rest of the iOS system, as we’ll see shortly. The UIApplication has a windows array, typically one per screen, and there’s only one screen unless we’re hooked up with a video output cable or AirPlay. Each window has a rootViewController. And that’s where the storyboard comes in: the application creates an instance of the view controller in the storyboard’s initial scene, and puts its view into the window.

UIApplication can also have a UIApplicationDelegate object, which is informed of major life-cycle events that affect the app. This is the AppDelegate class that Xcode gave us to start with. When all the app setup is done, the application(didFinishLaunchingWithOptions:) method gets called. From our point of view, this is where the app “starts,” although a bunch of stuff has already been done for us by this point. Some apps will use this callback to set up stuff that needs to be working immediately, or objects that will live for the entire life of the app, like data stores.

Of course, at some point, users will leave our app by pressing the home button, taking a phone call, accepting a notification from another app, and so on. That’s not the end for us; they might come back. UIApplicationDelegate tells us about these actions, with methods like applicationDidEnterBackground, applicationWillEnterForeground, and so on. We used applicationWillEnterForeground on a lark back in ​Trying Out Our Function​, when we made a quick Twitter call every time our app was foregrounded. There are also the related methods applicationWillResignActive and applicationDidBecomeActive that tell us we’ve been suspended so users can deal with an interruption like an alert from an incoming phone call or SMS message. If they take the call or switch to the Messages app, we’ll be backgrounded, but if they choose to ignore it, we’ll become active again.

If our app is backgrounded long enough, it will eventually be terminated, so if our app needed to save data for the next time it’s launched, going to the background is the right time to do that work. If the user force-quits us in the foreground, the app delegate finds out by way of a different method: applicationWillTerminate.