Our product is white labeled, so while we host the backend, which will include the "provider" in APNS parlance, the App Store submission is not done by us.
Does APNS have to use the same cert as the application's App Store cert?
APNS certificate is different from App Store cert. However, both certificates, app store and apns should be generate for same App id. i.e. you will need access to developer account on which app id is created.
Related
if a bundle id is created on a different apple developer account and APNS key on different one will this work
Actually i have moved from my app from one account to the other but old apns auth key doesn't seem to work and the limit to create new key on second account is reached
We're attempting to figure out what role is necessary for a user to have to generate an APNs certificate through the Apple Developer Portal. It appears that we currently have Developer role, and that this isn't enough (the only certificates that appear are for signing). We have another account that has an Admin role which does have access, but we want to be certain that an Admin role is required, as we'd prefer to request least permissions.
Setting up APNS with either TLS or autentication tokens require either the Account Holder or Admin role.
Can you add or enable the Account Holder role on your Developer account?
Here are a couple of links about APNS authentication types:
Communicate with APNs using authentication tokens
Communicate with APNs using a TLS certificate
Here is some more info about roles:
Program Roles
Hope this helps! Getting APNS set up is always a chore.
I'm planning to migrate the APNs to the Authentication tokens system from the old (certificate based), but I don't want to invalidate the existing valid tokens. Does anybody have any experience with this? Will the existing token still works after migration?
TIA
Token is device specific and if you create an Auth token (which is new way of using push notifications as they have no expiry date), It would have no effect on device token. I guess the proper question here would have been whether the notifications using the old APNS certificates would still be working or not(considering it has been set up on the server as well) even in that case the answer would be Yes. As long as you do not revoke the certificates it would still be working
The token is generated on the device that will receive the notification and is based on your bundle ID and the device. It is not dependent on the credentials that your server uses to connect to the APNS service (The iOS device has no information on this).
As a result you can change the way you connect and authenticate without any impact to existing tokens. It is no different to using a new certificate when the old one expired with the old system.
I've setup Firebase Cloud Messaging on our system to setup push notifications. Before our APNs certificate expired and we ran into some issues because of this.
Then I was able to generate an APNs Authentication Key and I assumed that this one couldn't expire. Can someone tell me if that assumption is correct?
No. APNs Auth Key will never expire as Apple suggests. It is now a more preferred way to handle Push Notifications than using APNs Certificate.
I've recently learned of the new APNS Authentication Key mechanism which is set to replace the functionality of the existing system of APNS certificates.
From my understanding this key supersedes all existing certificates, and can authenticate requests for all my apps.
I am confused about the transition though. Does this key only work for apps that are newly built/provisioned/released? My Firebase console invites me to upload my new APNS Authentication Key, but upon doing so, warns that my existing certificates which are being used in production will be removed. Does this mean my existing users will stop receiving push notifications?
IMHO, transitioning from certificate-based to authentication token-based only affects how your application server communicates with the APNS provider, thus existing users of your application will not be affected.