旧TestFlightからiTunes Connectに統合された新TestFlightへ

広告:超オススメUnity Asset
  広告:超オススメUnity Asset

ついに神サービス「TestFlight」(以下、旧TestFlight)が終了し、iTunes Connectに統合されたTestFlight(以下、新TestFlight)のみとなる日が来てしまいました。
(昨年のMEMOによると、ちょうど1年ほど前にアップルに買収された感じですね。「iOSアプリ開発に便利すぎるTestFlightがAppleへ」)

毎日便利に使っていただけに、このサービスの移行はかなり面倒そうです。
また、名前は同じものの、サービス自体もだいぶ変わりそうで、メリットデメリット、人それぞれいろいろと出てきそうなところです。

実機をMacにつなぐことをあまりせず、超簡単なテストアプリですら、TestFlightで配信してきた僕にとっては、移行する際に、大きな山がいくつかありました。その記録をMEMOしておきます。(このMEMOでは、外部テスターの実験はまだやっていません。内部テスターのみです。)

00

追記(2015.2.27):完全に旧TestFlightサイトにはアクセスできなくなっちゃいましたね。リダイレクトされるようになりました。↓

TestFlight has moved

雑感

僕が利用してきた機能は、TestFlightの中でも一部の配信機能のみだと思いますが、その中でもいい面悪い面が感じられましたので、まず羅列しておきます。

悪くなった点

  • テスターのAppleIDのメアドが、普段あまり確認していないメールの場合、メールによるテスターへの通知が役に立ちにくそう。(TestFlightアプリの通知機能が頼りになる)
  • 内部テスターに登録すると全部のアプリがテスターに見えてしまう。(これデカイ)
  • プレリリースアプリを配信するためにiTunes Connectへアップロードする際、機械的なチェックが厳しい。(申請時本番と同等レベル)
  • 気軽なアプリをバンバン登録するとiTunes Connectのアプリ一覧がごちゃごちゃになってイヤ
  • 外部テスターレベルの人への配布は、審査が必要な分手続きに時間がかかる
  • 過去ビルドにさかのぼることができない。(アクティブな最新ビルドのみ)
  • ビルドのリリースノートが書きにくい。(アップロードし終わるとすぐにテスターに通知が行くので、リリースノートを記載するのが通知より後になりそう)
  • Xcodeのベータ版では、外部テスターレベルの人への配布ができない。(配布できるのは、Xcodeのリリース版でビルドされたものに限定されている)

良くなった点

  • Apple純正の場所を使ってプレリリースアプリを配布できる
  • UDIDの収集などをせず、AppleIDのメアドさえわかればテスターにできる
  • テスター登録がAppleIDのみになったので、外部テスターレベルのユーザーの追加は比較的気楽にできそう
  • 本番と同じレベルで機械的なアプリチェックができるので、TestFlightの段階でチェック可能。

このMEMOの流れ

すでにApp Storeで配布済みのアプリの次バージョンのテストを行うには、これほどまでのトラブルはないと思いますが、新規のアプリを新TestFlightで配布する際、いろいろと出てくると思われます。僕がぶつかった問題の流れを最初にリストしておきます。

  1. 新TestFlightでの配布に必要なプロビジョニングプロファイルがない
    →「App StoreへのDistribution用プロビジョニングプロファイルの準備
  2. iTunes側にそのAppIDのアプリが準備されていない
    →「iTunes Connect側にアプリの受け皿を用意
  3. アプリにアイコンをつける必要あり
    →「仮でもいいのでアイコンを準備
  4. debug用のframeworkとか含んでちゃだめ
    →「自作Frameworkのリンクを本番用に修正
  5. ビルドのアップロードが成功したらアプリにそのビルドを反映させる
    →「ビルドの登録
  6. いよいよTestFlightのテスター登録
    →「内部テスターの準備
  7. 自分以外のテスターへの配布
    →「自分以外の内部テスターを追加

App StoreへのDistribution用プロビジョニングプロファイルの準備

旧TestFlightでは、Ad Hoc用のプロビジョニングプロファイルを使っていたため、新TestFlightに切り替えた時点で、Distribusion用のプロビジョニングプロファイルが必要になります。それがない状態でアーカイブしたものをApp Storeへアップロードしようとすると、こんなエラーが出ました。

No matching provisioning profiles found for “Applications/XXXXXX.app”

01

今後、いくつものアプリで新TestFlight配布用に使えそうなプロビジョニングプロファイルを作っておきます。iOS Dev Centerの「App IDs」に行って、汎用的なプロビジョニングプロファイルを作ってみます。

