Hello @Engineer! Thank you for looking into this issue. The FB number for the bug report is FB15272318

I am seeing the same issue with our users. Have you figured out what causes it?

I have resolved the issue, and it all comes down to where the extension is placed within the app bundle. The problem arose when the extension was located in the PlugIns and Foundation extensions directory. If you embed Live Caller ID .appex in ExtensionKit extensions, i.e. /Extensions directory instead of /PlugIns in bundle, then the problem goes away - this allows you to remove the NSExtensionPrincipalClass/NSExtension entries from the extension's Info.plist file. But it's unclear whether this behavior is an oversight on Apple's validation side or if it's intentional. The documentation does not provide any clarity on this matter, which makes it somewhat puzzling 😕

@DTS Engineer Hello! Here is a feedback with all the information and sysdiagnose - FB15878121

[quote='815142022, DTS Engineer, /thread/768857?answerId=815142022#815142022'] Clarifying things, is this still broken or did it start working again? [/quote] Yes, the issue is still ongoing. The situation is quite peculiar - while we can see some requests reaching our server (likely from beta users, rare cases), they are limited to only config and PrivacyPass-related endpoints. We don't see any actual data requests coming through. And development team has been unable to successfully make any requests reach the server through the phone calls. During my investigation in Console.app, I found some interesting logs indicating authentication errors with the token issuer directory: default 17:31:16.594584+0300 com.apple.CallKit.CallDirectory received Data useCase: <bundle_id>.identity default 17:31:16.594651+0300 com.apple.CallKit.CallDirectory sending action: fetch payload: ["extensionIdentifier": <bundle_id>, "identity_fetch_error": 400] And this one (I'm not sure if it's exactly relevant, but it looks like): [..., bundle id: <bundle_id>, url hash: <url_hash>, definite, attribution: developer] cancelled [... ip1<->ip2] Connected Path: satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, dns, uses wifi Privacy Stance: Proxied Duration: 0.116s, QUIC @0.068s took 0.001s bytes in/out: 2443/5082, packets in/out: 8/9, rtt: 0.045s, retransmitted bytes: 0, out-of-order bytes: 0 ecn packets sent/acked/marked/lost: 0/0/0/0 Notably, there's an interesting detail "Privacy Stance: Proxied". This leads to a hypothesis that all requests might be being proxied through Apple's Oblivious HTTP. However, the dev build was used here. I'm ready to provide any additional logs, data, or engage in any form of collaboration needed to help identify and resolve this issue as quickly as possible. Please let me know what other information would be helpful.