NSFileProviderReplicatedExtension: uploading after completion handler

Question

vry OP

Created 1d

Replies 1

Boosts 0

Participants 2

Hello,

I'm implementing an NSFileProviderReplicatedExtension (iOS 26 and macOS 26) and would like to validate my approach.

What I do

To make my uploads efficient I batch them: instead of uploading file-by-file inside each createItem / modifyItem, I ingest all local changes into my extension's local state quickly and upload the content blobs in the background in batches.

Concretely, for both createItem and modifyItem:

I persist the item to my local store, write its content blob to a local cache, and schedule the upload in my internal queue.
I call the completionHandler right away before uploading the item, returning the NSFileProviderItem with isUploaded = false.
Once the upload succeeds, I flip the item to isUploaded = true and call signalEnumerator(for: .workingSet) so the change is delivered through the working-set enumerateChanges.

This works in my testing, but I'm unsure it is the intended approach, and I have the following questions.

Question 1 — Honoring the Progress object

I call the completion handler early (step 2) and run the upload afterwards. The convenient part for my batched uploads is that I don't seem to need to honor the returned Progress at all — I never report into it and I just drop it, yet in my testing the upload still completes. I'd like to confirm two things:

(a) Can I ignore the Progress? I'd like to never report into the returned Progress and simply drop it: I coalesce uploads into batches drained from a persisted queue, so I can't map one Progress to one upload, and retaining thousands of them is itself a cost. Is that allowed? What makes me unsure is that the docs read a little asymmetrically — for createItem the progress is "presented in the user interface until the completion handler is called", whereas for modifyItem it is "expected to include the upload progress … even if the provider chose to call the completion handler before the upload finishes".

(b) If I ignore it, am I still granted execution time to finish the upload? This is what worries me, because the "Execution time" clause couples the two: the system "will grant enough time … to upload the file" but "will interrupt the call if it stops making progress." If I report no progress, does the system stop granting runtime?

Question 2 — Upload pipeline depth

When calling the completion handler before finishing the upload, both createItem and modifyItem are no longer gated by the NSExtensionFileProviderUploadPipelineDepth limit, and I can have thousands of items pending upload. This is crucial for my approach. Is this behaviour correct and intended?

Answer 1

Engineer OP

Apple

1d

It won't be possible to implement this approach on iOS. The system only runs your app extension when there are pending completion handlers from system calls into your extension. And there are timeouts, so you aren't able to hold completion handlers indefinitely (see the headers, there is documentation about the timeouts).

In general, the design of NSFileProviderReplicatedExtension strongly prefers you to scope uploads to the lifetime of the createItem/modifyItem calls. I do not recommend setting the isUploaded flag manually - allow the system to manage this state via the result of createItem/modifyItem calls.