Hello! We're currently testing Live Caller ID implementation and noticed an issue with userIdentifier values in our database. Initially, we expected to have approximately 100 records (one per user), but the database grew to about 10,000 evaluationKey entries. Upon investigation, we discovered that the userIdentifier (extracted from "User-Identifier" header) for the same device remains constant throughout a day but changes after a few days. We store these evaluation keys using a composite key pattern "userIdentifier/configHash". All these entries have the same configHash but different userIdentifier values. This behavior leads to unnecessary database growth as new entries are created for the same users with different userIdentifier values. Could you please clarify: Is this the expected behavior for userIdentifier to change over time? If yes, is there a specific TTL (time-to-live) for userIdentifier? If this is not intended, could this be a potential iOS bug? This information would help us optimize our database storage and implement proper cleanup procedures. Thank you for your assistance!

Hello! What is the TTL for evaluation key(s) used in Live Caller ID feature on iOS client side? We would like to align our server-side key storage TTL with the iOS client implementation to optimize memory usage. Would really appreciate your help on this.

I've been testing the Live CallerID feature using the Apple-provided local server example - live-caller-id-lookup-example. I've been running a local server with tunneling using ngrok for the initial setup. Everything was working perfectly with the following setup: @main final class CallerID: LiveCallerIDLookupProtocol { var context: LiveCallerIDLookupExtensionContext { LiveCallerIDLookupExtensionContext( serviceURL: URL(string: "https://example-tunnel.ngrok.io")!, tokenIssuerURL: URL(string: "https://example-tunnel.ngrok.io")!, userTierToken: Data(base64Encoded: "BBBB")! ) } } However, after I updated the URLs to the production ones, I encountered an issue: @main struct CallerID: LiveCallerIDLookupProtocol { var context: LiveCallerIDLookupExtensionContext { LiveCallerIDLookupExtensionContext( serviceURL: URL(string: "https://example.net/")!, tokenIssuerURL: URL(string: "https://example/issue")!, userTierToken: Data(base64Encoded: "BBBB")! ) } } The problem is that during calls or when updating PIR parameters, the application still attempts to connect to the initial ngrok tunnel URLs instead of using the new production URLs. I can confirm this because the logs on my local server show incoming requests, indicating that the application is still referencing the old ngrok tunnel URLs. Steps I’ve taken to resolve the issue include: Deleting and reinstalling the application. Using reset(forExtensionWithIdentifier:) Unfortunately, these attempts have not been successful. I even extracted the binary of the app and extension to inspect the strings, confirming that the correct production URLs are present. The server was started with the following command: PIRService --hostname 127.0.0.1 service-config.json Could this be some sort of caching bug on the iOS side, or am I missing something?

I'm reaching out to see if anyone else is experiencing issues with the Live Caller ID feature on iOS. We recently encountered a problem where the feature stopped working entirely. Here's a brief overview of the situation: We were monitoring test traffic on our backend and noticed everything came to a halt around 1:00 AM UTC on November 15th. After this time, any attempts to reach our backend through calls failed completely. I tested this across multiple devices running iOS 18.2 and iOS 18.0. I used both TestFlight builds and development builds via Xcode, which should communicate directly with our backend. I experienced the problem on our main application as well as a dedicated test app. To troubleshoot further, I even set up a local server on localhost and tried directing requests there, but the requests did not reach the local server when a call was received. Further debugging in Console.app revealed the following error: identity request returned error: Error Domain=com.apple.CipherML Code=400 "Error Domain=com.apple.CipherML Code=401 "Unable to request data by keywords batch: failed to fetch token issuer directory" However, when I manually tried to hit our server endpoint using curl, the request successfully reached the server: curl https://our_server/something hb_method=GET hb_uri=/something [Hummingbird] Request -- log on backend This suggests that while our backend is responsive, the requests from the iOS client side are simply not being initiated.

I’m encountering a problem with my iOS app with new Live Caller ID extension when uploading to TestFlight. Here’s what's happening: When I try to upload the app to TestFlight without the NSExtensionPrincipalClass, I get the following error: Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found in extension Info.plist for foo.app/PlugIns/bar.appex However, if I include the NSExtensionPrincipalClass in the Info.plist of my extension, the app fails to launch on both the dev build and through TestFlight. The error message I receive is: bar.appex with id <bundle_id> defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.live-lookup Has anyone experienced a similar issue? How to fix it?

I've noticed delays with the Live Caller ID Lookup feature, taking around 3 to 6 seconds to complete, even on repeated lookups. This seems odd since there's no server activity during these repeats, suggesting the information might be coming from a cache. Most of the time, it’s fast, but there are cases when it's unexpectedly slow, and I haven’t quite figured out the pattern yet. Is anyone else seeing this issue? FB number FB15372765 - with sysdiagnose and video demonstrating the delay.

Since upgrading to iOS 18, an issue has been observed where blocked incoming calls display "(null)" instead of the actual application name. At the time the calls defined by the same application contain the name of the application correctly.