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.

We are managing VPP license switching operations using Apple's VPP Manage Licenses API. License information is managed by matching the “clientUserIdStr” data with the VPP account ID information managed on the server side. We received an inquiry stating that a VPP license did not activate despite the activation process being performed. Upon checking the API results, the update API returned a success status during execution. However, the “clientUserIdStr” information was missing from the license information field in the response of the information retrieval API. We kindly request your guidance on the reason why the “clientUserIdStr” information is missing when retrieving license information, and the steps to ensure this information is reliably returned. VPPAccoountId:0123456789abcdef0123456789abcdef adamIdStr:521974902 *Some details have been altered from the actual data to protect personal information.