User Profile

In my opinion those changes are a step back in the user experience. So far, the CallKit was greatly above its competitiors, namely android since it is highly fractured and their VoIP call handling is messy and causes a lot of bugs. However, I'm affraid these changes will cause situations where the user may think their application is bugged when in fact it is caused by API changes."If the user is particularly fast at tapping the accept call button, or if the network conditions are poor or there is otherwise a lot of latency, then you should simply wait until the necessary handshakes are complete before calling fulfill on the CXAnswerCallAction. To the user, it simply appears that the call is taking some time to connect, which is a common experience even with standard phone calls"This is true IF the phone is locked. However, since every application has to implement a UI for the incoming calls (as the CallKit/native UI only remains active in lock state) a situation may occour where a user is using the phone, receives a call, picks the call up when in fact the VoIP call is not even connected, which will possibly cause the user to think it was a "ghost call", since nothing happens except (probably) the VoIP application opens up to the normal screen until the actual call arrives and triggers the incoming call UI.I know this may seem an extreme case but in several places, ex: in Portugal, where there is not 4G cover everywhere and some even cause a fallback to GSM, this may me more common than the standard user experience.I believe these changes only make sense IF the CallKit also fully enabled the native UI either for incoming or outgoing calls which would not lead to UI transitions and hide the fact that we are notifying the user for a call that might not have arrived yet.