その他

iPhoneアプリ開発開始時に気をつけるべきファイルの取り扱い (1)

こんにちは、亀本です。

今回から何回かに分けて、iPhoneの申請まわりの事に関するファイルの取り扱いノウハウを書いてみたいと思います。

ここでのファイルの取り扱い方の紹介方法は、ファイル一つ一つについて個別に言及するようなまとめ方はしません。
代わりに、そのファイルを作成・利用するタイミングを切り口として紹介し、その際にファイルをどう取り扱うべきかを、その理由とともに説明していきます。

(※なお、あくまでも個人的に感じたノウハウであって、必須事項ではありません。)

1回目は、まず触れるべきファイルの説明と、一番最初のCSR発行時に気をつけておくことを紹介します。

はじめに

iPhoneの開発を始めようとすると、最初にCSRやらProvisioning Profileやら、いまいちパッとつかみづらい概念が出てきます。
このあたりのよくわからない事、けっこう悩まされてしまいますよね。

とはいえ、最初始めるときはまだいいのです。
何しろ、Appleのサイト側にあれをやれ、これをやれ、という手順が載っているし、検索するといろんなところに開始手順についての解説が出てきます。
そういう意味で、ある程度頑張れば、「手順通り」でちゃんと整います。

しかし、それだけで事が済めば、苦労はしません。
だいたいが、そうやってよくわからないまま、「とりあえず」で整えてしまった環境が、ごちゃごちゃになってしまって、管理がとてもやりづらくなってしまうのです。

特に問題になるのは

・ 一定期間以上たって、証明書の有効期限が切れた場合
・ チーム開発を行うために、新しいマシンで開発を行う場合
-> 同じく、新しい環境に移行する場合

これらについて、自分がしばらくチーム開発や申請などを繰り返してきて、申請や開発に必要なファイル群をどう扱うべきか、ある程度ベストプラクティスが見えてきたので、書き残しておくことにしました。

開発開始時、どのファイルをどう扱っておけばいいか、などが全く分からない、という状態になってしまうようなら、以下のポリシーにしたがってファイルを扱っておけば、まずまず困ることはないと思います。

なお、話が冗長になるので、ここではファイルの個別の作成方法には触れません。
作成するときに必要な注意点のみを述べることにします。
ファイルの作成方法については、AppleのProvisioning Portalにある解説などを参考にしてください。

必要なファイル群

まず、開発、申請に使うファイルや情報を列挙しておきます。

・ 秘密鍵
–> 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

最初から最後まで、必要になるファイル/情報は、とにかくこれだけです。
開発のみ、申請のみ、など、立場によって関わるファイルは異なってきますが、すべてを一貫して扱う場合には、この9概念しか出てきません。

もちろん、「いやいや、これは開発と申請で別にした方が。。。」といったものもありますが、それらは適宜説明していきます。

最初にCSRを作る際に気をつけるべき事

さて、それでは本題に移りましょう。
まず、実機テスト・並びに申請時に一番最初に手をつけることになるであろう作業「証明書要求(CSR)の作成」の際に気をつけるべき点を紹介しておきます。

1. 証明書情報の「通称」には、グループ単位の名前をつけよう

CSRを作成しようとすると、そのフローの途中で「証明書情報」を入力する画面に差し掛かるでしょう。
ここで必要な情報として
・メールアドレス
・通称
という項目を入力し終えれば、CSRと秘密鍵(+公開鍵)ができあがります。

と、ここでつい、通称として自分の名前を入れてしまう人などは、是非そこで注意して、「申請するグループ単位の名前」をつけるようにしましょう。
(※もちろん、個人で活動されている方は問題ありません。)

ここでつけた名前は、その際に生成される秘密鍵などの名前になってきます。
では、なぜそれが個人名ではまずいのか?個人のものではないのか?なぜ「グループ単位の名前」がいいのか?

それは、その後の実機開発などの際に関わってきます。
何台かのMacで同一のアカウントで実機テストを行おうと思った場合には、この秘密鍵と、それに対応する証明書、Profileなどがワンセットで必要になります。

しかし、秘密鍵/証明書は、1つのアカウントごとに1つしか指定できないため、実質上、この鍵は他のマシンから移植するなど、徐々にプロジェクト全体、場合によっては会社全体で使われる事になっていくオチがあります。
そんな風に使われることになるので、ここに個人名がついていると、何の鍵だかよくわからない状態になってしまい、あまりよろしくありません。
(※各マシンごとに違うアカウントを発行して、それをすべて同じDeveloper Programに所属。。。とかやれないこともないですが、無駄に煩雑です)

なので、あとで鍵が何のための物かすぐわかるように、適切な集団の名前をつけておくと、運用しやすくてよいでしょう。
(※なお、鍵の名前自体は、あとから変えることも出来なくはないです。)

2. CSRと秘密鍵は、必ずペアして保存しておこう

秘密鍵とともに、証明書要求用のCSRのファイルが生成されると思います。
このCSR、中間ファイルっぽいので、よく捨てられてしまう事があります。
が、実はこのファイル、安易に捨ててはいけません。

というのも、最初の証明書を発行してから一定期間が経過すると証明書が有効期限切れになってしまい、再度証明書の要求をする必要がでてきます。
その際に、同じ秘密鍵を使い続ける=環境を特にいじらずに済ますには、再び現行の秘密鍵と対応するCSRで証明書の要求をすることで、そのまま同じ環境を、大していじらずに使い続けることが可能になります。

と、長期間続けて使い続けるには、このCSRが割と重要であるにもかかわらず、一度失ってしまうとあとから容易に復元でないため、このファイルは必ず、対応する秘密鍵とともにペアで保存しておくようにするとよいでしょう。

おわり

さて、ひとまず今回は、全容の紹介と、CSR生成時に考えておくとよいことを紹介しました。

次回以降でも、各ステップごとにとるべき対応やファイルの取り扱い方法について、紹介していきます。

author img for asial

asial

前の記事へ

次の記事へ

一覧へ戻る
PAGE TOP