apple-design-system-wwdc25 - SKILL.md Agent Skill

name: apple-design-system-wwdc25 description: Applies Apple's WWDC25 design-system guidance ("Get to know the new design system", session 356) and AppKit new-design guidance ("Build an AppKit app with the new design", session 310) to native Apple app UI as implementation checks. Use when designing, reviewing, or refactoring SwiftUI, UIKit, AppKit, or Catalyst UI for iOS, iPadOS, macOS (Tahoe), visionOS, watchOS, or tvOS involving Liquid Glass, toolbars, tab bars, sidebars, inspectors, sheets, popovers, scroll edge effects, concentric shapes, materials, icons/SF Symbols, controls, onboarding, settings, responsive layout, cross-device continuity, or HIG-quality polish; and for macOS AppKit work with NSToolbar, NSToolbarItemGroup, NSItemBadge, NSSplitViewController, split-item/titlebar accessories, NSBackgroundExtensionView, NSView.LayoutRegion, prefersCompactControlSizeMetrics, borderShape, tint prominence, slider neutralValue, NSGlassEffectView, NSGlassEffectContainerView, NSVisualEffectView, NSAppearance, scroll edge behavior, and AppKit/SwiftUI interop.

Apple Design System WWDC25 (+ AppKit New Design)

Use this skill whenever designing, reviewing, or refactoring UI for Apple platforms, and whenever building, refactoring, or reviewing macOS AppKit UI for the current Apple design system. It turns two WWDC25 sessions into implementation checks:

Session 356, "Get to know the new design system" — cross-platform design language, structure, and continuity.
Session 310, "Build an AppKit app with the new design" — AppKit-specific APIs and Mac implementation.

For broader HIG coverage, also use apple-human-interface-guidelines. When a macOS UI is SwiftUI-first with AppKit interop, also use build-macos-apps:swiftui-patterns; when bridging AppKit views into SwiftUI or SwiftUI into AppKit, also use build-macos-apps:appkit-interop.

Sources

Primary sources:

Get to know the new design system (session 356): https://developer.apple.com/videos/play/wwdc2025/356/ — themes: design language, structure, continuity. Key concepts: Liquid Glass as a functional layer, concentric shapes, refined color and typography, grouped bars, source-anchored sheets, scroll edge effects, inset sidebars, background extension, shared anatomy across devices, symbol/text clarity, and continuity across iPhone, iPad, and Mac.
Build an AppKit app with the new design (session 310): https://developer.apple.com/videos/play/wwdc2025/310/ — chapters: App structure, scroll edge effect, controls, glass, next steps. Major API themes: NSToolbarItem, NSToolbarItemGroup, NSItemBadge, NSSplitViewController, split item accessories, NSBackgroundExtensionView, NSView.LayoutRegion, prefersCompactControlSizeMetrics, control border shapes, tint prominence, slider neutral values, NSGlassEffectView, and NSGlassEffectContainerView.

Linked Apple references to verify when needed:

Adopting Liquid Glass: https://developer.apple.com/documentation/TechnologyOverviews/adopting-liquid-glass
Liquid Glass overview: https://developer.apple.com/documentation/technologyoverviews/liquid-glass
Applying Liquid Glass to custom views (SwiftUI): https://developer.apple.com/documentation/swiftui/applying-liquid-glass-to-custom-views
HIG Toolbars: https://developer.apple.com/design/human-interface-guidelines/toolbars
HIG Icons: https://developer.apple.com/design/human-interface-guidelines/icons
HIG Materials: https://developer.apple.com/design/human-interface-guidelines/materials
Designing for macOS: https://developer.apple.com/design/human-interface-guidelines/designing-for-macos
Human Interface Guidelines (root): https://developer.apple.com/design/human-interface-guidelines/
AppKit: https://developer.apple.com/documentation/AppKit
NSGlassEffectView: https://developer.apple.com/documentation/appkit/nsglasseffectview
NSGlassEffectContainerView: https://developer.apple.com/documentation/appkit/nsglasseffectcontainerview
NSBackgroundExtensionView: https://developer.apple.com/documentation/AppKit/NSBackgroundExtensionView

Source-attribution guidance: for source links in an answer, cite the WWDC session first (356 for cross-platform principles, 310 for AppKit APIs), then the specific Apple reference page. If Apple updates the HIG, re-check the linked pages before changing rules.

Cross-platform workflow

