Liquid Glass 対応 — タップルでの意思決定と実装

WRITER: sosuiiii
このエントリーをはてなブックマークに追加

Liquid Glass 対応 — タップルでの意思決定と実装

この記事で学べること

    • ✅ デザイン・方針がわかる
  • ✅ 実装の参考になる
  • ✅ バグ対応の参考になる

対応に困っていたり、なかなか温度感が上がらなかったりする方がいたら、ぜひこの記事を参考にしてください。

目次

  1. なぜやるのか
  2. デザインの変遷
  3. 対応期限
  4. 早めに対応を進めるべき理由
  5. 対応フロー
  6. 対応事例

なぜやるのか

Liquid Glassは、半透明のガラスのような質感と、光の反射・屈折を伴う動的なアニメーションが特徴です。

10年に1度のデザイン変更となっており、標準のデザインとして認知が進んでいます。

対応アプリも着々と増えており、Apple公式からもデザインギャラリーが公開されました。

私たちもその大きな流れに乗っていきます。

Liquid Glassの半透明ガラス質感を適用したUIの例1
Liquid Glassの半透明ガラス質感を適用したUIの例2

引用：Apple Document

デザインの変遷

実際に、これまでのデザインの変遷を見てみましょう。

2007〜2013年：スキューモフィズムデザイン
iPhone登場時のデザインで、デジタル機器に不慣れな人 (初心者) にも使ってもらえるように立体感を持ち、リアリティの高いデザイン

2013〜2025年：フラットデザイン
影や立体感を排除したシンプルなUIにすることで、文字や写真などのコンテンツを主役としたデザイン

2025〜：リキッドグラスデザイン
実世界のガラスのように光を反射・屈折する半透明の新素材を使い、コンテンツへの注目を高めつつ、周囲に応じて変化するダイナミックなデザイン

2007年スキューモフィズム、2013年フラット、2025年リキッドグラスのデザイン比較

デザイン刷新時の注意点

新しいデザインが浸透していく一方で、その流行に乗る際には注意すべきポイントが存在します。

過去の、スキューモフィズムデザインからフラットデザインへの変更時を振り返ります。

スキューモフィズムデザイン → フラットデザインの影響

  • ⭕️ シンプルになったことで情報理解や開発効率が向上
  • ❌ 立体感が失われたことで、どこがボタンやリンクなのか、ユーザーが直感的に理解しにくい

デザインの移り変わりの際には、これまでのデザインで培ったユーザーの価値観とのギャップが必ず生まれます。
立体感の強いスキューモフィズムデザインに慣れていたユーザーは、フラットデザインのオブジェクトの境界線の認知に慣れるまで多少の時間が必要でした。
この点を踏まえて、リキッドグラス移行でどの点に注意すべきかを考えます。

フラットデザイン → リキッドデザインの影響

Liquid Glass では、透過性と視認性のバランスが重要です。
透過性やインタラクション(タップしたり、ホバーしたりする時のオブジェクトの動き) が強いため、以下3点に特に注意します。

① Liquid Glass Layerの上に乗った要素 (文字など) が見づらい
② オブジェクトとしての存在感は強いので、多用するとトーン&マナー（トンマナ）が崩れる
③ 重要機能のLiquid Glass対応は控えめにして、影響を最小限に

①の対策としては、透過性を下げられる箇所に関しては背景色を設定したり、ベース背景と同化しないように色を変えるなどします。※対応事例は後述

  • 公式の推奨に従いつつ、視認性が損なわれる箇所は調整する
  • ex. 公式セッションでは、.sheetでモーダルを表示する際には背景色を設定するpresentationBackground を外すように推奨されているが、敢えて使用して透過性を下げる。

② に関しては、対応可能なUIオブジェクトを洗い出してデザイナー陣に掲示。実際にアプリを配布して適用判断していきました。

左：標準API適用、中央：白100%背景追加、右：白70%背景追加の比較

左：標準APIにそのまま従ったもの
真ん中：背景色 (白100%) を追加したもの
右：背景色(白70%)を追加したもの

※リリース成果物とは部分的な差分があります

 

対応期限

Liquid Glass 対応には期限があります。
2025年のWWDCでは、次のメジャーアップデートで互換性フラグを廃止することを宣言しています。

Apple 公式セッションより:

As you evaluate your app’s UI and the time you need to adopt the new design, we’re providing an option to continue to use your app’s current design with Xcode 26.
We intend this option to be removed in the next major release.
We are so excited to see the transformative effects of Liquid Glass in your apps.

要約すると:

しばらく現在のデザインを維持するオプションを提供するけど、次のメジャーアップデート (2026/09) でこのオプションを消すよ。

※ UIDesignRequiresCompatibility = true → Liquid Glass を無効化

早めに対応を進めるべき理由

