9月15日〜17日にiOSDC Japan 2017が開催されました。最終日の本編2日目も様々なテーマのもとに、32トーク、15LT、2企画トークが行われました。この記事では、この日の行われたトークの中から3つ取り上げて紹介します。

結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発

ベストトーク賞10位に入賞したトーク「結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発⁠」⁠。スピーカーはiOSDC 2017のコアスタッフでもある@motokiee氏です。昨年結婚式を挙げる際に作成したiOSアプリ開発に関する話を披露しました。

motokiee氏は結婚式において「みんなスマホで写真を撮るものの、新郎新婦にその写真が送られることがあまりない」ということを解決すべき問題として挙げました。その上で写真が送られない原因を「写真を撮ってから送るまでの間にすることや、何を使って写真を共有するかの意思決定をするコストが大きいから」であると考え、「⁠撮る」「⁠アップロード」を同時に行うことができるアプリの開発を決意したそうです。

しかしそう決めた時には結婚式まで1ヶ月を切っていた上に非常に多忙な時期と重なっていました。そこで結婚式に間に合わせるために課題を整理し、やらないことを決めていきます。「⁠ストアには出さず、DeployGateで配信する」「⁠（⁠もうすぐ出るSwift3ではなく）Swift2で開発する」そして「サーバサイド開発は行わず、Firebaseを使う」ということを決めました。

今回要件として挙げたことはFirebaseでほぼすべて実現可能でした。写真のタイムライン機能を実装するにあたってはDatabaseとStorageを、通知・お知らせ機能にはNotificationsとStorageを使ったそうです。Push通知に関してはその知見をiOSDCのアプリにも活かしています。

プロジェクトの進め方としては、やることを一元管理するためにGitHubのissueを使い、issueが更新されたらslackに通知するようにしたそうです。その際、非エンジニアの奥さんにもGitHubアカウントを作成してもらい、Push通知の文言の作成や配信のタスクを割り振ったそうです。このように奥さんにも手伝ってもらうことで、エンジニアという職業に対する理解、「⁠一緒にやっている感」を感じてもらうことに繋がったとのことです。

結果的に開発は間に合い、本アプリを用いて約200枚の画像がアップロードされたようです。

コード生成による静的なDependency Injection

ベストトーク賞の8位に入賞したトーク「コード生成による静的なDependency Injection⁠」⁠。@_ishkawa氏が発表しました。

最初はDIの基礎の説明から始まりました。DIは「必要なものを外から渡すこと」であると言い、画像ダウンローダを例にした説明がされました。

上記のコードは画像ダウンローダとしての要件は満たしています。しかしURLSession.sharedという固定のインスタンスを使っているため、URLSessionの挙動を変えたい時に差し替えがしづらくなってしまっています。そこで以下のようにコードを変えてみます。

initializerでURLSessionを外部から渡すことでDIを実現できました。これにより以下の効能が得られました。

• dependencyの切り替えが可能になり、その切替に際しImageDownloaderのコード変更は不要になった
• dependencyの詳細を必要以上に決めなくてよく、ImageDownloaderの責務を小さくできた

一方、デメリットも存在します。dependencyの詳細を決めてからインスタンスに渡すという責務が外部に生じ、複雑なdependencyを渡す場合はその責務が重くなってしまいます。

この例の場合、一番左のものを作るために一番右のものまでインスタンスを取得しなくてはいけないことになってしまいます。そこで右のものを自動的に取得する仕組みを作るという発想に至ります。

インスタンスを自動で取得する方法は以下の2つの方法が考えられます。

• DI用のinitializerを登録する
• DI用のprovider methodを用意する

概要はAndroidのDaggerを例にして説明しました。SwiftではAndroidのDaggerのようにアノテーションを使うことができません。そこで代わりに、プロトコルを作成してDIで使用できるものであることを示したり、SourceKittenというライブラリを使ってSwiftのコード構造を取得したりと独自の工夫を示しました。

プロトコルにした意味は以下の2つの理由が挙げています。

• provider methodの実装なしでこの構造が組める
  • テストなどで便利
