Mac OS X Lion was introduced in 2011 and came with a new feature called Power Nap. This allows computers to receive push notifications, check for new messages, update calendar events, run iCloud updates, download software updates, and run Time Machine backups in the background while a computer is asleep – they don’t go all the way to sleep, they just kinda’ take a nap.
Application persistence was released the next year and is an API that Apple uses in a number of programs on and exposes to third party software developers who can opt into the ability to have the state of an application persist and be restored when the app opens. This is made possible because the view controller of a given application can use the application(:shouldSaveState:) and application:shouldRestoreApplicationState:) methods. Apple initially called this the Resume feature and both owe their origins to the emergence of flash storage, which is required for Power Nap to function properly.
That saved application state data is typically stored in ~/Library/Saved Application State. Each application bundle identifier has a directory in that folder. For example, the Finder would save data in /com.apple.finder.savedState/data.data. Clearing that directory at one point was a required piece of troubleshooting for many an application, but I probably haven’t done so in four or five years. The savedState directory can also be used to host that data.data directory, which may also have a windows.plist, a layout of windows.
The data.data has a number of records, mostly encrypted, that can be decrypted in part with keys obtained from the windows.plist file. These are AES and this is all a bit different than how the actual Core Data storage is used. Core Data was introduced in 2005, with Mac OS X Tiger. That is a persistence framework (and an object graph to store data). It can serialize data into binary files the way the ApplicationState does; however it can also use XML (as in the case of, for example, a defaults domain) or in a sqlite database for more performant uses. Apple added the ability for developers to build their own atomic data storage and the design goes way back to the Enterprise Objects Framework (EOF) that NeXT built prior to the advent of Mac OS X (in 1994 after the DatabaseKit hit limitations with NextStep in 1992). One of the software developers on that team was Craig Federighi and the EOF became an important part of WebObjects (although this was prior to the introduction of Asynchronous JavaScript and XML, or Ajax, which helped popularize the concept of asynchronous everything.
So a developer can instruct an app to open to the saved state and kinda’ save a little data without importing the whole CoreData framework and thus change the architecture of an application. A developer can also just instruct an application to persist the state, although that could be interrupted by a user tossing the file, or a recovery agent doing so under the hood. Power Nap is obviously not the same as Application, or at least state, Persistence. Last night I caught myself kinda’ using the two interchangeably on a podcast. As Apple continues to allow more and more critical processes to happen in a Power Nap state, I should be more and more careful not to do so! Apologies if that created any confusion!
