TestFlight Public LinkでiOSアプリケーションのベータ版を運用したときのお話

TestFlightにはPublic Linkという公開URLから一般ユーザーをベータ版へ参加させる機能があります。
この機能は2018年9月から使えるようになった機能です。

iOSアプリケーションをAppStoreにリリースする際にはガイドライン上、ベータ版という扱いでリリースすることが禁止されています。
そのため、公式にベータ版としてアプリをリリースするにはこのTestFlight Public Linkを使う必要があるのですが、
今回はこのTestFlight Public Linkで実際に mocri のアプリのベータ版を運用した際のお話をさせていただきます。

TestFlight Public Linkを利用した狙いとしては大きく以下の内容となります。

良い点

1. 事前にメールアドレスの収集が不要

TestFlight Public Linkを利用しない場合、TestFlightで配信したアプリケーションをユーザーにテストしてもらうには、
予め対象ユーザーのメールアドレスを収集し、テストユーザーとして登録しなければいけませんでした。
ですが、TestFlight Public Linkを利用すると招待URLを知っているユーザーであれば誰でもダウンロードが可能になります。

2. ストアにリリースするよりも緩い審査

TestFlightでベータ版をリリースする際(一般ユーザーへ公開する場合)も審査があります。
ただ、この審査はストアにリリースするときよりも緩い審査になります。
そのため、ガッツリ作り込まなくてもリリース可能となるケースが多いです。

3. ビルド番号だけを変更すればそのバージョンの初回以外の審査をスキップし、即リリースできる

これは公式にも記載があるのですが、なかなか気づいていない人も多いのではないかと思います。
TestFlightではバージョンを挙げた際には審査が入るのですが、ビルド番号についてはチェックしない仕様となっています。
つまり、新しいバイナリをリリースする際にバージョン番号をそのままにしてビルド番号だけを上げてリリースすると、
審査なしに即リリースすることが可能になるのです。
これは新しい機能を作って即リリースし、また少し修正してリリースするというサイクルを繰り返したいベータ版には打ってつけの機能です。

4. ベータ版という免罪符を得られる

冒頭でも説明させていただいたとおり、iOSアプリケーションで公式にベータ版を謳えるのはこのTestFlightでリリースしたアプリのみになります。
ベータ版なのでユーザーからみてもある程度不具合があっても許容してもらえるケースもありますし、
本リリースでは良くなっているかもしれないという期待も持っていただけます。
開発者からしてみれば開発する作業そのものに大きな違いはありませんが、ユーザーからの見た目としては大きく異なってきます。
これはアプリの機能をいち早くユーザーに試してもらいたいスタートアップには最適であると言えます。

以上がTestFlight Public Linkを採用した狙いだったのですが、
実際にアプリを運用していくうちにいくつか大きな問題点が見えてきました。
これはTestFlightの仕組みそのものの問題や、前述の利点がそのまま問題点につながっているものもあります。大きくは以下の内容となります。

問題点

1. TestFlightのアプリをユーザーが削除してしまう

TestFlight Public Linkを利用してアプリケーションをダウンロードする場合はTestFlightのアプリを別途インストールしておく必要があります。
これは開発者からしてみれば慣れたことで当たり前のことかと思いますが、一般ユーザーからしてみればダウンロード以外の用途では利用しない不要なアプリという印象になりがちです。
つまり、一度アプリケーションをダウンロードしたあとにTestFlightのアプリを削除してしまうユーザーさんが思ったよりも多かったというのが1つの問題点でした。
これがAndroidアプリの場合、オープンテスト版を利用すればGoogle Playのアプリが使えるので大きな問題とはならなかったのですが、(のちにAndroid版をリリースした際にはオープンテスト版で当初リリースさせていただきました)
iOSの場合は現状TestFlightアプリを利用しなければベータ版アプリを一般ユーザーにダウンロードしてもらうことが出来ません。

これの何が一番問題なのかというと、バージョンアップのお知らせがTestFlightアプリ経由では出来ないということです。
もしユーザーがTestFlightアプリを削除してしまった場合、配信したアプリ側で自前でお知らせ機能やPush通知などを行ってバージョンアップのお知らせをするしかないということになります。
不幸中の幸い、mocriではリリース当初からPush通知を利用していたため、大きめの機能追加があった際はPush通知にてバージョンアップのお知らせをしていました。

2. ビルド番号だけの変更で審査はスキップできるが、その分本審査時にリジェクトを食らう可能性が懸念される

これは簡単にいうと知らないうちにガイドライン違反をした状態でアップデートを繰り返してしまう自体が発生しかねないということです。
緩いとはいえ審査をスキップできるということは、極端な話一度審査を通ったあとに審査NGとなる内容をアプリに盛り込むことも可能になります。
あくまでTestFlightでリリースされているアプリはベータ版であり、利用可能な期限も90日と決まっているため許されている仕様です。
そのため、その状態でいざ本リリースをしようとそのままAppStoreへ配布しようとしたときに、リジェクトをくらって大きな修正を余儀なくされる可能性が高くなってしまうわけです。
これが小さな修正なら大きな問題にはなりませんが、アプリの仕様の根幹にかかわるリジェクト内容だった場合は最悪作り直しになる可能性もあるでしょう。

以上のことから、ビルド番号を上げて審査をスキップできるからといって、やりすぎるとのちに大きな問題となる可能性があります。
審査は1日あれば終わるので、ビルド番号を上げて即リリースするのは不具合修正だけにするなど、小さく留めた方が無難かと思われます。

3. ダウンロード可能ユーザー数に上限がある

TestFlight Public Linkで配布可能なユーザー数は10000ユーザーと仕様で決まっています。
これを超えるユーザーにアプリを配布する場合は、AppStoreへリリースするしかありません。
当初mocriでは細々とユーザーインタビューなどで協力していただいていたフォロワーさんへ向けてリリース告知をして、そこまで大きくダウンロードされることを想定してはいなかったのですが、ある日インフルエンサーの方にRTされたのをきっかけに非常に多くダウンロードいただける事態となり、一気にこの10000ユーザーという上限に達してしまったのです。

もっともこれは例外中の例外かと思いますし、嬉しい事態でもあったのですが、
まさか上限に達するとは全く想定していませんでした。(そもそも上限があったのかとそのとき気づいたくらい…)
iOSベータ版のダウンロード可能な記載も公式サイトから一時的に取り下げざるを得ませんでした。

こうなってしまうとTestFlightによるベータ版運用とは何なのか、というベータ版運用の定義そのものが怪しくなったため、
本リリースに向けた改修をいくつか行った上でAppStoreへリリースさせて頂いたのですが、
このような事態もあるということは頭の片隅にでも入れておいた方が良いかもしれません。
(ちなみに、Google Playのオープンテスト版にはこのようなユーザー数の上限はありません)

まとめ

mocriでの利用経験を振り返ると、正直なところTestFlight Public Linkは使いどころが非常に難しいなと思いました。
ただ、いち早く使ってもらいたい＆ユーザーからのフィードバックをある程度もらって改善した上でAppStoreへリリースするという手順を踏みたいプロダクトにおいては、このベータ版という運用は大きな利点につながるかと思います。
TestFightのアプリをダウンロードしてまでベータ版を使っていただけるユーザーさんは熱量の高い方が多いので、(いわゆるコアユーザーの方) 効果的なフィードバックも受けられやすいかと思います。

• iOS
• mocri