iPhoneアプリ開発開始時に気をつけるべきファイルの取り扱い (2)
こんにちは、亀本です。
今回も、1回目に続いて、iPhoneアプリ申請まわりの、各種ファイルの取り扱いについての話の続きを書いていきたいと思います。
必要なファイル群
まず、前回も紹介したファイル群を改めて列挙しておきます。
・ 秘密鍵
--> hoge.p12
・ 秘密鍵に対応したCSR(証明書要求)
--> CertificateSigningRequest.certSigningRequest
・ CSRに対応した証明書(開発用)
--> development_identity.cer
・ CSRに対応した証明書(申請用)
--> distribution_identity.cer
・ 中間証明書
--> AppleWWDRCA.cer
・ デバイスID
--> iPhone実機から取得
・ AppID
--> 任意に設定
・ development用Provisioning Profile
--> hoge.mobileprovisioning
・ destribution用Provisioning Profile
--> hoge.mobileprovisioning
前回は、このうち秘密鍵とCSRの取り扱いについて紹介しました。
今回は、各種証明書と、デバイスID、App IDの運用時、作成時などのポイントを紹介して行きます。
証明書の有効期限に気をつけよう
iPhoneの開発・申請の際には、3種類の証明書が絡んできます。
・ CSRに対応した証明書(開発用)
・ CSRに対応した証明書(申請用)
・ 中間証明書
の3種類です。
開発用の証明書と申請用の証明書は、その名の通りです。
また、中間証明書は、AppleのProvisioning Portalで発行されている物になります。
これらについては、あまり運用の際に深く注意すべき事はありません。
証明書の有効期間中は、何度でもダウンロードしてこれるので、きちんと対応する秘密鍵やCSRが保持されていれば、
特に証明書側をペアで保存しておく、などの配慮はいりません。
ただし、開発用と申請用の証明書には有効期限があり、期間が切れたら再度CSRを使った証明書要求が必要になることだけ、
気をつけておく必要があります。
証明 書の有効期限は、Provisioning Portalでも、ローカルのキーチェーンアクセスでも、どちらでも閲覧可能なので、
これは、きちんとチェックしておきましょう。
しかも、証明書の有効期限が若干のはまりどころになることもあります。
一度自分がひっかっかったのが、ちょうど期限切れ当日に証明書の期限が切れている事に気づきいて証明書を
再度発行しようとしたところ、アメリカとの時差により、Appleのサイト側ではまだ期限切れ扱いになっておらず、
しばらくの間ローカルでのみ期限切れ扱い、というおかしな齟齬が生まれた事がありました。
証明書が期限切れになると、当然のことながら、アプリの申請ができなくなってしまいます。
アプリのリリースの時期などとかぶってしまわないように、気をつけましょう。
デバイスID につける名前は、分類しやすい区切りをつけよう
分類しやすい区切りって意味わかんない日本語ですね。
デバイスIDとは各実機ごとの端末識別子のことで、これをProvisioning Portalから登録することによって、
実機でのテストが可能になります。
表題の話は、つまるところ、デバイスIDをProvisioning Portal登録する際につける名前に、会社名とか部署名とか、
そういう類の接頭辞をつけておくと管理しやすいよ、と言う話です。
iPhoneの開発を会社単位でやっていると、実開発者以外にとてもいろいろな人に実機テストやアプリの確認を
おこなってもらう事になります。
開発者自身から始まって、テスター、マネージャ、顧客などなど。もっと複雑なプロジェクトチームになっている場合も
あります。
そういった作業を行っていると、どのデバイスIDが誰の物か、という事がきちんと視認できるように名前をつけておかないと、
本来そのプロジェクトに関わりのない人の端末にもインストールできるようにしてしまったり、同じような名前をつけてしまって
どれがインストールしたいデバイスだかわからない、などの事態に陥ります。
そのため、ある程度管理する数が増えてくるようなら、明確にどこの誰の物かがわかりやすいように、
所属する会社名、部署名などを接頭辞につけて、適切なグループ分けを行うようにすると、運用が楽になります。
また、iPhone3Gなのか4なのか、iPod Touchなのか、iPadなのか、など、端末の種類も一緒にわかるようにしておくと、一層便利です。
たとえば、「Asial Yudoufu iPhone4」とかです。(実際はちょっと違う名前つけてますけど。)
このあたりに心を配っておくと、後々わかりやすく、管理しやすくなると思います。
App ID は、アスタリスク(*)を忘れずに。
Provisioning Portalでの申請時に、「何これ？」となりやすいのがApp IDです。
App IDは複数作る事は可能ですが、削除が不可能なので失敗してゴミを残すと後々気分が悪いので、ちょっと気を配って作ってあげましょう。
iPhoneのアプリケーションは、バンドルと呼ばれるまとまりごとに分類して管理されるのですが、そのバンドルの
識別子となるのが、App IDです。
このApp ID で指定した値を、iPhoneアプリの申請用ビルドを行う際に、アプリのinfo.plist内で識別子(Bundle Identifier)に
指定する必要があります。
この識別子には、URLドメインを逆さまにし た記述を利用することが推奨されており、たとえばアシアルで
Fooというアプリケーションをリリースする場合であれば、「jp.co.asial.foo」という値を使うような感じになります。
なので、アプリの申請時には1度はお世話になるIDなのです。
ただし、このApp ID、一度値を指定してしまうと、変更がききませんし、識別子なので同じ値を2度使うこともできません。
となると、アプリを申請するごとに１つApp IDを作って。。。という手間が発生してしまいます。
App IDが分かれると、ビルド時に使うProvisioning Profileも別に用意せねばならず、同一の会社から複数の
アプリをリリースする場合には、とても管理が煩雑になります。
しかし、その手間を簡素化するために、App IDにはワイルドカードとして" * " (アスタリスク)を利用できるようになっています。
たとえば、アシアルであれば「jp.co.asial.*」といった具合でしょうか。
これを使うことで、「jp.co.asial.xxxx」という識別子のついたアプリケーションは、すべて1つのApp IDを使うことができ、
それはすなわち、すべてのアプリケーションを1つのProvisioning Profileで管理できることを意味します。
もちろん、アプリケーション個別にはきちんと一意なIDをつけてやる必要はありますが、
FooというアプリとBarというアプリ、それぞれに「jp.co.asial.foo」「jp.co.asial.bar」識別子を指定したとしても、
これらに個別にApp ID作る必要はなく、上記のアスタリスク付きのApp IDを使い回すことができます。
そのため、ある程度いろいろなアプリをリリースしていこうと考えている場合には、上記のようにアスタリスクを
つけたApp ID に、会社名などの汎用的な名前(「Asial App ID」など)をつけて管理してやると、運用がすっきりすると思います。
おわりに
今回は、各種証明書と、デバイスID、App IDの作成時、運用時のちょっとした心配りや注意点を紹介しました。
次回以降も引き続き、各種申請用ファイル群の注意点などについて、紹介していく予定です。
