Issues with Push Notifications and Call Implementation in Flutter App on iOS (Debug Works, Production/TestFlight Fails)

Question

FaisalAyub OP

Created 2d

Replies 1

Boosts 0

Participants 2

Hello Developers,

I am currently developing a Flutter application where I am implementing both push notifications (for messages) and VoIP call notifications. The implementation works perfectly fine on Android. However, I am facing issues specifically on iOS in the following scenarios:

Terminated State:

When the app is terminated on iOS, neither call notifications nor message notifications are received.

In the background state, things partially work, but in the terminated state, nothing comes through.

Debug vs Production:

In Debug mode, everything works as expected (both message and call notifications).

Once I release the app to TestFlight (Production), the notifications completely stop working:

Message notifications are not delivered at all.

Call notifications also fail to appear in terminated state.

Configuration Details:

I have already configured APNs with .p8 key in Firebase.

The required capabilities (Push Notifications, Background Modes → Remote notifications, VoIP, etc.) are enabled in Xcode.

I also updated the AppDelegate.swift / Notification handling code for production environment.

Despite these steps, the same issue persists in production/TestFlight.

It seems like the issue is specifically related to production environment handling on iOS, since everything works in debug.

My Question:

What could be causing push notifications and call notifications to not work in the terminated state on iOS, especially in production/TestFlight builds?

Are there additional configuration steps required for APNs, VoIP, or background handling in production that differ from debug mode?

Any guidance or similar experiences would be really helpful.

Thanks in advance for your support.

Answered by DTS Engineer in 857673022

What could be causing push notifications and call notifications to not work in the terminated state on iOS, especially in production/TestFlight builds?

So, the big question here is do notifications work properly when your foreground. Based on that answer:

Notifications do NOT work in the foreground, meaning notifications don't work at all-> The problem here is likely tied to how you're actually sending the push notification, most typically that you're sending your pushes to the wrong environment (for example, the app is using the sandbox but you're seeing pushes to the production server). This article has a good overview of what that involves.
Notifications work in the foreground but do NOT work in <insert particular case>-> There's a problem with your app that you need to debug and fix. The larger APNS system has no idea what your app/device is doing, so application state like background/foreground/terminated has NO effect on whether or not a push can reach your device. What does change behavior here is issues in your own app breaking how pushes are handled.

Shifting to your specific cases:

When the app is terminated on iOS, neither call notifications nor message notifications are received.

In the background state, things partially work, but in the terminated state, nothing comes through.

This is a bug in your app, with the most common case being your app assuming that the user will log in or otherwise interact with the app before calls "start". None of that will happen if your app launches into the background.

In addition, keep in mind that to many call failures will make the system stop ALL background voip push delivery, as described here:

"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."

Debug vs Production: In Debug mode, everything works as expected (both message and call notifications).

Once I release the app to TestFlight (Production), the notifications completely stop working:

Have you specifically tested your debug build in exactly the same way you test your production? In particular, without being attached to Xcode?

In order to function, the Xcode debugger disables normal app suspension and termination watchdogs. In practical terms, your app ends up being treated more like a foreground app, even if it's in the background. In the case of voip apps, that means the system will allow your background app to behave in ways that it would never allow under normal operation.

Are there additional configuration steps required for APNs, VoIP, or background handling in production that differ from debug mode?

In my experience, with the exception of switching APNs environments, voip issues that only happen "in production" are exceedingly rare. However, what is common is that the production build is that first time the app is actually tested under real world conditions, which then exposes existing issue that had previously been overlooked.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

2d

Recommended

What could be causing push notifications and call notifications to not work in the terminated state on iOS, especially in production/TestFlight builds?

So, the big question here is do notifications work properly when your foreground. Based on that answer:

Notifications do NOT work in the foreground, meaning notifications don't work at all-> The problem here is likely tied to how you're actually sending the push notification, most typically that you're sending your pushes to the wrong environment (for example, the app is using the sandbox but you're seeing pushes to the production server). This article has a good overview of what that involves.
Notifications work in the foreground but do NOT work in <insert particular case>-> There's a problem with your app that you need to debug and fix. The larger APNS system has no idea what your app/device is doing, so application state like background/foreground/terminated has NO effect on whether or not a push can reach your device. What does change behavior here is issues in your own app breaking how pushes are handled.

Shifting to your specific cases:

When the app is terminated on iOS, neither call notifications nor message notifications are received.

In the background state, things partially work, but in the terminated state, nothing comes through.

This is a bug in your app, with the most common case being your app assuming that the user will log in or otherwise interact with the app before calls "start". None of that will happen if your app launches into the background.

In addition, keep in mind that to many call failures will make the system stop ALL background voip push delivery, as described here:

"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."

Debug vs Production: In Debug mode, everything works as expected (both message and call notifications).

Once I release the app to TestFlight (Production), the notifications completely stop working:

Have you specifically tested your debug build in exactly the same way you test your production? In particular, without being attached to Xcode?

In order to function, the Xcode debugger disables normal app suspension and termination watchdogs. In practical terms, your app ends up being treated more like a foreground app, even if it's in the background. In the case of voip apps, that means the system will allow your background app to behave in ways that it would never allow under normal operation.

Are there additional configuration steps required for APNs, VoIP, or background handling in production that differ from debug mode?

In my experience, with the exception of switching APNs environments, voip issues that only happen "in production" are exceedingly rare. However, what is common is that the production build is that first time the app is actually tested under real world conditions, which then exposes existing issue that had previously been overlooked.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0