iOS 8 issue: unsubscribing unrelated tokens due to APNS response error of first push about uniqush-push HOT 5 OPEN

Thank you for your report! It is very helpful. I think that using device id an a unique identifier is really a bad choice. However, since this is designed by Apple, we have to cope with it.

Does this mean that a deivce's id is not changed even after an upgrade? In this case, we need to store a timestamp for each delivery point and for every push request. Although I feel there may still be some race conditions, but it might not be very easy to produce. Let me work on a fix next week.

from uniqush-push.

Yes, that's what I observed on the devices I tested. After an upgrade the token is invalidated on APNS side. The app has to register on first start and gets the same token valid again. In addition the APNS errors are delayed. This strange Apple design makes a proper usage unnecessary complicated.

from uniqush-push.

While I'm looking at what we can do to fix apns.go, this option is looking most appealing as gcm.go seems to work extremely well under full production load delivering millions of pushes a day.

https://cloud.google.com/solutions/mobile/ios-push-notifications/

from uniqush-push.

Is this fixed? I still see this issue happening

from uniqush-push.

1. Is this specific to the upgrade to iOS 8? If so, this will be really infrequent after 11 years(iOS 11)
2. If this is related to one token being invalid causing other tokens to be invalidated, I haven't noticed that before. It'd be useful if I had something that I could reproduce with https://github.com/uniqush/apns-simulator , but apns-simulator isn't configured for complex simulations right now. (may need to be updated)
3. device token may change (think that "device id" in earlier conversation really was referring to "device token")

Switching to APNS HTTP2 instead may be useful: See #157 and the PR implementing HTTP2

from uniqush-push.