REALITY iOSで使っている技術

REALITY iOSエンジニアのションローです。

同僚のはるがREALITY Androidの開発環境についての記事をあげていたので、だいぶ遅れましたがiOS版の記事を書くことにしました。

主にはiOSエンジニアの人に、REALITY iOSアプリの開発やチームに興味を持ってもらえるといいな！と思っています。

REALITYについて

このようなアバターを用いてライブ配信が出来るアプリで、多才で面白いユーザの皆さまが日々ライブ配信をしてくれています。

プロジェクトとして特徴的なのは、3Dコンテンツ部分をUnityで作り、それ以外をiOSネイティブ開発環境で作り、その2つをくっつけている部分です。

Unityの扱いは後述しますが、iOSチームはこのUnity部分以外の機能を開発しています。

歴史

Androidと同様に、REALITY iOSも2018年の夏にリリースされています。
厳密に言うと 2018/08/08にリリースされました。

ちなみにこのときのバージョンは1.0.1で、なぜ1.0.0でリリースされなかったかと言うと、自分がアプリ名をタイポしたからです。

この事件はREALITY iOS史上最大の過ちとしてgitのコミットに刻まれています。辛い。

チーム構成

iOSエンジニアチームは現在7名所属しており、Androidチームに比べると人数が若干多いです。
割と多才な人が多く、サーバサイド・Android・Unityなど他のプロジェクトへ貢献する事で人数に対する工数バランスがとられていたりします。

故に現在は採用においても「ピュアなiOS/Swiftの専門性」だけではなくそれ以外の専門性（Android, Unity, サーバサイド, 音声等メディアの知識等）を多少重視しています。

開発環境

記事執筆時 2020/11/2 時点では Xcode 12.1 を利用しています
また、以下のような開発支援ツールを利用しています

- タスクランナー
  - Makefile
- パッケージ管理
  - Bundler
  - CocoaPods
  - SwiftPM
- Lint / Formatter
  - SwiftLint
- ファイル/コード自動生成
  - XcodeGen
  - R.swift
  - Mockolo
  - LicensePlist
- CI / CD
  - Jenkins
  - fastlane

細かいツールを上げるともう少しあるのですが、代表的なものを上げました。

ツールの選定は割と自由にやっているのですが「開発に関わるあらゆるコマンドは全てMakefileから実行できる（ターゲットを作る）ようにする」というルールにしています。

利用ライブラリ

Rx
- RxSwift / RxCocoa
- RxDataSources
- RxOptional

Networking
- Alamofire
- Starscream
- HaishinKit.swift

UI / Animation
- lottie-ios
- SnapKit
- Eureka
- XLPagetTabStrip
- SwiftEntryKit

Datastore
- realm-cocoa
- KeychainAccess
- Default

Media
- Opus-iOS

Test
- XCTest
- RxBlocking / RxTest

こちらも代表的（多くのメンバーが触ってそうな）なものを上げました。

Rx系は随所で利用しており、ユニットテストも当然RxTestを利用して書いています。
RxTestを用いたイベントストリームのテストは慣れないと中々読み書きが難しいのですが、ユーザの入力や非同期処理がどういう順序で来ることを想定しているのか？が読み取れるので活用しています。

アーキテクチャ

アプリケーションアーキテクチャ
現在はそれなりに一般的な MVVM + CleanArchitecture を RxSwift を軸にして開発しており、エッセンスとして kickstarter/ios-oss や CleanArchitectureRxSwift を参考にしています。

プロダクト初期開発時は古典的な（Fat）MVCで作られてしまっており、年月をかけ徐々に移行している段階です。
移行において大切にしているのは「インクリメンタルに改善（移行）を行う」という事で、機能の開発と別系統で担当を立てた規模の大きいリファクタリング等は基本的行わないように注意しています。
大きな方向性はシニアメンバーが提示しつつも、全員がアーキテクトとして議論し、日々少しずつコードベース・プロジェクトを進化させられるチームになることを目指しています。

UIとレイアウト
主にStoryboardで定義しています。
サポートバージョンの問題もあり、SwiftUIへの移行はまだまだ進んでいません。
ただし、現状のREALITY iOSの運用ルールではiOS12のサポートを来年の3月いっぱいで終えるので、その後はSwiftUIを含めたiOS13系の様々な恩恵を完全に受けられるようになります。
iOSチームとしてはその時期を見据え、特定の画面や機能についてSwiftUIやCombineを試験的に導入しております。

画面遷移とDI
画面遷移周りはよく言えば自由、悪く言うと統一感が無い状態です。
開発当初は画面数があまり多くなかったので（言い訳）雑にやってしまい、そこからあまり改善できていません。
DIの仕組みもあまり整備されておらず、この2つをなんとかしたい！と思いつつもSwiftUIのことも考えるとややこしいなぁ、みたいな思いです。
一緒に考えてくれる人募集中です！

Unityとの付き合い方

Androidと同様にiOSもUnityで開発されたコードを取り込むフローが存在しています。

基本的にはUnityチームが開発したコードがFrameworkとして出力されるので、それをリンクするだけです。
Framework化の仕組みは、Unityバージョンの関係で公式のUnity as a Libraryを使えず独自に実装しており、独自ビルドフローのメンテナンスはiOSチームのメンバーが行うことが多いです。

Unity as a Library を使用する | Unity

独自方式Unity as a Libraryの概要については去年弊社にて行った勉強会で「ネイティブアプリとUnityアプリ統合への道」というタイトルで発表したので、そちらをご参照いただければと思います。

【開発編】WFLE VTuber Hackers Meetup Vol.02開催レポート | イベントレポート

上記の発表時は「c++レイヤーのクラッシュ」「Framework化」「シミュレータービルドサポート」が残課題だったのですが、c++レイヤーのクラッシュ以外は現時点で対応済みになっています。

現状の課題

作りたい機能はたくさんあり、一方で開発効率化やアプリ品質改善のための課題が山積みであります。
例をあげると

- 画面遷移、状態管理周りの整備
- Combine / SwiftUI など新しい機能を利用するための環境更新
- AVAudioEngine近辺でのクラッシュ
- Unityで実装された機能でのクラッシュ
- CI / CD 環境(Jenkins)のメンテナンスコスト

などなど。他にもたくさんあるので、iOSエンジニアの方が活躍する場は色々提供できると思います。笑

まとめ

RAELITY iOSの開発チームや環境についてざっくりまとめてみました。
Androidと同様に、3Dコンテンツ開発に利用するUnityをEmbedしている点が特徴的ですが、それ以外は割と一般的な開発環境であり、モダンで効率が良くなる新しい仕組みを取り入れる努力はそれなりに出来ていると思っています。

3Dコンテンツを用いたライブ配信アプリの開発であったり、課題の項目であげたような内容についてトライしたい！というiOSエンジニアの方は随時募集中ですので、ご興味ある方はぜひ応募頂けると幸いです。

応募までは行かないけどちょっと話を聞いてみたい！という人は以下のアカウントまでお気軽にお声がけください。

Tweets by tion_low