SwiftUI, Jetpack Composeの導入で変化した「家族アルバム みてね」のアプリ開発体験

「家族アルバム みてね」では2023年中旬頃から本格的にSwiftUIとJetpack Compose(以下Compose)を利用して画面の実装をしています。現在は主に新規画面の実装にてSwiftUIやComposeを活用しており、UIKitやXMLを用いた画面の実装と比べて開発体験が大きく変化したと感じています。
本セッションでは本格的に利用し始めて見えてきた変化について、良かった点だけでなく現状抱えている課題や改善点も含めてお話します。

Transcript

1. ©MIXI SwiftUI, Jetpack Composeの導入 で変化した「家族アルバム みてね」 のアプリ開発体験 佐藤 光 みてねプロダクト開発部 プロダクト開発Dグループ アプリ開発チーム
2. ©MIXI 2 自己紹介 • 佐藤 光 @hicka04 • みてねプロダクト開発部 ◦ 2021年11月 中途入社 • ｢家族アルバム みてね｣(以下みてね)の1ユーザー • 好きなもの ◦ ラーメン ◦ ポケモン
3. ©MIXI 3 アジェンダ • ｢家族アルバム みてね｣について • SwiftUI, Jetpack Composeについて • 導入の背景と実装方法 • 導入で変化した開発体験 • まとめ
4. ©MIXI ｢家族アルバム みてね｣について
5. ©MIXI 「家族アルバム みてね」について • 子どもの写真や動画を家族と共有し、 コミュニケーションして楽しむサービス • 世界中の家族の”こころのインフラ”を作る ◦ 7言語 / 175の国と地域で展開 • 2015年4月 リリース • 2023年11月に利用者数が2,000万人(※1)を突破 ママやパパの「半数」が使うアプリに(※2) 5 ※1: iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 ※2:「みてね」登録時に入力されたお子さまの誕生日と厚生労働省発表「人口動態統計」から算出
6. ©MIXI 「家族アルバム みてね」について • iOSとAndroidは別々のコードベースで開発 ◦ iOS: Swiftメイン (95%) ◦ Android: Kotlinメイン (97%) • 職能にとらわれず実装する文化 ◦ iOSエンジニアがAndroidを実装したり ◦ AndroidエンジニアがiOSを実装したり • スクラムを採用 ◦ 1スプリント2週間 ◦ 各スプリントのゴール達成のために足りないところを協力しあう ◦ スプリントレビューでもらったフィードバックを元にブラッシュアップ 6
7. ©MIXI SwiftUI, Jetpack Composeについて
8. ©MIXI 8 SwiftUI, Jetpack Composeについて SwiftUI　 • WWDC2019 発表 • iOS13+ で利用可能 • View protocolに準拠し body にレイアウトを記述 Jetpack Compose(※) • Google I/O 2019 発表 • 2021/7 にStable • @Composable 関数に レイアウトを記述 • 宣言的にUI構築ができるライブラリ ※: 以下Compose
9. ©MIXI 導入の背景と実装方法
10. ©MIXI 10 導入の背景 • 職能にとらわれず実装する文化 ◦ 既存のUIKit, AndroidViewの書き方が難しい ◦ 新しい領域にチャレンジしづらい • デファクトになりつつある ◦ 少ないコードで直感的に書ける 宣言的UIの導入によって • アプリ開発の敷居を下げる • 開発体験の向上 ｢家族アルバム みてね｣にSwiftUIを導入しました
11. ©MIXI 11 実装方法 • MVVMアーキテクチャ • ViewModel: 画面の状態を管理 ◦ iOS: @Published ◦ Android: StateFlow • View: ViewModelが公開する状態を監視してUIを描画する ◦ 1つの画面: Screen ▪ ViewModelに依存する｢StatefulなScreen｣ ▪ 引数で受け取った値を使ってレイアウトを組む｢ StatelessなScreen｣ ◦ デザインシステムに定義されたコンポーネントを組み合わせてUI構築
12. ©MIXI 12 実装方法: SwiftUI StatefulなScreen StatelessなScreen
13. ©MIXI 13 実装方法: SwiftUI
14. ©MIXI 14 実装方法: SwiftUI • StatelessなScreenを使ってプ レビュー • プレビューに必要なデータを引 数で渡すだけ • ViewModelやRepository等 のMockが不要
15. ©MIXI 15 実装方法: Compose StatefulなScreen StatelessなScreen
16. ©MIXI 16 実装方法: Compose
17. ©MIXI 17 実装方法: Compose
18. ©MIXI 導入で変化した開発体験
19. ©MIXI 19 ① UIの記述が直感的 • SwiftUI, Compose自体の特徴 • 1つのファイルで完結する ◦ .storyboard or .xib + .swift → .swift ◦ .xml (layout, style…) + .kt → .kt • 同じファイル内でも上下に行き来することが少ない ◦ Delegate や Listener → Modifier ◦ 宣言と動作が1箇所に記述される
20. ©MIXI 20 ② ｢とりあえず動く｣を作るまでが早くなった • 早い段階でフィードバックを貰える ◦ 実装時に思いつかなかった機能の改善案が出る ◦ 早い段階でバグ検出 • 事例 ◦ 2週間毎のスプリントレビューに｢とりあえず動く｣状態で持っていき たくさんフィードバックをもらって活発な議論ができた ◦ デザインツール(Figma)では表現しきれないアニメーション周り ｢とりあえず動く｣状態のアプリを見ながらデザイナーと調整 • よりアジャイルに
21. ©MIXI 21 ③ iOSとAndroidの実装を行き来しやすくなった • SwiftUIとComposeの実装方法が似ている → 頭の切り替えがしやすい ◦ 主にそれぞれのプラットフォームでの記述方法に変換する作業になる ▪ HStack, VStack ↔ Row, Column ▪ ObservableObject + @Published ↔ ViewModel + StateFlow ▪ など • 職能にとらわれずに実装を進めるみてねにおいて大きなメリット ◦ スプリントのゴール達成に向けて協力しやすい
22. ©MIXI 22 SwiftUIとComposeの実装比較 　SwiftUI 　Compose
23. ©MIXI 23 　SwiftUI 　Compose SwiftUIとComposeの実装比較
24. ©MIXI 24 　SwiftUI 　Compose SwiftUIとComposeの実装比較
25. ©MIXI 25 　SwiftUI 　Compose SwiftUIとComposeの実装比較
26. ©MIXI 26 ④ プレビュー高速化のためにマルチモジュール化加速 • プレビューを確認するのに アプリを実行するのと同じかそれ以上の時間が必要になっていた • Screenのコードを別モジュールに移動する • 約3分 → 10~30秒 • 関連してビジネスロジックたちもモジュールへの移行が加速 ◦ Unitテストを単体で実行する場合の時間短縮 ◦ アプリ全体のビルド時間への影響はまだ軽微
27. ©MIXI 27 ⑤ SwiftUI, Composeの方が時間がかかる場合がある • 実現したい機能がSwiftUI, Composeで使えない ◦ 原因 ▪ SwiftUI: 下限OSバージョン (現在iOS15+) ▪ Compose: targetSdkVersionによって使えるバージョンが決まっている ◦ UIKit, AndroidViewで実装し直し • 実装開始後に使いたいコンポーネントが使えないことに気づく ◦ デザインシステムのコンポーネントは必要なときに実装する運用 ◦ 共通のUIパーツの依存関係が絡み合っていてモジュールに移動できない
28. ©MIXI 28 ⑥ UIKit, AndroidViewと連携する必要がある • ほとんどがUIKit, AndroidViewで実装されている ◦ 約10~20%がSwiftUI, Compose ◦ SwiftUI, Composeは、主に新規画面の実装で活用している ◦ 既存画面の置き換えは積極的に行われていない • 画面遷移はUIKit, AndroidViewに寄せている ◦ SwiftUIやComposeで実装された画面の割合が増えたら、再度検討 ◦ SwiftUIやCompose側の画面遷移のAPIの進化を期待
29. ©MIXI まとめ
30. ©MIXI 30 まとめ • SwiftUI, Composeによって、開発体験が大きく改善 ◦ UIの記述が直感的 ◦ ｢とりあえず動く｣を作るまでが早くなった ◦ iOSとAndroidの実装を行き来しやすくなった ◦ プレビュー高速化のためにマルチモジュール化加速 • 引き続きSwiftUI, Composeの推進は必要 ◦ コンポーネントの拡充 / 既存画面の置換 によって現状の課題を小さく ▪ SwiftUI, Composeのほうが時間がかかる場合がある ▪ UIKit, AndroidViewと連携する必要がある
31. ©MIXI