博士

ロボ子、今日はBackend-driven UIについて話すのじゃ。

ロボ子

Backend-driven UIですか。バックエンドがUIの構造まで決めるというものですね。

博士

そう！バックエンドからJSONでUIの定義を送ることで、アプリのアップデートなしにUIを変更できるのがミソじゃ。

ロボ子

それは便利ですね！記事によると、アプリのレビューなしに変更を反映できるのが大きな利点の一つだとか。

博士

そうじゃ。「JSON DSLはローカルのレンダリングエンジンで解釈されるデータであり、Appleのガイドライン2.5.2に違反しない」とのことじゃ。

ロボ子

エンジニアの関与なしに変更できるのも魅力的ですね。プロダクト担当やマーケティング担当が自分たちでUIを調整できると。

博士

その通り！A/Bテストも加速できるし、マルチテナントのホワイトラベリングも容易になるぞ。

ロボ子

記事では、Backend-driven UIの構築例として、静的コンテンツ、レイアウトとナビゲーション、完全インタラクティブなマルチメディアの3つのフェーズが紹介されていますね。

博士

最初はテキストや画像などの静的コンテンツを表示するのじゃ。ContentItemとContentTypeを使って、ビューの種類を定義するぞ。

ロボ子

ContentTypeはenumで定義するんですね。テキスト、コードブロック、画像など、レンダリングするビューの種類を定義すると。

博士

次に、Netflixみたいなレイアウトを作るのじゃ。コンテナとナビゲーションを追加して、再帰的なネストを使うぞ。

ロボ子

StackContentViewでHStackまたはVStackを選択し、NavigationLinkContentViewで画面遷移を実装するんですね。

博士

最後は、音声録音やカメラアクセスなどの複雑なコンポーネントを導入して、完全インタラクティブなUIを作るのじゃ。

ロボ子

MapLocationInputViewで地図を埋め込んだり、ContentType.submitButtonでデータを送信したりするんですね。

博士

ただし、Backend-driven UIが向かない場合もあるぞ。高度なジェスチャーやアニメーションが必要な場合は避けるべきじゃ。

ロボ子

カスタムオンボーディングフローのテストやペイウォールの実験など、コンテンツヘビーな場合に適しているんですね。

博士

DSLにバージョン管理を導入したり、エラー時のフォールバック画面を用意したりすることも重要じゃ。

ロボ子

SwiftUIをJSONで再実装していることに気づいたら立ち止まって考える、という注意点も心に留めておきます。

博士

サンプルプロジェクトもあるみたいじゃから、試してみると良いぞ。[https://github.com/jacobsapps/BackendUI/](https://github.com/jacobsapps/BackendUI/)

ロボ子

ありがとうございます、博士。勉強になりました！

博士

ところでロボ子、Backend-driven UIで作ったUIがバグだらけだったら、それはフロントエンドの責任じゃなくて、バックエンドのせい…ってコト！？

ロボ子

博士、それはちょっと乱暴な言い方だと思います…！