11月20日と21日の2日間，東京・お台場のグランドニッコー東京 台場で開催されたLINE（⁠株⁠）の技術カンファレンス「LINE DEVELOPER DAY 2019⁠」⁠。本稿では，その中から「Production」をテーマに11月21日に開催されたChristopher Rogers氏と伊藤宏幸氏によるセッションの模様をお届けします。

「iOS版LINEの成長」by Christopher Rogers氏

LINE App Dev 4チーム Senior Software EngineerのChristopher Rogers氏より，「⁠iOS版LINEの成長」というテーマでセッションが行われました。

LINEアプリのコードは，バージョン9.18になるまでの間に3万から140万行に増えています。このような大きさになると，エンジニアリングの観点からも多くの問題が出てきます。これらの問題をどのように整理／解釈し，解決していったのでしょうか。

ライブラリの依存性

まずは「依存性」の問題。ライブラリをアップデートするときに，ほかのライブラリとの互換性を確認する必要があります。ときには，ヘッダやサーチパス，C++の標準ライブラリなどのビルドセッティングも，アップデートしなければならなくなることもあります。

そこで導入されたのが「CocoaPods」であり，これはXcodeと統合しやすいという利点があります。ただし，デフォルトの挙動を変更する必要があったため，CocoaPods の高度な使い方をする必要がありました。

2014年からはSwiftを使い始めましたが，CocoaPodsはSwiftに対応していませんでした。そこで，Swiftの依存パッケージを追加するために，「⁠Carthage」も同時に使うことにしました。Carthageはフレームワークのプレビルドを行うため，Xcodeとの統合はほとんどできませんが，Romeによるリモートキャッシュを利用できるようになりました。

Romeのリモートキャッシュを利用することで，サーバ上でCarthageの生成物をキャッシュでき，ライブラリのアップデートがない限りリビルドをする必要がなくなりました。ただし，リモートキャッシュがポイゾニングされることがあったため，QAビルドやリリースビルドで使えないという問題がありました。

アプリの起動時間の問題

続いて，アプリの起動時間がどのように影響を受けたかという話題に。起動時間が長くなった理由の1つが，「⁠動的フレームワーク」です。Carthageを使い始めたことにより，多くの動的フレームワークが使われるようになりました。この問題に対する同社のソリューションはシンプルで，すべて静的フレームワークにしようというものでした。

Xcodeをコンフィギュレーションしながら静的フレームワークを作るには，まず動的フレームワークのターゲットを作成し，ビルドターゲットの設定を開いて，Mach-O typeを「Static Library」に変更します。基本的にはこれで完了です。

ほとんどの動的フレームワークを静的フレームワークに変換したことで，起動時間が1.6秒ほど短縮したとのことです。

Objective-CとSwiftのブリッジング

続いて，Objective-CとSwiftのブリッジングの話題に移ります。さまざまな事情から，Objective-CのカテゴリをSwiftクラスで定義したいときがあります。しかし実際にやってみると，いくつかの理由でできないことがわかります。たとえば，クラスの定義が必要というものです。そこで，Swiftで生成されたヘッダをインポートしようとしてもうまくいきません。なぜなら，生成されたヘッダとブリッジングヘッダの間には依存関係の循環があるからです。

LINEでは別の問題として，SwiftクラスのインスタンスでカスタムObjective-Cネームが付けられているものがあり，それがブリッジングヘッダの中では使えませんでした。これらはSwiftからは見ることができません。

これまでは，こうしたインスタンスがコードベースに多数ありましたが，Swiftもこうしたものに対して改善されてきています。そのため，現在では，問題のあるクラスは1つだけになっています。