Is there a way to prevent the app from coming to the foreground when accepting a call with a banner-type call kit in a VoIP app?

Question

Created 12h

Replies 1

Boosts 0

Participants 2

I'm developing a VoIP app. Currently, I'm using CallKit to control call acceptance, and end-of-call processing. When a call comes in while using the phone, CallKit appears as a banner at the top of the screen.

When I click "Accept" on the banner, the app opens and the call is received. (For OEMs, clicking the "Accept" button in the banner will accept the call as is.)

The reason this feature is needed is, for example, when a call comes in as a banner call while using a navigation app, accepting the call causes the navigation app to go to the back and the VoIP app to come to the foreground, causing inconvenience to customers. This needs to be improved.

Please advise.

Answered by DTS Engineer in 870078022

I'm developing a VoIP app. Currently, I'm using CallKit to control call acceptance and end-of-call processing. When a call comes in while using the phone, CallKit appears as a banner at the top of the screen.

When I click "Accept" on the banner, the app opens and the call is received. (For OEMs, clicking the "Accept" button in the banner will accept the call as is.)

Is there a way to prevent the app from coming to the foreground when accepting a call with a banner-type call kit in a VoIP app?

No, not currently.

When I click "Accept" on the banner, the app opens and the call is received.

Yes. This has been how CallKit worked since the framework was introduced in iOS 10, where it inherited the existing iOS behavior. The call banner was introduced in iOS 14, but the behavior of CallKit app was not changed. I believe that decision was made to avoid disrupting existing apps since past experience had shown VoIP developers to be resistant to nearly any change.

I'll also note that CallKit opening into the calling app was actually a change specifically driven by developer feedback when CallKit was introduced in iOS 10. When the framework shipped in the initial beta, it used EXACTLY the same call UI flow as Phone.app, but developer feedback during the beta caused us to dismiss the system UI in favor of foregrounding the app so it could present its own UI.

(For OEMs, clicking the "Accept" button in the banner will accept the call as is.)

Note that the banner presentation itself is actually controlled by Phone.app settings, where you can also toggle back to the full screen UI.

The reason this feature is needed is, for example, when a call comes in as a banner call while using a navigation app, accepting the call causes the navigation app to go to the back and the VoIP app to come to the foreground, causing inconvenience to customers. This needs to be improved.

If you haven't already, please file a bug requesting this and post the bug number back here. However, I do need to note that the current behavior has been in place for several years and we've received very little developer feedback about it. It's possible we might provide an API to let an app opt into the new behavior, but it's very unlikely we'll change the default behavior. As I noted above, our experience has been that most VoIP app developers are resistant to system behavior changes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

1h

Recommended

I'm developing a VoIP app. Currently, I'm using CallKit to control call acceptance and end-of-call processing. When a call comes in while using the phone, CallKit appears as a banner at the top of the screen.

When I click "Accept" on the banner, the app opens and the call is received. (For OEMs, clicking the "Accept" button in the banner will accept the call as is.)

Is there a way to prevent the app from coming to the foreground when accepting a call with a banner-type call kit in a VoIP app?

No, not currently.

When I click "Accept" on the banner, the app opens and the call is received.

Yes. This has been how CallKit worked since the framework was introduced in iOS 10, where it inherited the existing iOS behavior. The call banner was introduced in iOS 14, but the behavior of CallKit app was not changed. I believe that decision was made to avoid disrupting existing apps since past experience had shown VoIP developers to be resistant to nearly any change.

I'll also note that CallKit opening into the calling app was actually a change specifically driven by developer feedback when CallKit was introduced in iOS 10. When the framework shipped in the initial beta, it used EXACTLY the same call UI flow as Phone.app, but developer feedback during the beta caused us to dismiss the system UI in favor of foregrounding the app so it could present its own UI.

(For OEMs, clicking the "Accept" button in the banner will accept the call as is.)

Note that the banner presentation itself is actually controlled by Phone.app settings, where you can also toggle back to the full screen UI.

The reason this feature is needed is, for example, when a call comes in as a banner call while using a navigation app, accepting the call causes the navigation app to go to the back and the VoIP app to come to the foreground, causing inconvenience to customers. This needs to be improved.

If you haven't already, please file a bug requesting this and post the bug number back here. However, I do need to note that the current behavior has been in place for several years and we've received very little developer feedback about it. It's possible we might provide an API to let an app opt into the new behavior, but it's very unlikely we'll change the default behavior. As I noted above, our experience has been that most VoIP app developers are resistant to system behavior changes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0