Getting FruitBasket File Provider Demo to run

tl;dr

I'm trying to get the FruitBasket demo to operate (Synchronizing files using file provider extensions | Apple Developer Documentation) on Sonoma 14.1.2. I'm probably being stupid about something but It doesn't work as I expect so would welcome any suggestions.

Details

  • I downloaded the FruitBasket demo code
  • I attempted to carefully follow the README and replace all instances of group.com.example.apple-samplecode.FruitBasket
  • I built and ran and created a domain

My new domain appears in the Finder side-bar. It appears as a directory in ~Library/CloudStorage/. But attempting to (e.g.) ls ~/Library/CloudStorage/* gives me an ETIMEDOUT error and the Finder says something similar.

Things that I observed:

  • once a domain exists, there is indeed a Provider executable running.
  • it never generates any log messages
  • attaching the Xcode debugger to it and setting some seemingly likely to be invoked breakpoints (e.g. Extension.Extension.enumerator) never hit the breakpoints.
  • my naïve take on the disassembly when pausing it suggests that it's waiting for incoming Mach messages. (That seemed sensible.)
  • FruitBasket starts with an error:
    Couldn't read values in CFPrefsPlistSource<0x6000039853b0> (Domain group.org.liqui.apple-samplecode.FruitBasket, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using     kCFPreferencesAnyUser with a container is only allowed for System Containers,  detaching from cfprefsd
    

Questions

  • Does the above error suggest that I have set the group value wrong somewhere?
  • Maybe Extension+Servicing.swift:21 defining the NSFileProviderServiceName("com.example.FruitService") is mismatched somewhere?

Replies

Indeed, per-above I was being stupid about something and have solved this problem. Learning:

  • based on value of keys like com.apple.security.application-groups, assorted state is written to ~/Library.
  • correcting a typo in a file like FruitBasket.entitlements results in there being both the new updated state in ~/Library and the old incorrect state
  • the fileproviderd appears to cache some of this state
  • and as a result: Provider registers itself under a new updated name for its XPC service end point while fileproviderd keeps on trying to connect to the original (incorrect) XPC service end point
  • deleting all the invalid state from ~/Library and restarting fileproviderd corrected the issue.