SwiftUIのLiquid Glass: iOS 26でReturnを出荷して見えた3つのパターン

AppleのLiquid Glassは、1行で書けるSwiftUIのAPI、.glassEffect()です。¹ 私の瞑想タイマーアプリReturnでは、iOS、macOS、tvOSをまたいで9箇所で利用しています。² そのうちの1箇所では、このモディファイアをカスタムShapeに適用し、タイマーの数字そのものをグリフ単位でliquid glassに変換しています。

興味深いのは、1行で済む使い方を超えたときに何が起きるかという点です。AppleのHuman Interface Guidelinesは厳格なレイヤリングルールを定めています。Liquid Glassはファンクショナルレイヤー（コントロール、ナビゲーション、一時的なUI）に属し、コンテンツレイヤーには決して使ってはなりません。³ Returnの9つの利用箇所のうち、ほとんどは教科書通りのファンクショナルレイヤーへの適用です。ピッカー、ボタン、コントロールストリップ、一時停止状態のバッジなどです。興味深いのは、ルールを破らずに曲げている残り3つの使い方です。

このエッセイでは、私が出荷した3つのパターン、それらが守っているルール、そして私を捕まえた落とし穴、さらに意図的に使わなかったAPIの領域について解説します。

TL;DR

• iOS 26はLiquid Glassを.glassEffect(_:in:)として提供します。デフォルトのバリアントは.regular、デフォルトのシェイプはCapsuleです。¹
• Returnでは、1行の使い方を超える3つのパターンを採用しています。カスタムShapeへのガラス適用（Core Textのグリフパスによるタイマーテキスト）、ミラーパターン（反転＋マスクされたコピーによる下方の反射）、そしてファンクショナルレイヤーのHUDオーバーレイです。
• AppleのHIGルール: Liquid Glassはファンクショナルレイヤーへ、標準マテリアルはコンテンツレイヤーへ。³
• 私は意図的にGlassEffectContainerを使いませんでした。モーフィングAPIはReturnでは出番がなく（あるガラス要素が別のガラス要素にアニメーションすることがない）、レンダリングパフォーマンスのギャップもベンチマーク取得していません。これは推奨ではなく、未測定のトレードオフです。¹
• 落とし穴: フラットな背景上のガラスはフラットに見える、ジッター無しの数字レンダリングには固定幅セルが必要、tvOSのHStackはlayout-direction環境値を無視する、reduce-motionはモーフアニメーションで尊重しなければならない。

1行のAPIとレイヤリングルール

AppleはLiquid Glassを小さなサーフェスエリアで提供しており、WWDC 2025では主要なデザインの柱として紹介されました。¹¹³

Text("Hello, World!")
    .font(.title)
    .padding()
    .glassEffect()                              // default: .regular variant, Capsule shape

Text("Hello, World!")
    .glassEffect(in: .rect(cornerRadius: 16))   // custom shape

Text("Hello, World!")
    .glassEffect(.regular.tint(.orange).interactive())  // tint + touch reactivity

つまみは3つです。バリアント（.regularまたは.clear）、シェイプ（任意のShape）、そしてGlassEffectStyleチェーン（tint、interactive）。これが単一ビューに対するAPIのすべてです。複数ビューのレンダリングは別のGlassEffectContainerで扱われますが、これについては後述します。

HIGはAPIよりも厳格です。AppleのHuman Interface Guidelinesは、すべてのiOS 26+のインターフェースに2つのレイヤーを定義しています。³

1. コンテンツレイヤー: ユーザーが消費するドキュメント、リスト、写真、メディアです。ここでは標準マテリアル（既存の.regularMaterial、.thinMaterialなど）を使います。
2. ファンクショナルレイヤー: コントロール、ナビゲーション、タブバー、サイドバー、一時的なオーバーレイです。ここではLiquid Glassを使います。

Appleの具体的な指示はこうです。「Liquid Glassをコンテンツレイヤーに使ってはいけません。Liquid Glassはインタラクティブな要素とコンテンツの間に明確な区別を提供するときに最も効果を発揮します。コンテンツレイヤーに含めると不要な複雑さと混乱した視覚階層を生み出します」³

