SwiftUI導入から1年、 
 SwiftUI導入とVueFluxライクな状態管理 
 
 2025/03/03 
 
 CA.swift #22 
 〜Swiftの進化を活かした技術基盤への挑戦〜 
 
 CL事業部 吉田 周平 
 

自己紹介
 2 吉田 周平 (しゅうしゅう)
 
 株式会社 CyberAgent
 Fantech CL 事業部
 24年新卒
 

CLの事業内容 
 

LDHのオリジナル番組や生配信を楽しめる動画配信サービス 
 4 

SwiftUI導入背景 
 

SwiftUI導入背景 
 6 ● SwiftUI導入の理由
 ○ 新規でジョインするエンジニアがSwiftUI経験者である可能性が高い 
 ○ コードの可読性とメンテナンス性の向上 
 ○ Storyboardの差分を見るのが辛い（コードレビュー時の負担が大きい） 
 ● 既存のアーキテクチャとの整合性 
 ○ VueFlux[1]の考え方と大きく異ならないようにする 
 ■ 単一方向のデータフローを維持 
 ○ 既存のエンジニアが違和感なく移行できる形にする 
 ○ アーキテクチャの統一性を確保することで、チーム全体の開発効率を損なわない 
 [1] https://github.com/ra1028/VueFlux 

VueFluxとは？ 
 

VueFlux [1]とは？
 8 Actions Mutations State Computed View ● ReduxやVuexに近い、Swift向けの 単一方向状態管理ライブラリ
 ● Ryo Aoyama氏によって開発された 
 ● 単一方向データフロー
 Action: 非同期処理やイベントの結果に応じてMutationを発火さ せる
 Mutation: Stateを変更する唯一の仕組み 
 State: 状態をひとまとめに管理
 Computed: Stateから派生値を計算・外部に公開 
 dispatch データの 一元管理 state->ui に派生 [1] https://github.com/ra1028/VueFlux 

VueFluxをどのように使っているか？ 
 9 ViewController Adapter(Store) State+Mutations DataModel ① User Action ② Call methods ③ Action dispatch ④ Update ViewController ⑤ 変化を購読→更新 ③ Action発行 ② Call methods 

VueFluxをどのように使っているか？ 
 10 ViewController Adapter(Store) State+Mutations DataModel ① User Action ② Call methods ③ Action dispatch ④ Update ViewController ⑤ 変化を購読→更新 ③ 発行されるActionの定義 ④ 状態の更新 

VueFluxをどのように使っているか？ 
 11 ViewController Adapter(Store) State+Mutations DataModel ① User Action ② Call methods ③ Action dispatch ④ Update ViewController ⑤ 変化を購読→更新 ⑤ 変化を購読→更新 

VueFluxライクな状態管理 
 

SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 13 ViewController Adapter(Store) State+Mutations ViewController UIKit + VueFlux Call methods Action dispatch Notify Change ViewControllerが 変更を受け取り、UI を作り替える SwiftUI View ObservableObject @Published State SwiftUI View SwiftUI + VueFluxライク Call methods Action dispatch Notify Change 状態変化を検知 →自動で再描画 Adapter State 

SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 14 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change Screen(親View) ● @StateObject var adapter ● dataModelをContentに渡す ↓ クロージャーでイベントを渡す Content(子View) ● UIの実装のみ ● 子→親で状態を返さず、 あくまで"イベント"送信 

SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 15 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change Screen(親View) ● @StateObject var adapter ● dataModelをContentに渡す ↓ クロージャーでイベントを渡す Content(子View) ● UIの実装のみ ● 子→親で状態を返さず、 あくまで"イベント"送信 

SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 16 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change ● Store機能 ○ @Published var state ● 非同期処理やイベントの結果 に応じてActionを発行する 

SwiftUIでVueFluxライクなアーキテクチャを再現する仕組み 
 17 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change AdapterからActionを受け取り mutateで状態を更新 

導入したメリットとデメリット 
 18 メリット デメリット ● ボイラープレートが増える 
 ○ シンプルな機能でも雛形のコードが必要 
 ● 大型機能ではAdapterが肥大化しやすい 
 ○ 非同期処理や画面遷移など外部とのやり取 りを全てAdapterで行うため 
 ● 画面数が多いとコード量が増える 
 ○ Screen, Content, Adapter, State, DataModel←最低でもこの５つが必要になる 
 ● SwiftUIの恩恵を受けられる 
 ○ 宣言的UIとなり、UIKit+VueFluxよりもコード がシンプル
 ○ Storyboardを使う必要がなくなり、コードレ ビューしやすい
 ● テストがしやすい
 ● ライブラリの依存が少ない 
 
 

まとめ
 19 1. SwiftUI導入の背景
 a. 新規エンジニアがSwiftUIを学んでいる可能性が高い 
 b. Storyboardの差分確認が辛く、宣言的UIを検討 
 c. 既存のVueFlux（単方向データフロー）と大きく矛盾しないアーキテクチャが必要 
 2. VueFluxをどのように使っているか？ 
 a. 単方向データフロー: Action → Mutation → State → View(Controller) 
 b. Adapter(Store) + State + DataModelを組み合わせ、ViewControllerがUI更新 
 3. SwiftUIでVueFluxライクな状態管理を実現 
 a. Screen & Content の構成: Screenが親Viewとして@StateObjectを保持し、ContentはUI表 示とイベント通知に特化 
 b. Adapter(Store)はObservableObjectとして@Published var stateを管理し、mutating func mutateで単方向フローを再現 
 

テスト
 20 ● Adapterから受け取るAPI通信のAPIから、正しい状 態更新ができているかテストすることができる 
 ● Actionのassociated valueにレスポンスを入れて Stateで変換する
 
 
 

Stateからの実行を行う「command」機能 
 21 SwiftUI View Adapter (ObservableObject) State+DataModel SwiftUI View Call methods Action dispatch Notify Change Command Stateが変わった瞬間にUI イベントやログ送信が可能