Another data point for this issue. I'm see this issue on a device with no obvious way to get it going again. Today, when I attempt a PUSH, my console shows the following: com.apple.pushLaunch.xx.xxxxxx.***.xx:B449BC:[ {name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Absolutely Must Not Proceed, Score: 0.00, Rationale: [{[pushDisallowed]: Required:0.00, Observed:1.00},]}} {name: ThunderingHerdPolicy, policyWeight: 1.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{timeSinceThunderingHerdTriggerEvent < 300}]}}  ], FinalDecision: Absolutely Must Not Proceed} Very curious about: ThunderingHerdPolicy. I don't always see that, and sometimes only ApplicationPolicy. This test was done right after a reboot of the device. Upon re-running the test 10 minutes after the reboot, I no longer see ThunderingHerdPolicy rejection reason (just the ApplicationPolicy ) Things I have done (each to no effect): Rebooted the device Uninstalled and re-installed the app run under the XCode debugger (this is suppose to bypass the throttling for development purposes) waited a day, and tried again (hoping for a reset) Observations: This seems like new behaviour since 15.3.X upgrade Pushing "alert" type notification works fine and they are either displayed (if app in background) or received by my handler (app in foreground). *ONLY when "content-avaialable:1" is included does this happen As frustrating as this is, if the "running under debugger" exception would allow it to work, then I could at least get work done.

Well, I'll answer my own question. After some research on using xcodebuild, I found references to the "-destination" argument. I then added destination 'generic/platform=iOS' to my xcodebuild command line, and things seem'd to compile without errors. I suppose that I should have been using this in the past, it's only when running on MacOS 11.X that is seems to enforce this. Cheers!