このルールは、実際のアプリにマッピングするまでは制限的に聞こえます。Returnは瞑想タイマーです。コンテンツレイヤーは、すべての背後に流れる呼吸イメージとループ動画です。ファンクショナルレイヤーは、デュレーションピッカー、開始/一時停止/停止のボタンスタック、セカンダリ設定ボタンの行、そして（tvOSでは）一時停止状態のバッジです。Returnの9つのガラス利用箇所のうち8つは、教科書通りのファンクショナルレイヤーへの適用です。iOSとmacOSのコードパス向けの3つのデュレーションピッカーバリアント、開始/一時停止トグル、停止ボタン、設定ボタンの行、tvOSの一時停止インジケーター、そしてもう1つの一時的なコントロールオーバーレイです。⁴

9つ目は意図的なエッジケース（タイマー数字そのものに適用されるLiquid Glass）で、これは次のセクションで解説します。

パターン1: カスタムShapeへのガラス適用

Returnのタイマー数字は、ガラスの背景の上に描かれたテキストではありません。ガラスそのものがテキストなのです。.glassEffect(.clear, in:)は任意のShapeを受け入れ、⁹ ShapeはPathを生成するプロトコルです。¹⁰ そのため、トリックはこうなります。Core Textを使ってタイマー文字列をグリフのパスに変換し、¹¹ そのパスをShapeとして.glassEffectに渡すのです。⁵⁶

import SwiftUI
@preconcurrency import CoreText

struct GlassTextShape: Shape {
    let text: String
    let font: CTFont

    func path(in rect: CGRect) -> Path {
        guard !text.isEmpty else { return Path() }
        let combinedPath = CGMutablePath()

        let attrString = NSAttributedString(string: text, attributes: [.font: font])
        let line = CTLineCreateWithAttributedString(attrString)
        guard let runs = CTLineGetGlyphRuns(line) as? [CTRun], !runs.isEmpty else {
            return Path()
        }

        for run in runs {
            let glyphCount = CTRunGetGlyphCount(run)
            guard glyphCount > 0 else { continue }
            var glyphs = [CGGlyph](repeating: 0, count: glyphCount)
            var positions = [CGPoint](repeating: .zero, count: glyphCount)
            let range = CFRange(location: 0, length: glyphCount)
            CTRunGetGlyphs(run, range, &glyphs)
            CTRunGetPositions(run, range, &positions)

            for i in 0..<glyphCount {
                guard let glyphPath = CTFontCreatePathForGlyph(font, glyphs[i], nil) else { continue }
                let transform = CGAffineTransform(translationX: positions[i].x, y: positions[i].y)
                combinedPath.addPath(glyphPath, transform: transform)
            }
        }

        // Core Text y-axis is flipped vs SwiftUI; flip then re-bound and center.
        var swiftPath = Path(combinedPath).applying(CGAffineTransform(scaleX: 1, y: -1))
        let flippedBounds = swiftPath.boundingRect
        let offsetX = rect.midX - flippedBounds.midX
        let offsetY = rect.midY - flippedBounds.midY
        return swiftPath.applying(CGAffineTransform(translationX: offsetX, y: offsetY))
    }
}

Return/Return/GlassTextShape.swiftからの実際のプロダクションコードです。⁵ path(in:)関数はCore Textを使って文字列をレイアウトし、各CTRunを辿り、各グリフのCGPathを抽出して、それらを1つのCGMutablePathに結合します。結合後の2つの非自明なステップが続きます。Core Textの座標系は原点を左下に置きますが、SwiftUIのPathは左上に置きます。そのためパスはCGAffineTransform(scaleX: 1, y: -1)で反転する必要があります。次に反転されたパスのboundingRectはy値が負になるので、SwiftUIがShapeに渡すrect内に再センタリングするためのトランスレーションが必要です。どちらかの変換を飛ばすと、グリフは上下逆さまに描画されるか、画面外に出てしまいます。

そして適用は1行で済みます。

Rectangle()
    .fill(.clear)
    .glassEffect(.clear, in: textShape)
    .frame(width: cellWidth, height: cellHeight)

クリアなRectangleはヒットターゲットのプレースホルダーで、実際の見た目はtextShapeが生成する任意のシェイプです。グリフパスのシェイプを使うと、Liquid Glassマテリアルはグリフのアウトラインだけを満たします。結果として、タイマーの各数字が独立したliquid-glassフォームとなり、背後で動くアニメーションを屈折させます。⁶

