Tweet
Tweet

Slide 1

Slide 1 text

©MIXI SwiftUI, Jetpack Composeの導入 で変化した「家族アルバム みてね」 のアプリ開発体験 佐藤 光 みてねプロダクト開発部 プロダクト開発Dグループ アプリ開発チーム

Slide 2

Slide 2 text

©MIXI 2 自己紹介 ● 佐藤 光 @hicka04 ● みてねプロダクト開発部 ○ 2021年11月 中途入社 ● ｢家族アルバム みてね｣(以下みてね)の1ユーザー ● 好きなもの ○ ラーメン ○ ポケモン

Slide 3

Slide 3 text

©MIXI 3 アジェンダ ● ｢家族アルバム みてね｣について ● SwiftUI, Jetpack Composeについて ● 導入の背景と実装方法 ● 導入で変化した開発体験 ● まとめ

Slide 4

Slide 4 text

©MIXI ｢家族アルバム みてね｣について

Slide 5

Slide 5 text

©MIXI 「家族アルバム みてね」について ● 子どもの写真や動画を家族と共有し、 コミュニケーションして楽しむサービス ● 世界中の家族の”こころのインフラ”を作る ○ 7言語 / 175の国と地域で展開 ● 2015年4月 リリース ● 2023年11月に利用者数が2,000万人(※1)を突破 ママやパパの「半数」が使うアプリに(※2) 5 ※1: iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 ※2:「みてね」登録時に入力されたお子さまの誕生日と厚生労働省発表「人口動態統計」から算出

Slide 6

Slide 6 text

©MIXI 「家族アルバム みてね」について ● iOSとAndroidは別々のコードベースで開発 ○ iOS: Swiftメイン (95%) ○ Android: Kotlinメイン (97%) ● 職能にとらわれず実装する文化 ○ iOSエンジニアがAndroidを実装したり ○ AndroidエンジニアがiOSを実装したり ● スクラムを採用 ○ 1スプリント2週間 ○ 各スプリントのゴール達成のために足りないところを協力しあう ○ スプリントレビューでもらったフィードバックを元にブラッシュアップ 6

Slide 7

Slide 7 text

©MIXI SwiftUI, Jetpack Composeについて

Slide 8

Slide 8 text

©MIXI 8 SwiftUI, Jetpack Composeについて SwiftUI　 ● WWDC2019 発表 ● iOS13+ で利用可能 ● View protocolに準拠し body にレイアウトを記述 Jetpack Compose(※) ● Google I/O 2019 発表 ● 2021/7 にStable ● @Composable 関数に レイアウトを記述 ● 宣言的にUI構築ができるライブラリ ※: 以下Compose

Slide 9

Slide 9 text

©MIXI 導入の背景と実装方法

Slide 10

Slide 10 text

©MIXI 10 導入の背景 ● 職能にとらわれず実装する文化 ○ 既存のUIKit, AndroidViewの書き方が難しい ○ 新しい領域にチャレンジしづらい ● デファクトになりつつある ○ 少ないコードで直感的に書ける 宣言的UIの導入によって ● アプリ開発の敷居を下げる ● 開発体験の向上 ｢家族アルバム みてね｣にSwiftUIを導入しました

Slide 11

Slide 11 text

©MIXI 11 実装方法 ● MVVMアーキテクチャ ● ViewModel: 画面の状態を管理 ○ iOS: @Published ○ Android: StateFlow ● View: ViewModelが公開する状態を監視してUIを描画する ○ 1つの画面: Screen ■ ViewModelに依存する｢StatefulなScreen｣ ■ 引数で受け取った値を使ってレイアウトを組む｢ StatelessなScreen｣ ○ デザインシステムに定義されたコンポーネントを組み合わせてUI構築

Slide 12

Slide 12 text

©MIXI 12 実装方法: SwiftUI StatefulなScreen StatelessなScreen

Slide 13

Slide 13 text

©MIXI 13 実装方法: SwiftUI

Slide 14

Slide 14 text

©MIXI 14 実装方法: SwiftUI ● StatelessなScreenを使ってプ レビュー ● プレビューに必要なデータを引 数で渡すだけ ● ViewModelやRepository等 のMockが不要

Slide 15

Slide 15 text

©MIXI 15 実装方法: Compose StatefulなScreen StatelessなScreen

Slide 16

Slide 16 text

©MIXI 16 実装方法: Compose

Slide 17

Slide 17 text

©MIXI 17 実装方法: Compose

Slide 18

Slide 18 text

©MIXI 導入で変化した開発体験