Read the cross-platform rules below before making any Apple-platform UI change.
Identify the target platforms and input modes: iPhone, iPad, Mac, watchOS, tvOS, visionOS, pointer, touch, keyboard, controller, or focus.
Prefer standard SwiftUI, UIKit, AppKit, and Catalyst components before custom drawing. Let system bars, sheets, controls, sidebars, menus, and materials adopt the current design behavior.
Remove custom backgrounds, borders, dividers, and decorative overlays from navigation and control layers unless the product has a specific functional reason.
Treat Liquid Glass as a functional navigation/control layer above content, not as a decorative content material.
Build the app anatomy once, then adapt layout and density per device. Do not create separate unrelated UI systems for iPhone, iPad, and Mac.
Before finishing, run the Cross-platform Review Checklist and verify the changed UI on every relevant appearance, contrast, size class, and input mode.

AppKit workflow

Read the AppKit rules below before changing AppKit UI.
Build or inspect with the current SDK first. Many toolbar, split-view, control, menu, and material updates are automatic.
Audit structure from the top down: window, toolbar, split view, sidebar/inspector, scroll views, accessory views, controls, menus, then custom glass.
Prefer AppKit-owned behaviors over custom effects. Remove legacy NSVisualEffectView sidebar material, custom toolbar backing, fixed control heights, and sibling-view glass hacks.
Use AppKit's new APIs only where they express intent: toolbar item grouping/prominence/badges, split item accessories, background extension, layout-region corner avoidance, compact metrics, border shape, tint prominence, neutral slider values, and glass effect containers.
Verify with real window resizing, edge-to-edge content, light/dark adaptive toolbar glass, keyboard/default-button behavior, pointer interaction, accessibility, and performance.

Non-negotiables

Cross-platform:

No dense wall-of-card Apple UI. Use structure, grouping, hierarchy, and native components instead of card-heavy decoration.
No custom toolbar or tab-bar chrome that fights system materials.
No Liquid Glass in the content layer except transient interactive cases such as active controls.
No unlabeled or ambiguous symbols when text is clearer.
No platform fork unless behavior genuinely differs. Keep shared anatomy and shared core interactions.
No "looks good in one screenshot" signoff. Check window resizing, light/dark, increased contrast, reduced transparency, reduced motion, keyboard focus, and touch/pointer hit targets.

AppKit:

Do not fake Liquid Glass with blur overlays or decorative translucent siblings.
Do not put noninteractive toolbar titles/status labels on glass; make those toolbar items unbordered.
Do not keep legacy sidebar NSVisualEffectView material when using new split-view sidebar glass.
Do not hardcode AppKit control heights. Use Auto Layout and only opt into compact metrics for genuinely dense legacy panels.
Do not add nearby multiple glass views without NSGlassEffectContainerView.
Do not use Liquid Glass for regular content. Reserve it for top-level controls and navigation that float over content.

Cross-platform rules (WWDC25 session 356)

Source basis: Apple WWDC25 session 356, "Get to know the new design system", plus its linked Apple HIG and Liquid Glass references.

Design Language

Treat Liquid Glass as a system-level design update, not a visual effect to sprinkle around.
Use system components first. Standard controls, navigation, sheets, popovers, split views, tab bars, and toolbars inherit the new look and behavior when built with current SDKs.
Custom UI must harmonize with system rhythm: shape, spacing, typography, color, motion, depth, and input behavior need to feel native together.
Use system colors and semantic colors by default. If custom colors are necessary, provide light, dark, and increased-contrast variants.
Test custom color over material, transparency, and busy content. Legibility beats atmosphere.
Use stronger, clearer typography for key moments such as alerts, onboarding, and decision points.
Prefer left-aligned readable text in dense or instructional UI.
Do not scale font size with viewport width. Use Dynamic Type and platform text styles.
Avoid negative letter spacing. It fights system typography and harms readability.
Let system spacing and metrics drive layout. Avoid hardcoded control dimensions unless matching a measured platform requirement.

Shape And Concentricity

Align nested shapes around a shared center where possible.
Use three shape ideas consistently:
- Fixed-radius shapes for compact controls and dense layouts.
- Capsules for controls whose radius is half their height.
- Concentric shapes for nested surfaces where inner radius follows parent radius minus padding.
Use capsules for high-emphasis touch-friendly actions, sliders, switches, large buttons, and controls that need strong focus.
On macOS, small and medium dense controls can remain rounded rectangles; large or spacious controls can use capsules.
Use concentric inner radii for artwork inside cards, tiles inside panels, and nested containers.
Do not leave inner corners pinched, flared, or visually unrelated to the parent.
Near iPhone screen edges, favor capsule controls with enough margin from the display edge.
Near iPad or Mac window edges, align concentric shapes with the window or pane edge.
For reusable components that can be nested or standalone, use a concentric shape with a sensible fallback radius.
Do not use excessive rounding everywhere. Shape choice should express density, hierarchy, and platform context.