HIGのニュアンス。 Appleが定めるルールはファンクショナルレイヤーにLiquid Glass、コンテンツレイヤーに標準マテリアルですが、明示的な例外が1つあります。コンテンツレイヤーの一時的なインタラクティブコントロール（スライダー、トグル）は、アクティブ化されたときLiquid Glassを取れるというものです。³ Returnのタイマー数字は状態表示であり、コントロールではありません。Timer.publish(every: 1, ...)から1秒に1回更新され、タップジェスチャーは持っていません（その下にある開始/一時停止ボタンが状態を切り替えます）。なので、ここにLiquid Glassを置くのは意図的なエッジケースで、文字通りのインタラクティビティというより意図において「一時的なインタラクティブコントロール」に近いものです。なぜなら数字はユーザーがセッション中ずっと見続ける視覚的フォーカルポイントだからです。私はルールを曲げているのであり、破ってはいません。HIGを厳密に読むレビュアーは、これは標準マテリアルにすべきだと主張できるでしょう。私は、タイマーはプログレスインジケーターと同じファミリーの経過時間コントロールサーフェスだと主張します。Appleのドキュメントはこのケースを直接的に裁定していません。

Text + 背景ではなくカスタムShapeを選ぶ理由。 ガラス背景の上にレンダリングされたTextは、ガラスの上のテキストとして読まれます。ガラスそのものとしてレンダリングされたTextは、別の視覚カテゴリーとして読まれます。ユーザーは数字を機能的なフォアグラウンドとして、特に通して見るために存在する一時的な要素として知覚するのです。

パターン2: ミラーパターン

Returnは、タイマーの下にその反射をフェードアウトさせて表示します。実際のプロダクションコードは次の通りです。⁶

VStack(spacing: 0) {
    GlassTimerText(text: displayTime, fontSize: fontSize)
        .accessibilityLabel("Time remaining: \(accessibleDescription)")

    if showReflection {
        GlassTimerText(text: displayTime, fontSize: fontSize)
            .scaleEffect(x: 1, y: -1)
            .mask(
                LinearGradient(
                    stops: [
                        .init(color: .white.opacity(0.2), location: 0),
                        .init(color: .clear, location: 0.6)
                    ],
                    startPoint: .top,
                    endPoint: .bottom
                )
            )
            .offset(y: -8)
            .accessibilityHidden(true)
    }
}

ミラーは3つの変換で構成され、すべて標準のSwiftUIプリミティブです。¹⁴

1. scaleEffect(x: 1, y: -1)が2つ目のコピーを上下反転させます。
2. .mask(LinearGradient(...))が反射を上端で20%の不透明度から、60%の位置で完全に透明にフェードさせます。
3. .offset(y: -8)が反射を8ポイント上に引き上げ、見える継ぎ目を残さずに元の図形と接するようにします。

反射に付ける.accessibilityHidden(true)モディファイアは重要な役割を担っています。VoiceOverはミラーされた時刻を二度読み上げてはいけません。元のインスタンスのaccessibilityLabelとaccessibilityAddTraits(.updatesFrequently)はすでに上の主要なGlassTimerTextインスタンスに付いており、反射は純粋に装飾的なものです。

これがLiquid Glass特有に機能する理由。 反射はGlassTimerTextからガラスマテリアルを継承します。元の図形が乗っている任意の背景（呼吸する円のグラデーション、動画、色付きシーン）は、両方のコピーを通して屈折します。ミラーはガラス特有のコードを必要としません。ガラスマテリアルが屈折を無料で処理してくれるのです。エフェクト全体は3つのモディファイアと1つのグラデーションだけです。

アクセシビリティのコスト。 reduce-motionユーザーにもミラーは見えますが、時刻更新の間のガラスマテリアルのアニメーションは、@Environment(\.accessibilityReduceMotion)を介して別の場所で抑制されています。⁷ 反射そのものは静的で、アニメーションするのは数字遷移の間のモーフだけです。

パターン3: 一時的なコントロールのためのガラスHUDオーバーレイ

