Server-Driven UIでプロダクト開発してますか?
Server-Driven UI(SDUI)はAirbnbが用いた設計手法でUIの構造、レイアウト、さらには一部の動作ロジックを、クライアント側ではなくサーバー側で定義・制御するアーキテクチャパターンです。
モバイルアプリ開発においてA/Bテスト等でUIを分ける際にいくつかやり方があるかと思いますが、
このLTではStacというFlutter専用のSDUIのFrameworkを用いた紹介をします。
Flutter 3.27.0 がリリースされ、 Android においても Impeller が標準となりました。
我々はAndroid のパフォーマンス向上を期待し、 Flutter をアップグレードすることに決めました。
手元の端末たちでは問題なく動作したため、アプリをリリースしました。
気がつくと、ユーザー様からクレームをたくさん頂くことになりました。
このセッションでは、失敗した経緯をみなさんと笑顔で振り返り、今後の糧とさせていただきます。
2025/6/9、Appleは新たなデザイン言語であるLiquid Glassを発表しました。
そしてコミュニティから挙がった声は……
「Flutterはこのムーブメントについていけない、終わりだ!」「Flutter is dead.」 ……
なるほど、確かにFlutterは構造上、Liquid Glassを取り込むことは難しいです。
では、Flutterは本当に死を迎えたのでしょうか?
自分はそうは思いません。
むしろ、Flutterの真価はプラットフォーム固有の事情に左右されないことにあると考えています。
このトークでは、Flutterの立ち位置や採用する価値を整理したうえで、どのようなプロジェクトにFlutterが最適なのか?というお話をします。
iOS 17で登場した「Assistive Access」機能をご存知ですか?
一見するとFlutter開発者には無縁に思えるかもしれませんが、実はこの機能には認知にやさしいUI設計における多くのヒントが詰まっています。
本LTでは、Assistive Accessの概要とともに、Flutterアプリでも活かせる認知負荷を軽減するためのデザイン原則を紹介します。
特に、「ボタンはたくさんあったほうが便利」や「多機能こそユーザーフレンドリー」といった常識に疑問を投げかけ、誰にとってもわかりやすく、操作しやすいUIを考えるきっかけとなるセッションを目指します。
認知負荷の視点から、自分のアプリ設計を見直してみませんか?
Flutterに「こんな機能があったら便利なのに」と思ったことはありませんか? 不具合がFlutterのバグによるものであることが判明し、「Flutter SDKのバグが直れば解消できるのですが」と共有したことはありませんか?
Flutterはオープンソースプロジェクトであり、誰でも貢献できます。あなたのアイデアや不満は、あなたの貢献のきっかけになるかもしれません。
本セッションは「なぜFlutterの開発に"あなた"がなぜ関わるべきなのか」をテーマに、Flutterのコントリビューションの魅力と方法についてお話しします。また、話者がFlutterの開発に関わることで得た知識や経験をもとに、コントリビューションの様々な価値を紹介します。
みなさんはFlutterのデザインはどのようにする派閥でしょうか?
自分は圧倒的にネイティブデザイン派閥でした。ですがWWDC25でLiquid Glassが発表された今、ネイティブデザイン派閥は危機に直面しています。
コミュニティの動きはとても早くLiquid Glassの見た目の再現はすぐに達成されましたが、Flutter内で見た目だけ再現してもLiquid Glassの思想まで再現したとは残念ながら言えません。
そこで今回FlutterのAdd-to-appの機能を使って、Liquid GlassのナビゲーションレイヤーをSwiftUIで、コンテンツレイヤーをFlutterで記述するという形式にトライし、どこまでうまくいくのか?何が課題なのか?をざっくりと紹介していきます。
Flutter開発では、アプリケーションの実行や配布のたびにビルドが発生します。
通常、ビルドキャッシュは意識せずとも自動で働きますが、その仕組みを理解することで開発効率をさらに高められます。
本セッションでは、Flutter SDKの内部実装に触れながら、ビルドキャッシュの構造と動作を詳しく解説します。
また、キャッシュが有効・無効になる条件を理解し、 flutter test
実行時の不要な再ビルドを回避することで、テスト実行を高速化できる実践的なアプローチも紹介します。
build/
ディレクトリや .dill
ファイルなど、ビルド成果物の正体を知りたい方iOS26の発表直後、FlutterのHot reloadが実機では動作しない問題が発生し、アプリ開発者は窮地に立たされまさした。
この問題は現代のOSのセキュリティ制約とJITコンパイラが深く関わっています。この課題にどう向き合い、どう解決していったのかを時系列で振り返りましょう。この解決の過程を振り返ることで、フレームワークへの理解が更に進み、FlutterのコアであるHot reload技術についてより深い知見を得ることができます。
フレームワークやVMのアップデートが、どうやって自分たちの開発体験やアプリの品質に直結するのかを追体験しましょう。
Widget の「移動」をアニメーションする animated_to というパッケージを開発して公開しました。これを使うと from/to を計算することなく自由に Widget を動かせます。
そんな animated_to は RenderObject をカスタマイズすることで実現しています。from/to の計算、描画位置の更新、これらはいずれも RenderObject の仕事であり、そこに Widget のリビルドは発生しません。リビルドが必要ないのでアニメーションも滑らかです。
このセッションでは、animated_to の実装を例に RenderObject の仕組みとカスタマイズ方法について説明します。
Flutter 3.10から標準になった描画エンジンImpellerは、それまでの標準であったSkiaと比較すると、描画処理の最適化、シェーダーの事前コンパイルにより、特にMetal(iOS,macOS)での動作が大幅に安定しました。
しかし、Impellerの恩恵はそれだけではありません。
描画までの中間コードが削減されたことで、3D描画を実現するFlutter GPUや、高性能化したdart:uiのシェーダー機能など、Flutterの新たな可能性を開く基盤となっています。
本セッションでは、ImpellerとSkiaの描画の仕組みを比較解説し、Impellerが実現した新機能の技術的背景を深掘りします。
Flutterの描画の仕組みを理解したい方
描画エンジンレベルでのパフォーマンス改善を試みたい方
シェーダーによる視覚表現や3D描画に興味のある方