Home/ Questions/Q 7883417
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T04:31:37+00:00

I’m using UIManagedDocument s to manage my files in iCloud. After setting up the

  • 0

I’m using UIManagedDocuments to manage my files in iCloud. After setting up the NSMetadataQuery like so:

iCloudQuery = [[NSMetadataQuery alloc] init];
[iCloudQuery setSearchScopes:
    [NSArray arrayWithObject:NSMetadataQueryUbiquitousDocumentsScope]];
[iCloudQuery setPredicate:
    [NSPredicate predicateWithFormat:@"%K like %@", NSMetadataItemFSNameKey, @"DocumentMetadata.plist"]];

I’m encountering a curious problem – when my documents are named without a file extension (for example @"NewDocument2") or a public extension like .txt, the metadata query correctly finds the DocumentMetadata.plist file. However, when using my custom file extension, the query never finds anything… not when the query starts, nor when I add a new document.

It seems to me that the query is probably seeing my document with its custom file extension, is not realising that it is, in fact, a directory (a file package at any rate), and so does not look inside to find the DocumentMetadata.plist file. However, I have declared my custom UTI in the app’s info.plist.

Perhaps I have declared my UTI wrongly? I followed Apple’s guidelines (in the Document-Based App Programming Guide for iOS and Uniform Type Identifiers Overview) in creating it, but it seems like something is wrong.

Edit: Under ‘Exported UTIs’ in the info.plist, my type is set to conform to ‘com.apple.package’.

Edit:
I’m still struggling with this issue. I’m working around it for now by not using a file extension.

When using the custom file extension, I’m processing the iCloud metadata query results and the DocumentMetadata.plist file is definitely inside the file package, but the metadata query can’t see it. When enumerating the query results, the following is printed to the log:

<iCloud Container URL>/Documents/
<iCloud Container URL>/Documents/New%20Document.spdoc/
<iCloud Container URL>/Documents/New%20Document.spdoc/DocumentMetadata.plist
<iCloud Container URL>/Documents/New%20Document.spdoc/StoreContent.nosync/
<iCloud Container URL>/Documents/New%20Document.spdoc/StoreContent.nosync/(A%20Document%20Being%20Saved%20By%20<AppName>%202)/
<iCloud Container URL>/Documents/New%20Document.spdoc/StoreContent.nosync/(A%20Document%20Being%20Saved%20By%20<AppName>)/
<iCloud Container URL>/Documents/New%20Document.spdoc/StoreContent.nosync/.persistentStore_SUPPORT/
<iCloud Container URL>/Documents/New%20Document.spdoc/StoreContent.nosync/.persistentStore_SUPPORT/_EXTERNAL_DATA/
<iCloud Container URL>/Documents/New%20Document.spdoc/StoreContent.nosync/persistentStore

(There are also a bunch of files in a “CoreDataLogs” directory, however I didn’t show them here for brevity).

I can only think that this problem is something to do with incorrectly creating my file package UTI. Has anybody else successfully used custom file packages with iCloud? Is this a bug?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is by design.

    The API works this way for Spotlight as well. It shouldn’t descend into package documents because the contents of those documents are basically private. With iCloud, this doesn’t make all that much sense, but I suspect that they won’t be changing it. It wouldn’t make sense for the API to work in two different ways depending on where it’s being used.

    I guess this is a historic thing — on Mac you can implement a Spotlight importer to handle your custom document type. On iOS, I don’t think this is possible yet (correct me if I’m wrong). So for now, you just have to work around this ‘feature’ of the API.

    You can search for the document instead and then just get the metadata from there. Otherwise, chaining the extension as you have done should work.

    • 0