Same here, same issue on ios 18.3 and 18.5 I've been trying to work around it by setting badge to 1 for those messages, or debouncing them if clearing notification behavior is ok. Part of problem is that the badge clearing response from OS blocks notifications for a moment, so it even wipes out any updates to that notification. This is happening in local notifications. Don't know yet if ios 26 is similar. I was about to try badge nil tomorrow, so I'll refactor and retest.

UPDATE: Running additional tests with 18.5 on iPhone 12, app works fine. So far the issue seems isolated to managed devices deployed to a specific environment. It not clear what else could be different about this environment accept for device model. We are seeing a high number of reconnects, which we attributed to the sleep mode interrupting the provider's ability to respond to incoming message, but maybe there is a larger networking issue or the cadence of NEAppPushProvider ability to listen and respond to incoming messages is different in newer models?

I have similar issue, but it's a private app. It was already released and in 'Ready for Sale' status months ago. Existing ABM orgs still have access. It's been placed in 'Ready for Distribution' status for weeks/months. The release option is disabled. The first new ABM org since has just reached out because they are having trouble accessing it. There are no warnings, or unaccepted agreements pending in App Store Connect. EDIT: New status just appeared: Developers must provide their trader status to submit new apps or app updates for distribution in the European Union (EU) We do not distribute to EU ( only US & Canada). Does this apply to our app? UPDATE: I acknowledged that we are not a Trader and not distributing to EU. Release option still disabled. Should I assume this was in the way, and it's still processing? EDIT: Under pricing & availability the app is still listed as ...available in all future App Store countries or regions. Is this a problem? Updating the setting requires 24hrs to process, and obviously we wouldn't want to delay org access unnecessarily.

I solved it. I'll post a summary tomorrow.

Multiple times you've requested to confirm whether I'm using manual/automatic signing. in my original post I stated: " My profiles are set to include the Local Push Connectivity entitlement instead of Default. I don’t (cant’t?) automatically manage signing because of this." In other words, I'm using MANUAL SIGNING, because the Local Push Connectivity entitlement, which seemed to require manual signing historically. I'm also curious whether this is in fact [still] the case. Thank you for your assistance.

https://feedbackassistant.apple.com/feedback/14869466

Hi Paris, Yes, as previously stated: My entitlement files for each target have 
com.apple.developer.networking.networkextension app-push-provider My profiles are set to include the Local Push Connectivity entitlement instead of Default. Even validating older Archives which have already previously successfully uploaded & published to AppStoreConnect are throwing the same error.

I'm having the same issue: trying to test AppConfig compatibility with my approved TestFlight build using our Company's MDM. I blew through one of our 2 allotted support tickets trying to get an answer. So when I get something back I'll share.