Slide 19

Slide 19 text

©MIXI 19 ① UIの記述が直感的 ● SwiftUI, Compose自体の特徴 ● 1つのファイルで完結する ○ .storyboard or .xib + .swift → .swift ○ .xml (layout, style…) + .kt → .kt ● 同じファイル内でも上下に行き来することが少ない ○ Delegate や Listener → Modifier ○ 宣言と動作が1箇所に記述される

Slide 20

Slide 20 text

©MIXI 20 ② ｢とりあえず動く｣を作るまでが早くなった ● 早い段階でフィードバックを貰える ○ 実装時に思いつかなかった機能の改善案が出る ○ 早い段階でバグ検出 ● 事例 ○ 2週間毎のスプリントレビューに｢とりあえず動く｣状態で持っていき たくさんフィードバックをもらって活発な議論ができた ○ デザインツール(Figma)では表現しきれないアニメーション周り ｢とりあえず動く｣状態のアプリを見ながらデザイナーと調整 ● よりアジャイルに

Slide 21

Slide 21 text

©MIXI 21 ③ iOSとAndroidの実装を行き来しやすくなった ● SwiftUIとComposeの実装方法が似ている → 頭の切り替えがしやすい ○ 主にそれぞれのプラットフォームでの記述方法に変換する作業になる ■ HStack, VStack ↔ Row, Column ■ ObservableObject + @Published ↔ ViewModel + StateFlow ■ など ● 職能にとらわれずに実装を進めるみてねにおいて大きなメリット ○ スプリントのゴール達成に向けて協力しやすい

Slide 22

Slide 22 text

©MIXI 22 SwiftUIとComposeの実装比較 　SwiftUI 　Compose

Slide 23

Slide 23 text

©MIXI 23 　SwiftUI 　Compose SwiftUIとComposeの実装比較

Slide 24

Slide 24 text

©MIXI 24 　SwiftUI 　Compose SwiftUIとComposeの実装比較

Slide 25

Slide 25 text

©MIXI 25 　SwiftUI 　Compose SwiftUIとComposeの実装比較

Slide 26

Slide 26 text

©MIXI 26 ④ プレビュー高速化のためにマルチモジュール化加速 ● プレビューを確認するのに アプリを実行するのと同じかそれ以上の時間が必要になっていた ● Screenのコードを別モジュールに移動する ● 約3分 → 10~30秒 ● 関連してビジネスロジックたちもモジュールへの移行が加速 ○ Unitテストを単体で実行する場合の時間短縮 ○ アプリ全体のビルド時間への影響はまだ軽微

Slide 27

Slide 27 text

©MIXI 27 ⑤ SwiftUI, Composeの方が時間がかかる場合がある ● 実現したい機能がSwiftUI, Composeで使えない ○ 原因 ■ SwiftUI: 下限OSバージョン (現在iOS15+) ■ Compose: targetSdkVersionによって使えるバージョンが決まっている ○ UIKit, AndroidViewで実装し直し ● 実装開始後に使いたいコンポーネントが使えないことに気づく ○ デザインシステムのコンポーネントは必要なときに実装する運用 ○ 共通のUIパーツの依存関係が絡み合っていてモジュールに移動できない

Slide 28

Slide 28 text

©MIXI 28 ⑥ UIKit, AndroidViewと連携する必要がある ● ほとんどがUIKit, AndroidViewで実装されている ○ 約10~20%がSwiftUI, Compose ○ SwiftUI, Composeは、主に新規画面の実装で活用している ○ 既存画面の置き換えは積極的に行われていない ● 画面遷移はUIKit, AndroidViewに寄せている ○ SwiftUIやComposeで実装された画面の割合が増えたら、再度検討 ○ SwiftUIやCompose側の画面遷移のAPIの進化を期待

Slide 29

Slide 29 text

©MIXI まとめ

Slide 30

Slide 30 text

©MIXI 30 まとめ ● SwiftUI, Composeによって、開発体験が大きく改善 ○ UIの記述が直感的 ○ ｢とりあえず動く｣を作るまでが早くなった ○ iOSとAndroidの実装を行き来しやすくなった ○ プレビュー高速化のためにマルチモジュール化加速 ● 引き続きSwiftUI, Composeの推進は必要 ○ コンポーネントの拡充 / 既存画面の置換 によって現状の課題を小さく ■ SwiftUI, Composeのほうが時間がかかる場合がある ■ UIKit, AndroidViewと連携する必要がある

Slide 31

Slide 31 text

©MIXI