Liquid Glass Layering

Liquid Glass belongs to functional elements such as navigation, controls, sidebars, bars, sheets, popovers, and transient interactive control states.
Do not use Liquid Glass as a background for normal content, data cards, prose, lists, dashboards, or decorative panels.
Standard materials belong inside the content layer when a content surface needs depth or separation.
Apply material to the control surface itself, not to arbitrary inner subviews.
Do not stack Liquid Glass layers on top of each other.
Avoid overusing custom Liquid Glass effects. Too much material distracts from content.
If multiple custom glass elements morph or interact, group them in the platform-supported container for better behavior and performance.
Always test reduced transparency and reduced motion. The design must remain understandable without full material and animation effects.
Treat focus state, overlap, and interaction as dynamic. Do not bake static translucency assumptions into screenshots or constants.
Controls should float above content only when that improves structure or access.

Structure And Information Architecture

Navigation and controls form a functional layer above content. Keep the content layer and functional layer visually distinct.
Remove old custom toolbar, tab bar, sidebar, and navigation backgrounds unless still functionally required.
Do not express hierarchy with extra decoration. Prefer layout, grouping, position, and system tint.
Group toolbar items by function and frequency.
Avoid overcrowded bars. Move secondary actions into menus.
Do not group a text button and an icon button as if they are one combined action.
Primary actions should remain visually separate and clearly identifiable.
On iOS, make Search a first-class tab when search is a core persistent destination.
Tab bars are for persistent navigation, not screen-specific actions.
Accessory views in tab bars should support persistent app-wide experiences, not local commands.
Menus should use symbols where symbols improve scanning.
Closely related menu actions should not repeat near-identical symbols. Use one symbol to introduce the group and let labels distinguish actions.
Use standard selectors and platform APIs so common menu items can inherit standard glyphs and behavior.
Top contextual-menu actions should match the swipe actions for the same item.

Sheets, Popovers, And Modality

Anchor action sheets and contextual surfaces to the element that caused them.
Specify the source view, item, or presentation anchor for action sheets and popovers.
A task that interrupts the main flow needs clearer focus, often with dimming and a stronger modal boundary.
A parallel task can separate from content with material without breaking the flow.
Half sheets and inset sheets need content behind them to remain visually intentional.
Check sheet edge content so controls do not collide with rounder corners.
Remove custom visual-effect backgrounds from popovers and sheets unless a real platform gap requires them.
When a sheet grows into deeper engagement, preserve focus and legibility through stronger opacity or system behavior.
Modal copy should be brief, specific, and action-oriented.
Do not make users hunt for the primary action in modal surfaces.

Scroll Edges And Background Extension

Scroll edge effects clarify where floating UI meets content. They are not decoration.
Use scroll edge effects only when floating or pinned UI overlaps scrollable content.
Apply one scroll edge effect per view.
Do not mix or stack soft and hard edge effects in the same boundary.
Use soft edge effects for most iOS and iPadOS interactive overlap.
Use harder edge effects mainly on macOS when text, table headers, or controls need stronger separation.
In split views, each pane may have its own edge effect, but heights should align.
Sidebars can be inset and built with Liquid Glass so content can extend behind them.
Use background extension effects for expansive hero images, tinted backgrounds, or large visual surfaces.
Keep text and controls above background extension effects to avoid distortion or contrast loss.
Let scroll views extend beneath sidebars when discovery or continuity benefits.
Do not use blur as a divider replacement where there is no functional boundary.

Layout And Continuity

Design the app anatomy once, then adapt the same anatomy across devices.
Preserve the user's task across device changes, window resizing, and layout transitions.
iPhone layouts are narrow and focused. Prioritize task clarity.
iPad is the adaptive middle ground. Support resizing and fluid column changes.
Mac is wide and expansive. Use density, inspector patterns, sidebars, and keyboard affordances appropriately.
Keep intentionally grouped content together as layout adapts.
Use the same symbols for the same concepts across devices.
Keep component anatomy stable: icon, label, accessory, selection marker, and state indicator should appear in familiar positions even when presentation changes.
Platform variation should express the same framework, not become a separate app.
Core interactions must remain the same even when the component form changes.
Selection, navigation, and state feedback should be consistent across tab bars, segmented controls, sidebars, menus, and lists.
Support arbitrary iPad and Mac window sizes instead of designing only for preset breakpoints.
Use split views and safe areas so the system can manage window controls, title bars, and resizing.