その際、Bundle IDは、「*」(アスタリスク)だけにしておくことで、いろいろなアプリでそのプロビジョニングプロファイルが利用できるようになると思います。

02

App IDが用意できたら、次に、Distribusion用のプロビジョニングプロファイルを作成します。

03

新TestFlightでは、Ad Hocではなく、App Store用で。

04

先ほど作成した「XXXXX.*」となっているApp IDを選択。

05

iOS Distribution用のcertificateを選択。(なければ、certificateのセクションで作成)

06

適当な名前をつけて「Generate」で。僕は新TestFlightのためにこれを使うつもりで「MUSHIKAGO APPS BETA」としておきました。

07

XcodeのPreferences>accounts>View Detailsにてリフレッシュボタンを押すと、先ほど作成したiOS Distribution用のプロビジョニングプロファイルが現れると思います。

08

Build SettingsのProvisioning Profile欄で確認しても、先ほど作成したものが存在していることがわかります。

09

ここは、そのまま「Automatic」でいいでしょう。適切なものがあれば、探してビルドしてくれると思います。

10

この状態で「Producs>Archive」でビルドします。

11

OrganizerでそのビルドをSubmitします。

12

途中では、これが出てきたら、先ほど作成したプロビジョニングプロファイルを持つアカウント(通常は自分のアカウント)を選択。

13

いよいよSubmit。

14

アップロードされて・・・さて、どうなるか(次のトラブルへつづく)

15

iTunes Connect側にアプリの受け皿を用意

旧TestFlightの感覚でいくと、初めてのアプリをアップロードした場合でも自動的に新規アプリを登録できましたが、新TestFlightでは、iTunes Connect側に先にそのiOS Appを登録しておかないとこんなエラーが出ます。受け皿を作っておいてから、ビルドをアップロードする流れになります。

iTunes Store operation failed.
No software with CFBundleIdentifier of ‘xxx.xxxxxxx.xxxxxx’ exists.
Verify your bundle identifier is correct. ・・・

16

これはアップロードしようとしているアプリのIDがiTunes Connect側にないぞ、というときに出るようです。iTunes Connectの「マイ App」で「新規 iOS App」を作成して受け皿を準備しておきます。

「+」を押して「新規 iOS App」を選択。

17

アプリの情報を入れます。バンドルID欄では、先ほど作った「*」になっているものを選択。すると、「バンドル ID のサフィックス」欄が現れるので、そこにXcodeでアプリを作成するときのBundle ID(XcodeのGeneral>Identityセクションにある「com.xxxx.XXXXX」みたいになってるやつ)を入力。で「作成」ボタンを押すと受け皿が作成されます。

18

作成されたアプリには「プレリリース」セクションがあり、こここそが新TestFlightなわけです。

19

では改めてアップロード・・・さて、どうなるか(次のトラブルへつづく)

20

仮でもいいのでアイコンを準備

旧TestFlightではアイコンのついていないアプリでも配布することはできました。ところが、新TestFlightはアイコンがないと機械的なチェックで受け付けてくれないようです。。。その時のエラーがこれ。

ERROR ITMS-90022: “Missing required icon file. ・・・

これはメンドクサイ。。

21

XcodeのGeneral>App Icons and Launch Imagesの「App Icons Source」にある「→」を押して、アイコンを適用していきます。

22

本番のアイコンでなくてもPNG画像を適切なサイズで適用しておけばいいと思います。急いでるときは、ひじょーに面倒なアイコンの作成。。僕のMEMOによると、まず、1024の正方形でPNG(透過なし)で作っておいて、以下の順番に縮小してファイルを用意していけばいいと思います。

180
152
120
87
80
76
58
40

これらをドラッグ&ドロップで以下のようにアイコン適用部分にはめ込んでいきましょう。ちなみに1024の透過なしPNGは、iTunes Connectのアプリサムネイルにつけてあげましょう。こちらはついでなので、マストではありません。

23

アイコンをつけて、Archive。

24

そして、アップロード・・・さて、どうなるか(次のトラブルへつづく)

25

自作Frameworkのリンクを本番用に修正

こんどのは、厄介そうなのが出ました。

ERROR ITMS-90087: “Unsupported Architectures. Your executable contains unsupported architectures ‘[x86_64]’.”

26

これは、僕のこのアプリならではのトラブル。。
[Xcode6] iOSアプリプロジェクト内にframeworkプロジェクト」で作ってきたように自作Frameworkを含んだ事に関係するエラーでした。

