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氏自身がこのトークの口頭原稿を公開しています。より詳しい情報を知りたい方はご覧ください。