Returnの残り8つのガラス利用箇所は、教科書通りのファンクショナルレイヤーへの適用です。⁴ それぞれが同じパターンに従います。

durationPicker
    .frame(height: 50)
    .frame(maxWidth: 320)
    .glassEffect()
    .padding(.horizontal, 20)
    .transition(.opacity.combined(with: .scale(scale: 0.95)))

.transition(.opacity.combined(with: .scale(scale: 0.95)))が重要な役割を担う部分です。一時的なコントロールに対するLiquid Glassは、コントロールが一時的に動くときにのみ正しく感じられます。画面に永続的に居座る静的なガラスHUDは、クロームとして読まれます。ユーザーがタップしたときにフェード＋スケールで現れ、目を逸らすと元に戻るガラスHUDは、瞬間的なコントロールサーフェスとして読まれます。

glassEffectに関するAppleのドキュメントは、これを暗黙的に示しています。モディファイアは「コンテナにレンダリングを送るためにコンテンツをキャプチャ」し、「タッチとポインタのインタラクションにリアルタイムで反応する」とあります。¹ アニメーションフックはAPIにはありませんが、レンダリングパイプラインはガラス要素が動くことを前提としています。静的なガラス要素はそのアフォーダンスを取りこぼしてしまいます。

Returnはこのパターンを、デュレーションピッカー（ユーザーがタップしたときに上にスライド）、開始/一時停止トグルボタン（常に表示されるが押下時にスケール）、停止ボタン（セッション中のみ表示）、設定ボタン行（デュレーションピッカーの下にある水平方向のコントロールストリップ）、そしてtvOSの一時停止状態バッジ（Apple TVでセッションが一時停止されたときのみ表示）に使っています。5つのコンテキストすべてがHIGのファンクショナルレイヤールールを尊重しています。³

GlassEffectContainerの問題

Appleは、アプリが複数のビューに.glassEffect()を使う場合は常にGlassEffectContainerを使うことを推奨しています。理由は2つあります。レンダリングパフォーマンスの向上（ガラスエフェクトがバッチ化される）と、トランジション中にシェイプを互いにモーフさせる能力です。¹

私は使いませんでした。理由はアプリ固有のものであり、Appleのガイダンスに対する反論ではありません。Returnには9つのガラスビューがありますが、互いにモーフする必要はどれにもありません。⁴⁶ デュレーションピッカーが開始ボタンにアニメーションすることはありません。タイマーテキストが設定ボタン行にアニメーションすることもありません。各ガラス要素は独立しています。モーフィングAPIは発火するユースケースがなく、コンテナのスペーシングルールは、現在は調整不要なレイアウトを制約してしまうでしょう。

レンダリングパフォーマンスの議論については、測定なしには完全に反論できません。Appleのドキュメントは、コンテナの外で「あまりにも多くの」ガラスエフェクトはパフォーマンスを劣化させる可能性があると警告しています。¹ Returnの9つのビューは、一度に画面を共有することはありません（デュレーションピッカーはメニュー状態でのみ表示され、停止ボタンはセッション中の一時停止時にのみ表示されます）。任意のフレームで見えるガラス要素は3つか4つで、これはiOS、iPadOS、macOS、watchOS、tvOSをまたいでテストしたすべてのデバイスで滑らかに動作していますが、コンテナでラップされたものとモディファイアのみのものを比較するinstrumentsトレースは取っていません。なので正直に言うと、Returnは観察された良好なユーザー体験に基づいてGlassEffectContainerをスキップしているのであり、測定されたパフォーマンス等価性に基づいているわけではありません。

このことから引き出したルールはこうです。GlassEffectContainerは、複数のガラス要素が同時に表示されアニメーションするアプリのためのものです。 Appleの例はglassEffectUnion(id:namespace:)を使ったシンボルセットレンダリングです。4つの天気シンボルが一体となって流動的にマージしたり分裂したりするものです。¹ それは教科書的なユースケースです。将来のReturnの機能でガラス要素がモーフしたりコンテナのスペーシングルールを共有したりする必要が出てきたら、そのときがコンテナを追加する適切なタイミングです。今日のアプリでは、まだそのケースに到達していません。

私を捕まえた落とし穴

プロダクションから得た3つの本物のバグです。