自作Frameworkをデバッグ用のものにリンクしていてはいけない感じです。つまり、iTunes Connectへのアップロードでは本番と同じデータをアップロードしないと怒られるわけですね。詳しくはまた別途MEMOを書きますが、Release用の自作Frameworkにリンクしたらこのエラーは出なくなりました。

これも旧TestFlightでは許してくれたのに、新TestFlightでは許してくれない事ですね。

ここまでのいくつかの山を乗り越えてようやく成功しました。この緑のチェックマークを見ると、えらくほっとしますね。

27

ビルドの登録

ArchiveしたビルドがiTunes Connectのアプリ受け皿に正しくアップロードされると、マイ App>アプリの「ビルド」欄に「+」が現われます。(アップロード成功してから5分くらい処理に時間かかるかも)

「+」を押すと、アップロード済みのビルドがあるのでそれを選択して「終了」。

28

ビルドを選択したら「保存」を押して反映させましょう。

29

ちなみに、一度アップロードしたビルド番号(バージョン表記は1.0.0でビルド番号はカッコ内の「(5)」部分。)のものは削除できないので、まったく同じビルド番号がついたものは、ビルド番号を変えないとアップロードできません。

アップロード時に

ERROR ITMS-4238: “Redundant Binary Upload. There already exists a binary upload with build version ‘x’ for train ‘1.0.0’”

28a

のようなエラーが発生します。ビルド番号を変えるには、General>Identity>Build欄です。

28b

適当に数値を足していけばいいと思います。(旧TestFlightの感覚だとコレ毎回やるの忘れますね、旧TestFlightでは不要でしたから。これ自動化できないかなぁ?)

内部テスターの準備

次にいよいよ、テスターの登録です。

まず、旧TestFlightのテスターと新TestFlightのテスターでは随分と閲覧できる範囲や役割などが違ってきます。単純に旧TestFlightのテスターをそのまま新TestFlightのテスターにすればいいというわけではなくなってくると思います。

また、新TestFlightでは「内部テスター」と「外部テスター」に大きく役割が分けられています。

内部テスター
内部テスターは、同じ開発環境で制作を共にしているような間柄でかなり信頼関係の深い人に限定されると思います。「テクニカル」という権限であっても、他のテスターの情報が見えたり、アプリの詳細部分を操作することができたりと、開発者とほぼ同等の権限が与えらえれてしまいます。(ここは将来的にもう少し権限の限定されたテストユーザの登録ができるようになってほしいところ)

外部テスター
旧TestFlightのテスターはどちらかというと、こちらに近いのではないでしょうか?(場合によるかな)
ちょっといろいろなデバイスでアプリのテストをし、フィードバックをもらいたいというケースでは、テスターはこちらの方が向いています。
が、プレリリース段階であってもアプリ配布の際に審査があるのと、Xcodeβ版では外部テスターそのものが扱えないというデメリットがあります。

僕のこのアプリは、Xcodeβ版のアプリなので、内部テスターを登録していくことにします。

とりあえず、「ビルド」セクションにある「TestFlightベータ版テスト」のスイッチをオンにし、「内部テスター」をクリック。

30

まだ、自分自身も登録されていない状態になってると思います。「ユーザと役割」ページでテスターの準備をします。その後、このアプリのテスターとして招待するような流れです。

31

まず、ユーザと役割の内部テスターで自分自身のApple IDにチェックをして「保存」し、自分自身を内部テスターにしましょう。

32

マイ App>アプリ>プレリリースページに戻り、アップロードされているビルドをクリックします。そのビルドの詳細情報を記載できるので、ここにリリースノート的な内容を書き込みます。

33

次に内部テスターセクションを開き、先ほど内部テスターとして登録した自分自身のApple IDにチェックを入れ「招待」ボタンを押します。当然ながらこれは最初の一回だけで、次ビルドから一度登録したテスターに対して新ビルドの通知が行くようになります。

34

内部テスターを X 人招待しますか?のアラートが出るので「招待」を押します。

35

Apple IDとして登録してあるメアドのメールを確認してみます。ここで注意ですが、このメール、5分くらい時間がかかることがあります。迷惑メールとして弾かれたのかとか、いろいろ探していたら、時間が経ったら普通に届いたりしました。

36

メールにある「Open in TestFlight」をクリック。

37

Apple製のTestFlightアプリが起動します。インストールされていなければ、App Storeが開くと思います。旧TestFlightのアプリみたいなやつもまったく同じ似たようなアイコン画像で「TestFlight」という名前なので気をつけてください。(旧TestFlightがあったら、混乱するので削除しちゃっていいと思います)

