iOS app loses entry to the Paperwork folder contained in the iCloud ubiquity container

I’ve an iOS app that writes recordsdata to its iCloud ubiquity container. The container is laid out in Signing & Capabilities as iCloud.com.myappbusiness.myappid the place “com.myappbusiness.myappid” is the bundle identifier.
It really works more often than not however for some customers (lower than 1%) it stops working sooner or later, more than likely after any replace of my app. Gadget reboot or app reinstallation doesn’t assist.
What appears to assist is popping off iCloud for the app within the iOS Settings (at which level the app saves recordsdata to the machine regionally) after which turning it on once more.

I can’t replicate the problem and should depend on person suggestions. I’ve tried numerous fixes over the previous half a 12 months, added retries after timeout, error handlers, tracing, and many others. However the error at all times seems to somebody after one other app replace.

I’ve narrowed it right down to the three strains of code beneath that examine for the existence of the app iCloud container:

NSFileManager* fileManager = [[NSFileManager alloc] init];
NSURL* containerUrl = [[fileManager URLForUbiquityContainerIdentifier:nil] 
                      URLByAppendingPathComponent:@"Paperwork"];
BOOL doesExist = [fileManager fileExistsAtPath:containerUrl.path];

doesExist returns NO when the problem occurs. I.e. the app doesn’t see its container and it appears to be like prefer it doesn’t exist. The folder ought to exist as this occurs to long run customers which have used the app earlier than.
Relating to the containerUrl, I can see it within the log that I get from the affected customers and it’s the right path to the container, e.g. /non-public/var/cellular/Library/Cell Paperwork/iCloud~com~myappbusiness~myappid/Paperwork

I’ve tried the code above as it’s and in addition inside a file coordinator handler:

[[[NSFileCoordinator alloc] initWithFilePresenter:nil] coordinateWritingItemAtURL:targetFileUrl
                      choices:NSFileCoordinatorWritingForReplacing error:&error
    byAccessor:^(NSURL * _Nonnull newURL) { ... the code right here ... }];

I’ve run out of concepts what else to strive. Is there something clearly fallacious with this strategy or am I lacking one thing within the code right here? Is that this a permission problem? Do I must recreate the Paperwork folder if it isn’t accessible?