I'd like to distribute apps via an apple Enterprise account to press, beta users, investors, our internal team, etc. All the created content should end up on our main production app though.
We currently use a normal apple developer account but recently signed up for an Apple Enterprise dev account. I've played around with it and was required to make a new BundleID which would mean that I'd need to generate a new Push Notification Certificate and subsequently upload that certificate to a different staging environment. But the issue here is that all those accounts will then only be made in the staging environment and not in the production app. Do you see my conundrum here? Maybe staging environments are not the solution but they seem the only way for me to handle my multiple bundle ID's. Now ideally Apple would allow me to merge these two accounts but I've read elsewhere that this is not possible.
This problem seems to arise as a result of Apple's infrastructural "decisions" but I'd love to discuss possible solutions that allow me to use our Enterprise account, mostly for the ease of distribution it enables.
Read the enterprise account terms carefully before distributing using the enterprise account. It's intended for distributing only to customers within your organization. For press and reviewers there are promo codes that can allow for early downloads from the app store. For investors and beta testers you should use the normal distribution methods using the non-enterprise account.
As for the multiple account issue, Kinvey stores the device_token with each user that may receive remote notifications. Those device_tokens are tied to a specific provisioning profile which is tied to both your developer cert and the bundle ID, which are tied to the push cert that's uploaded to the console.
We've chosen to optimize around the one bundle ID per app, and using the dev vs. prod certs in different environments. If you need to support multiple bundle IDs you can use a dedicated environment for the second bundle ID and then use custom endpoints to manually register devices tokens to the correct environment and then manually mange the tokens in your user object. In the custom endpoint that's responsible for actually sending the push you would manually build the user object to pass to push.send().
almost 7 years ago
Here we have a different (but still similar) issue.
Two bundle IDs because the apps are for different audiences (pros and customers) with a single Kinvey App.
I don't think that the problem is related to Apple's architecture, but from then fact that Kinvey's backend supports a single push certificate that, in our specific case, has to be one of the two apps.
At the moment we are solving that with a custom (via php) push delivery, but coupling it with Kinvey it's not easy since we have to collect all devices ids, then send them to our script. It's even more complicated with Collections Hooks.
I hope Kinvey will consider a more complete push implementation.