The reasons why CallKit cannot be used are as follows: our call scenario involves the iPhone actively calling an electric vehicle, which is a one-sided call; the UI interface requires customization; and the main reason is that the application needs to be listed on the Apple Store in China, where legal policies do not permit it. How are you determining that failure rate? Have you ever directly reproduced it under controlled conditions or at least "seen" it occur? Do you have any user reports that provide any more detail or context? During the actual call process, when switching between iPhone, speaker, and Bluetooth earphones using AVRoutePickerView, if I continuously switch the route 10 times, it will inevitably fail 1 to 2 times. The code determines the success of the switch by listening to the "AVAudioSession.routeChangeNotification" notification. When a failure occurs, no logs can be captured, and the only indication is that the checkmark icon on the AVRoutePickerView UI reverts to the previous selection.

The application we developed allows iPhones to call devices running non-iOS operating systems, so CallKit cannot be used. The implementation relies on the .playAndRecord session to provide input and output capabilities. However, we have split this into two separate chains: a "pure recording engine" and a "pure playback engine," thereby avoiding the issue where the iOS full duplex engine locks the output path. This approach enables simultaneous recording and playback with switchable routing. When users use AVRoutePickerView to switch between the iPhone, speakers, and Bluetooth earphones, there is approximately a 20% chance of failure. In such cases, AVRoutePickerView reverts to the previous selection, and we do not receive any failure logs. Could you provide us with some suggestions?