[Apple Documentation ApplePushService]2 から
トークンの信頼のこのフェーズの形式により、APNのみが後で尊重するトークンを生成し、デバイスから渡されたトークンがその特定のデバイスに対して以前にプロビジョニングされたトークンと同じであることを保証できます。そのデバイス用。
ユーザーがバックアップデータを新しいデバイスに復元するか、オペレーティングシステムを再インストールすると、デバイストークンが変更されます。
Appleの公式文書は、この点に関して不明確です。私が観察したのはこれです：トークンは、特定のデバイス、アプリケーション、およびドメインに対して不変です（本番とサンドボックス）。システムが確実に機能するためには、これが真実でなければならないと信じています。アプリケーションの更新が新しいAPNトークンをトリガーする状況を考えてください。通知を有効にして、Twitterのような最高の新しいアプリを使用していた場合、iTunesからアプリを更新するとどうなりますか？更新を自分のデバイスに「同期」してからアプリケーションを実行していなくても、引き続き通知が送信されることを期待する必要がありますか？更新されたアプリを実行していなくても、OSがユーザーに代わって通知を受信できるため、アプリケーションを変更する行為はAPNシステムに影響を与えません。
明確にするために、Appleは「アプリケーションは起動するたびに（APNサーバーに）登録し、プロバイダーに現在のトークンを与える必要がある」と述べています。私は心から同意します;そうすることで、悪い仮定や異常な状況からアプリケーションを保護できます。
単一デバイスのすべてのアプリでプッシュ通知トークンは一意ですか？ に対する回答の1つは、デバイストークンが「オペレーティングシステムのインストール」ごとに一意であることを示しています。また、バックアップからデバイスに復元するとトークンが保持されますが、デバイスをワイプすると新しいトークンが取得されます。これは、シームレスな操作とプライバシーというAppleの意図と完全に一致します。デバイスのワイプは、おそらく新しい関連付けを保証するほど深刻ですが、OSの更新後にイメージを復元するユーザーは、既存の通知を保持する必要があります。 iPadで最新のiOS5アップデートを思い出した場合、アップグレード後に最新のバックアップを復元したので、これにより通知トークンの一貫性が維持されます。 [編集：バックアップをdifferentデバイスに復元しても、トークンは複製されません。]
警告：このテーマに関する明確な知識はありませんが、APN（サードパーティの開発者として）での合理的な経験があります。いつものように、仮定を検証することが最善です。
更新（2012年6月）：
最近、a> Appleエンジニアと話をして、b>いくつかの実世界のテストを実行する機会がありました。
完全にするために、APNトークンを返すことについて話すとき、単一のバンドル識別子/アプリケーションのコンテキストを想定しています
最初に、Appleエンジニアは、2つのデバイスが同じAPNを返すことはできないはずだと言った。以下のコメントにもかかわらず、私はこれが失敗する状況を特定することができませんでした。
次に、アップグレードテストのシーケンスと結果を次に示します。
IPhone4にインストールされたiOS4から始めます。 iTunesのバックアップデバイス
IOS5へのアップグレード
以前のテストから、APNトークンが異なることがわかりましたデバイスにバックアップを復元します
APNトークンはステップ1と同じになりました。IOSのリセット（クリーンデバイス）
APNトークンの変更別の電話をiTunesにバックアップし、そのバックアップをテストデバイスに復元します。基本的に、電話を切り替えているかのように、「間違った」バックアップを復元しています。
APNトークンが再び変更されます。さらに、それは明確であり、元のトークンまたは「クローン」トークンのいずれにも一致しません。「正しい」バックアップをデバイスに復元します。
APNトークンはステップ1と同じになりました。最後に、電話機をiOS6（beta2）にアップグレードし、バックアップを復元して、再テストしました。予想どおり、トークンはステップ1のトークンと一致し続けました。
この時点で、APNトークンは異なるデバイス間で複製できないとかなり確信しています。おそらくこれは以前のバージョンのiOSのバグとして発生した可能性がありますが、iOS5（およびおそらくiOS6）がAPNトークンを正しく処理していると確信しています。
更新（2012年8月）
これを追加していないことに気付きました。デバイストークンwillが変更されます。 Apple開発者の1人は、トークンが実際に期限切れになることを共有しました（2年後だと思います）。多くの目的で、これは不変と考えることができる十分な長さです。
[特に毎年電話を交換するので、2年ごとに新しいトークンでテストスクリプトを更新する必要があるかどうかは心配していません。]
reinstallアプリの場合、iOS9とAPNプッシュトークンの変更でテストしました。
YES、デバイストークンは変更できます。
アプリはトークンを受け取るたびに、トークンを保存する必要があります。次に、新しいトークンが受信されるたびに（最終的にwillが発生します）、新しいトークンを保存されているトークンと比較し、それらが異なる場合：
- デバイスのローカルストレージを更新します（おそらく
nilを含む） - トークンを使用するデバイス上のすべてを更新して、新しいトークンを認識します
- このトークンを認識しているAPIを新しいトークンに更新します。
実際問題として、最後のステップは自明ではない可能性が最も高いです。たとえば、デバイスがサブスクライブした郵便番号に基づいてデバイストークンに気象アラートを送信するサービスがある場合、old_tokenおよびnew_tokenをそのサービスに渡す必要があります。配信を更新できます。
エルゴは、一般的に「デバイストークン」を受け入れるAPIの100％には、そのトークン用のUPDATE機能も必要です。 Tonotこのためのビルドは、to誤配信および非ビルド用-配信された通知。
デバイストークンはiOS 8以降から変更されます
Apple Webサイトから以下のテキストを参照してください。 ユーザー通知の登録、スケジューリング、および処理
デバイストークンは、特定のデバイス上のアプリにプッシュ通知を送信するための鍵です。デバイストークンは変更される可能性があるため、アプリは起動されるたびに再登録し、受信したトークンをサーバーに渡す必要があります。デバイストークンの更新に失敗すると、リモート通知がユーザーのデバイスに届かない場合があります。ユーザーがバックアップデータを新しいデバイスまたはコンピューターに復元するか、オペレーティングシステムを再インストールすると、デバイストークンは常に変更されます。データを新しいデバイスまたはコンピューターに移行する場合、ユーザーはリモート通知をそのデバイスに配信する前にアプリを1回起動する必要があります。
アプリが新しいデバイスに復元されない限り、変更されるべきではありません（この時点でプッシュ通知を受け入れるように求められず、新しいトークンを受け入れる必要がある時点で登録済みの呼び出しを送信します）。
ただし、Appleは、変更されないことを保証しません（したがって、ドキュメントで言及されていないため）。最悪の場合はより良いプログラムを作成し、いつか変わる可能性があると想定します。また、トークンをサーバーに定期的に送信すると、しばらく登録されておらず、おそらくアプリを削除したか、しばらく前に興味を失ったトークンを削除することができます（ドキュメントでは、これを望ましい動作として指定しています！）.
Appleでは、リンクはすぐに時代遅れになります！だから私は今かなりはっきりしているように見えるものを引用しています：
アプリでデバイストークンをキャッシュしないでください。代わりに、必要なときにシステムから取得します。 APNsは、特定のイベントが発生すると、アプリに新しいデバイストークンを発行します。デバイストークンは、たとえば、ユーザーがバックアップからデバイスを復元するとき、ユーザーがアプリを新しいデバイスにインストールするとき、ユーザーがオペレーティングシステムを再インストールするときなど、異なることが保証されます。キャッシュに依存するのではなく、トークンを取得することで、プロバイダーがAPNと通信するために必要な現在のデバイストークンを確保できます。デバイストークンをフェッチしようとしてもトークンが変更されていない場合、フェッチメソッドはすぐに戻ります。
unregisterForRemoteNotificationsを呼び出した後にトークンが変更されることは誰もしなかったので、言及する価値があると思います。次回registerForRemoteNotificationsを呼び出すと、トークンは異なります。 Appleのドキュメントでこの確認を見つけることができませんでしたが、自分でそのような動作を目撃しました。これを覚えておいてください
APNは、さまざまな理由で新しいデバイストークンを発行できます。
ユーザーが新しいデバイスにアプリをインストールします
ユーザーがバックアップからデバイスを復元する
ユーザーがオペレーティングシステムを再インストールする
その他のシステム定義のイベント
その結果、アプリは起動時にデバイストークンを要求する必要があります。
参照- Apple Docs
NB：APNsデバイストークンは可変長です。サイズをハードコーディングしないでください。
Apple Push notification stuff への参照として
デバイストークンは、特定のデバイス上のアプリにプッシュ通知を送信するための鍵です。デバイストークンは変更される可能性があるため、アプリは起動されるたびに再登録し、受信したトークンをサーバーに渡す必要があります。デバイストークンの更新に失敗すると、リモート通知がユーザーのデバイスに届かない場合があります。ユーザーがバックアップデータを新しいデバイスまたはコンピューターに復元するか、オペレーティングシステムを再インストールすると、デバイストークンは常に変更されます。データを新しいデバイスまたはコンピューターに移行する場合、ユーザーはリモート通知をそのデバイスに配信する前にアプリを1回起動する必要があります。
デバイストークンをキャッシュしないでください。トークンは必要なときにいつでもシステムから取得できます。アプリが以前にリモート通知用に登録されている場合、registerForRemoteNotificationsメソッドを再度呼び出しても追加のオーバーヘッドは発生せず、iOSは既存のデバイストークンをアプリのデリゲートにすぐに返します。さらに、iOSは、アプリの登録または再登録に応答するだけでなく、デバイストークンが変更されるたびにデリゲートメソッドを呼び出します。
アプリのインストール時のデバイストークンリレー。
つまり、アプリケーションを再インストールすると、変更されます; iOSアップグレードeccなどのバックアップから実行する場合は改善されません。
問題を回避するための正しい使用方法は、NSPAppDelegateメソッドで、アプリケーションの起動ごとにdidRegisterForRemoteNotificationsWithDeviceTokenで指定されたものを取得することです。
はい変更できます。理想的には、コールバックメソッドを介してトークンを受け取るとき
- （void）application：（UIApplication *）application didRegisterForRemoteNotificationsWithDeviceToken：（NSData *）deviceToken
アプリは、リモートサーバーでトークンを登録/更新する必要があります。これにより、APNSとサーバー上のトークンの同期が維持されます。
Appleドキュメント に従って、
アプリ固有のデバイストークンの取得と処理は次のように機能します。
アプリは、リモート通知のためにAPNに登録します。新しいデバイストークンが必要になると、APNはデバイスの証明書に含まれる情報を使用してトークンを生成します。中央の右向きの矢印に示すように、トークンキーを使用してトークンを暗号化し、デバイスに返します。システムは、application：didRegisterForRemoteNotificationsWithDeviceToken：デリゲートメソッドを呼び出して、デバイストークンをアプリに戻します。トークンを受信したら、アプリは（デリゲートメソッド内で）バイナリまたは16進形式でプロバイダーに転送する必要があります。このトークンがないと、プロバイダーは通知をデバイスに送信できません。詳細については、リモート通知サポートの構成のリモート通知を受信するための登録を参照してください。
このリンク デバイストークンによる
各リクエストに含まれるデバイストークンは、通知を受信するデバイスのIDを表します。 APNは、デバイストークンを使用して、一意のアプリとデバイスの各組み合わせを識別します。また、デバイスに送信されるリモート通知のルーティングを認証するためにも使用します。アプリがデバイス上で実行されるたびに、APNsからこのトークンを取得し、プロバイダーに転送します。プロバイダーはトークンを保存し、その特定のアプリとデバイスに通知を送信するときにトークンを使用します。 トークン自体は不透明で永続的であり、デバイスのデータと設定が消去された場合にのみ変化します。APNのみがデバイストークンをデコードおよび読み取ることができます。