UIDocument Recover Unsaved Changes On App Crash/Force Quit

Question

From what I understand, the UIDocument class can track unsaved changes to a file and even locks the file so it cannot be checked out by more than one person. But what happens if the user force quits the app without saving or the app crashes? How would I go about recovering the unsaved changes to a UIDocument so that when the app re-launches it reopens the UIDocument with the most recent unsaved changes? Do I need to make duplicate copies of each file before it is changed and alter the temporary duplicate until the user saves the changes? Or does Apple provide a simpler implementation? I have also considered encoding and storing the Data file contents and the undoManager of each UIDocument instance periodically as a cache. Would that work?

Answer 1

The UIDocument and UIManagedDocument do automagic change tracking (calling a function where you can return true if the document has changed) and saving the changes to disk by respecting other system constraints (for example: if another process is trying to read the file). The way Apple does saving is in a very safe way, if you don't override the base class methods. When the save operation is triggered, Apple saves to a temp file and if the save is successfully a quick rename and delete of the original file is done (IIRC the rename/delete is atomic, or near atomic). You can assume that the save operation doesn't leave a corrupt file in the file system for 99.99% of all cases.

Apple triggers save operations in the background at specific points (like: time based, app switched to background, before other process tries to accesses the file, ...), but I couldn't find any clear statement what happens when the application is force quit.

That said, logic and common sense tells me, that if you force quit an application, the current document state can't be saved. Even implementing a "quick save" manually for a force-quit may not be technically feasible. A periodic background save operation (like UIDocument already does) may be the best strategy.

About saving the state of the undo manager: This would be the same technical problem as with saving the UIDocument. There is no event or anything else that tells the application it's about to be force-quit.

You should read the Apple Documentation. It's very long but it explains the process in more detail. My advice to you would be, to implement the strategy that Apple imposes. These strategies are sound, and work for many, many applications in the Apple ecosystem and for their users. On top of that, you have a reduced implementation cost and automagic improvements (when Apple updates their implementation).