ICloud Ubiquity Container works in app, but I'm unable to expose/publish App folder on iDrive. Some say 'wait a day or two' for it to resolve itself

Question

The Time Consuming Nightmare:

I believe I've been meticulous and done everything right in terms adding iCloud capabilities and creating an app iCloud container, wherein my goal is to give have an app-specific folder visible and accessible on my iDrive.

Yet, after hours of dinking around with it, I still can't get the app's "ubiquity container" to appear on iDrive. I've checked the configuration many times and everything looks perfect. I've read everything I can find. Some people say they've seen issues like this resolve after a day or two, when it spontaneously started working.

But that's a real ding to my development schedule. Really can't be sitting around twiddling my thumbs waiting on a guessing game that may not pay off, only to potentially wind-up back at the drawing board after two wasted days, just to learn one data point - that waiting 2 days didn't work.

Overall, iOS App's iCloud configuration is functional:

My app is able to create a directory hierarchy, and create some files in the container, and everything is consistent and behaves as expected.

While the folder (container) isn't visible on the iDrive, the data I've been creating and working with in my iPhone, my Mac is secretly maintaining an iCloud mirror of it here:

~/library/Mobile\ Documents/iCloud~com~MyDomain~MyApp

The data written by my iOS app into the directories of the container, are kept hidden by the ICloud infrastructure, at least on the Mac side (which adds '.' as a prefix to the filename, and '.icloud' as a suffix). So each file is hidden to people doing a simple 'ls' from the command line on macOS, but everything works inside the iOS app.

My configuration:

@matt documented the standard configuration very well in this answer.

• I've ensured it all looks like that.

Note: The iCloud container identifier appears twice in the entitlements file, and all that is edited/managed automatically when the iCloud capability is added or removed or modified in the XCode App's target's Signing and Capabilities tab, configuration screen. AFAICT there's no need, at least in XCode 14.3 to manually edit the entitlements file.

• The Bundle ID is correct.

• The following are showing up on the Apple Developer's site, and look correct and match the App's configuration in XCode (and the plist and entitlements file):

• • Development Certificate
• • App ID
• • Provisioning profile

• ICloud container identifier = "iCloud." + App ID

• "/Documents" appended to ubiquity container URL (my dir tree is beneath that).

• I've bumped the bundle version and build #'s many times throughout the process but it doesn't seem to help.

What might be going on:

Since so much does work, I believe I've nailed most if not all of the iCloud configuration steps.

I'm becoming suspicious this is a bug on Apple's side. That it is a a vestigial effect of me changing the container name. Theoretically I should be able to change the container, because on the Apple Developer site, in the App ID capabilities iCloud configuration section, you can manage and edit the iCloud container list.

But I've read a report from a user who says that if the provisioning profile used a previous app container name, publishing a new container won't work for that provisioning profile.

And this app used to have a different name, different provisioning profile and an iCloud container was created and the folder successfully published on iDrive, under the old iCloud container identifier.

What may have been the problem in my case:

After renaming the app, and corresponding profile and identifiers, I built the app and launched it, but unfortunately I'd forgotten to update the container under the NSUbiquitousContainers key in Info.plist. So I inadvertently was trying publish the the old container id whereas my app was configured with a newer container name. They were mismatched in other words.

I wonder if that polluted the iCloud for bundle ID or provisioning profile? But after fixing Info.plist, why wouldn't that resolve it after bumping the bundle version and build'#s?

Answer 1

How it all got FUBAR:

Moral of the story: You can get your iCloud configuration into a broken state, where the iCloud infrastructure will not publish your app folder, even after you correct the configuration in the ways you can visually check.

The solution seems to be that you need to re-provision iCloud and the app, at least to some extent. I will show what worked for me.

But first, you may wonder, what kind of misconfiguration may keep iCloud from playing nicely with your container?

In my case, I think it was either because:

(A) I changed the name of the iCloud container (e.g. created a new container identifier), and then tried to use the new container identifier with the a Bundle ID (and provisioning profile?) I'd published another container identifier with previously...

--or--

(B) Because there was a temporary mismatch between the iCloud container name I'd listed in entitlements & App Signing and Capabilities tab, and the container name I listed in Info.plist (to inform iCloud that the container should be published (e.g. app folder visible on iDrive)).

And if either A or B are true, I assume the 'botched container state' scenario could possibly occur through other kinds of typos or configuration conflicts while provisioning iCloud for the app, leading non-recoverable problems even after the configuration appears to be corrected by the developer through visually inspecting everything about the configuration.

This last assumption is based on the horror stories on the 'Net that I've see regarding the iCloud container not appearing no matter what people do.

Desperate Times Call for Desperate Measures:

So I made the difficult decision to re-bundle, re-provision and re-entitle and re-do the capabilities of my app. It turned out to be much less painful than I presumed it would be, and a good education about setting App parameters with Apple and the App Store. It was certainly a lot less painful than spinning my wheels for hours in futility looking for a needle in a haystack in the configuration.

Thus, I'm not sure I really needed to do all of the following things, but it did resolve the problem quickly.

Cut to the Chase:

First I decided to create a new bundle ID. I was able to easily choose a good sensible alternative bundle name, after reading up about *exactly* what Bundle IDs are, how they're used, why the naming conventions are why they are, and what you can be flexible about. The main thing about changing your app's Bundle ID is that you must do it *before* you release your app to the App Store because it can't be changed later for that app, even if you sell your company or the app source to someone else.

This is what I re-configured (note: I unchecked "Automatically manage signing" in Xcode, because after getting all this stuff created on the Apple Developer site (and understanding it), it's very easy to just pick what you configured on the Developer Site inside Xcode):

1. Created a new bundle ID (in Xcode, app project's target configuration screen... just typed it into the text field carefully)

2. Created a new App ID (on the Apple Development site)

3. Created a new provisioning profile (on the Apple Development site)

4. Created a new ubiquity container identifier (on the Apple Development Site)

5. Edited Info.plist and ensured that the iCloud container name I was trying to publish by setting NSUbiquitousContainerIsDocumentScopePublic key to YES (true) in the iCloud container's dictionary, within the NSUbiquitousContainers key's dictionary, matched the iCloud container identifier in the provisioning profile and the app's entitlement file.

While I did most of it on the Apple Developer site, I might have been able to do it more directly from Xcode as Apple has been streamlining the process over the years. It may also be worth noting that I had some container identifiers I didn't want to appear in selection lists or ever see again. I was able to address that by clicking the "CloudKit Console" button in Xcode, which takes you to a web site. Poking on that CloudKit management site, you should quickly stumble on a mechanism that lets you to hide or make invisible iCloud identifiers you aren't using.

After doing all of the above, I bumped the app bundle version and build, built and ran the app.

Voilà!

Finally, the ubiquity container was published. Not only that, but it appeared in the Files app virtually immediately after running the app, wherein my app creates directories and files in the container (starting with creating the all important /Documents folder that becomes the root of your apps directory tree!). Another area where I'm not sure I needed to do all of that just to see the App container appear the iDrive. See the original question for more about what my app does to populate the container.