1

While this works fine in the Simulator, on device, when my custom keyboard extension tries to open a UIDocument in the shared container written by the containing app, it fails to do so. The following is logged to the Console:

2019-05-10 15:39:09.640305-0700 TagManagerKeyboard[15249:1890026] [claims] 528516A6-B168-43EA-8AAF-B7B1754EE42E grantAccessClaim message failed: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.FileCoordination was invalidated." UserInfo={NSDebugDescription=The connection to service named com.apple.FileCoordination was invalidated.}
2019-05-10 15:39:09.640891-0700 TagManagerKeyboard[15249:1890026] A process invoked one of the -[NSFileCoordinator coordinate...] methods but filecoordinationd crashed. Returning an error.

The error reported to UIDocument.handleError(:userInteractionPermitted:) is not very helpful:

Error Domain=NSCocoaErrorDomain Code=256 "The file “MyFile” couldn’t be opened." UserInfo={NSURL=file:///private/var/mobile/Containers/Shared/AppGroup/3A486D56-F897-4B13-A09F-0B4183686E2C/MyFile}

I open the document in viewDidLoad() of my UIInputViewController subclass:

if let container = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.mycompany.MyApp")
{
    let containerPath = Path(container.path)
    let file = containerPath + "MyFile"
    self.doc = MyDocument(fileURL: file.url)
    debugLog("Extension doc at \(file)")
    self.doc.open
    { (inSuccess) in
        debugLog("Opened doc: \(inSuccess)")
        NotificationCenter.default.post(name: .dataUpdated, object: nil)
    }
}

This crash occurs 100% of the time. RequestsOpenAccess is YES in the Info.plist. And again, this works in the simulator. I also tried it on an iOS 9.5.3 iPad I have, and it has a similar crash.

Any ideas why it crashes on device?

Rick
  • 3,298
  • 3
  • 29
  • 47
  • I don't understand. That doesn't seem to be an Apple API. Where is this documented? – Rick May 11 '19 at 00:10
  • Sorry. It came from this https://stackoverflow.com/questions/32119938/how-to-test-if-allow-full-access-permission-is-granted-from-containing-app Which isn't a perfect solution. There is no api to explicitly check if full access has been granted. Do you actually get a crash, or simply an error to the error handler. If the latter then you just have to carry on as best you can after receiving the error. If you get an actual crash, what line does it crash on? – Paulw11 May 11 '19 at 00:17
  • Oh, I see. iOS doesn't prompt for giving full access, you just have to know to enable it in Settings. And there is no API to check, you just have to assume errors in using the shared container are due to this. – Rick May 11 '19 at 00:17
  • iOS reports that filecoordinationd crashed. Typical Apple error reporting, I guess. I can't present an alert from my keyboard extension to tell the user what to do, it'll have to be in my keyboard UI. – Rick May 11 '19 at 00:18
  • A message in the log isn't a crash in your app. If your app doesn't crash (stop running) then you can carry on without access to the tags file (use a fixed set of tags or whatever) – Paulw11 May 11 '19 at 00:19
  • I never said it was a crash in my app. I said filecoordinationd is crashing. Yes, I can carry on, but only to show that the user must allow full access. – Rick May 11 '19 at 00:23
  • Just be aware of clause 4.4.1 https://developer.apple.com/app-store/review/guidelines/#minimum-functionality – Paulw11 May 11 '19 at 00:26
  • Thanks. I'll have to take my chances, since the app is quite useless without access to data created by the user in the containing app. – Rick May 11 '19 at 00:28

1 Answers1

1

This happens because my keyboard did not have “Allow Full Access” to be set.

enter image description here

Rick
  • 3,298
  • 3
  • 29
  • 47