【iOS】【SwiftUI】KINTOかんたん申し込みアプリにおけるSwiftUI化についての話

この記事は KINTOテクノロジーズアドベントカレンダー2024 の4日目の記事です🎅🎄
 はじめにこんにちは。モバイルアプリ開発グループでiOSチームのチームリーダーをやっている中口と申します。

普段の業務では、
KINTOかんたん申し込みアプリ(以下「申し込みアプリ」とします。)
Prism Japan(スマホアプリ版/最近リリースされたばかりのWeb版)
のiOS開発を担当しています。
本記事では、担当している申し込みアプリをSwiftUI化することになりましたので、その過程や方針について書いていきます。
こちらのブログは
iOSエンジニアの方
SwiftUIのアーキテクチャに興味のある方
チームにおいてSwiftUIを導入することになった方
などに読んでもらえたら嬉しいです。


また、本記事は先日開催されましたKINTOテクノロジーズ×RIZAPテクノロジーズ Mobile Tipsでの発表を元に執筆させていただきます。

本記事では、ソースコードなどを用いた具体的なSwiftUI化の実例などは記載しておりません。

一方で、チームとしてどのようにSwiftUI化をすることになったのか、という過程の部分を中心に書いております。

チームでのSwiftUI化に悩みがある方などの一助になれば幸いです。
 ファーストリリースの時のアーキテクチャ選定申し込みアプリは2023年9月にリリースされました。

その際に選定された主なアーキテクチャは

UIKit
VIPER
Combine

でした。
2023年の3月ごろより開発が始まった本アプリですが、2023年に新規でiOSアプリを開発する場合「UIKit」にするか「SwiftUI」にするか結構迷いどころですよね??
この時期であればSwiftUIによる開発の方が世間的にもメジャーになっている感覚がありました。
ですが申し込みアプリではUIKitを選定しました。
その理由としては、本アプリが短納期であったことと、メンバーにSwiftUIに明るいメンバーがいなかったことが挙げられます。
新技術を使ってリスクを犯すより、慣れた技術を使って安定的にリリースすることを重視したためです。
ではファーストリリース後、どのような流れでSwiftUI化に至ったのか、次に書いていきます。

 SwiftUIへ移行したい：第1波2023年のファーストリリース後、バグ改修や小規模アップデート、リファクタリングなどを粛々と進めていましたが、その中で何か新しいことに取り組んでみたいよね、という話が出ました。
いくつかの候補が上がりましたが、その中で人気が高かったのがSwiftUIでした。


2024年の3月ごろにswiftUI化1回目の波が来る
チーム内にてSwiftUIを進めるかどうか議論したところ下記のような意見がありました。
●やる理由
SwiftUIへの興味
●やらない理由
チーム内にSwiftUIに精通したメンバーが不在
SwiftUIへの明確は必要性を感じない(その当時の時点で)
チームメンバーの入れ替えなどもあり新メンバーも多く、SwiftUIに着手している人的、時間的リソースが無い
私自身がチームリーダーとしてSwiftUI化をやり切れる自身がなかった


この時はやらない理由が多かった
こういった理由からSwiftUI化はまだ先と判断いたしました。

 SwiftUIへ移行したい：第2波それから、約半年が経ちました。

1on1などをやっていると、SwiftUIをやってみたいという意見はまだまだ多く、改めてSwiftUI化について議論することになりました。


2024年の8月ごろにSwiftUI化2回目の波が来る
第1波とは状況も変化しておりまして、再度議論したところ下記のような意見となりました。
●やる理由
SwiftUIへの興味が徐々に情熱に変わってきた
SwiftUI有識者が加入した(社内的な組織変更により)
当時の新メンバーが中心メンバーになっていき、チーム全体として人的、時間的リソースが確保できると感じた
●やらない理由
本当にSwiftUI化に着手して大丈夫かという不安


この時はやる理由が多かった
これらの状況からSwiftUI化を進めることと判断いたしました。

 目的を間違えてはいけないこのようにチーム一丸となってSwiftUI化を進めようとなりましたが、目的を間違えてはいけないと考えています。


