VB開発者のためのWindowsストアアプリをリリースするための13の極意
極意6： ユーザーがWindowsストアからアプリを入手したとき、そのアプリは完全に機能しなければならない
「アプリは完全に機能しなければならない？！」ってどういう意味？ 筆者の体験談から、マイクロソフトのテスターが「アプリが不完全だ」と判断する例と対処法を説明する。
前書き ―― 今回の極意について
さて、これは一体何を意味しているのだろうか？
「Windows 8アプリの認定の要件」の内容は、一見しただけではなかなか理解しづらい面がある。筆者なんかは、初めてWindowsストアにアプリを申請する際、一切この「認定の要件」には目を通した記憶がない。リジェクトされて初めて中身を見たというのが本音だ。しかし現状では、ある程度は事前に「認定の要件」に目を通して理解しておかねばならないのかもしれない。でないと、あっさりとリジェクトされ、無駄な時間だけが過ぎていくことになる。かといって、リジェクトされた後で「認定の要件」に目を通しても、それはそれでいいのではないかと思う。先に「認定の要件」に目を通すと、逆にルールに縛られてアプリが作りづらくなるのでは、と危惧する。
審査員にテスト用アカウントの用意
筆者は最近、Windowsストアに「Facebookに画像を投稿」を申請した。このアプリは認定され、ストアで公開されている（次の画像を参照）。
このアプリは［画像ファイル選択］ボタンで、ローカル・フォルダーにある画像を選択して、Facebookにアップロードするアプリだ。Facebookにアクセスする必要があるために、審査員用にFacebook上のテスト・ページを作成した。ページが作成できたら、「審査担当者へのコメント」欄にFacebook上のテスト・ページへアクセスするためのアカウントとパスワードを記述して知らせておくのだ。なお、「審査担当者へのコメント」欄に入力した内容は、公には表示されないので、テスト用のアカウントやパスワードを入力しておいても心配はない。
審査員はテストする場合、テスト用のページにアクセスして画像がアップロードできるかどうかを確認できる。時々、自分自身もそのページにアクセスして、何か画像がアップロードされているかどうかを確認できる。画像がアップロードされていれば、認定も近い、と判断できる。ただし、審査員がアップロードした画像の公開を「友達」に限定していると、確認はできない。その場合は、自分で作成したテスト・ページの、テスト用の人物と友人になる以外にない(-_-;)。
このようなテスト用のページを作成しないで、アカウントもパスワードも教えることなく申請すると、当然、リジェクトされるので注意してほしい。
マイクロソフトのテスターが、アプリが不完全だと判断すると、そのアプリは認定されない
自分の作ったアプリをテスターが検証して、うまく動作しなかった場合は、もちろんリジェクトされる。バグはなかったのに、なぜリジェクトされたのだろう、という疑問を解消するためには、Windowsストアに申請するアプリ・パッケージを作成した際に、「Windows App Certification Kit 2.2」で、作成したアプリ・パッケージの検証を行うことだ。MSDNのサイトにも「アプリの認定を受ける一番の方法は、認定を受けてWindowsストアに掲載されるためにアプリを提出する前に、自分のコンピューターでアプリの検証とテストを行うことです。」と記載されている。このために用いられるのが「Windows App Certification Kit 2.2」だ。
Windows App Certification Kit 2.2での検証
この「Windows App Certification Kit 2.2（以下、WACK 2.2）での検証」については、別の回で詳細に解説する予定なので、ここでは簡単に紹介しておく。
Windowsストア・アプリが出来上がり、デバッグでも問題なく動作した。ロゴも作成した。さて、いよいよWindowsストアに申請しようと思ったら、まずはWindowsストアにアップロードする「アプリ・パッケージ」を作成しなければならない。Visual Studio 2012（以下、VS 2012）のメニューバーの［プロジェクト］－［ストア］と選択して、まずは［アプリケーション名の予約］を行う。Webブラウザが開き、サインインのページが表示されるので、サインインして、アプリケーションの名前を予約する。
その後、再び、［プロジェクト］－［ストア］と選択して［アプリ パッケージの作成］を選択する。再度、サインインを求められるので、サインインすると「アプリ・パッケージ」は数秒で作成される。プロジェクト・ファイルを作成したフォルダー内に、「AppPackages」というフォルダーが作成され、その中に、拡張子が「.appxupload」というファイルが作成されるので、このファイルを申請時にアップロードする。このファイルが作成されると、いよいよ「WACK 2.2」を起動するかどうかと尋ねられる（次の画面を参照）。
［Windows アプリケーション認定キットを起動する］ボタンをタップすると「WACK 2.2」が起動して、次の画面のように検証が始まる。検証作業には結構時間がかかる。気長に待つしかない。
数分後、検証が終了する。検証が成功した場合は「合格」と表示される（次の画面を参照）。
あくまでも筆者の経験上のことだが、デバッグで問題なく動作するアプリは、この「WACK 2.2」の検証で「不合格」になることはまずない。ただし、ロゴを作成していない場合は「不合格」となるので注意してほしい。
ただ、今までに数回「不合格」になったことはある。そのときの理由は失念してしまったが、「不合格」になった場合は「不合格」の理由も表示される。しかし、正直読んでも意味が分からなかった。そんな場合は、Windows 8を再起動し、再度「アプリ・パッケージ」を作成して、「WACK 2.2」で検証すると、ほとんどの場合、100％合格となるだろう。デバッグでは問題なくアプリは正常に動作するのに、検証で「不合格」になった場合は、Windows 8を再起動して再度チャレンジすることをお勧めする。
意味の分からないリジェクト理由
デバッグも問題なく、「WACK 2.2の検証」も合格になっても、リジェクトになることはある。「極意5」の「カテゴリとサブカテゴリの選び方」で紹介した「画像の合成」リリース2は、2回リジェクトされた。2回目が、カテゴリとサブカテゴリでのリジェクトだ。実はこのリジェクト以前に、次の理由で最初にリジェクトされていたのだ。
これだけのリジェクト理由を書かれても、さっぱり意味が分からない。この中で、まず目に付いたのが、「アプリには、ユーザー アカウントが必要ですか?その場合は、テスト アカウント 1 件を [審査担当者へのコメント] ボックスに含める必要があります。」という箇所だ。しかし、筆者はFacebookにアップロードするための、テスト検証用アカウントとパスワードは「審査担当者へのコメント」欄で知らせていた。よって、これがリジェクト理由ではない。
次に目に付いたのが、「・アプリでサポートするとしているすべてのアーキテクチャでアプリが動作しない。たとえば、あらゆる CPU で動作するとしている場合、そのアプリは ARM を含むすべてのアーキテクチャで動作する必要があります。」という部分だ。この部分でピン！ときた箇所があった。
VS 2012の「構成マネージャ」で「Any CPU」を選択
結論を言うと、先の「画像の合成」アプリを、約1年前に申請したときは、VS 2012のメニューバーの［ビルド］－［構成マネージャー］で表示される「Any CPU」の部分を、全て「x86」でビルドし、「アプリ・パッケージ」もx86用だけでしか作成せずに申請していた。もちろん、特に問題はないから認定はされたわけだ。しかしリリース2を申請する際、［構成マネージャー］は「x86」にしたままビルドし、「アプリ・パッケージ」はx64、ARM用も作成し、そのまま申請してしまった。x86用でしかビルドされていないのに、x64、ARM用としても申請したから、これら2つでは動かないわけだ。そのため、「そのアプリは ARM を含むすべてのアーキテクチャで動作する必要があります。」という理由でリジェクトされてしまった。
その後、［構成マネージャー］を「Any CPU」に直して再ビルドし、再度「アプリ・パッケージ」を作成し直して申請したら、カテゴリとサブカテゴリでリジェクトされた後、再申請して無事認定されたというわけだ。
先の画像の理由のように、いろいろリジェクト理由を書かれると、正直どれが本当の理由なのかが分からない。こんな場合は一応、全てのリジェクト理由に目を通して、自分で理解できる部分を修正すると、意外と、これだけで認定されることがある。リジェクト理由の難解さに、くじけることなく、自分の分かる範囲で修正して再申請すればいいと思う。それでもリジェクトされれば、今度は違ったリジェクト理由になるため、修正箇所もおのずと絞られて分かりやすくなる。
以上は、筆者の実体験から導き出した対処法で、参考にはしていただきたいが、必ずしも万人に適用できるものではないことをご了承いただきたい。
お知らせ
Windows 8の［検索］チャームで「ストア」を指定し、検索欄に、「kuniyasu」または「YakushijiKuniyasu」または「eightman」と入力すると、筆者の公開しているアプリの一覧を見ることができる。
■
今回はこれで終わりだ。今回の要件のポイントは2つある。Facebookなどに何かをアップロードするアプリでは、テスト用のアカウントとパスワードを審査担当者用に用意すること。「WACK 2.2」の検証で、アプリのバグ以外に何か不具合はないかどうかを検証すること。以上の2つだ。特に、「WACK 2.2」の検証は絶対に実行しておかねばならない。
筆者は1度だけ、1度は検証に合格しているし、コードを修正した箇所も、ほんのちょっとだから、「アプリ・パッケージ」を作るだけでいいだろうと判断して、この検証を行わないで申請したことがある。すると、ほんの1時間ほどでリジェクト・メールが来た。Windowsストアの検証の初期の段階（＝審査員による審査結果ではなく、アプリによる自動検証の時点）でリジェクトされたのだ。
一度検証に合格し、コードもほんの少ししか修正していないからといって、絶対に「WACK 2.2」の検証を省略してはならない。この点は十分に肝に銘じておいていただきたい。
最後に紹介したように、バグもなく「WACK 2.2の検証」でも合格しても、VS 2012のささいな設定ミスでリジェクトされることはある。こういったささいなミスは、「WACK 2.2の検証」でも引っ掛からない、各自が気を付ける以外に方法はない。そのためには、たくさんのアプリを作って経験を積んでいく以外に方法はないだろう、というのが筆者の結論である。
では、また次の機会にお会いしよう。
※以下では、本稿の前後を合わせて5回分（第4回～第8回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
6. 【現在、表示中】≫ 極意6： ユーザーがWindowsストアからアプリを入手したとき、そのアプリは完全に機能しなければならない
「アプリは完全に機能しなければならない？！」ってどういう意味？ 筆者の体験談から、マイクロソフトのテスターが「アプリが不完全だ」と判断する例と対処法を説明する。
7. 極意7： アプリは、キーボード、マウス、タッチで機能する必要がある
作成したアプリは、キーボードでもマウスでもタッチでも動く必要がある。この理由で申請をリジェクトされた場合の体験談と対処法を紹介する。
8. 極意8： アプリで広告を表示するために、説明、タイル、通知、アプリ バー、または端からのスワイプ操作を使ってはならない
収益を得るために広告を掲載する場合、何が良くて何がダメなのか。不合格になった認定レポートを紹介し、その対処方法を紹介する。
