Inquiry regarding issues with the CXSetTranslatingCallAction action

Question

Created 1w

Replies 1

Boosts 0

Participants 2

We are currently verifying the functionality of CXSetTranslatingCallAction. We tested its implementation in a VoIP app—using Apple's Translate app by default—and confirmed that it works correctly in some instances. However, we have encountered an issue where, under certain conditions, the real-time translation feature becomes unavailable until the device is rebooted.

The issue manifests as follows:

When the real-time translation feature is enabled in CallKit, a beep sounds accompanied by the announcement "Starting translation," but the translation fails to proceed and terminates immediately. This behavior persists upon repeated attempts.
Restarting the app does not resolve the issue; once this occurs, the feature remains unusable until the device itself is rebooted.

Since the feature works normally after a device reboot, it does not appear to be a fundamental implementation error; I would like to investigate the root cause of this behavior. What information or steps are required to investigate this?

I conducted the test using an iPhone 16 Pro running OS version 26.5. It is the same for both CallKit and LCK.

Answer 1

DTS Engineer OP

Apple

5d

However, we have encountered an issue where, under certain conditions, the real-time translation feature becomes unavailable until the device is rebooted.

A few questions:

Once it breaks, does the failure only affect your app or does translation fail in other apps, particularly Phone.app?
When you say you "restart your app", did you specifically force quit and relaunch your app?

Since the feature works normally after a device reboot, it does not appear to be a fundamental implementation error; I would like to investigate the root cause of this behavior. What information or steps are required to investigate this?

The basic process here is to:

Start with as minimally configured device as possible. Ideally, this is a dedicated test device that ONLY has your app installed, but at minimum, you should reboot the device and only interact with the specific app you're testing.
Install the "Phone (General)" profile. This will unredact most call-related logging, which makes it easier to follow exactly what's happening.
Reproduce the issue under as controlled conditions as possible. Ideally, that's simply slow, direct testing, but, if necessary, you can proceed with normal testing and simply wait for the problem to happen.
Once the problem starts, reproduce the problem a few times. Take notes about what you did and when you did it, as well as noting the time anything happened.
When you've finished testing, leave the device idle for a few minutes, then trigger and collect a sysdiagnose using the instructions in the profile installation guide.
File a bug, upload your sysdiagnose and testing notes to that bug, then post the bug number back here.

In terms of investigating this yourself, the basic process is to open up the console archive in the sysdiagnose, then see if you can determine what happened based on what we logged. There isn't really any easy way to summarize that process, but Quinn's "Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem" is a decent starting point.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware