これまでiOS 9/El Capitan/Xcode 7以降で要注意箇所、App Transport SecurityのTLS要件が思った以上に厳しかった件、Xcode 7ではデフォルトでビルド時にビットコードが含まれる ((実際にはiOSをターゲットにした場合のみ、OSXをターゲットにした場合はデフォルトではビットコードに含まれない)) 、iOS 9/El CapitanではIPv6対応が必須だが・・・などでiOS9及びXcode 7などへの言及をしばしば行ったが、まだ要注意箇所があった。ここでは、それについて説明を行いたい。
2016年からAPNSデバイストークンが長くなる
それは、『iOSのPUSH通知(APNS)の特徴・ノウハウまとめ(iOS 9まで対応)』(Qiita)及び『WWDC 2015 – Big changes to Apple push notifications』(Odecee)によれば2016年からApple Push Notification Service (APNS)と呼ばれるプッシュ通知システムで使用されるデバイストークンが現行の32bytes ((16進数の文字列に変換した場合64文字)) から100bytes ((16進数の文字列に変換した場合200文字)) に伸びるということである。
デバイストークンが長くなるに至ったと考えられる主な要因
『iOS7でのAPNSデバイストークンに関する挙動について』(ゆれくるコール開発日誌)及び『iOS 9からAPNSデバイストークンがアプリインストールの度に変わるようになったようです』(Qiita)によれば、iOS6まではデバイスごとに紐づけられていたAPNSデバイストークンが、iOS 7以降ではデバイス/アプリごとに紐づけられるように変更され、さらにiOS 9以降ではインストール毎にAPNSデバイストークンが変更されるようになったとのことである。
これによって、APNSデバイストークンが発行される頻度が大幅に増えており、それによって、32bytesでは発行できるデバイストークンが枯渇して行ったことが背景として考えられる。そのため、デバイストークンの長さを100bytesに変更することによって枯渇に対応しようということなのだろうか。
デバイストークンが長くなることによる注意点
基本的にはアプリ単体で完結する分には注意点はいらないものと考えられる。
データベース上の注意点
しかしながら、SNSアプリやソーシャルゲームなどで、クライアント・サーバーモデルを使ってプッシュ通知を行う場合、基本的にはデータベースでAPNSデバイストークンを格納するものと考えられる。この場合、iOSのデバイストークンとAndroidのプッシュ通知システムにおいてiOSのデバイストークンに相当するRegistration IDがデータベース上同じ属性に格納されている場合 ((通常、この場合は別途iOS/Androidを判別する属性があるはず)) は、基本的にはAndroidのRegistration IDの方が可変長とはいえ長くなるため、基本的には問題は発生しない。
しかしながら、AndroidのRegistration IDとiOSのデバイストークンを別々の属性に格納して、なおかつiOSのデバイストークンに割り当てた属性の長さがバイナリーで32bytes、16進数の文字列で確保する場合は64文字分しか確保されていなかった場合は問題となる。なぜならそのままでは100bytesに伸ばされたデバイストークンを格納できないからである。
そのためには、デバイストークンを格納する属性の長さをバイナリーで100bytes、16進数の文字列で確保する場合は200文字、あるいはそれ以上に変更するというデータベースの改修が必要になる。
もしクライアント・サーバーモデルでサービスを展開しており、サーバーからプッシュ通知を行っているのであれば、デバイストークンの部分のチェックは必須となるだろう。
最後に
今回はiOS 9での変更点というよりは、Appleのプッシュ通知システムの変更という側面が強く、対応が必要になるのはクライアントサイドというよりはサーバーサイドと考えられる。
サーバーの設計によって対処が不要な場合と必要な場合が分かれてくるので、是非ともチェックはしておきたいものであると考えている。
ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しています。主にスマートフォン向けアプリやウェブアプリの開発を携わっています。ご用の方はコメントかコンタクトフォームにて。
