Wow, after almost 3.5 years since the original report, looks like iOS 26.4 finally fixed this crash. Took its sweet time 😅

+1 I’m surprised that such a critical bug hasn’t been fixed after so many years. We also get a lot of complaints from users.

When the extension sends a request to our backend server using the PIR encryption process, is the user's phone number visible to our server? No, that's the whole point of the protocol.

I can confirm this bug still exists in iOS 18.0. Call Directory extensions continue to show English names even when device is set to any non-English language. Also, if English localization is missing, the system displays a random localization instead. Still not fixed?

@glebfann Is your app on appstore ? do you use apple relay service ? @icallme Hey! Yes, our app is available on the App Store, so the Apple Relay Service is functioning for us. Did you have this problem ? As far as I recall, we only experienced one issue where at some point the feature stopped working in all environments, but it's working fine now. I'd recommend checking the logs in Console.app to get more detailed information about what's happening. You might also want to try using tcpdump to analyze the network traffic.

Thank you very much for your detailed response, Kevin. This information is helpful for our implementation. I have an additional question about our current observations. We launched our app in TestFlight to approximately 100 users, but in just 12-15 hours, our database grew to 11,000 unique evaluation keys with a request rate of ~0.5 RPS to our /key endpoint. This seems unusual given the 7-day TTL you mentioned. The rapid growth continues now. Do you have any insights on why this might be happening? While researching, I found a paper (https://arxiv.org/pdf/2406.06761) suggesting that privacy-preserving systems like this might generate fake requests for enhanced security. Could this explain our situation? If so, why would there be such a high volume of these requests? Thank you again for your assistance.

The issue was resolved by enabling HTTP/2 on our server. Although this requirement wasn't mentioned in any documentation 🤷‍♂️

We've recently noticed that around the same timeframe, there was a significant increase in requests from Apple to our OHTTP gateway configuration endpoint (/ohttp-configs). This leads us to hypothesize that Apple might have switched to an OHTTP scheme (even for dev version from XCode) and is attempting to fetch OHTTP configs from our gateway, and for some reason, the subsequent requests in the flow are not happening. Could this be related to the Live Caller ID issues we're experiencing? I've filed a separate feedback (FB16056172) with details about these OHTTP configuration endpoint requests. Would be grateful if you could confirm whether these events are connected.

@DTS Engineer Hello! Are there any updates on the issue?

Apple provides an official example service for Live Caller ID at live-caller-id-lookup-example. You can use this reference implementation to understand the required backend structure and test your client-side code. Additionally, comprehensive documentation is available at swiftpackageindex.

[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.

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

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 😕

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

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