Sandbox restriction message caused by differing Application Identifier Prefix and Team Identifier in an extension?

I'm working on an out-sourced application for a company and when a version of it built using ids and provisioning profiles from my Apple account it runs without problems.

However when it is built and run using the company's ids and provisioning profiles I am seeing an issue with it.

What is happening is when a notification service extension uses a call extension then the OS logs:

doQueryCallExtensionStatusWithDispatchGroup() COMPLETED WITH ERROR: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.CallKit.CallDirectory was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo=
NSDebugDescription=The connection to service named com.apple.CallKit.CallDirectory was invalidated: failed at lookup with error 159 - Sandbox restriction.

I noticed that in the company's provising profile for the notification service extension the app identier prefix is different from the team identifer. In my own provisioning profile the app identifier prefix and team identifer are the same. Could it be the case that this difference in identifiers within the provisioning profile is leading to the sandbox error message?

Attached is the notification service extension provisioning profle provided to me by the company (converted to a .plist for readability)

Up vote post of mungbeans Down vote post of mungbeans
5.7k views
Posted by
mungbeans
Reply
Add a Comment

Accepted Reply

The issue here is actually this entitlement:

com.apple.developer.usernotifications.filtering

Because that entitlement can "hide" notifications, it's sandbox profile is actually more restrictive than the standard NSE sandbox. That's what's preventing access to CXCallDirectoryManager, not the App ID properties. I suspect it worked in development configuration because you didn't use the entitlement, so you never saw the issue.

-Kevin Elliott DTS Engineer, CoreOS/Hardware

Posted by
DTS Engineer
Up vote reply of DTS Engineer Down vote reply of DTS Engineer
Post marked as solved

  • Hello, yes thats correct the filtering entitlement wasn't used in my profile (as I don't have it).

    Is there anything that can be done regarding this such that the notification service extension can still continue to filter but can also use the call extension?

    —
    mungbeans
Add a Comment

Replies

The issue here is actually this entitlement:

com.apple.developer.usernotifications.filtering

Because that entitlement can "hide" notifications, it's sandbox profile is actually more restrictive than the standard NSE sandbox. That's what's preventing access to CXCallDirectoryManager, not the App ID properties. I suspect it worked in development configuration because you didn't use the entitlement, so you never saw the issue.

-Kevin Elliott DTS Engineer, CoreOS/Hardware

Posted by
DTS Engineer
Up vote reply of DTS Engineer Down vote reply of DTS Engineer
Post marked as solved

  • Hello, yes thats correct the filtering entitlement wasn't used in my profile (as I don't have it).

    Is there anything that can be done regarding this such that the notification service extension can still continue to filter but can also use the call extension?

    —
    mungbeans
Add a Comment

I got the same error before I added the WeatherKit to the project.

Posted by
perbrondum
Up vote reply of perbrondum Down vote reply of perbrondum
Add a Comment