Silent Push background launch rejected with "pushDisallowed" and "AMNP" on TestFlight build

Question

y_yatsui OP

Created 17h

Replies 1

Boosts 0

Participants 2

Hello,

I am implementing background processing using Silent Push Notifications in an iOS application.

The app needs to receive requests from a server and execute processing in the background. For this purpose, I am using Silent Push Notifications to wake up the application. However, the application is not being launched as expected when running the TestFlight version.

I would appreciate any guidance regarding this behavior.

Environment

Xcode 26.3
iOS 18.6
TestFlight distribution
Push Notifications capability enabled
Background Modes enabled
Remote notifications enabled
APNs Authentication Key (.p8)
APNs Production environment

Background

Previously, the application periodically connected to a server in the background and sent location information when requested by the server.

Since that background processing no longer behaves as expected, I started implementing an alternative approach using Silent Push Notifications.

When running the application directly from Xcode in Debug mode, Silent Push works correctly and the app is launched in the background.

However, when using the TestFlight build on the same device, the behavior differs and the app is not launched in the background.

Observed Behavior

The APNs request appears to be successful:

APNs response status is HTTP 200
Using the device token obtained from the TestFlight build
Alert Push notifications are received successfully
application:didReceiveRemoteNotification:fetchCompletionHandler: is called when the app is in the foreground
The same method is not called when the app is in the background

Silent Push payload:
{
  "aps": {
    "content-available": 1
  }
}

HTTP/2 headers:
apns-push-type: background
apns-priority: 5

Verified Items

Production device token is being used APNs topic matches the application's bundle identifier Alert Push notifications work correctly Background App Refresh is enabled on the device The application has not been force-quit completionHandler is always called after processing completes

Console Logs

The following logs appear when the push is sent:

Submitted: com.apple.pushLaunch.jp.co.comp.MyApp.ext.mdm
Application Policy
response: {100, 0.00, [{[pushDisallowed]: Required:0.00, Observed:1.00},]}
Decision: AMNP

I also see:

Insufficient history window for deviceActivityLikelihood stream
deviceActivityLikelihood returned a nil timeline

Questions

Under what conditions are pushDisallowed and Decision: AMNP generated?
What factors can cause iOS to reject a background launch triggered by a Silent Push Notification?
Since Alert Push notifications are received successfully, is it reasonable to conclude that APNs configuration, topic configuration, and device token usage are correct?
Are there any specific settings, entitlements, or implementation details that should be reviewed to resolve the pushDisallowed condition?
The behavior differs between the Debug build launched from Xcode and the TestFlight build running on the same device. Are there any restrictions, policies, or differences applied to TestFlight builds that could explain this behavior?
If the observed behavior is expected by design, what would Apple recommend as the appropriate architecture or API for server-triggered background processing in this scenario?

Thank you for your time and assistance.

Answer 1

Engineer OP

Apple

4h

The behavior you are seeing is expected, and it is due to content-available (aka "background" or "silent") push notifications being throttled when being delivered to apps that are in the background.

Background push notifications are never guaranteed to be delivered to the app every single time.

Additionally, notifications sent at low priority (priority 5) are throttled, regardless of payload. And background push notifications must always be sent at low priority. While you may expect up to several 1 or 2 push notifications per hour across all apps on a device, it is entirely possible and appropriate that you may receive none at all. Additionally, these notifications will not be delivered to the app at all if the user has not launched the app for a while.

The throttle is disabled if you run your app with a debugger attached. This allows you to test that your notifications are being received correctly, but should only be considered a best-case scenario.

The important point is that apps should never be designed expecting that every background push notification will be received. This is not how APNs is intended to work; it is intended to inform the user or app that some event of interest has occurred. Apps are expected to work properly, albeit perhaps with degraded functionality, if push notifications are not received. The user can turn off push notifications or background app updates at any time, and of course push notifications will not be received if the device doesn’t have network connectivity.

Also, an app will not be woken in the background by a push notification if the app had previously been force-quit. Force quit is considered a drastic choice by the user to say that they do not want the app to run, often because it misbehaved in some unrecoverable manner.

If the purpose of using silent notifications is to execute some code that is triggered remotely, I suggest looking into using a Notification Service Extension as discussed at https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension. The Notification Service Extension will be executed for every visible push notification. So, it could serve your needs, as long as the user has not disabled the visibility of your notifications through various settings. The service extension will not be executed for push notifications that will not be presented visually.

Although using totally silent pushes will not be a feasible solution for most apps, you may want to look at using the Interruption Levels for notifications and setting your notifications to "passive". This setting will allow you to send high priority pushes, and execute the Notification Service Extension when the notification arrives, but will be less likely to interrupt the user, although these are not completely invisible like silent pushes.

Argun Tekant /  WWDR Engineering / Core Technologies