(×) 技術的好奇心でSwiftUI化したい、が目的となってしまってはダメ

(○) 将来のメンテナンス性をあげる

 ・ デファクトスタンダードに追随する

 ・ Combineによる実装をしていたが、それが複雑化してきていまっているので脱却したい




(×) SwiftUI化することでアプリの質が落ちてしまってはダメ

(○) これまでと同水準以上の質を担保する




(×) 本来のリリースタスクを後回しにしてSwiftUI化を進めるなど、作業の優先順位を間違えてはダメ

(○) 追加機能はこれまでと同じペースで対応する

上記のことはしっかりと意識しつつ、チーム内でどのようにSwiftUI化を進めるか議論を進めました。

 SwiftUI化のアーキテクチャ選定チーム内でどのようなアーキテクチャを採用したいか議論しましたが、主な意見としては下記が挙げられました。
ライブラリは使いたくない
ViewModelは使いたくない




1.ライブラリは使いたくない


こちらは主にThe Composable Architecture(TCA)を指すのですが、ライブラリを使用するとその「アップデートを常に気にしなくてはいけない」、「サポートが終了したらどうしよう」、などの懸念点からなるべくTCAを使いたくないという意見が多かったです。

また、社内の別プロジェクトてTCAを使っているプロジェクトがあるのですが、そこでも使用感としても、「学習コストが高い」、「ライブラリのアップデートが早すぎてついていくのが大変」、「親Reducerの依存関係が強くなりすぎる」など課題を感じていたこともあり、TCAは見送りました。

2.ViewModelは使いたくない


SwiftUIのアーキテクチャにViewModelを採用するかどうかは、よく議論の対象になるかと思いますが、SwiftUIはすでにbindingの機能を有しておりMVVMを使うことでむしろSwiftUIの良さが活かしきれないのではないか、という意見が多かったです。

そのため、ViewModelを使わない方針で意見がまとまりました。

 MVアーキテクチャを採用その結果、我々のチームはMVアーキテクチャを採用することになりました。
図で示すと下記のような感じになります。



MVアーキテクチャ
Viewは原則Modelのみとやりとりを行います。

またAPIで取得したデータなどはモデルを介してViewに渡すようにしています。
現時点で我々はMVアーキテクチャに対して、
シンプルになり、将来的なメンテナンス性の向上につながる(Combine脱却)
ライブラリに依存しない
SwiftUIの機能を最大限に発揮できる
このようなメリットを感じており、上記のアーキテクチャ選定の議論で出たような内容を反映できたと考えています。


 SwiftUI化の導入部分における方針また、SwiftUI化するにあたって導入部分の方針として下記どちらにするかをチームにて議論しました。
まず個別のViewをSwiftUI化する
まず画面遷移に関する部分をSwiftUI化する
その結果、 「まず画面遷移に関する部分をSwiftUI化する」 という方針にてSwiftUI化を進めることになりました。
その理由としては
経験的に画面遷移にまつわる部分が後々つまずくことが多かった
遷移を管理するViewがUIKitのままだと、個別のViewをSwiftUI化したのにそれを(臨時的に)UIKitにwrapするケースが多く発生する
などの理由からです。

 SwiftUI化これからここまでSwiftUI化の過程や方針を書かせていただきましたが、申し込みアプリのSwiftUI化はまだまだ始まったばかりです。

本記事を掲載する2024年12月時点ではまだ、プロダクションコードにSwiftUIのコードは一切入っていません。
現在は、「毎朝行っている朝会の中で余った時間(20分くらい)を利用する」、「毎週1時間SwiftUIに特化したMtgを行う」など、SwiftUI化のためのコミュニケーションの時間を増やしております。
その中で一部のメンバーにより、SwiftUI化を進めるためのサンプルコードを用意してもらいそちらをベースにチームメンバー全体にレクチャーしたり、チーム内で共通認識を持つためのコーディング規約を整備し始めたところです。

今後もSwiftUI化の実装が本格化したらペアプロやモブプロなども導入していき、チーム全体としてSwiftUIのレベルを上げていきたいと考えております。