弊社iOSアプリにアーキテクチャを導入してみた

はじめに

サーバサイドチームに所属している丁(てい)です。

2016年の入社当初から今年の初めまで約3年半iOSチームに所属しながらネイティブアプリ開発をしていたので、今日はその中で弊社のiOSアプリにアーキテクチャを適用した過程などを紹介できればと思います。

当時のことを思い出しながらさまざまな紆余曲折などをしみじみと回顧しつつご紹介していく文章になるとは思いますが、お付き合いいただけますと幸いです。

ちなみにこちらの記事弊社Androidアプリにアーキテクチャを適用した内容が端的かつ整理された状態で紹介されているので、「お前のだらだら書く文章に付き合ってられねえわ」と言う方はこちらの記事をお勧めいたします。

当初の状況

私が入社した2016年5月時点での弊社iOSアプリは大体以下のような状況でした。

  • ほぼ全てのソースコードがObjective-Cで書かれている。
  • 初期開発時にWebViewで提供していた画面をネイティブに置き換えている最中。
  • ネイティブに置き換えた物はvoidメソッドが無数に存在しながら副作用しまくってるFatViewController状態。
  • 自動テスト?何それ美味しいの??

このような状況で当時流行りだったMVVM(+RxSwift)をObjective-Cでネイティブに置き換えたトップ画面に対してSwiftでリプレースしつつMVVM(+RxSwift)を試験的に採用してみようと言うことになりました。

ここで今振り返ると悪手だったのは当時のリプレース実装担当者も含めて全てのチームメンバーがアーキテクチャ(MVVM)に対しての知見があまりないまま採用して導入しまったことにより、コードメンテナンスが非常に困難な複雑で巨大なViewControllerが誕生してしまったことです。

「目玉焼きが焼ける」

上記のような状況でしたがチームメンバーの血と汗が滲むような量的努力により、なんとかサービスを提供するアプリとしてのギリギリの体裁は保っていました。(と思いたい)

そんな折、弊社iOSアプリのAppStoreレビューにこのような文章が書かれるようになります。

・アプリ使ってるとiPhoneがめっちゃ熱くなるんだけど・・・
・使ってる最中にすぐ落ちるからイライラする。
・iPhone熱くなりすぎ。目玉焼き焼けるんじゃね?w

実際に我々メンバーもリリース前テストなどでアプリを使ってるとiPhoneが発熱し使えば使うほど重くなり、最終的にはクラッシュすると言う事象を確認してましたが、ソースコードが整理されていないためどこに原因があるかを探ることすら困難な状況でした。

結構な発熱になるので「携帯カイロ機能搭載と言う名目で売り出せばいいんじゃね?」って言うあまり笑えない冗談を言いながらも、この課題に真っ向から向き合うことが出来ずに悶々とする日々を送っていました。

Androidへのアーキテクチャ導入

弊社はiOSと共にAndroidアプリをリリースしているのですが、先に触れたようにAndroidアプリにもいくつかの課題があり、それを解決するために外部から技術顧問の方を招聘して知識を借りながら当時チームリーダーだったW氏を中心にソースコードの整理とアーキテクチャの導入が先行して進んでました。

iOSアプリはというと引き続き前述の状況が続き、アプリの発熱、クラッシュの頻発などに加えソースコードの複雑性によりリリースのたびにバグが発生して対応に追われるという辛い状況が続いてました。

そこで弊社の偉い人とW氏とK氏と私で課題解決に関する議論を行った末、Androidに導入した知見を元にiOSにもアーキテクチャを導入してまずソースコードの見通しをよくしつつその過程で発熱、クラッシュの原因を炙り出して潰していくという方針が定まりました。

採用アーキテクチャの選定

iOSにアーキテクチャを導入するという方針が定まったことでようやくこの課題に対して一歩前に進める準備は出来ましたが、当時のiOSチームメンバーは正直「アーキテクチャ??何それ美味いの??」状態でした。

多少表現は大袈裟ですが、当たらずとも遠からずの状況でしたのでまずAndroidチーム所属だったW氏をiOSチームにコンバートして先陣を切ってもらいつつ、横で私がその知見を盗んで蓄積して他のチームメンバーに展開していくという作戦を立てることにしました。

まず最初に行ったのは「アーキテクチャ??何それ美味いの??」状態からの脱却のため、代表的なアーキテクチャをメンバーそれぞれが少し学習してからその内容を持ち寄って発表して、その中から弊社のアプリにマッチするものを選ぼうというものでした。

結論から言うとこの作業は無駄でした。 そもそもアーキテクチャに対する造詣が浅いので、多少MVVMやVIPERの記事を読んだところでその本質を理解できるわけがありません。

N氏と私でMVVMやVIPERに関する浅い知識を持ち寄って発表会を行いましたが全員いまいちピンと来なかったため、すでにAndroidアプリへの導入経験があるW氏の中にある程度知見のたまっているMVP(GUIアーキテクチャ)+CleanArchitecture(システムアーキテクチャ)を横展開で採用するということになりました。

※当初W氏が我々に説明するために書いた概要図がこちら。

MVP+CleanArchitecture構想図

終わりに

この記事を書いている2020年10月時点の弊社iOSアプリはほぼほぼSwiftでリプレースされており、まだまだ完璧な形とは言い難く課題はたくさんあるものの、ある程度ルール化されたアーキテクチャに則ってチームメンバー間で統一された思想のもとで開発が進められているせいで、残念なことに極端な発熱による目玉焼き機能は現在失われております。

今回はアーキテクチャの導入に至った経緯などをだらだらと書いただけの記事になってしまいましたが、次回以降はできるだけハマったポイントなどや失敗とそれに対する解決策などを語ることで、あわよくば同じような悩みを抱えている人の一助になれれば良いなという思いを頭の片隅に置きながらだらだらと書いていこうと思います。

現在の状況に至るまでの過程をこれから何回かに分けてゆるく書いて行くつもりです。 次回は導入計画立案や導入当初にあった出来事などを書いてみようと思います。


弊社では一緒にプロダクトを改善していただける仲間を探しています!

こちらでお気軽にお声がけください!

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです