`NSFileCoordinator` does not work reliably across applications and share extensions

[irace]

• Radar #18341292

NSUserDefaults and SQLite are useful for synchronizing data access across both extension and container application, but as per WWDC Session 217, NSFileCoordinator is also supposed to be an option for those of us using NSCoding for custom data persistence. We tried hard, but couldn’t actually get it to reliably work.

Our use case required both our app and extension to write to the same file, where only the app would read from it. We observed a number of problems while both extension and app processes were running simultaneously. NSFilePresenter methods intended to indicate that the file had been or will be modified (presentedItemDidChange or relinquishPresentedItemToWriter:) would either:

• Not be called at all
• Only be called when switching between applications
• Be called, but only after a method that would cause the app to overwrite the data that the extension had just written (either savePresentedItemChangesWithCompletionHandler: or relinquishPresentedItemToReader:) was called first

  Workaround

Rather than trying to keep access to a single file synchronized across processes, we modified our extension to instead atomically write individual files, which are never modified, into a directory that the application reads from.

This isn’t to say that NSFileCoordinator isn’t currently a viable option if you’ve got a different usage than we do. The New York Times app, for example, is successfully using NSFileCoordinator in a simpler setup, where the container app is write-only and the extension is read-only.

[irace]

This may now be fixed: http://www.atomicbird.com/blog/file-coordination-fix