Liquid Glass対応には、落とし穴がたくさんあります。

  • iOS26未満と以上で同じAPIでも挙動が違う
  • iOS26.X.Xの中でも、バージョンによって挙動が変わる
    • タブバーのAPIやセーフエリア、アニメーションの挙動など (後述)
  • ナビバー、タブバーの高さがそれぞれ 44px→56px、49px→83px に
  • 既存のカスタム実装と競合し、見た目や挙動が崩れる
  • バージョンによっては、正しく使用しても、見た目や挙動が崩れる。特に26.0.X
  • タブバーのタイトル・アイコンのカスタマイズが大きく制限される

メジャーアップデートと同時にLiquid Glass対応を終えるスケジュールでは、これらの落とし穴に十分対処できません。バグを含んだバージョンのリリースや、検証期間の不足による事業影響は無視するべきではありません。

対応フロー

いきなり完璧に対応したものをテスト・リリースするのは、リスクが大きいため段階的なリリースを設計します。
後になって、「やっぱりここも対応したいね」とズルズル対応にならないよう、しっかりと理想形を描いてそこを目指します。

※対応時期に関しては、当時の実際のものを書いています。

フェーズ1 (1月中旬)

1-a：タブの Liquid 化が主
1-b：それ以外の箇所は、Liquid化をせずレイアウトが崩れた部分を直す程度

タブのLiquid Glass対応と、キーボードのデザイン崩れ等の問題

※全て対応事例が後述されています。
1枚目：タブタイトルの色変更が効かなくなっています。バージョンによっては、アイコンの色が変わらないバージョンもあります。
3枚目：キーボードが丸みを持ち、透過するようになったことでデザインが崩れています。
4枚目：戻るボタンと、ユーザーステータスが同一のグルーピングUIにまとめられてしまっています。
5枚目：戻るボタンの右側に、余分な余白が入っていることがLiquidGlassの境界線によって可視化されています。

フェーズ2 (1月中旬 〜 2月中旬)

2-a：ナビゲーション・シートの Liquid 化が主
2-b：1-bでLiquid化しなかった箇所を、Liquid化。(入力フィールドなど)

フェーズ2でのナビゲーション透過、シート透過調整、入力フィールド調整の対応例

1枚目：ナビゲーションが透過されるようにする
2枚目：シートの透過性が高いので、調整する
3枚目：キーボードの透過や丸みに合わせて、入力フィールドを調整する

フェーズ3 (2月中旬 〜 3月中旬)

3-a：適切な範囲で Full Liquid Glass 化
3-b：強制適用されない箇所も含めて調整を検討
タップルと Liquid Glass の世界観のバランスは崩さないように、クオリティ重視で進める

フェーズ3でのFloatingButtonのLiquid化と検索バーのLiquid化の対応例

1枚目：結果的にHorizontalPagerのナビゲーションはLiquid化せず。FloatingButtonや通知バーなどをLiquid化
2枚目：検索バーのLiquid化

対応事例

事例 1: Tab / NavigationBar の背景

let appearance = UITabBarAppearance()
appearance.configureWithDefaultBackground()

let appearance = UINavigationBarAppearance()
appearance.configureWithDefaultBackground()

事例 2: 入力フィールドの視認性

入力フィールドにtintで色付けして視認性を改善したビフォーアフター

特に強調したいもの以外には使用すべきではない (公式ソース) が、背景と同化して見にくいため、tint で少し色付けします。

.regular.tint(Color)

事例 3: テキストエディタとモーダル

テキストエディタの色差異、カスタムナビの高さ崩れ、モーダル透過の問題例

左：テキストエディタとScrollViewの色の差異ができたので、直します。

.scrollContentBackground(.hidden)

真ん中：カスタムナビゲーションだったため、高さが合わずレイアウト崩れ
標準APIに置き換えます。

右：モーダルの透過性が高く、テキストやスライダーの視認性が悪いので背景色をつける

.presentationCornerRadius(CGFloat)
.presentationBackground(Color)

モーダルの透明度調整事例

事例 4: あえて対応しないもの

現状、HorizontalPager に適した Liquid UI がないため、他サービスの対応状況を見て良いものがあれば参考にする予定です。

HorizontalPagerにLiquid UIを適用しない判断をした画面例

 

公式ドキュメントでは以下の透明化を防ぐAPIが紹介されている

 

事例 5: エッジスワイプで戻る時に、白いグラデーションが降りてくる iOS26.1 (23B85)

エッジスワイプ時に白いグラデーションが降りてくる不具合の画面

iOS26.2 (23C5044b) では治っていることを確認。アップデートを推奨

事例 6: glassEffectの評価で落ちる iOS26.0 beta 2 (23A5276f)

#5 View.glassEffect
#6 Hoge.body.getter ... Foo.swift:320

パブリック・パブリックベータ・次のデベロッパベータのバージョンにアップデート

