Thanks for the speedy response Kevin. Our app is a workplace app so I don't think users will thank us for adding to their contacts sadly. Also users aren't expected to be in the contacts so we would like LCK handle to behave as it does on CallKit. Can you share whether this is likely to be fixed in an upcoming release and we can make a call on whether to port out working/tested solution from LCK to CallKit. We also need the benefits of this working in china so would appreciate if we can find a way without managing two solutions.

Update: more testing since posting (iPhone 15 Pro, iOS 27.0.1, FB24933340). 1. The production configuration behaves the same. The repro above lists all three kinds in supportedHandleTypes. With [.generic] only (what we ship), value is still shown on the ring, the banner and in Recents. 2. Donation is ruled out for later calls too. After a successful donation (id in personHandle and customIdentifier, name in displayName), ringing the same handle again still shows the id. Putting the name in value and donating the id doesn't help either: the UI reads correctly, but a Recents redial returns the name and ignores the donated person and its customIdentifier. 3. A redial carries nothing else to map back from. In scene(_:continue:), both when the app is running and from a cold launch, the INStartCallIntent has only the contact's personHandle.value (type unknown) and display name. callRecordToCallBack, callRecordFilter, customIdentifier and contactIdentifier are all nil, and the intent and interaction identifiers are new on every tap. There's no conversation UUID, so whatever is in value is the only way back to the person. 4. callservicesd's name lookup never checks displayName. While reporting the call it logs: Finding the appropriate localized name to use for handles - handle can't/shouldn't be formatted as a phone number, so using the unmodified destination ID Received result from SGSuggestionsService: result (null) Suggestions: No suggested name found for '<private>' SNAP Suggestions: Hiding suggested nickname to prevent phishing. (isDomestic = 0, handleType = 1) That looks like Contacts, then Suggestions, then the raw value, with suggested names deliberately hidden for generic handles. That would explain both the ignored displayName and why donation doesn't help. Revised questions: Is displayName meant to be shown for .generic handles, or only as a fallback for .phoneNumber and .emailAddress handles that don't match a contact? If LiveCommunicationKit can't show a name while keeping a stable identifier, is CallKit (with localizedCallerName) the recommended path outside mainland China, keeping LiveCommunicationKit only where CallKit isn't available?

So after some investigation. I found having the async setup() function caused this behaviour to prevent retries. When moving to the synchronous setup function I no longer get issue. The problem being I need to do async code in my setup... If I move my code to the following, test repetitions now work and I see no such errors override func setUp() { super.setUp() continueAfterFailure = false // setup async seems to prevent test repetitions from working let exp = expectation(description: "setup") Task { try await setupWebApp(router: router) exp.fulfill() } wait(for: [exp], timeout: 10) }

I’m seeing the same behaviour and it’s causing my test repetition mode to not fire and thus it doesn’t re-run tests