レアジョブ唯一のアプリエンジニアの羽田です。
まだレアジョブではAppleTVアプリとかはやっていないんですが、前職や趣味でいくつかAppleTV開発に参画させていただいた経験から、ユーティリティ系などを作るときの勘所があるので今後開発される方の参考になればと思っています。
ご指摘などあれば編集リクエストなどを送っていただければ幸いです。
＊この時作ったアプリがApple Best 2016 AppleTVに選ばれました！！
1. 【作る前に】そもそも本当にやる必要があるのかどうか
AppleTVが販売されて半年以上経とうとしていますが、正直あまりまだ復旧しているとは言い難いです。
Apple tv tech talkに参加した時も販売台数とか聞きに行ってみたら、「んふふ、内緒！」みたいな感じで濁されましたし。
販売台数などは公開されていませんが、アプリのランキング上位のDAUなどを見てもまだまだこれからだと思っています。またいろいろな制約や、要求される体験のちがいがあり、これを認識していないとアプリを作るハードルが一気に上がります。
1_A. 要求される体験との親和性
Apple tv interface guidelineによれば、AppleTVではshared experienceという体験を提供することが推奨されています。
Create a shared experience. People often enjoy TV in a communal environment. Consider how your app can appeal to a group, as well as what happens if the user is a different person each time your app is launched.
これが何かというと、iOSやMacOSのアプリケーションは一人で使うのに対してtvOSのアプリケーションは複数人で大きな画面を見ながら触れることが前提になっています。
そのため、今リモコンを持っている人がどこに注目しているのか、それを実現するためにFocus engineというのが搭載されていたり、その他にも様々な仕組みが組み込まれています。
この体験と、これから作ろうと思っているものがマッチしているのか。これを検討してください。
例えば自分のみしか見る必要のない個人のライフログを観覧するアプリや、タスク管理アプリなどはiOSのほうが便利ですよね。SiriRemoteは正直そこまで操作性が高いとは言えません、文字列入力も大変です。あまりアクティブに操作する様なアプリケーションは向いていないと思われます。
AppleTVの体験とマッチしないものをわざわざ作るのは間違っています。
1_B. ブラウザがない問題
ご存知の通り、webブラウザがなくすべてAPI経由での開発になります。
そこで問題になってくるのが、webへ流入させたりが難しいので、既存のアプリやwebとは異なるエコシステムになってしまうことが多々あることです。
これは結構大きな問題で、動画サービスなどであれば自社コンテンツの動画を見るという体験をまずさせることができれば、そのポテンシャルはとても大きいのですが、ECやCGMのようなものはいかにサービス成長のためにAppleTVのコンテンツを使うか結構頭をしぼらないと出てきません。
また一方でそもそものユーザーの母数も少ないので、見込める結果についても期待値計算が難しいと思います。
1_C. 思ったより多い機能制限
iOSではあったような魅力的なセンサー類や、先述の通りブラウザがありません。
これにより、できることはより限られます。
また後述しますがtvOS用の言語であるTVMLやTVJSを使った場合さらに多くの制限が生まれるので、
まずアイデアがそもそも実装可能か？というのを公式リファレンスを見て確認してください。
＊作る前に
ここまで考えて「やっぱうちのサービスはAppleTV対応したほうがいい！」「このアイデアはAppleTVに向いている！」と思ったのであれば続きをどうぞ
2.【デザイン】大画面とリモコン操作
AppleTVでは画面とインターフェースが離れているので、リモコンと音声でこれを操作する仕組みがあります。
これによってモバイルやPCとはまた異なるデザイン思想が必要になります。
2_A.大画面
開発者としては嬉しいことに、tvOSは1Deviceだけなので複数デバイス対応や横幅対応などは必要ありません。
ただユーザーはテレビを見るので、シミュレーターで見ているよりももっと大画面で見ることが期待されます。
またアプリと異なり、画面とユーザーの距離が大きく離れています、スマホであれば見づらければ画面を近づければいいですがテレビだとそうもいかないですよね。
視聴距離の計算の例を見ると、一般的な画面と人の距離はテレビの高さの1.5倍から3倍で、大きく離れます。そのため文字の最小サイズやコンテンツサイズなど、思っているより大きなものが求められます。
大きいコンテンツが必要だということは、表示される画像の画質なども関わってきます。CGMの場合ユーザーが投稿する画像の画質が高いとは限らないので実際作ってみると残念な感じになることも・・・
2_B.リモコン操作
ユーザーは大画面の中の要素選択のためにリモコンをスワイプし、目的の要素にたどり着いたらクリックをしてやっと選択ができます。スマホの様にすぐ目的の要素をクリックすることができません。
そこでシームレスなアプリ体験のためにはコンテンツの連続性を考えなければいけません。
ユーザーがコンテンツにたどり着くまでのフローで混乱させない様な要素設計が必要になります。
このどの要素をフォーカスしているときに、どの方向にスワイプすると、フォーカスがどのように移動するか？みたいのはデフォルトで動く以外にも実装して指定することも可能です。エンジニアと相談してみてください。
3_C.画像リソース
アプリiconに関して異なる仕様で用意する必要があります。
Icons and Imagesを確認してみてください。
画像サイズは@1xで大丈夫。
All images on Apple TV are @1x resolution.
また画像はフォーカスされることによって見え方が変わることがあり、そのときに違和感のない様なデザインが必要になります。
3. 【開発】構成と設計と実装
AppleTVでは開発に使える選択肢がいくつかあります、実装言語や構成。
そこについて述べます。
3_A. 構成
スタンドローンなアプリケーションか、webのようなクライアントサーバ構成で作ることができます。
これらを比較してみましょう。
| スタンドアローンアプリケーション | クライアントサーバ構成 | |
|---|---|---|
| 開発言語 | swift/ObjC | TVML,TVJS |
| デバッグ | 楽 | 面倒 |
| リリース | 審査必要 | ネイティブに関わる変更・申請時のみ |
| クライアント | なし | サーバが必要 |
開発言語
TVML,TVJS・・・何言ってんだと思いますが、あるんです。
HTML,JSのtvOS版ですね。
TVML tutorialをみるとクライアントサーバ構成でTVMLを使って開発するやり方が載っています。
デバッグ
HTMLやJSとは結構違うし、Console.logとかでログを出せるんですが、tvOSのデバッグでTVJSのconsole.logを見る方法にも書いた様にSafariでログ見ないといけなくてきつい。
リリース・クライアント
サーバにクライアントのTVML,TVJSを置いて管理するのでアプリケーションの更新はサーバ側で行います。
ここは審査を待たずにリリースできるのでいいところかもしれません・・・と思ってましたが、結局webっぽい管理コスト（デプロイの仕組み、バージョニング、ログ管理、etc...）が必要になってきます。そのくせwebとは違うものなので、既存の便利な仕組みが使えません。
一方で当然メリットもあって、Templateがとても便利なことです。これはレイアウトを組むだけでなく、FocusEngineの仕組みや、アニメーション、フォーカス時にタイトルのラベルも一緒に拡大されるなどの細かいデザインの嬉しいものがいろいろ機能してくれるので本当にすぐアプリは作れます。
3_B. 設計・開発
設計に関してはデザインや開発前に考慮することで検討していた様なことが問題なければこれまでと変わりません。
気をつけるべきなのは開発ですね。
ライブラリ
cocoapodsでは対応していないライブラリも多くあります。AFNetworkingやSDWebImageのようなモダンで誰もが使っていそうなライブラリは結構対応しています。
UIImageView
画像をCollectionViewやTableViewの要素とするときに選択できる様にここのチェックをonにしなければいけません。実際にフォーカスは当たっていてもその視覚効果をつけるために必要なプロパティになります。
UITableView/UICollectionView
Mastering the tvOS Focus Engineをみると詳しく書いてあります、フォーカス管理のためのDelegateメソッドが追加されていて、これを使ってフォーカス管理をします。
フォーカスが次に当たるindexpathは以下の様にとれます。
func collectionView(collectionView: UICollectionView, shouldUpdateFocusInContext context: UICollectionViewFocusUpdateContext) -> Bool {
let selectedRow = context.nextFocusedIndexPath?.row
}
3_C.API
これに関しては既存のものをうまく使えばいいんですがね・・・
静的なjsonとかでもいいなってなれば、無料でホスティングできるサービスとかいっぱいあるのでぜひ使ってみてください。個人的にはAzureのフリープランを使うといいと思います。
githubと連携もできるし、すぐデプロイやオートスケールが使えます。以下の設定ファイルをルートにおけばデプロイがちょろっとできます。
<?xml version="1.0"?>
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".json" mimeType="application/json" />
</staticContent>
</system.webServer>
</configuration>
3_D.審査
24時間で通るっぽいです
＊20160601_次のバージョンの申請は24時間で通りませんでした！たまたまだった・・・
まとめ
今回開発に参加した以下のアプリでも上記の様なことを考えて実装をしました。
“テレビを窓に変える”、Apple TV向けに風景動画を配信する「LandSkip」
サービスとの親和性もありますが、新デバイスに対応することは多くの知見やモチベーションなどを生むのでエンジニアやデザイナーがクリエイターシップを持って開発を主導し、自社サービスの新たな価値提案をできるといいと思います。