当设备在线时进行更改时，iCloud 守护程序似乎会在几秒钟内将更改上传到 iCloud 服务器。但是，我注意到当本地 iCloud 容器离线完成更改然后设备上线时，iCloud 守护程序在上传更改时不一致。重新建立连接后，在将更改上传到 iCloud 服务器并被其他设备检测到之前，我会遇到几秒到 30 分钟的延迟。这是正常的吗？有什么方法可以告诉 iCloud 守护进程强制上传？
我只使用 UIDocument 的子类（创建、打开、更改、将文件保存到 iCloud 容器）和 NSMetadataQuery 来检测更改。重新上线后，键 NSURLUbiquitousItemIsUploadedKey 的文件状态为 false 并且可以长时间保持这种状态。我尝试重新保存文件以尝试强制 iCloud 守护程序上传更改，但它似乎没有帮助。
我知道这是一个老问题，但我一直在忍受这个问题很长一段时间才发现为什么，所以如果其他人遇到这个线程，这里是......
如果你使用 NSURL 的getResourceValue:forKey:error:方法，我猜你是因为你提到 using NSURLUbiquitousItemIsUploadedKey，你可以看到文件显然没有上传，因为 NSURL在非常特殊的情况下缓存了资源值。
主要文档中没有提到任何地方，但是如果您深入研究 NSURL.h，您会发现以下措辞奇怪的 gem，值得完整阅读以了解其含义：
资源值缓存的行为在 NSURL 和 CFURL API 之间略有不同。
当从主线程使用获取、设置或使用缓存资源值的 NSURL 方法时，由 URL 缓存的资源值（作为临时属性添加的除外）在下一次主线程的 run loop 运行时失效。
CFURL 函数不会自动清除 URL 缓存的任何资源值。客户端可以完全控制缓存的生命周期。如果您使用 CFURL API，则必须使用 CFURLClearResourcePropertyCacheForKey 或 CFURLClearResourcePropertyCache 来清除缓存的资源值。
返回由给定资源键标识的资源值。此方法首先检查 URL 对象是否已经缓存了资源值。如果是这样，它将缓存的资源值返回给调用者。如果没有，则该方法从后备存储同步获取资源值，将资源值添加到 URL 对象的缓存中，并将资源值返回给调用者。资源值的类型因资源属性而异（请参阅资源键定义）。如果此方法返回 YES 并且 value 填充为 nil，则表示资源属性不适用于指定的资源，并且在确定资源属性不可用时没有发生错误。如果此方法返回 NO，则填充可选错误。此方法目前仅适用于文件系统资源的 URL。
基本上，如果您在主线程以外的任何线程上使用 getResourceValue: ，它将缓存第一个结果，并一次又一次地将相同的结果返回给您。直觉，嗯？您认为会在文档中以大粗体标记的那种东西，而不是埋在标题中......
对我来说，这表现为设备偶尔会“卡住”，因为他们认为某个特定的 URL 没有下载，而实际上它在很久以前就已经下载了。重新启动应用程序通常似乎可以解决问题。强制getResourceValue:forKey:error:只在主线程上运行终于一举摆脱了这个小问题。