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

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

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.

"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.

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.

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

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.

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.

Its not possible

The asset download extension would have been an opportunity to transmit the new push token, but the documentation for it says "Use the framework only to download additional assets for your app; don’t use it for any other purposes. For example, don’t collect or transmit data"

Did you find the reason why you're widget isn't updating?

"What other reasons could there be that a push message was sent but did not reach the application?" PushSharp is sending the pushes over the Apple production environment but the app you're trying send them to is a debug build, or vice versa. Your target handset has got Personal Focus currently turned on You are sending app-directed pushes but the app is terminated

You can send it using HTTP, exactly how the HTTP content is structured is up to you. Once you've sent it, your app needs to check to see if its changes (its not often, but it can), if so then you have to send the new one.

App-directed pushes are not delivered to your app if your app is terminated or in the background (unless just moved to the background) so using an app-directed push just isn't going to be able to do what you want. So you'll have to investigate if a notification service extension has the ability to do what you want.

I found out what the problem is - which I believe must be a bug in Xcode in how it creates the extension target. If different types of extension are created (for example an action extension or a call extension) then if you look at the Code Signing Entitlements section within Build Settings its empty. However, if a background asset download extension is created then it's not empty. If its changed to be empty then the problems described above go away.