Long delay between updateChangeCount and actual save on UIDocument

No, that's about the typical interval before an autosave. In general, saving can be an expensive operation, so a more immediate autosave would be undesirable.

If you need to commit changes on a tighter schedule, you're going to have to do something manually. This could be an explicit save or autosave, or something like journalling of changes so they can be replayed in the event of a crash. But consider the effect on performance and (particularly) battery life.

Thank you. A journaling approach will work well for me, as user actions translate well into atomic operations.

My problem was surfaced by a tester who habitually dismisses apps by double pressing the home button and swiping up to close the app. I tested this approach with Notes and Pages and was unable to lose any data!

I don't know anything about NSUndoManager but you may want to try and protect yourself from such irrational user behaviours by doing some kind of "force save" immediately when the app enters the background.

I agree that it would make sense to attempt the save when the app leaves the foreground. It's possible even that autosave runs normally at this time, except under the scenario described. (That is, just switching to another app might trigger an autosave sooner than usual.)

I think there's also an argument that says that no change in app behavior is desirable. Losing data is going to discourage the user from routinely doing something that's a really bad idea. In that user's mind, "closing" the app by swiping it out of the app list is reclaiming the resources being consumed by the app, but that's not in general true. That app list is not running apps, but recent apps. Apps that have been already terminated by the system due to idleness are still in that list, even though they don't consume any resources. On the opposite front, there may be other cleanup operations (other than saving, things involving network access, for example) that might be aborted by forcing the app to terminate.

The gosh-honest truth is that on iOS, apps in the background are not running unless they need to be, or they are not consuming enough resources to matter.

Of course, I understand that you can't really tell users they're Doing It Wrong™, but it may not be worth jumping through hoops to code around users who really are Doing It Wrong™.

So it turns out this was a programming error on my part under poor connectivity conditions. 😝

iOS behaves impeccably (in this case). When you switch app context, the system checks the document immediately for unsaved changes and provides an opportunity to perform a save. Obviously the app needs to be a good citizen in respect of efficiency etc.

I think I misrepresented the tester, who was just going to extremes to break my app, which turned out to be of great help!

Thanks for the input.