Multiple apps with a single ApnsClient with token authentication?

[j...@turo.com]

Friends,

I've been seeing some alarming posts on Apple's push notification forums:

• https://forums.developer.apple.com/thread/71523
  
• https://forums.developer.apple.com/thread/72999
  

Those threads suggest that, even though we send an authentication token with each push notification, Apple is "binding" connections to the set of topics associated with whichever token it receives first, and subsequent attempts to send notifications with valid key associated with a different set of topics (a different team ID?) will cause ALL notifications on that connection to be rejected with HTTP/403 (InvalidProviderToken). This is a Big Deal™ for Pushy, and flies counter to a number of design decisions related to auth tokens.

Regrettably, we at Turo only have our one team (and thus only one signing key). I'm trying to get clarification from Apple, but in the meantime, have any of you succeeded in using a single ApnsClient with keys from multiple teams in the wild?

Thanks very much!

-Jon

[Justin Mason]

Sorry — I haven’t tried this out yet so I cannot confirm :(

> --
> Pushy is an open-source Java library for sending APNs (iOS and OS X) push
> notifications. Pushy is brought to you by the engineers at RelayRides.
> ---
> You received this message because you are subscribed to the Google Groups
> "pushy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pushy-apns+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Azilet Beishenaliev]

We tried to use single ApnsClient with multiple keys and faced the mentioned issue - APNs rejects pushes with "InvalidProviderToken" error.
Sad news...

[j...@turo.com]

We recently got confirmation that this is, unfortunately, the intended behavior. We just released Pushy v0.10, which changes our model for handling tokens/private keys to match the server behavior.

Thanks for the report!

-Jon