Icons, Text, And Labels

Use SF Symbols and HIG-preferred glyphs for common actions where possible.
Symbols are good when the action has a widely recognized visual shorthand.
Use text labels when a symbol is ambiguous.
Do not use a pencil icon for every edit-like concept if the actual action could mean annotate, compose, modify, or select.
Do not use a checkmark for actions that could be confused with confirm, done, selected, or approve unless context is unmistakable.
In bars, symbol-heavy UI is acceptable only when recognition is strong and accessibility labels are correct.
Menus can use symbols for scanability, but text remains the precise contract.
Keep icon visual weight balanced. Do not assume equal frame size means equal perceived size.
Never rely on icon-only affordances without accessibility labels.
For destructive or security-sensitive actions, text clarity beats compactness.

Controls (cross-platform)

Use standard Button, Toggle, Slider, Stepper, Picker, TextField, segmented controls, and platform equivalents whenever possible.
Do not hardcode control layout metrics that prevent current SDK controls from adopting updated shape and size.
Review controls for crowding after rebuilding with the latest SDK.
Use the extra-large control size when spacious, high-emphasis labeling benefits.
Use color in controls sparingly.
Tinted primary actions should remain legible in light, dark, and increased contrast.
Dense inspector UI on macOS can use smaller controls and rounded rectangles.
Touch-first UI should preserve comfortable hit targets and spacing.
Pointer and keyboard UI should preserve focus rings, hover states, menu access, and shortcuts.
Do not layer glass controls over busy content without separation.

Lists, Tables, Forms, And Organization

List, table, and form rows may need more breathing room under the new design.
Use updated section corner radii and system grouped styles where possible.
Section headers should use title-style capitalization when matching the current system style.
Dense operational UI still needs scanability; do not turn every row into a large decorative card.
Use table/list selection states consistently across platforms.
Use disclosure, accessory, and status placement consistently across iPhone, iPad, and Mac variants.
Keep repeated content in stable dimensions to avoid layout shift.
Empty, loading, error, and permission-denied states must be designed, not improvised.

Accessibility And Settings

Test light, dark, increased contrast, reduced transparency, and reduced motion.
Test Dynamic Type or platform text scaling.
Test keyboard navigation and visible focus.
Test VoiceOver labels for icon-only buttons and custom controls.
Test pointer hover and right-click/context menus on iPad and Mac.
Test touch target size on iPhone and iPad.
Avoid conveying state by color alone.
Keep material-backed text legible over realistic content, not blank mock backgrounds.
Prefer system colors and vibrant colors over fixed grays on material.
Custom animation must respect motion settings and must not be required for comprehension.

Platform Notes

SwiftUI: prefer NavigationStack, NavigationSplitView, toolbar, confirmationDialog, standard controls, safe areas, and current material/glass APIs.
UIKit: prefer UINavigationBar, UITabBar, UIToolbar, UISplitViewController, standard controls, source views for presentations, and standard selectors.
AppKit: prefer NSToolbar, NSSplitViewController, standard controls, menus, title bar behavior, and macOS density conventions.
Catalyst: audit every toolbar, menu, split view, and modal because inherited defaults can reveal web-like or iOS-only assumptions.
iPadOS: support continuous window resizing, menu bar commands, pointer, keyboard, and fluid split-view layouts.
macOS: do not inflate all controls to touch scale. Preserve desktop density while adopting new materials and hierarchy.
watchOS: keep to standard button styles and toolbar APIs.
tvOS: use standard focus APIs so focus effects and Liquid Glass behavior align with the system.
visionOS: preserve depth hierarchy, focus clarity, and legibility; avoid decorative material overload.

Cross-platform Review Checklist

Before calling Apple-platform UI work complete, verify:

Standard components were preferred over custom drawing.
Custom bars, tab bars, sidebars, and controls do not fight system material.
Liquid Glass is only in the functional layer or transient interactive controls.
Nested shapes are concentric or intentionally fixed.
Toolbar actions are grouped by function and frequency.
Primary actions are separate and obvious.
Tab bars contain persistent navigation, not contextual commands.
Action sheets/popovers originate from their source.
Scroll edge effects are used only where functional and not stacked.
Background extension keeps text and controls above distorted content.
Symbols are consistent across devices.
Ambiguous actions use text labels.
Shared component anatomy survives iPhone, iPad, and Mac layouts.
Window resizing keeps task continuity.
Light, dark, increased contrast, reduced transparency, and reduced motion were checked.
Keyboard, pointer, touch, and accessibility labels were checked.
No dense wall of decorative cards was introduced.
The UI feels like the current Apple platform, not a web app in a native shell.

AppKit rules (WWDC25 session 310)

Source basis: Apple WWDC25 session 310, "Build an AppKit app with the new design", plus AppKit, Liquid Glass, and macOS HIG references.

Adoption Pass

Rebuild with the current Xcode SDK before redesigning. Let AppKit show what updates automatically.
Audit from structural regions inward: window, toolbar, split view, sidebar, inspector, scroll views, accessory views, controls, menus, custom glass.
Remove custom chrome before adding new chrome.
Use AppKit controls and containers first; custom views should fill actual product gaps.
Validate in active and inactive window states, light and dark appearance, high contrast, reduced transparency, and reduced motion.

Window And Toolbar Structure

Treat the toolbar as a floating functional region above content.
Let NSToolbar place items on adaptive glass by default.
Trust automatic toolbar grouping for multiple action buttons.
Use NSToolbarItemGroup when toolbar actions need explicit logical grouping.
Use spacers to separate unrelated toolbar groups.
Do not put noninteractive labels, titles, counters, or status indicators on glass as if they are buttons.
For noninteractive toolbar items, set the toolbar item to an unbordered presentation.
Use toolbar item prominence for important state or primary emphasis.
Use a toolbar item background tint only when color communicates meaningful state or priority.
Do not tint a group of unrelated toolbar actions.
Use NSItemBadge for unread, pending, new, or notification-like toolbar state.
Badges must communicate state, not decoration.
Check toolbar content against adaptive glass over bright and dark scrolled content.
Dark Mode support must flow through NSAppearance; do not special-case static toolbar colors.

Split Views, Sidebars, And Inspectors

Use NSSplitViewController for split layouts so AppKit can supply current sidebar and inspector materials.
Use sidebar or inspector split-item behavior instead of hand-built panel chrome.
Sidebars float above adjacent content on glass.
Inspectors use edge-to-edge glass beside content.
Remove legacy sidebar NSVisualEffectView material; it blocks the new sidebar glass.
If content should flow beneath a floating sidebar, enable automatic safe-area adjustment on the content split item, not on the sidebar.
Use content under sidebars for maps, artwork, media, horizontal scrolling, swipe-reveal list rows, and other surfaces that benefit from edge-to-edge continuity.
Keep controls and text inside safe areas even when visual content extends beneath glass.
Do not obscure important artwork just to achieve the sidebar-underlay effect.
For edge-to-edge artwork without spare negative space, use background extension rather than covering the actual content.

Background Extension

Use NSBackgroundExtensionView when content should visually extend under a titlebar, sidebar, or inspector without moving important content under those regions.
Assign the actual content as the background extension view's content view.
Let the view place content inside the safe area and generate edge extension outside it.
Use this for hero art, posters, photos, maps, media, and rich visual backgrounds.
Do not use it for text-heavy or control-heavy surfaces where replicated/blurred edges reduce clarity.

Window Corners And Layout Regions

New macOS window corners are softer and larger, especially with toolbars.
Content close to window corners can clip or feel crowded.
Use NSView.LayoutRegion and corner adaptation when controls need to sit near a rounded window corner.
Prefer layout-region guides over hardcoded corner padding.
Use horizontal or vertical corner adaptation based on which edge the content approaches.
Keep corner avoidance inside Auto Layout constraints so resizing remains correct.
Titlebar-only windows and toolbar windows can have different corner geometry; do not assume one radius.

Scroll Edge Effect (AppKit)

The scroll edge effect separates floating glass from edge-to-edge content.
In AppKit, let NSScrollView host the effect for scrollable content.
The effect can adapt as floating regions appear, disappear, or change size.
Use titlebar accessories and split item accessories for floating content that should participate in the scroll edge effect.
Use NSSplitViewItemAccessoryViewController for accessories that belong to a single split pane.
Add top-aligned or bottom-aligned split item accessories through the split view item APIs.
Do not fake scroll edge effects with manual overlays.
Do not place floating accessory controls outside the mechanisms that update safe areas and edge effects.
Prefer accessory APIs because they influence both the visual edge and the content safe area.

