Where can I find the "restorecount" value macOS uses to track open windows and reset it?

Question

1. In System Preferences uncheck `General > Close windows when quitting an app
2. Open TextEdit.app
3. Press Cmd+N for a New file
4. Quit TextEdit.app
5. In Finder go to ~/Library/Containers/com.apple.TextEdit/Data/Library/Saved Application State/com.apple.TextEdit.savedState/ we'll be looking for a file here shortly
6. Open TextEdit.app
7. Quickly, open the file restorecount.plist that has appeared in Finder
8. Look at the end value

Currently, on my macOS installation, end has a value of 570214618 which, as I understand it, means that since whatever epoch — a long time ago in an operating system far, far away — there have been over 570 million "windows" opened on my Mac. The value is shared across all user accounts. 10 months ago, that number was 544 million on my system according to this old question of mine: https://apple.stackexchange.com/a/320967/15281

The effect of this is that, for some apps, there is a noticeable (4 to 5 seconds) delay whilst they do something before their restored windows appear. My workaround, see the above linked question, is to turn off window saving for those specific apps. But I'd rather not have to do that.

So, I'd like to reset the restorecount value at its source. Does anybody know where it is stored and/or how can I reset it?

Answer 1

The end value is not the number of windows you have opened, it is a Cocoa timestamp. 570214618 corresponds to January 26, 2019 4:56:58 PM GMT. As far as I can tell, the purpose of restorecount.plist is just to track how long it takes to restore the windows.

For apps that are taking a long time to start, you can try cleaning out their saved application state and see if that helps, but there are lots of other reasons an app might take a long time to start. The most common reason an app takes a long time to start is that it needs a lot of memory and you are already using all the available RAM so some memory needs to be compressed or written to disk in order to free up memory for the app. You can get a sense of this by looking at the "memory pressure" in the Activity Monitor.

You can also look at the amount of Swap Used (also in Activity Monitor). If that number goes up when you launch an app, then not having enough free memory is definitely a source of delay.