I am implementing flutter_callkit_incoming for handling call notifications in my Flutter app. However, I am facing an issue where VoIP push notifications are not consistently received when the app is in the background or terminated.
According to Apple’s documentation: "On iOS 13.0 and later, if you fail to report a call to CallKit, the system will terminate your app. Repeatedly failing to report calls may cause the system to stop delivering any more VoIP push notifications to your app."
I have followed the official installation guide: flutter_callkit_incoming installation and implemented all necessary configurations. However, VoIP notifications sometimes get lost and do not deliver reliably.
Here is the payload I am using:
{ "notification": { "title": "New Alert", "body": "@H is calling you..." }, "android": { "notification": { "channelId": "channel_id", "sound": "sound_name.mp3" } }, "apns": { "payload": { "aps": {} } }, "data": { "title": "New Call", "body": "@H is calling you...", "notificationType": "CALL", "type": "NOTIFICATION", "sound": "sound_name" }, "token": "token" }
I expect the call notification to appear even when the app is in the background or killed state. Has anyone encountered this issue and found a solution? Any insights would be greatly appreciated.
I expect the call notification to appear even when the app is in the background or killed state. Has anyone encountered this issue and found a solution? Any insights would be greatly appreciated.
I have worked with many, many developers reporting issues like this and ALL of those issues have been caused be one of two factors:
-
The push did not in fact reach the device because the device did not have a network connection with the push server at the time the push was sent. Exactly WHY it did not varies considerably, but all of these factors were outside the apps control.
-
The push DID reach the app, but the app failed to work properly. Exactly WHY it failed is also quite variable, but a few common cases are:
-
The app assumes the user will always login when the app launches, which breaks when the app is launched into to the background.
-
The app assumes data will be available when it isn't, particularly in the case where the app is relaunched on a locked device immediately after reboot ("Prior to first unlock").
-
The app does NOT in fact immediately report every incoming call to CallKit as the API contract requires.
My basic recommendation here is that you need to completely validate your call handling code before you try and look for any external factor. There should not be ANY path through your PushKit delegate that does not ALWAYS report a call. Similarly, PushKit and CallKit should both be setup up early in the launch process and left active for your apps entire lifetime.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