「INSTALL」を押します。

38

インストールされると「OPEN」となるので、そのボタンで起動することができます。

39

もし、旧TestFlightですでに同じプレリリースアプリをインストールしていた場合、以下のようなアラートが表示されると思います。上書きして入れ替えちゃってもいいでしょう。おそらくアプリ内のデータを維持したまま入れ替えられると思います。

41

これでようやく新TestFlightで配信することができました!
大変なのは、最初だけで、これ以降は楽にビルドを配信することができると思います。

試しに、新しいビルドをアップロードしてみると、アップロードして間もなく自動的にメールとTestFlightアプリ経由でテスターに通知が行きました。
(旧TestFlightでは、アップロードしている間を使ってリリースノートが書けましたが、新TestFlightでは新しいビルドのためのリリースノートを書くタイミングがないぞ??。。。)

42

自分以外の内部テスターを追加

これは自分を追加したときと、流れはほとんど同じですね。ただ、人によってはApple IDのメアドは普段あまり読んでいないメアドに登録している可能性もあるので、そこだけ注意ですね。招待するメアドがApple IDのメアドなのもちょっとネックです。

43

「ユーザと役割」で氏名を入れて、相手のApple IDを入れて「次」。

44

次の警告メッセージは一瞬混乱するのですが、すでにApple IDにあるメアドですよ、というメッセージのようです。相手のメアドは当然普段使っているApple IDなので、これは、このまま「次」でいいのだと思います。

45

「Technical」でいいでしょう。(もうちょっと低い権限が欲しいところですが。。)

46

ここは何も変更せずに、そのままで保存。

47

これで、テスターの方にメールで通知が行ったはずです。が、この処理に5分〜10分くらいかかるようです。すぐに行かないので注意。

48

これは、テスターの方の確認メールのショットですが、こんな感じ。Activate your accountをクリック。

48a

Acceptをクリック。

48b

ログイン後の画面は、こんな感じ。まさに開発者同等レベルの画面で、

48c

アプリもすべて見えます。内部テスターは、このことを踏まえて、信頼関係の深い共同開発者の方を招待するようにすべきだと思われます。

48d

招待したテスターでも以下の作業はできるんだと思いますが、一応、自分のアカウントに戻って、今度は、新しく登録したアプリ(この例では、WoodenHeadというアプリ)の内部テスターとして、そのユーザを招待します。この矢印を付けた人が新しいテクニカルテスターです。

49

ユーザと役割の内部テスターとしてマークして保存します。

50

マイAppのプレリリースページに戻り、内部テスターセクションを確認。内部テスターとして登録した人が現れているので、チェックマークをつけて、このプレリリースアプリの内部テスターとして招待します。

51

チェックマークをつけると、「保存」ボタンのところが、「招待」になるので、

52

招待します。

53

こちらはテスターのメール画面のショットです。PCメールで確認したときのショット。

53a

「Open in TestFlight」を押すと、「iOSデバイスでこのメールを開いてね」というメッセージになって先に進めません。iPhone/iPadなどのデバイスでこのメールを確認してもらいましょう。

53b

iPhoneで同じメールを確認した画面。「Open in TestFlight」を押すと、

53c

Apple製のTestFlightアプリがインストールされてなければ、App Storeが起動すると思います。アイコンとアプリ名が旧TestFlightのものと同じな似ているので要注意です。(旧TestFlightの方は厳密にはアプリではなくショートカットですが)

53d

入手を押してインストール。TestFlightアプリはこんな感じ。

53e

起動して、最初の起動では、Acceptを。

53f

このTestFlightの通知機能はオンにしておきましょう。新しいビルドがアップされると、iOSの通知機能で知ることができるようになります。

53g

最終ビルド(新TestFlightではアクティブなビルドがひとつだけあります)が表示されているので、INSTALL。

53h

旧TestFlightで同じものを配信していたテスターの場合は、すでにインストールされている可能性もあり、このようなダイアログが出ますが、ここは上書きしちゃいましょう。

53i

これでようやくテスターにプレリリースアプリを配布することができました。

53j

このような感じで、最初の最初は手間がかかりますが、一度登録してしまえば、あとはiTunes Connectに新しいビルドをアップロードするだけで配布できるため、テスティング環境としては、十分便利に使えると思います!

また、このMEMOでは、外部テスターの実験ができていませんが、またの機会にやってみようと思います。