事例 7: コンテンツがセーフエリアを超えない

コンテンツがセーフエリアを超えず余白が生じている画面

UIKit を使っている画面では、xib上のアンカーをview.topにしても
セーフエリアを超えて描画されない箇所が見られました。

edgesForExtendedLayout = [.top, .bottom]
extendedLayoutIncludesOpaqueBars = true

また、UIKitもSwiftUIもトップコンテンツがScrollViewかつ余白が入っていなければ
自動でナビゲーションを超えて描画してくれるようになっています。

ScrollView { } // ナビゲーション下でもコンテンツが透けて見える
VStack { ScrollView } // ナビゲーション下でもコンテンツが透けて見えない
ScrollView { }.padding(.top, 1) // ナビゲーション下でもコンテンツが透けて見えない

もしも不要なStackやpaddingがあるせいでignoreSafeArea等を使用しているのであれば、
まずはStackやpadding, ignoreSafeAreaの除去を試みてください。

事例 8: TabIconとTabTitleがくっつく iOS26.0 beta 2 (23A5276f)

パブリック・パブリックベータ・次のデベロッパベータのバージョンにアップデート

事例 9: 非選択時のTabIconの色が変わらない iOS 26.0 ~

どの標準APIを触っても、タブやアイコンの色変更に制限がかかるようになりました。
タブが透過する仕様上、視認性の観点から制限がかかっていると推測しますが、サービスとして看過できないためどうにかして色を変えます。

withRenderingMode(.alwaysTemplate)
+
UITabBarItemAppearance.normal.iconColor = ...

alwaysTemplateとAppearanceで変えていた色を、
あらかじめ色を変更した画像と alwaysOriginal の組み合わせによって色を変更しました。

image.tintedImage(...)
+
.withRenderingMode(.alwaysOriginal)

非選択タブアイコンの色がalwaysOriginalで変更された結果と、タブタイトルの色変更ができない事例

バージョンアップデートが進むと、今度はタブタイトルの色変更ができなくなっていました。

タブのタイトルごと画像に含めて、タブのアイコンとタイトルのUI調整をした事例

デザイン上、どうしても対応したいという要望もあったため、
アイコンにタイトルを含めることで対応しました。

 

事例 10: 戻るボタンに余分な余白が入る

明確な縁が描画される都合上、iOS26未満で見えなかったレイヤ構造が可視化されるようになりました。
このケースでは、ナビの戻るボタンの共通実装に半角スペースが入っていたことが原因でした。

backBarButton.title = " " // これが原因
self.navigationItem.backBarButtonItem = backBarButton

事例 11: List.swipeActionsのアニメーション崩れ

leading, trailingを付けて左右にスワイプすると、List上部が潰れる

List.swipeActions使用時にList上部が潰れるアニメーション崩れ

こちらはやむなしで潰れる分上に上げて、クリップするようにしました。

事例 12: ナビアイコンにつけているバッジがクリップされる

Liquid Glassの仕様でクリップされてしまうので、バッジのデザインそのものを変更

左：iOS26以上でバッジが見切れた状態、右：通知有効時のUI刷新後

左：iOS26以上でバッジが見切れていることがわかる
右：iOS26以上における通知有効時のUIを刷新

.buttonStyle(.glassProminent) // Navに配置したボタンのGlassLayerの色付け

 

事例 13: OSバージョンごとのデザインを統一

以下の観点から、デザインは極力統一できるように心がけました。

  • デザインコスト
  • 実装コスト
  • デバッグコスト

タップルでも、途中まではiOS26未満と以上でデザインを分けていましたが、一部を除いて統一する意思決定をしました。

iOS18以下の統一前・統一後とiOS26以上の入力フィールドデザイン比較

1列目：統一前のiOS18以下の入力フィールド
2列目：統一後のiOS18以下の入力フィールド
3列目：フェーズ3対応後のiOS26以上向け入力フィールド

最初はLiquidGlass向けの入力フィールドがiOS18以下のデザインにも合うとは思いもしませんでしたが、
いざ合わせてみると違和感がありませんね。

 

事例 14: Androidとのデザイン棲み分け

Androidのデザインに関しては、Liquid Glass がiOS独自のデザインシステムであるため、適用しない(棲み分けてデザインする) 方針としました。

 

おわりに

タップルでは、この機にいくつかの既存のカスタム実装を捨てて標準APIに全乗りする意思決定をしました。

デザイン主軸で対応が進められる機会もなかなかないので、とても良い機会でした。

画面によってばらつきのあったシートやナビゲーションのスタイルなどが統一され、
運用面での恩恵も多く受けました。

また、想定した以上にiOS26以上の不具合が多く出てきたので、早めに対応を進めることをお勧めします。

コードとデザインを自由に行き来する ー Figma MCP × AIエージェントがもたらしたSpindle開発フローの変化
次の記事