• 利用時に必要なものが揃っていることが保証される
  • 提供不足であればコンパイルエラーになる

自動的に取得できない際にdependencyになる場合はresolveメソッドのパラメータで渡すことによって解決できるとしています。

なお、@_ishkawa氏自身がこのトークの口頭原稿を公開しています。より詳しい情報を知りたい方はご覧ください。

Human Interface Guidelineから滲み出る限界感を考える

埴生孝慈氏のトークは「Human Interface Guidelineから滲み出る限界感を考える⁠」⁠。Apple製のアプリに感じるHuman Interface Guideline（以下、HIG）との齟齬を読み解いていきました。

まず最初はApp Storeアプリのボタン、ボーダーについてです。一見iOSアプリらしくないように見えますがWebも含めた購入導線の一貫性が保たれており、HIGの「Consistency（一貫性⁠）⁠」が守られていることがわかります。

次にApp Storeアプリでトーストが使われている点についてです。この件についてはアラートを使わないようにするためにとった苦肉の策だったのではないかと解釈しています。HIGではアラートは重要な状況でのみ使用するべきということが言及されており、そのためにトーストを使ったのではないかと述べています。

Musicアプリでボールドフォントが使われていることについては要素を明確に区別するためではないかと述べています。HIGには「Clarity（明瞭さ⁠）⁠」という項目があり、そこでは読みやすいテキストやスペースを使って明瞭なUIを提供し、コンテンツの強調やインタラクティブ性の提供を行うべきとされています。さらにHIGのWhat's New in iOS 11の中でBolder navigationという項目が追加され、NavigationBarは大きく太いタイトルを使うべきと明示されていることを指摘しました。

以上の例から、Appleのアプリは一見HIGから逸脱しているように見えるが、その深部を探るとHIGの意図から外れていないと見ることができると言います。App Store審査ガイドラインを見ると「独自のアイディアを生み出し、それを形にしましょう」と言及されており、HIGの指針と一致していれば表現方法については独自のアイディアが許容されているようです。

これらを踏まえた上でどのようにHIGと折り合いをつけていけば良いでしょうか。HIGに愚直に従えばiOSアプリらしいアプリにはなるがそれが魅力に直結するとは限らず、より魅力的にするためにはHIGの指針を満たした上で独自に作ることが必要であるとのことです。その際にはAppleがどのようにHIGから逸脱しているかを参考にすると良いというアドバイスがありました。

ベストトーク賞

イベントのクロージングで、ベストトーク賞の発表が行われました。どのトークも非常に興味深いものではありましたが、その中でも参加者の投票によって上位10名に選ばれた人たちが表彰されました。ここでは上位3トークを紹介します。

• 1位：「RxSwiftのObservableとは何か」/ @gomi_ningen氏
• 2位：「ディープリンクの設計と実装」/ @ninjinkun氏
• 3位：「Build high performance and maintainable UI library」/ @KishikawaKatsumi氏

4〜10位までの詳細は公式ブログで紹介しています。興味のある方はご覧ください。

終わりに

今年のiOSDCも設計の話、Server Side Swiftの話、UIに関する話、他言語とiOSに関する話など様々なテーマのトークがあり、どれを聞こうか迷われた方も多いのではないでしょうか。

今年はオープニングの時、実行委員長の長谷川氏から「iOSDCはコミュニケーションの場です」「⁠輪になって話すときは人一人分のスペースを空けて、話に入りやすいようにしましょう」という言葉がありました。この言葉は参加者の皆さんに響いたようでAsk the Speackerを積極的に活用したり、ランチや懇親会時に様々な人との交流が行われる場面が見られ、トーク以外の場面でも学びある場になったのではないかと思います。

コアスタッフ@huin氏が製作した振り返り動画を見ると参加者の笑顔がたくさん見られ、スタッフ一同充実感でいっぱいです。

来年また、オーディエンス、スピーカー、スポンサー、スタッフ、いずれの形であったとしても皆様にお会いでき、そして一緒にiOSDCを作り上げられるよう心から願っています。