よると「サービス終了。以下の文章は早速「当時こういうものがあった」というものになってしまいました。TestingはClutch.ioによるA/Bテスト実行のフレームワーク+ウェブサービス。属にいうモバイルBaaSの内の更にA/Bテスト実行に特化した作りになっているところが面白いと思いましたのでここで紹介します。Clutch.ioとは?iOS/Androidに対応したモバイルアプリケーション開発基盤を提供するサンフランシスコのスタートアップが運営しているサービス。Frameworkを提供してたんだけど、最近A/Bテストの方に注力してきた。ここで言うA/Bテストウェブ業界のランディングページ最適化のようなサイト一部の見た目を切り替えるのが典型的な例。iOSアプリの事情でいうとウェブアプリのように柔軟に内部処理の切り替えや平行的実験をすることが難しいので、従来は単純にウェブサイトを埋込むことで行われてきた。Testingのアプローチは,まずA/Bテスト=実験に使うデータだけをキー・バリュー構造に定義してサーバーからクライアントへ配信できるようにしておき、実験が「達成」した時に今度はクライアントがサーバにその通知をする。するとその統計情報をClutch.ioのダッシュボードで閲覧・分析ができるようになる。DocumentationテストコードBlocksベースのメソッドを使用する。goalReached:@"loginButtonColor"];詳細はドキュメント参照。Documentation不満だった点Goalの段階設定が足りない。例:ゴール=ユーザー登録完了→ボタンをタップしたけど完了まで操作してもらえなかった/ボタンをタップしてもらえなかったプランについてfreeプランでは1つのアプリ、月に5000ユーザーのアプリ起動までに制限されてる。これダッシュボード上は無制限に検証用にアプリを作成できて、本番に有効化できるのが1個だけとかだと使いやすいのに、と思いました。Testingはfreeプランでは利用でなかったので改善される余地はあるかもしれない。組込むことのオーバーヘッドについてClutch.ioのサーバーにA/Bテストに使う値を取得しに言って結果を送信していることによる通信処理の負担はないのか気になっている。一応ネットワークが利用不可の時は以前にダウンロードしたデータを使いまわして、結果はネットワークが復帰した時に再度サーバーに送信されるようになる。個体識別方法についてサービスの性質上、各端末を区別しないといけないので個体識別の値を取得しているものと思われる。・MACアドレスのハッシュ値が利用されると書いてある。今のところ一方向的は送信のみなのでこのハッシュ値を元にサーバー上の個人のデータが取得できる、というようなことはなさそう。アプリ間で端末を同定する必要もなさそうなのでUUIDでよさそうだが、このへんClutch.ioの「月あたり何ユーザーまではこの月額プラン」というビジネスモデルが関係しているのかもしれない。自分が使ってみた限りでは特にアルファ版とか実験的とか謳っているわけではないんだけど、実用的な段階には程遠いと感じました。アプリを作成できるけど削除、変更できなかったりと。前述のとうりコンセプト自体は面白いと思うし発展の余地もありそうなので取り上げました。アプリをバンバンリリースしている会社なんかは既に同じような社内向けシステムを構成しているのかもしれません。サーバーアクセス解析などとは違ってデスクトップアプリの統計情報送信に近いのでユーザー同意やオプトアウト設定などまだ課題があると感じました。