「えっ、あのUIできないの？」SwiftUIでぶつかる理想と現実 by Akihiko Sato

SwiftUIをメインで使っているプロダクトでは、デザイナーやPdMとのやり取りで誰もがこんな経験をしたことがあるのではないでしょうか。

👩‍💼： 「この機能、〇〇アプリみたいなUIにしてください！」
🧑‍💻： 「了解です〜！」
（実装中・・・）
🧑‍💻： 「iOS 15や16だとちょっと上手く動かないんですよね…」
👩‍💼： 「えっ、〇〇アプリではできてますよ？」
🧑‍💻： 「ちょっとやり方変えてみますね…（仕方ない、UIKitを使うか…）」

SwiftUIは年々進化していて、新しい表現力やインタラクションを作り出せる強力なツールです。しかし、多くの有名アプリではまだUIKitが使われており、デザイナーやPdMがそれらを参考にすることも多いです。その結果、SwiftUIだけでは再現が難しいUI表現を求められる場面がよくあります。

開発者は、UIViewRepresentableやUIViewControllerRepresentableを使ってUIKitを取り入れる選択を迫られますが、これによりSwiftUI本来の宣言的なスタイルや一貫した状態管理が崩れ、保守性や可読性に新たな課題が生まれます。

このLTでは、実際に「SwiftUIだけでは実装できなかったUI」や、「UIKitを使わざるを得なかったシーン」を例に挙げつつ、そのときに考えた工夫やトレードオフを共有します。たとえば、カスタムトランジションやインタラクティブなスクロール、特殊なジェスチャー処理など、現場でぶつかったリアルな壁を紹介します。