Controls (AppKit APIs)

AppKit control metrics changed. Audit any old fixed heights.
Use Auto Layout instead of hardcoded control heights.
Mini, small, and medium controls remain desktop-density controls but now have more breathing room.
Large and extra-large controls express higher emphasis and use rounder capsule-like shapes.
Use extra-large controls only for primary actions people launch the app to perform.
For dense inspectors and popovers that genuinely need previous sizing, set prefersCompactControlSizeMetrics on the relevant container view.
Do not set compact metrics globally just to avoid layout work.
Use borderShape to align buttons, popup buttons, and segmented controls with a custom container's shape.
Use capsule shapes for medium controls inside capsule containers when concentricity would otherwise break.
Use glass bezel style only for buttons that need to float above content.
Use bezel color or tint only when it improves meaning, state, or action recognition.
Use tint prominence to control how much visual weight a color receives.
For destructive buttons, prefer lower prominence red tint when a warning cue is needed without overpowering a nearby primary/default action.
Make the default action respond to Return with a key equivalent where appropriate.
Let default-button status drive primary prominence instead of manually over-tinting.
Use slider tint prominence to choose whether the filled track is meaningful.
Use slider neutralValue when the visual fill should communicate deviation from a baseline, such as playback speed around 1x.

Menus (AppKit)

Add clear, recognizable symbols to important menu actions.
Menu icons should form a scan-friendly column within sections.
Use symbols for recognition, not decoration.
Avoid near-duplicate symbols in closely related actions.
Text remains the precise command name; iconography supports scanning.
Keep menu bar menus and context menus consistent in action naming and symbol choices.
Prefer standard menu commands and selectors so the system can apply current platform behavior.

Custom Liquid Glass (AppKit)

Before adding custom glass, ask whether the element is top-level functionality floating over content.
Use custom glass sparingly for important controls and navigation, not content cards.
Use NSGlassEffectView to put specific content on glass.
Set the glass effect view's contentView; do not put glass behind content as a sibling.
Let AppKit apply legibility treatments through the glass content relationship.
Customize corner radius only to maintain shape harmony.
Customize tint only when it supports state, brand, or action hierarchy without hurting legibility.
If several glass views are close together or form a logical group, wrap them in NSGlassEffectContainerView.
Use NSGlassEffectContainerView.spacing to control when grouped glass elements visually merge.
Grouping glass views improves visual correctness because glass sampling is shared.
Grouping glass views improves performance by reducing repeated sampling passes.
Do not allow one glass view to sample another glass view through overlap or proximity outside a container.
Profile custom glass in realistic windows over real content.

Mac Experience Rules

Mac apps should use large displays to reduce unnecessary nesting and modality.
Preserve comfortable information density; do not inflate the app into touch-only spacing.
Support resizable, hideable, showable, movable windows and full-screen mode when appropriate.
Use the menu bar for complete command access.
Support keyboard shortcuts for frequent actions.
Support high-precision pointer workflows.
Support toolbar customization or view configuration where it fits the app's purpose.
Keep inactive-window behavior polished.
Do not ship an iOS layout in a Mac window.

AppKit Review Checklist

Before calling AppKit new-design work complete, verify:

Built with the current SDK.
Toolbar items group correctly.
Noninteractive toolbar items are not bordered/glass-backed like buttons.
Important toolbar actions use prominence or badges only with meaning.
Split views use NSSplitViewController and correct sidebar/inspector behavior.
Legacy sidebar material was removed.
Content that extends beneath sidebars uses safe-area adjustment correctly.
Rich edge-to-edge visuals use NSBackgroundExtensionView where appropriate.
Corner-adjacent controls use layout regions instead of magic padding.
Scroll edge effects come from scroll/accessory APIs, not overlays.
Control heights are not hardcoded.
Compact metrics are limited to genuinely dense legacy regions.
Border shapes preserve concentricity.
Default buttons have correct keyboard behavior.
Sliders with baselines use neutral values.
Menus include helpful symbols.
Custom glass uses contentView, not sibling backgrounds.
Nearby glass elements are grouped in a glass effect container.
The window resizes cleanly.
Light/dark, contrast, reduced transparency, reduced motion, keyboard, pointer, and accessibility states were checked.