Its not possible

If an app is terminated then there's no way of waking it (unless voip push is used, but you can't use that if you're not a voip app) You can have an app directed push, that will get delivered to the app, but not if its terminated. Or you can have a user directed push, that doesn't get delivered to the app but will be delivered to the user, going via a notification service extension if there is one. However the notification service extension cannot wake the app. BTW You have both contentAvailable and mutableContent set here but its supposed to be one or the other, not both. And if you are using content-available which you say your are, then that will not get delivered to the notification service extension. Seems like you are mixing things up and don't have a clear understanding of the different types of push and what they get delivered too. Anyway, regardless, you cannot wake a terminated app with a push.

Firstly if it crashed there will be a crash report on the iPhone you can extract to look at. If that doesn't help/pinpoint the reason then add verbose logging and start to narrow down where it occurring.

"The problem is that app reviewers test the app on emulator". What makes you say that statement?

The last time I experimented with this, data in NSUserDefaults gets transferred but not data in the keychain. If that's the case, then can't you just check that the device identifier in the keychain is present or not, and if not then you require the fresh registration.

"They should add you to their Development Team, with the appropriate permissions." That is potentially dangerous and companies are not necessarily willing to do that because if the person getting added to the developer team leaves the company they have the ability to logon to the other companies account and do malicious things there. Also in order to develop/test the app prior to delivery its necessary to also have your iPhone registered with their development portal, if you have a large development team and large test team and a large number of iPhones to register, then registering them all on the other company's account might not be possible.

I work for a third party company that provides apps on behalf of other companies and have not found any easy solution to this. What we have been doing is building an archive using their developer profiles/certificate (which they have to provide us with) and then they sign it for distribution using their distribution profile/certificates. This means we have the ability to build and run the app but we don't have the ability to publish it nor have access to their Apple account. However, the downside of this is, during the development and testing process before the archive is delivered, we can only build/install the app on phones if they are registered with Apple. And the limit for this is 100. The company we provide the app for is a very large well known company who have quite a lot of publishes apps and therefore Apple's limit of 100 development phones is too small, we have managed to get a couple of our phones registered with their Apple account, however our team of developers and testers and not to mention it needs testing on a wide range of devices means this is unsatisfactory. So what we decided to do is have two versions of the app - create two workspaces which are identical to each other and share the same source code. The only difference being one of the apps has an apple bundle id registered to our Apple account and signing is automatic with our developer profiles, and the other workspace has an apple bundle id registered to the other company and signing is manual using their developer profiles. Then for development and testing everything is done using the app registered to our Apple account, and it can be installed/run on as many iPhones as we want. Then when its time for a release to be made, as a final sanity check the app with their bundle id can be installed and tested on one of the iPhone registered to their Apple account before an archive of that app is build and given to them.

The answer is already in the stack overflow question. Why posting here, don't you believe what people say on stack overflow?

Have you at least looked at the crash logs? If not why not?

You might get some answers if you post your question on stack overflow

Second what Ptit-Xav says. If you're installing via running the app in Xcode then (unless you are explicitly changing the scheme setting) you are installing a debug build, which is not the same as a release build, and will often lead to different behaviors.

Forgot to mention the WWDC22 session mentions a bunch of stuff to go into info.plist, but it doesn't mention BAManifestURL. In general the WWDC materials seem out of date and no use anymore. Is there some accurate up-to-date documentation?

Looks like I have to use xcrun, and update the Mac to Ventura. Going to try and update it now and see what happens

Switch from using a silent push notification to a user push notification, then that will get displayed to the user even if the app is terminated. If the push payload's notification title/subtitle/body can be set by the server then it will just get displayed to the user directly. If the notification title/subtitle/body needs to be changed after the push has been received, then that can be done by using a notification service extension.

You need to get your terminology correct in your requirement as its not clear what you are asking. What does schedule local notification mean exactly? A local notification and a push notification are two different things, your talking about local notification and push notification and so its confusing what you want. A local notification is posted by the app, they can be scheduled by the app to be displayed in the future. A push notification is not a local notification, when the app receives a silent push notification it can display a local notification, but the app cannot receive a silent notification if its not running. There are different types of push notification, if you send a non silent notification then it will be displayed to the user (and will look like a local notification) even if the app is not running.