ガラス数字のジッター。 SF Pro Roundedはプロポーショナルレンダリングで可変幅の数字を持っています。タイマーがカウントダウンするにつれ、表示される文字列の長さが変わり、周囲のHStackが毎秒リフローしてタイマー全体がジッターしました。修正は、各文字に固定幅セルを使うことです。各数字はfontSize * 0.6のcellWidthを、各コロンはfontSize * 0.3を取り、HStackは安定したグリッドになります。⁶

HStack(spacing: 0) {
    ForEach(Array(text.enumerated()), id: \.offset) { _, char in
        let isColon = char == ":"
        let cellWidth = isColon ? colonCellWidth : digitCellWidth
        GlassDigitCell(character: String(char), font: ctFont,
                       cellWidth: cellWidth, cellHeight: cellHeight)
    }
}

このセルはApple標準ではありません。小さな固定フォントサイズでのプロポーショナル幅レンダリングのワークアラウンドです。Appleの.monospacedDigit()を付けたSF Pro RoundedはText上で同じ問題を解決しますが、このモディファイアはカスタムShapeベースのガラスレンダラーでは利用できません。固定セルレイアウトはその代替です。

tvOSのレイアウト方向のオーバーライド。 同じGlassTimerTextがiOS、iPadOS、macOS、tvOSで動いていました。tvOS特有の問題として、iOSバージョンが環境内のオーバーライドを尊重したのに対し、HStackが右から左の言語環境下でミラーされました。修正は、レイアウト方向を環境値と明示的なflipsForRightToLeftLayoutDirection(false)モディファイアの両方でピン留めすることでした。これは数字セルのHStackに直接適用します（親のVStackは別途環境オーバーライドを適用し、反射コピーがそれを継承するようにしています）。⁶

HStack(spacing: 0) { ... }
    .flipsForRightToLeftLayoutDirection(false)
    .environment(\.layoutDirection, .leftToRight)

理由はこうです。tvOSのHStackは、一部のバージョンで環境レベルのオーバーライドを無視するように見えます。flipsForRightToLeftLayoutDirection(false)は、より確実に尊重される明示的なノーミラー契約なのです。¹² ベルトとサスペンダーです。

数字のモーフでのreduce-motion。 Liquid Glassは表示される文字列の間のモーフ遷移をデフォルトでアニメーションします。accessibilityReduceMotionを有効にしているユーザーは、モーフがちらつきとして見えました。修正はこうです。⁶

.animation(reduceMotion ? nil : .easeInOut(duration: 0.15), value: displayTime)

アニメーションモディファイアは@Environment(\.accessibilityReduceMotion)を読み、reduce-motionが有効なときは遷移を完全に無効にします。Appleのアクセシビリティガイダンスは明示的です。装飾的なアニメーションはすべてユーザーのモーション設定を尊重しなければなりません。⁷

Liquid Glassを使わないとき

拒絶もデザインの一部です。

Liquid Glassをコンテンツレイヤーに置かないこと。 AppleのHIGは明示的で、このルールを無視すると混乱した階層を生み出します。ユーザーは何がインタラクティブで何がコンテンツなのかを判断できなくなります。³ ガラスエフェクトがリスト行や写真カードを装飾しているなら、そのデザインはプラットフォームと戦っています。

フラットな背景の上でガラスを使わないこと。 Liquid Glassは背後にあるものを屈折させます。「背後にあるもの」が単一の単色なら、屈折は曲げるものを持たず、結果としてフラットな色付きの矩形として読まれます。多様なコンテンツ（グラデーション、画像、動画）の上にガラスを置くか、ガラスを使わないかのどちらかです。Returnのタイマー画面は、テーマベースのカバー画像とループ動画を背景としてVideoBackgroundViewを介して流しており、⁴ その上のガラス要素が常に屈折させるテクスチャを持つようにしています。

高頻度コンテンツへのガラスには注意を。 ガラスマテリアルのレンダリングはGPUバウンドで、ガラスシェイプ変更間のデフォルトのモーフアニメーションそのものがアニメーションです。1秒に1回更新されるタイマーは私のテストでは問題ありませんが、60Hzの波形やオーディオビジュアライザーは未検証で、おそらくモーフアニメーションと衝突します。上限のベンチマークは取っていません。これを測定された閾値ではなく、ヒューリスティックとして扱ってください。Appleのドキュメントもそれを公表していません。

