The notification that results in this delegate method isn’t sent out until the fail/success result of the actual writeout is received, meaning that it can’t start until after the writeout is not just complete but its result status is also known. Although it is possible for the notification to be delayed, I can’t see a way for it to be premature to the existence of the file unless the bug is in NSData.
Based on this design and that I haven’t received this issue report before (I have had reports of delays, which is sometimes expected), my expectation in this case is that the issue lies elsewhere, but if you don’t have any leads on any peculiarities of the implementation that could result in an issue on the filesystem side, rather than polling, I would recommend just padding the action that you take after receiving that delegate callback using some type of sleep, by whatever number of milliseconds gives you consistent results. It’s likely to be a small number. If you don’t want to pad it generally, it would probably work fine to make one attempt and then if that fails make one time-padded attempt.