はじめに
こんにちは。モバイルテックリードの大澤です。 普段はあすけんのAndroid/iOSアプリを開発しています。今回はUIKitをメインにしたiOSアプリにSwiftUIを積極的に取り入れるための施策を実施しましたので、その取り組みをわかりやすくまとめました。
主に前回記事の続編になります。
この記事は、株式会社asken (あすけん) Advent Calendar 2024 の12/6の記事です。
UIKitベース時代
あすけんのiOS版は10年以上運用されているアプリです。
UIのレイアウトはOSSのSnapKitを利用してAutoLayoutで実装していました。storyboardやxibは数ファイルという状態です。
アーキテクチャはMVCをベースに実装していました。
SwiftUIベースへの移行
1. アーキテクチャの変更
SwiftUIベースの実装時のアーキテクチャを定めました。
基本となるコードはテンプレートから自動生成できるようにして実装コストを下げるようにしています。
詳しくは前回記事をご覧ください。
2. UIKitとの共存可能にする
下記の記事を参考にUIKitにUIViewとして、SwiftUIのViewを追加する仕組みを導入しました。
あすけんでは導入後に問題にはなっていないですが
UIHostingControllerSizingOptionsのintrinsicContentSizeを使う時にはパフォーマンスに影響を与える可能性があるので注意が必要です。
3. アーキテクチャの共通化
UIKitの資産を活かす仕組みを入れたのですが、アーキテクチャがMVCとMVIで揃っていませんでした。 そのため、ViewState(Model)とIntent、Routerをまとめて渡せるContainerの仕組みを追加することで、 UIKit も含めてアーキテクチャの共通化を図りました。
ViewStateの変数を@PublishedとすることでUIKitでも状態変更を受け取れます。
下記の記事が参考になりました。
4. SwiftUIのPreviewの有効化
共通化したことでモックデータを扱いやすくなり、Previewを活用する機運が高まりました。 しかし、あすけんアプリでは多くの依存を持つライブラリを導入した影響で何もしないとSwiftUIのPreviewがエラーになっていました。現在は対策を追加し、正常に動くようになりました。
SwiftUIのPreviewの判定をし、プレビューに関係ないコードを呼ばれないようにする。
下記の判定を追加し、エラーになるコードを呼ばれないように修正を入れました。
ProcessInfo.processInfo.environment["XCODE_RUNNING_FOR_PREVIEWS"] == "1"
プレビューのオプションを変更
2024年11月現在でXcode16.1でエラーが発生したため、Xcodeの「Enable Legacy Previews Execution.」を有効にしエラーを回避しました。(iOS17シミュレータではエラーが発生しない)
Editor -> Canvas -> Enable Legacy Previews Execution.
アプリを起動せずにViewの状態に合わせたUIの調整がしやすくなりました。
結果
前回の記事でも言及しましたが
SwiftUIの割合は5%前後で推移していたが、4ヶ月で約10%まで引き上げることに成功しました🎉
SwiftUIのUIの再利用性も高いので生産性アップを肌で感じてます。
「わたしの記録」の画面でもSwiftUIの導入が一部進みました。
askenでは新しい仲間を募集しています！