reduce-motionをテストせずにガラスを出荷しないこと。 すべてのガラスアニメーションはaccessibilityReduceMotionでゲートすべきです。⁷ ガラスシェイプ間のデフォルトのモーフは単なるフェードではなく、運動的なエフェクトです。

iOS 26+で出荷するアプリにとってLiquid Glassが意味するもの

テーゼは小さいです。Liquid Glassは、アプリがすでにHIGのレイヤリングルールを尊重しているときにのみ、1行のAPIになります。 ファンクショナルレイヤーにコントロールを、コンテンツレイヤーにコンテンツを置くSwiftUIアプリは、.glassEffect()モディファイアでLiquid Glassを採用でき、デフォルトでネイティブに感じられます。

2つのレイヤーを混合するアプリ（リスト行内のコントロール、コンテンツとして扱われるナビゲーションバー、写真カード上の装飾的なクローム）はLiquid Glassを採用しても違和感を覚えるでしょう。マテリアルは正しいのですが、その下のアーキテクチャがそうではないのです。

カスタムShapeパターン（パターン1）はルールをきれいに拡張します。機能的にコントロールであるものは何でも、従来の意味で「コントロール」のように見えなくても、Liquid Glassを取れます。タイマーはコントロール、レベルメーターはコントロール、プログレスインジケーターはコントロールです。それぞれにLiquid Glassを使うのは仕様通りです。

この記事は、同じアプリのデータレイヤーをApp Intents経由およびMCPサーバー経由で出荷した私の以前の記事と組み合わせて読んでください。視覚レイヤーは同じスタックの3つ目のサーフェスです。システムAI向けの型付きエンティティ、クロスLLMエージェント向けのファイルフォーマット、そしてデバイスにいる人間向けのLiquid Glassです。⁸

FAQ

iOS 26以外のプラットフォームで.glassEffect()を使えますか？

.glassEffect()モディファイアはiOS 26+、iPadOS 26+、macOS 26+、watchOS 26+、tvOS 26+、visionOS 26+です。26以前のプラットフォームには.background(.regularMaterial)などがあり、フロステッドガラス効果を生み出しますが、新しいLiquid Glassの屈折ではありません。¹

GlassEffectContainerは見た目を変えますか？

コンテナでラップされたガラス要素は、スペーシングルールが重なりを引き起こすときにシェイプをブレンドできます。コンテナがない場合、各.glassEffect()は独立しています。アニメーション中にガラス要素が流動的にマージすべきアプリでは、GlassEffectContainerが適切なツールです。各ガラス要素が個別に保たれるアプリでは、コンテナはオーバーヘッドです。¹

なぜTextを直接.foregroundStyle(.thinMaterial)で使わないのですか？

thinMaterialは標準マテリアルで、Liquid Glassではありません。見た目はフロステッドガラスのオーバーレイで、Liquid Glassの屈折を伴う光を曲げる効果ではありません。³ 新しいマテリアル特有の見た目を望むテキストには、.glassEffect(.clear, in: customShape)がサポートされたパスです。

マーケティング用にLiquid Glassのスクリーンショットをどう撮ればよいですか？

ガラスエフェクトはランタイムでGPUレンダリングされるので、スクリーンショットはエフェクトがすでに適用されたシミュレーターまたは実機から取られます。AppleのLiquid Glass公式リファレンス画像はHIGドキュメントページとWWDC 2025セッションから来ています。³

GlassTextShapeは任意のテキストで動きますか、それとも数字だけですか？

Core Textがレイアウトできる任意の文字列が動きます。Returnは数字とコロンに使っていますが、同じShapeは文字、シンボル、絵文字（適切なフォントで）、または混合文字列でも動きます。パフォーマンスはグリフカウントによって制限されます。ガラスとしてレンダリングされる長い段落は高コストですが、6文字のタイマーは些細なものです。

3つのパターン、1つのルール、そして意図的にスキップした1つのAPIです。Liquid GlassはiOS 26+アプリの3つ目のサーフェスで、型付きエンティティと共有ファイルフォーマットの上に位置します。1行のAPIは本物です。その下のHIGルールこそが、1行を機能させるものです。

参考文献