[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PPWFM2HEPQFVTBBVZVRW2Z":3,"skill-same:01M6PPWFM2HEPQFVTBBVZVRW2Z":92},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6PPWFM2HEPQFVTBBVZVRW2Z","ipados-design-guidelines",null,"Apple Human Interface Guidelines for iPad. Use when building iPad-optimized interfaces, implementing multitasking, pointer support, keyboard shortcuts, or responsive layouts. Triggers on tasks involving iPad, Split View, Stage Manager, sidebar navigation, or trackpad support.","headmktlucca-ui\u002Fneuroads-lp","headmktlucca-ui","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F247379838?v=4","01M6PDVAV6M1W96D1SR1PDF8CS","NeuroAds","01M6PDVAZ4P281GNDKD45CYTF5",0,"MIT","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fipados\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"guidelines","ipados design guidelines","design","apple","for","implementing","manager","split","interface","keyboard","triggers","platform","ipad","responsive","stage","human","use","view","tasks","support","2026-11-10 10:12:30",false,"---\nname: ipados-design-guidelines\ndescription: Apple Human Interface Guidelines for iPad. Use when building iPad-optimized interfaces, implementing multitasking, pointer support, keyboard shortcuts, or responsive layouts. Triggers on tasks involving iPad, Split View, Stage Manager, sidebar navigation, or trackpad support.\nlicense: MIT\nmetadata:\n  author: platform-design-skills\n  version: \"1.0.0\"\n---\n\n# iPadOS Design Guidelines\n\nComprehensive rules for building iPad-native apps following Apple's Human Interface Guidelines. iPad is not a big iPhone -- it demands adaptive layouts, multitasking support, pointer interactions, keyboard shortcuts, and inter-app drag and drop. These rules extend iOS patterns for the larger, more capable canvas.\n\n---\n\n## 1. Responsive Layout (CRITICAL)\n\n### 1.1 Use Adaptive Size Classes\n\niPad presents two horizontal size classes: **regular** (full screen, large splits) and **compact** (Slide Over, narrow splits). Design for both. Never hardcode dimensions.\n\n```swift\nstruct AdaptiveView: View {\n    @Environment(\\.horizontalSizeClass) var sizeClass\n\n    var body: some View {\n        if sizeClass == .regular {\n            TwoColumnLayout()\n        } else {\n            StackedLayout()\n        }\n    }\n}\n```\n\n### 1.2 Don't Scale Up iPhone UI\n\niPad layouts must be purpose-built. Stretching an iPhone layout across a 13\" display wastes space and feels wrong. Use multi-column layouts, master-detail patterns, and increased information density in regular width.\n\n### 1.3 Support All iPad Screen Sizes\n\nDesign for the full range: iPad Mini (8.3\"), iPad (11\"), iPad Air (11\"\u002F13\"), and iPad Pro (11\"\u002F13\"). Use flexible layouts that redistribute content rather than simply scaling.\n\n### 1.4 Column-Based Layouts for Regular Width\n\nIn regular width, organize content into columns. Two-column is the most common (sidebar + detail). Three-column works for deep hierarchies (sidebar + list + detail). Avoid single-column full-width layouts on large screens.\n\n```swift\nstruct ThreeColumnLayout: View {\n    var body: some View {\n        NavigationSplitView {\n            SidebarView()\n        } content: {\n            ContentListView()\n        } detail: {\n            DetailView()\n        }\n    }\n}\n```\n\n### 1.5 Respect Safe Areas\n\niPad safe areas differ from iPhone. Older iPads have no home indicator. iPads in landscape have different insets than portrait. Always use `safeAreaInset` and never hardcode padding for notches or indicators.\n\n### 1.6 Support Both Orientations\n\niPad apps must work well in both portrait and landscape. Landscape is the dominant orientation for productivity. Portrait is common for reading. Adapt column counts and layout density to orientation.\n\n---\n\n## 2. Multitasking (CRITICAL)\n\n### 2.1 Support Split View\n\nYour app must function correctly at 1\u002F3, 1\u002F2, and 2\u002F3 screen widths in Split View. At 1\u002F3 width, your app receives compact horizontal size class. Content must remain usable at every split ratio.\n\n### 2.2 Support Slide Over\n\nSlide Over presents your app as a compact-width overlay on the right edge. It behaves like an iPhone-width app. Ensure all functionality remains accessible in this narrow mode.\n\n### 2.3 Handle Stage Manager\n\nStage Manager allows freely resizable windows and multiple windows simultaneously. Your app must:\n- Resize fluidly to arbitrary dimensions\n- Support multiple scenes (windows) showing different content\n- Not assume any fixed size or aspect ratio\n\n```swift\n@main\nstruct MyApp: App {\n    var body: some Scene {\n        WindowGroup {\n            ContentView()\n        }\n        \u002F\u002F Support multiple windows\n        WindowGroup(\"Detail\", for: Item.ID.self) { $itemId in\n            DetailView(itemId: itemId)\n        }\n    }\n}\n```\n\n### 2.4 Never Assume Full Screen\n\nThe app may launch directly into Split View or Stage Manager. Do not depend on full-screen dimensions during setup, onboarding, or any flow. Test your app at every possible size.\n\n### 2.5 Handle Size Transitions Gracefully\n\nWhen the user resizes via multitasking, animate layout changes smoothly. Preserve scroll position, selection state, and user context across size transitions. Never reload content on resize.\n\n### 2.6 Support Multiple Scenes\n\nUse `UIScene` \u002F SwiftUI `WindowGroup` to let users open multiple instances of your app showing different content. Each scene is independent. Support `NSUserActivity` for state restoration.\n\n---\n\n## 3. Navigation (CRITICAL)\n\n### 3.1 Sidebar for Primary Navigation\n\nIn regular width, replace the iPhone tab bar with a sidebar. The sidebar provides more room for navigation items, supports sections, and feels native on iPad.\n\n```swift\nstruct AppNavigation: View {\n    @State private var selection: NavigationItem? = .inbox\n\n    var body: some View {\n        NavigationSplitView {\n            List(selection: $selection) {\n                Section(\"Main\") {\n                    Label(\"Inbox\", systemImage: \"tray\")\n                        .tag(NavigationItem.inbox)\n                    Label(\"Drafts\", systemImage: \"doc\")\n                        .tag(NavigationItem.drafts)\n                    Label(\"Sent\", systemImage: \"paperplane\")\n                        .tag(NavigationItem.sent)\n                }\n                Section(\"Labels\") {\n                    \u002F\u002F Dynamic sections\n                }\n            }\n            .navigationTitle(\"Mail\")\n        } detail: {\n            DetailView(for: selection)\n        }\n    }\n}\n```\n\n### 3.2 Automatic Tab-to-Sidebar Conversion\n\nSwiftUI `TabView` with `.sidebarAdaptable` style automatically converts to a sidebar in regular width. Use this for seamless iPhone-to-iPad adaptation.\n\n```swift\nTabView {\n    Tab(\"Home\", systemImage: \"house\") { HomeView() }\n    Tab(\"Search\", systemImage: \"magnifyingglass\") { SearchView() }\n    Tab(\"Profile\", systemImage: \"person\") { ProfileView() }\n}\n.tabViewStyle(.sidebarAdaptable)\n```\n\n### 3.3 Three-Column Layout for Complex Hierarchies\n\nUse `NavigationSplitView` with three columns when your information architecture has three levels: category > list > detail. Examples: mail (accounts > messages > message), file managers, settings.\n\n### 3.4 Toolbar at Top\n\nOn iPad, toolbars live at the top of the screen in the navigation bar area, not at the bottom like iPhone. Place contextual actions in `.toolbar` with appropriate placement.\n\n```swift\n.toolbar {\n    ToolbarItemGroup(placement: .primaryAction) {\n        Button(\"Compose\", systemImage: \"square.and.pencil\") { }\n    }\n    ToolbarItemGroup(placement: .secondaryAction) {\n        Button(\"Archive\", systemImage: \"archivebox\") { }\n        Button(\"Delete\", systemImage: \"trash\") { }\n    }\n}\n```\n\n### 3.5 Detail View Should Never Be Empty\n\nWhen no item is selected in a list\u002Fsidebar, show a meaningful empty state in the detail area. Use a placeholder with icon and instruction text, not a blank screen.\n\n### 3.6 Reduce Recall in Large-Canvas Navigation\n\nKeep sidebar selection, search terms, and disclosure state visible and preserved across size changes and scene switches. In multi-column layouts, users should resume from structure on screen, not from memory.\n\n---\n\n## 4. Pointer & Trackpad (HIGH)\n\n### 4.1 Add Hover Effects to Interactive Elements\n\nAll tappable elements should respond to pointer hover. The system provides automatic hover effects for standard controls. For custom views, use `.hoverEffect()`.\n\n```swift\nButton(\"Action\") { }\n    .hoverEffect(.highlight)  \u002F\u002F Subtle highlight on hover\n\n\u002F\u002F Custom hover effect\nMyCustomView()\n    .hoverEffect(.lift)  \u002F\u002F Lifts and adds shadow\n```\n\n### 4.2 Pointer Magnetism on Buttons\n\nThe pointer should snap to (be attracted toward) button bounds. Standard UIKit\u002FSwiftUI buttons get this automatically. For custom hit targets, ensure the pointer region matches the tappable area using `.contentShape()`.\n\n### 4.3 Support Right-Click Context Menus\n\nRight-click (secondary click) should present context menus. Use `.contextMenu` which automatically supports both long-press (touch) and right-click (pointer).\n\n```swift\nText(item.title)\n    .contextMenu {\n        Button(\"Copy\", systemImage: \"doc.on.doc\") { }\n        Button(\"Share\", systemImage: \"square.and.arrow.up\") { }\n        Divider()\n        Button(\"Delete\", systemImage: \"trash\", role: .destructive) { }\n    }\n```\n\n### 4.4 Trackpad Scroll Behaviors\n\nSupport two-finger scrolling with momentum. Pinch to zoom where appropriate. Respect scroll direction preferences. For custom scroll views, ensure trackpad gestures feel natural alongside touch gestures.\n\n### 4.5 Customize Cursor for Content Areas\n\nChange cursor appearance based on context. Text areas show I-beam. Links show pointer hand. Resize handles show resize cursors. Draggable items show grab cursor.\n\n### 4.6 Pointer-Driven Drag and Drop\n\nPointer users expect click-and-drag for rearranging, selecting, and moving content. Combine with multi-select via Shift-click and Cmd-click.\n\n---\n\n## 5. Keyboard (HIGH)\n\n### 5.1 Cmd+Key Shortcuts for All Major Actions\n\nEvery primary action must have a keyboard shortcut. Standard shortcuts are mandatory:\n\n| Shortcut | Action |\n|----------|--------|\n| Cmd+N | New item |\n| Cmd+F | Find\u002FSearch |\n| Cmd+S | Save |\n| Cmd+Z | Undo |\n| Cmd+Shift+Z | Redo |\n| Cmd+C\u002FV\u002FX | Copy\u002FPaste\u002FCut |\n| Cmd+A | Select all |\n| Cmd+P | Print |\n| Cmd+W | Close window\u002Ftab |\n| Cmd+, | Settings\u002FPreferences |\n| Delete | Delete selected item |\n\n```swift\nButton(\"New Document\") { createDocument() }\n    .keyboardShortcut(\"n\", modifiers: .command)\n```\n\n### 5.2 Discoverability via Cmd-Hold Overlay\n\nWhen the user holds the Cmd key, iPadOS shows a shortcut overlay. Register all shortcuts using `.keyboardShortcut()` so they appear in this overlay. Group related shortcuts logically.\n\n### 5.3 Tab Key Navigation Between Fields\n\nSupport Tab to move forward and Shift+Tab to move backward between form fields and focusable elements. Use `.focusable()` and `@FocusState` to manage keyboard focus order.\n\n```swift\nstruct FormView: View {\n    @FocusState private var focusedField: Field?\n\n    var body: some View {\n        Form {\n            TextField(\"Name\", text: $name)\n                .focused($focusedField, equals: .name)\n            TextField(\"Email\", text: $email)\n                .focused($focusedField, equals: .email)\n            TextField(\"Phone\", text: $phone)\n                .focused($focusedField, equals: .phone)\n        }\n    }\n}\n```\n\n### 5.4 Never Override System Shortcuts\n\nDo not claim shortcuts reserved by the system: Cmd+H (Home), Cmd+Tab (App Switcher), Cmd+Space (Spotlight), Globe key combinations. These will not work and create confusion.\n\n### 5.5 Detect Hardware Keyboard\n\nAdapt UI when a hardware keyboard is connected. Hide the on-screen keyboard shortcut bar. Show keyboard-optimized controls. Use `GCKeyboard` or track keyboard visibility to detect state.\n\n### 5.6 Arrow Key Navigation\n\nSupport arrow keys for navigating lists, grids, and collections. Combine with Shift for multi-selection. This is essential for productivity-focused apps.\n\n### 5.7 Shortcuts Must Be Discoverable\n\nDo not rely on users memorizing shortcut vocabularies. Expose commands through the Cmd-hold overlay, menu labels, and visible focus movement so people learn shortcuts by recognition and repetition.\n\n---\n\n## 6. Apple Pencil (MEDIUM)\n\n### 6.1 Support Scribble\n\niPadOS converts handwriting to text in any standard text field automatically. Do not disable Scribble. For custom text input, adopt `UIScribbleInteraction`. Test that Scribble works in all text entry points.\n\n### 6.2 Double-Tap Tool Switching\n\nApple Pencil 2 and later supports double-tap to switch tools (e.g., pen to eraser). If your app has drawing tools, implement the `UIPencilInteraction` delegate to handle double-tap.\n\n### 6.3 Pressure and Tilt for Drawing\n\nFor drawing apps, respond to `force` (pressure) and `altitudeAngle`\u002F`azimuthAngle` (tilt) from pencil touch events. Use these for variable line width, opacity, or shading.\n\n### 6.4 Hover Detection (M2+ Pencil)\n\nApple Pencil with hover (M2 iPad Pro and later) provides position data before the pencil touches the screen. Use this for preview effects, tool size indicators, and enhanced precision.\n\n```swift\n\u002F\u002F UIKit hover support via UIHoverGestureRecognizer\nlet hoverRecognizer = UIHoverGestureRecognizer(target: self, action: #selector(pencilHoverChanged(_:)))\nhoverRecognizer.allowedTouchTypes = [NSNumber(value: UITouch.TouchType.pencil.rawValue)]\ncanvas.addGestureRecognizer(hoverRecognizer)\n\n@objc func pencilHoverChanged(_ hover: UIHoverGestureRecognizer) {\n    let location = hover.location(in: canvas)\n    showBrushPreview(at: location)\n}\n```\n\n### 6.5 PencilKit Integration\n\nFor note-taking and annotation, use `PKCanvasView` from PencilKit. It provides a full drawing experience with tool picker, undo, and ink recognition out of the box.\n\n```swift\nimport PencilKit\n\nstruct DrawingView: UIViewRepresentable {\n    @Binding var canvasView: PKCanvasView\n\n    func makeUIView(context: Context) -> PKCanvasView {\n        canvasView.tool = PKInkingTool(.pen, color: .black, width: 5)\n        canvasView.drawingPolicy = .anyInput\n        return canvasView\n    }\n}\n```\n\n---\n\n## 7. Drag and Drop (HIGH)\n\n### 7.1 Inter-App Drag and Drop is Expected\n\niPad users expect to drag content between apps. Support dragging content out (as a source) and dropping content in (as a destination). This is a core iPad interaction.\n\n```swift\n\u002F\u002F As drag source\nText(item.title)\n    .draggable(item.title)\n\n\u002F\u002F As drop destination\nDropTarget()\n    .dropDestination(for: String.self) { items, location in\n        handleDrop(items)\n        return true\n    }\n```\n\n### 7.2 Multi-Item Drag\n\nUsers can pick up one item, then tap additional items to add them to the drag. Support multi-item drag by providing multiple `NSItemProvider` items. Show a badge count on the drag preview.\n\n### 7.3 Spring-Loaded Interactions\n\nWhen dragging over a navigation element (folder, tab, sidebar item), pause briefly to \"spring open\" that destination. Implement spring-loading on navigation containers to enable deep drop targets.\n\n### 7.4 Visual Feedback for Drag and Drop\n\nProvide clear visual states:\n- **Lift**: Item lifts with shadow when drag begins\n- **Move**: Destination highlights when drag hovers over valid target\n- **Drop**: Animate insertion at drop point\n- **Cancel**: Item animates back to origin\n\n### 7.5 Support Universal Control\n\nUniversal Control lets users drag between iPad and Mac. If your app supports drag and drop with standard `NSItemProvider` and UTTypes, Universal Control works automatically.\n\n### 7.6 Drop Delegates for Custom Behavior\n\nUse `DropDelegate` for fine-grained control over drop behavior: validating drop content, reordering within lists, and handling drop position.\n\n```swift\nstruct ReorderDropDelegate: DropDelegate {\n    let item: Item\n    @Binding var items: [Item]\n    @Binding var draggedItem: Item?\n\n    func performDrop(info: DropInfo) -> Bool {\n        draggedItem = nil\n        return true\n    }\n\n    func dropEntered(info: DropInfo) {\n        guard let draggedItem,\n              let fromIndex = items.firstIndex(of: draggedItem),\n              let toIndex = items.firstIndex(of: item) else { return }\n        withAnimation {\n            items.move(fromOffsets: IndexSet(integer: fromIndex),\n                      toOffset: toIndex > fromIndex ? toIndex + 1 : toIndex)\n        }\n    }\n}\n```\n\n---\n\n## 8. External Display (MEDIUM)\n\n### 8.1 Provide Extended Content, Not Just Mirroring\n\nWhen connected to an external display, show complementary content rather than duplicating the iPad screen. Presentations, reference material, or expanded views belong on the external display while controls stay on iPad.\n\n```swift\n@main\nstruct MyApp: App {\n    var body: some Scene {\n        WindowGroup {\n            ContentView()\n        }\n        \u002F\u002F Additional scene for external display\n        WindowGroup(id: \"presentation\") {\n            PresentationView()\n        }\n    }\n}\n```\n\n### 8.2 Handle Display Connection and Disconnection\n\nObserve external display lifecycle via `UIWindowScene` events in your `SceneDelegate` or by listening for `UIScene` session notifications (`UIApplication.didConnectSceneSessionNotification` \u002F `UIApplication.didDisconnectSceneSessionNotification`). Transition gracefully — if the external display disconnects mid-presentation, bring content back to the iPad screen without data loss.\n\n```swift\n\u002F\u002F SceneDelegate: detect when a scene (external display window) connects or disconnects\nfunc scene(_ scene: UIScene,\n           willConnectTo session: UISceneSession,\n           options connectionOptions: UIScene.ConnectionOptions) {\n    guard let windowScene = scene as? UIWindowScene else { return }\n    configureExternalDisplay(for: windowScene)\n}\n\nfunc sceneDidDisconnect(_ scene: UIScene) {\n    restoreContentToiPad()\n}\n```\n\n### 8.3 Support Full External Display Resolution\n\nUse the full resolution and aspect ratio of the external display. Do not letterbox or pillarbox your content. In iOS 16+ multi-scene contexts, `UIScreen.main` is deprecated — query the connected display via `UIWindowScene.coordinateSpace.bounds` and `UIWindowScene.screen.scale`, or use `@Environment(\\.displayScale)` in SwiftUI.\n\n---\n\n## 9. Accessibility (CRITICAL)\n\n**Impact:** CRITICAL\n\n### Rule 9.1: VoiceOver Labels on All Interactive Elements\n\nEvery button, control, and interactive element must have a meaningful accessibility label. Icon-only toolbar items and custom views must use `.accessibilityLabel()`.\n\n**Correct:**\n```swift\nButton(action: compose) {\n    Image(systemName: \"square.and.pencil\")\n}\n.accessibilityLabel(\"Compose new message\")\n```\n\n**Incorrect:**\n```swift\nButton(action: compose) {\n    Image(systemName: \"square.and.pencil\")\n}\n\u002F\u002F VoiceOver reads \"square.and.pencil\" — meaningless to users\n```\n\n### Rule 9.2: Support Dynamic Type Including Accessibility Sizes\n\nUse semantic text styles (`title`, `body`, `caption`) so text scales with the user's preferred size. In iPad's larger canvas, never clamp text size or disable scaling. Test up to the five accessibility size steps.\n\n```swift\nText(\"Section Header\")\n    .font(.headline)  \u002F\u002F Scales with Dynamic Type automatically\n```\n\n### Rule 9.3: Pointer Accessibility — Hover Must Not Be the Only Cue\n\nHover states (`.hoverEffect`) enhance pointer input but must not be the sole indicator of interactivity. Ensure all interactive elements are also distinguishable via color, shape, or label for VoiceOver and keyboard-only users.\n\n### Rule 9.4: Full Keyboard Access and Focus Routing\n\nWith Full Keyboard Access enabled, Tab must move focus through all interactive elements in logical order. In Split View and multi-window layouts, focus must not escape to a hidden or occluded window. Use `@FocusState` and `.focusable()` to control the keyboard focus graph.\n\n```swift\nstruct FormView: View {\n    @FocusState private var focusedField: Field?\n\n    var body: some View {\n        VStack {\n            TextField(\"Name\", text: $name)\n                .focused($focusedField, equals: .name)\n            TextField(\"Email\", text: $email)\n                .focused($focusedField, equals: .email)\n        }\n    }\n}\n```\n\n### Rule 9.5: VoiceOver in Split View — Separate Focus Contexts\n\nIn Split View, each app has its own VoiceOver focus context. Your app must not assume it occupies the full screen. Ensure VoiceOver can navigate your entire visible interface even at 1\u002F3 or 1\u002F2 split width. Do not hide actionable content outside the visible region without also removing it from the accessibility tree.\n\n### Rule 9.6: Respond to Bold Text\n\nWhen the user enables Bold Text in Settings, custom-rendered text must adapt. SwiftUI text styles handle this automatically. UIKit code must check `UIAccessibility.isBoldTextEnabled` or use `@Environment(\\.legibilityWeight)` in SwiftUI.\n\n**Correct:**\n```swift\n\u002F\u002F SwiftUI — handled automatically for standard text styles\nText(\"Section Header\")\n    .font(.headline)\n\n\u002F\u002F SwiftUI — custom rendering respects legibilityWeight\n@Environment(\\.legibilityWeight) var legibilityWeight\n\nvar body: some View {\n    Text(\"Custom Label\")\n        .fontWeight(legibilityWeight == .bold ? .bold : .regular)\n}\n```\n\n**Incorrect:**\n```swift\n\u002F\u002F Hardcoded weight ignores Bold Text preference\nlabel.font = UIFont.systemFont(ofSize: 17, weight: .regular)\n\u002F\u002F Missing: re-query font when UIAccessibility.boldTextStatusDidChangeNotification fires\n```\n\n### Rule 9.7: Respond to Increase Contrast\n\nWhen the user enables Increase Contrast in Settings, custom colors must provide higher-contrast variants. Use `@Environment(\\.colorSchemeContrast)` in SwiftUI or `UIAccessibility.isDarkerSystemColorsEnabled` in UIKit.\n\n**Correct:**\n```swift\n\u002F\u002F SwiftUI\n@Environment(\\.colorSchemeContrast) var contrast\n\nvar separatorColor: Color {\n    contrast == .increased ? Color.primary : Color.secondary\n}\n\n\u002F\u002F UIKit\nlet useHighContrast = UIAccessibility.isDarkerSystemColorsEnabled\nlet borderColor: UIColor = useHighContrast ? .label : .separator\n```\n\n**Incorrect:**\n```swift\n\u002F\u002F Static color ignores Increase Contrast setting\nlet borderColor = UIColor.separator \u002F\u002F Always low-contrast; ignores user preference\n```\n\n---\n\n## Evaluation Checklist\n\nUse this checklist to verify iPad-readiness:\n\n### Layout & Multitasking\n- [ ] App uses adaptive layout with `horizontalSizeClass`\n- [ ] Tested at all Split View ratios (1\u002F3, 1\u002F2, 2\u002F3)\n- [ ] Tested in Slide Over (compact width)\n- [ ] Stage Manager: resizes fluidly to arbitrary dimensions\n- [ ] Multiple scenes\u002Fwindows supported\n- [ ] Both orientations (portrait and landscape) work correctly\n- [ ] No content clipped at any size\n- [ ] Safe areas respected on all iPad models\n\n### Navigation\n- [ ] Sidebar visible in regular width\n- [ ] Tab bar used in compact width\n- [ ] Detail view shows placeholder when no selection\n- [ ] Toolbar items placed at top, not bottom\n- [ ] Three-column layout used where appropriate\n\n### Pointer & Trackpad\n- [ ] Hover effects on all interactive elements\n- [ ] Right-click context menus available\n- [ ] Pointer cursor adapts to content (I-beam for text, etc.)\n- [ ] Click-and-drag works for reordering\n\n### Keyboard\n- [ ] Cmd+key shortcuts for all major actions\n- [ ] Shortcuts appear in Cmd-hold overlay\n- [ ] Tab key navigates between form fields\n- [ ] No system shortcut conflicts\n- [ ] Arrow keys navigate lists and grids\n- [ ] Return\u002FEnter activates default action\n\n### Apple Pencil\n- [ ] Scribble works in all text fields\n- [ ] Drawing apps support pressure and tilt\n- [ ] Double-tap interaction handled (if applicable)\n\n### Drag and Drop\n- [ ] Content can be dragged out to other apps\n- [ ] Content can be dropped in from other apps\n- [ ] Multi-item drag supported\n- [ ] Visual feedback for all drag states\n\n### External Display\n- [ ] Extended content shown (not just mirror)\n- [ ] Graceful handling of connect\u002Fdisconnect\n\n### Accessibility\n- [ ] VoiceOver labels on all icon-only buttons and custom interactive elements\n- [ ] Text uses semantic type styles and scales with Dynamic Type (including accessibility sizes)\n- [ ] All functionality reachable with Full Keyboard Access (Tab navigation, logical focus order)\n- [ ] Interactive elements are distinguishable without relying solely on hover state\n- [ ] VoiceOver navigates correctly at all Split View widths\n- [ ] Bold Text preference respected (SwiftUI handles automatically; UIKit checks `UIAccessibility.isBoldTextEnabled`)\n- [ ] Increase Contrast preference respected (custom colors provide higher-contrast variants via `colorSchemeContrast` or `isDarkerSystemColorsEnabled`)\n\n---\n\n## Anti-Patterns\n\n### DO NOT: Scale Up iPhone Layouts\nStretching a single-column iPhone UI to fill an iPad screen wastes space, looks lazy, and provides a poor experience. Always redesign for the larger canvas.\n\n### DO NOT: Disable Multitasking\nNever opt out of multitasking support. Users expect every app to work in Split View and Slide Over. Requiring full screen is hostile to iPad workflows.\n\n### DO NOT: Ignore the Keyboard\nMany iPad users have Magic Keyboard or Smart Keyboard. An app with no keyboard shortcuts forces them to reach for the screen constantly. Provide shortcuts for all frequent actions.\n\n### DO NOT: Use iPhone-Style Bottom Tab Bars in Regular Width\nTab bars at the bottom waste vertical space on iPad and look out of place. Convert to sidebar navigation in regular width. SwiftUI does this automatically with `.sidebarAdaptable`.\n\n### DO NOT: Show Popovers as Full-Screen Sheets\nOn iPad, popovers should anchor to their source element as floating panels. Only use full-screen sheets for immersive content or flows that genuinely need the full screen. Avoid the iPhone pattern of everything being a sheet.\n\n### DO NOT: Ignore Pointer Hover States\nMissing hover effects make the app feel broken when using a trackpad. Users cannot tell what is interactive. Always add hover feedback to custom interactive elements.\n\n### DO NOT: Hardcode Dimensions\nNever hardcode widths, heights, or positions based on a specific iPad model. Use Auto Layout constraints, SwiftUI flexible frames, and `GeometryReader` for dynamic sizing.\n\n### DO NOT: Forget Drag and Drop\nOn iPad, drag and drop between apps is a core workflow. Not supporting it makes your app a dead end for content. At minimum, support dragging text, images, and URLs in and out.\n\n### DO NOT: Override System Keyboard Shortcuts\nClaiming Cmd+H, Cmd+Tab, Cmd+Space, or Globe shortcuts will not work and confuses users who expect system behavior. Check Apple's reserved shortcuts list before assigning.\n\n### DO NOT: Present Dense Content Without Scrolling\nLarge iPad screens tempt designers to show everything at once. Content should still scroll when it exceeds the visible area. Never truncate content to avoid scrolling.\n","# iPadOS Design Guidelines\n\nComprehensive rules for building iPad-native apps following Apple's Human Interface Guidelines. iPad is not a big iPhone -- it demands adaptive layouts, multitasking support, pointer interactions, keyboard shortcuts, and inter-app drag and drop. These rules extend iOS patterns for the larger, more capable canvas.\n\n---\n\n## 1. Responsive Layout (CRITICAL)\n\n### 1.1 Use Adaptive Size Classes\n\niPad presents two horizontal size classes: **regular** (full screen, large splits) and **compact** (Slide Over, narrow splits). Design for both. Never hardcode dimensions.\n\n```swift\nstruct AdaptiveView: View {\n    @Environment(\\.horizontalSizeClass) var sizeClass\n\n    var body: some View {\n        if sizeClass == .regular {\n            TwoColumnLayout()\n        } else {\n            StackedLayout()\n        }\n    }\n}\n```\n\n### 1.2 Don't Scale Up iPhone UI\n\niPad layouts must be purpose-built. Stretching an iPhone layout across a 13\" display wastes space and feels wrong. Use multi-column layouts, master-detail patterns, and increased information density in regular width.\n\n### 1.3 Support All iPad Screen Sizes\n\nDesign for the full range: iPad Mini (8.3\"), iPad (11\"), iPad Air (11\"\u002F13\"), and iPad Pro (11\"\u002F13\"). Use flexible layouts that redistribute content rather than simply scaling.\n\n### 1.4 Column-Based Layouts for Regular Width\n\nIn regular width, organize content into columns. Two-column is the most common (sidebar + detail). Three-column works for deep hierarchies (sidebar + list + detail). Avoid single-column full-width layouts on large screens.\n\n```swift\nstruct ThreeColumnLayout: View {\n    var body: some View {\n        NavigationSplitView {\n            SidebarView()\n        } content: {\n            ContentListView()\n        } detail: {\n            DetailView()\n        }\n    }\n}\n```\n\n### 1.5 Respect Safe Areas\n\niPad safe areas differ from iPhone. Older iPads have no home indicator. iPads in landscape have different insets than portrait. Always use `safeAreaInset` and never hardcode padding for notches or indicators.\n\n### 1.6 Support Both Orientations\n\niPad apps must work well in both portrait and landscape. Landscape is the dominant orientation for productivity. Portrait is common for reading. Adapt column counts and layout density to orientation.\n\n---\n\n## 2. Multitasking (CRITICAL)\n\n### 2.1 Support Split View\n\nYour app must function correctly at 1\u002F3, 1\u002F2, and 2\u002F3 screen widths in Split View. At 1\u002F3 width, your app receives compact horizontal size class. Content must remain usable at every split ratio.\n\n### 2.2 Support Slide Over\n\nSlide Over presents your app as a compact-width overlay on the right edge. It behaves like an iPhone-width app. Ensure all functionality remains accessible in this narrow mode.\n\n### 2.3 Handle Stage Manager\n\nStage Manager allows freely resizable windows and multiple windows simultaneously. Your app must:\n- Resize fluidly to arbitrary dimensions\n- Support multiple scenes (windows) showing different content\n- Not assume any fixed size or aspect ratio\n\n```swift\n@main\nstruct MyApp: App {\n    var body: some Scene {\n        WindowGroup {\n            ContentView()\n        }\n        \u002F\u002F Support multiple windows\n        WindowGroup(\"Detail\", for: Item.ID.self) { $itemId in\n            DetailView(itemId: itemId)\n        }\n    }\n}\n```\n\n### 2.4 Never Assume Full Screen\n\nThe app may launch directly into Split View or Stage Manager. Do not depend on full-screen dimensions during setup, onboarding, or any flow. Test your app at every possible size.\n\n### 2.5 Handle Size Transitions Gracefully\n\nWhen the user resizes via multitasking, animate layout changes smoothly. Preserve scroll position, selection state, and user context across size transitions. Never reload content on resize.\n\n### 2.6 Support Multiple Scenes\n\nUse `UIScene` \u002F SwiftUI `WindowGroup` to let users open multiple instances of your app showing different content. Each scene is independent. Support `NSUserActivity` for state restoration.\n\n---\n\n## 3. Navigation (CRITICAL)\n\n### 3.1 Sidebar for Primary Navigation\n\nIn regular width, replace the iPhone tab bar with a sidebar. The sidebar provides more room for navigation items, supports sections, and feels native on iPad.\n\n```swift\nstruct AppNavigation: View {\n    @State private var selection: NavigationItem? = .inbox\n\n    var body: some View {\n        NavigationSplitView {\n            List(selection: $selection) {\n                Section(\"Main\") {\n                    Label(\"Inbox\", systemImage: \"tray\")\n                        .tag(NavigationItem.inbox)\n                    Label(\"Drafts\", systemImage: \"doc\")\n                        .tag(NavigationItem.drafts)\n                    Label(\"Sent\", systemImage: \"paperplane\")\n                        .tag(NavigationItem.sent)\n                }\n                Section(\"Labels\") {\n                    \u002F\u002F Dynamic sections\n                }\n            }\n            .navigationTitle(\"Mail\")\n        } detail: {\n            DetailView(for: selection)\n        }\n    }\n}\n```\n\n### 3.2 Automatic Tab-to-Sidebar Conversion\n\nSwiftUI `TabView` with `.sidebarAdaptable` style automatically converts to a sidebar in regular width. Use this for seamless iPhone-to-iPad adaptation.\n\n```swift\nTabView {\n    Tab(\"Home\", systemImage: \"house\") { HomeView() }\n    Tab(\"Search\", systemImage: \"magnifyingglass\") { SearchView() }\n    Tab(\"Profile\", systemImage: \"person\") { ProfileView() }\n}\n.tabViewStyle(.sidebarAdaptable)\n```\n\n### 3.3 Three-Column Layout for Complex Hierarchies\n\nUse `NavigationSplitView` with three columns when your information architecture has three levels: category > list > detail. Examples: mail (accounts > messages > message), file managers, settings.\n\n### 3.4 Toolbar at Top\n\nOn iPad, toolbars live at the top of the screen in the navigation bar area, not at the bottom like iPhone. Place contextual actions in `.toolbar` with appropriate placement.\n\n```swift\n.toolbar {\n    ToolbarItemGroup(placement: .primaryAction) {\n        Button(\"Compose\", systemImage: \"square.and.pencil\") { }\n    }\n    ToolbarItemGroup(placement: .secondaryAction) {\n        Button(\"Archive\", systemImage: \"archivebox\") { }\n        Button(\"Delete\", systemImage: \"trash\") { }\n    }\n}\n```\n\n### 3.5 Detail View Should Never Be Empty\n\nWhen no item is selected in a list\u002Fsidebar, show a meaningful empty state in the detail area. Use a placeholder with icon and instruction text, not a blank screen.\n\n### 3.6 Reduce Recall in Large-Canvas Navigation\n\nKeep sidebar selection, search terms, and disclosure state visible and preserved across size changes and scene switches. In multi-column layouts, users should resume from structure on screen, not from memory.\n\n---\n\n## 4. Pointer & Trackpad (HIGH)\n\n### 4.1 Add Hover Effects to Interactive Elements\n\nAll tappable elements should respond to pointer hover. The system provides automatic hover effects for standard controls. For custom views, use `.hoverEffect()`.\n\n```swift\nButton(\"Action\") { }\n    .hoverEffect(.highlight)  \u002F\u002F Subtle highlight on hover\n\n\u002F\u002F Custom hover effect\nMyCustomView()\n    .hoverEffect(.lift)  \u002F\u002F Lifts and adds shadow\n```\n\n### 4.2 Pointer Magnetism on Buttons\n\nThe pointer should snap to (be attracted toward) button bounds. Standard UIKit\u002FSwiftUI buttons get this automatically. For custom hit targets, ensure the pointer region matches the tappable area using `.contentShape()`.\n\n### 4.3 Support Right-Click Context Menus\n\nRight-click (secondary click) should present context menus. Use `.contextMenu` which automatically supports both long-press (touch) and right-click (pointer).\n\n```swift\nText(item.title)\n    .contextMenu {\n        Button(\"Copy\", systemImage: \"doc.on.doc\") { }\n        Button(\"Share\", systemImage: \"square.and.arrow.up\") { }\n        Divider()\n        Button(\"Delete\", systemImage: \"trash\", role: .destructive) { }\n    }\n```\n\n### 4.4 Trackpad Scroll Behaviors\n\nSupport two-finger scrolling with momentum. Pinch to zoom where appropriate. Respect scroll direction preferences. For custom scroll views, ensure trackpad gestures feel natural alongside touch gestures.\n\n### 4.5 Customize Cursor for Content Areas\n\nChange cursor appearance based on context. Text areas show I-beam. Links show pointer hand. Resize handles show resize cursors. Draggable items show grab cursor.\n\n### 4.6 Pointer-Driven Drag and Drop\n\nPointer users expect click-and-drag for rearranging, selecting, and moving content. Combine with multi-select via Shift-click and Cmd-click.\n\n---\n\n## 5. Keyboard (HIGH)\n\n### 5.1 Cmd+Key Shortcuts for All Major Actions\n\nEvery primary action must have a keyboard shortcut. Standard shortcuts are mandatory:\n\n| Shortcut | Action |\n|----------|--------|\n| Cmd+N | New item |\n| Cmd+F | Find\u002FSearch |\n| Cmd+S | Save |\n| Cmd+Z | Undo |\n| Cmd+Shift+Z | Redo |\n| Cmd+C\u002FV\u002FX | Copy\u002FPaste\u002FCut |\n| Cmd+A | Select all |\n| Cmd+P | Print |\n| Cmd+W | Close window\u002Ftab |\n| Cmd+, | Settings\u002FPreferences |\n| Delete | Delete selected item |\n\n```swift\nButton(\"New Document\") { createDocument() }\n    .keyboardShortcut(\"n\", modifiers: .command)\n```\n\n### 5.2 Discoverability via Cmd-Hold Overlay\n\nWhen the user holds the Cmd key, iPadOS shows a shortcut overlay. Register all shortcuts using `.keyboardShortcut()` so they appear in this overlay. Group related shortcuts logically.\n\n### 5.3 Tab Key Navigation Between Fields\n\nSupport Tab to move forward and Shift+Tab to move backward between form fields and focusable elements. Use `.focusable()` and `@FocusState` to manage keyboard focus order.\n\n```swift\nstruct FormView: View {\n    @FocusState private var focusedField: Field?\n\n    var body: some View {\n        Form {\n            TextField(\"Name\", text: $name)\n                .focused($focusedField, equals: .name)\n            TextField(\"Email\", text: $email)\n                .focused($focusedField, equals: .email)\n            TextField(\"Phone\", text: $phone)\n                .focused($focusedField, equals: .phone)\n        }\n    }\n}\n```\n\n### 5.4 Never Override System Shortcuts\n\nDo not claim shortcuts reserved by the system: Cmd+H (Home), Cmd+Tab (App Switcher), Cmd+Space (Spotlight), Globe key combinations. These will not work and create confusion.\n\n### 5.5 Detect Hardware Keyboard\n\nAdapt UI when a hardware keyboard is connected. Hide the on-screen keyboard shortcut bar. Show keyboard-optimized controls. Use `GCKeyboard` or track keyboard visibility to detect state.\n\n### 5.6 Arrow Key Navigation\n\nSupport arrow keys for navigating lists, grids, and collections. Combine with Shift for multi-selection. This is essential for productivity-focused apps.\n\n### 5.7 Shortcuts Must Be Discoverable\n\nDo not rely on users memorizing shortcut vocabularies. Expose commands through the Cmd-hold overlay, menu labels, and visible focus movement so people learn shortcuts by recognition and repetition.\n\n---\n\n## 6. Apple Pencil (MEDIUM)\n\n### 6.1 Support Scribble\n\niPadOS converts handwriting to text in any standard text field automatically. Do not disable Scribble. For custom text input, adopt `UIScribbleInteraction`. Test that Scribble works in all text entry points.\n\n### 6.2 Double-Tap Tool Switching\n\nApple Pencil 2 and later supports double-tap to switch tools (e.g., pen to eraser). If your app has drawing tools, implement the `UIPencilInteraction` delegate to handle double-tap.\n\n### 6.3 Pressure and Tilt for Drawing\n\nFor drawing apps, respond to `force` (pressure) and `altitudeAngle`\u002F`azimuthAngle` (tilt) from pencil touch events. Use these for variable line width, opacity, or shading.\n\n### 6.4 Hover Detection (M2+ Pencil)\n\nApple Pencil with hover (M2 iPad Pro and later) provides position data before the pencil touches the screen. Use this for preview effects, tool size indicators, and enhanced precision.\n\n```swift\n\u002F\u002F UIKit hover support via UIHoverGestureRecognizer\nlet hoverRecognizer = UIHoverGestureRecognizer(target: self, action: #selector(pencilHoverChanged(_:)))\nhoverRecognizer.allowedTouchTypes = [NSNumber(value: UITouch.TouchType.pencil.rawValue)]\ncanvas.addGestureRecognizer(hoverRecognizer)\n\n@objc func pencilHoverChanged(_ hover: UIHoverGestureRecognizer) {\n    let location = hover.location(in: canvas)\n    showBrushPreview(at: location)\n}\n```\n\n### 6.5 PencilKit Integration\n\nFor note-taking and annotation, use `PKCanvasView` from PencilKit. It provides a full drawing experience with tool picker, undo, and ink recognition out of the box.\n\n```swift\nimport PencilKit\n\nstruct DrawingView: UIViewRepresentable {\n    @Binding var canvasView: PKCanvasView\n\n    func makeUIView(context: Context) -> PKCanvasView {\n        canvasView.tool = PKInkingTool(.pen, color: .black, width: 5)\n        canvasView.drawingPolicy = .anyInput\n        return canvasView\n    }\n}\n```\n\n---\n\n## 7. Drag and Drop (HIGH)\n\n### 7.1 Inter-App Drag and Drop is Expected\n\niPad users expect to drag content between apps. Support dragging content out (as a source) and dropping content in (as a destination). This is a core iPad interaction.\n\n```swift\n\u002F\u002F As drag source\nText(item.title)\n    .draggable(item.title)\n\n\u002F\u002F As drop destination\nDropTarget()\n    .dropDestination(for: String.self) { items, location in\n        handleDrop(items)\n        return true\n    }\n```\n\n### 7.2 Multi-Item Drag\n\nUsers can pick up one item, then tap additional items to add them to the drag. Support multi-item drag by providing multiple `NSItemProvider` items. Show a badge count on the drag preview.\n\n### 7.3 Spring-Loaded Interactions\n\nWhen dragging over a navigation element (folder, tab, sidebar item), pause briefly to \"spring open\" that destination. Implement spring-loading on navigation containers to enable deep drop targets.\n\n### 7.4 Visual Feedback for Drag and Drop\n\nProvide clear visual states:\n- **Lift**: Item lifts with shadow when drag begins\n- **Move**: Destination highlights when drag hovers over valid target\n- **Drop**: Animate insertion at drop point\n- **Cancel**: Item animates back to origin\n\n### 7.5 Support Universal Control\n\nUniversal Control lets users drag between iPad and Mac. If your app supports drag and drop with standard `NSItemProvider` and UTTypes, Universal Control works automatically.\n\n### 7.6 Drop Delegates for Custom Behavior\n\nUse `DropDelegate` for fine-grained control over drop behavior: validating drop content, reordering within lists, and handling drop position.\n\n```swift\nstruct ReorderDropDelegate: DropDelegate {\n    let item: Item\n    @Binding var items: [Item]\n    @Binding var draggedItem: Item?\n\n    func performDrop(info: DropInfo) -> Bool {\n        draggedItem = nil\n        return true\n    }\n\n    func dropEntered(info: DropInfo) {\n        guard let draggedItem,\n              let fromIndex = items.firstIndex(of: draggedItem),\n              let toIndex = items.firstIndex(of: item) else { return }\n        withAnimation {\n            items.move(fromOffsets: IndexSet(integer: fromIndex),\n                      toOffset: toIndex > fromIndex ? toIndex + 1 : toIndex)\n        }\n    }\n}\n```\n\n---\n\n## 8. External Display (MEDIUM)\n\n### 8.1 Provide Extended Content, Not Just Mirroring\n\nWhen connected to an external display, show complementary content rather than duplicating the iPad screen. Presentations, reference material, or expanded views belong on the external display while controls stay on iPad.\n\n```swift\n@main\nstruct MyApp: App {\n    var body: some Scene {\n        WindowGroup {\n            ContentView()\n        }\n        \u002F\u002F Additional scene for external display\n        WindowGroup(id: \"presentation\") {\n            PresentationView()\n        }\n    }\n}\n```\n\n### 8.2 Handle Display Connection and Disconnection\n\nObserve external display lifecycle via `UIWindowScene` events in your `SceneDelegate` or by listening for `UIScene` session notifications (`UIApplication.didConnectSceneSessionNotification` \u002F `UIApplication.didDisconnectSceneSessionNotification`). Transition gracefully — if the external display disconnects mid-presentation, bring content back to the iPad screen without data loss.\n\n```swift\n\u002F\u002F SceneDelegate: detect when a scene (external display window) connects or disconnects\nfunc scene(_ scene: UIScene,\n           willConnectTo session: UISceneSession,\n           options connectionOptions: UIScene.ConnectionOptions) {\n    guard let windowScene = scene as? UIWindowScene else { return }\n    configureExternalDisplay(for: windowScene)\n}\n\nfunc sceneDidDisconnect(_ scene: UIScene) {\n    restoreContentToiPad()\n}\n```\n\n### 8.3 Support Full External Display Resolution\n\nUse the full resolution and aspect ratio of the external display. Do not letterbox or pillarbox your content. In iOS 16+ multi-scene contexts, `UIScreen.main` is deprecated — query the connected display via `UIWindowScene.coordinateSpace.bounds` and `UIWindowScene.screen.scale`, or use `@Environment(\\.displayScale)` in SwiftUI.\n\n---\n\n## 9. Accessibility (CRITICAL)\n\n**Impact:** CRITICAL\n\n### Rule 9.1: VoiceOver Labels on All Interactive Elements\n\nEvery button, control, and interactive element must have a meaningful accessibility label. Icon-only toolbar items and custom views must use `.accessibilityLabel()`.\n\n**Correct:**\n```swift\nButton(action: compose) {\n    Image(systemName: \"square.and.pencil\")\n}\n.accessibilityLabel(\"Compose new message\")\n```\n\n**Incorrect:**\n```swift\nButton(action: compose) {\n    Image(systemName: \"square.and.pencil\")\n}\n\u002F\u002F VoiceOver reads \"square.and.pencil\" — meaningless to users\n```\n\n### Rule 9.2: Support Dynamic Type Including Accessibility Sizes\n\nUse semantic text styles (`title`, `body`, `caption`) so text scales with the user's preferred size. In iPad's larger canvas, never clamp text size or disable scaling. Test up to the five accessibility size steps.\n\n```swift\nText(\"Section Header\")\n    .font(.headline)  \u002F\u002F Scales with Dynamic Type automatically\n```\n\n### Rule 9.3: Pointer Accessibility — Hover Must Not Be the Only Cue\n\nHover states (`.hoverEffect`) enhance pointer input but must not be the sole indicator of interactivity. Ensure all interactive elements are also distinguishable via color, shape, or label for VoiceOver and keyboard-only users.\n\n### Rule 9.4: Full Keyboard Access and Focus Routing\n\nWith Full Keyboard Access enabled, Tab must move focus through all interactive elements in logical order. In Split View and multi-window layouts, focus must not escape to a hidden or occluded window. Use `@FocusState` and `.focusable()` to control the keyboard focus graph.\n\n```swift\nstruct FormView: View {\n    @FocusState private var focusedField: Field?\n\n    var body: some View {\n        VStack {\n            TextField(\"Name\", text: $name)\n                .focused($focusedField, equals: .name)\n            TextField(\"Email\", text: $email)\n                .focused($focusedField, equals: .email)\n        }\n    }\n}\n```\n\n### Rule 9.5: VoiceOver in Split View — Separate Focus Contexts\n\nIn Split View, each app has its own VoiceOver focus context. Your app must not assume it occupies the full screen. Ensure VoiceOver can navigate your entire visible interface even at 1\u002F3 or 1\u002F2 split width. Do not hide actionable content outside the visible region without also removing it from the accessibility tree.\n\n### Rule 9.6: Respond to Bold Text\n\nWhen the user enables Bold Text in Settings, custom-rendered text must adapt. SwiftUI text styles handle this automatically. UIKit code must check `UIAccessibility.isBoldTextEnabled` or use `@Environment(\\.legibilityWeight)` in SwiftUI.\n\n**Correct:**\n```swift\n\u002F\u002F SwiftUI — handled automatically for standard text styles\nText(\"Section Header\")\n    .font(.headline)\n\n\u002F\u002F SwiftUI — custom rendering respects legibilityWeight\n@Environment(\\.legibilityWeight) var legibilityWeight\n\nvar body: some View {\n    Text(\"Custom Label\")\n        .fontWeight(legibilityWeight == .bold ? .bold : .regular)\n}\n```\n\n**Incorrect:**\n```swift\n\u002F\u002F Hardcoded weight ignores Bold Text preference\nlabel.font = UIFont.systemFont(ofSize: 17, weight: .regular)\n\u002F\u002F Missing: re-query font when UIAccessibility.boldTextStatusDidChangeNotification fires\n```\n\n### Rule 9.7: Respond to Increase Contrast\n\nWhen the user enables Increase Contrast in Settings, custom colors must provide higher-contrast variants. Use `@Environment(\\.colorSchemeContrast)` in SwiftUI or `UIAccessibility.isDarkerSystemColorsEnabled` in UIKit.\n\n**Correct:**\n```swift\n\u002F\u002F SwiftUI\n@Environment(\\.colorSchemeContrast) var contrast\n\nvar separatorColor: Color {\n    contrast == .increased ? Color.primary : Color.secondary\n}\n\n\u002F\u002F UIKit\nlet useHighContrast = UIAccessibility.isDarkerSystemColorsEnabled\nlet borderColor: UIColor = useHighContrast ? .label : .separator\n```\n\n**Incorrect:**\n```swift\n\u002F\u002F Static color ignores Increase Contrast setting\nlet borderColor = UIColor.separator \u002F\u002F Always low-contrast; ignores user preference\n```\n\n---\n\n## Evaluation Checklist\n\nUse this checklist to verify iPad-readiness:\n\n### Layout & Multitasking\n- [ ] App uses adaptive layout with `horizontalSizeClass`\n- [ ] Tested at all Split View ratios (1\u002F3, 1\u002F2, 2\u002F3)\n- [ ] Tested in Slide Over (compact width)\n- [ ] Stage Manager: resizes fluidly to arbitrary dimensions\n- [ ] Multiple scenes\u002Fwindows supported\n- [ ] Both orientations (portrait and landscape) work correctly\n- [ ] No content clipped at any size\n- [ ] Safe areas respected on all iPad models\n\n### Navigation\n- [ ] Sidebar visible in regular width\n- [ ] Tab bar used in compact width\n- [ ] Detail view shows placeholder when no selection\n- [ ] Toolbar items placed at top, not bottom\n- [ ] Three-column layout used where appropriate\n\n### Pointer & Trackpad\n- [ ] Hover effects on all interactive elements\n- [ ] Right-click context menus available\n- [ ] Pointer cursor adapts to content (I-beam for text, etc.)\n- [ ] Click-and-drag works for reordering\n\n### Keyboard\n- [ ] Cmd+key shortcuts for all major actions\n- [ ] Shortcuts appear in Cmd-hold overlay\n- [ ] Tab key navigates between form fields\n- [ ] No system shortcut conflicts\n- [ ] Arrow keys navigate lists and grids\n- [ ] Return\u002FEnter activates default action\n\n### Apple Pencil\n- [ ] Scribble works in all text fields\n- [ ] Drawing apps support pressure and tilt\n- [ ] Double-tap interaction handled (if applicable)\n\n### Drag and Drop\n- [ ] Content can be dragged out to other apps\n- [ ] Content can be dropped in from other apps\n- [ ] Multi-item drag supported\n- [ ] Visual feedback for all drag states\n\n### External Display\n- [ ] Extended content shown (not just mirror)\n- [ ] Graceful handling of connect\u002Fdisconnect\n\n### Accessibility\n- [ ] VoiceOver labels on all icon-only buttons and custom interactive elements\n- [ ] Text uses semantic type styles and scales with Dynamic Type (including accessibility sizes)\n- [ ] All functionality reachable with Full Keyboard Access (Tab navigation, logical focus order)\n- [ ] Interactive elements are distinguishable without relying solely on hover state\n- [ ] VoiceOver navigates correctly at all Split View widths\n- [ ] Bold Text preference respected (SwiftUI handles automatically; UIKit checks `UIAccessibility.isBoldTextEnabled`)\n- [ ] Increase Contrast preference respected (custom colors provide higher-contrast variants via `colorSchemeContrast` or `isDarkerSystemColorsEnabled`)\n\n---\n\n## Anti-Patterns\n\n### DO NOT: Scale Up iPhone Layouts\nStretching a single-column iPhone UI to fill an iPad screen wastes space, looks lazy, and provides a poor experience. Always redesign for the larger canvas.\n\n### DO NOT: Disable Multitasking\nNever opt out of multitasking support. Users expect every app to work in Split View and Slide Over. Requiring full screen is hostile to iPad workflows.\n\n### DO NOT: Ignore the Keyboard\nMany iPad users have Magic Keyboard or Smart Keyboard. An app with no keyboard shortcuts forces them to reach for the screen constantly. Provide shortcuts for all frequent actions.\n\n### DO NOT: Use iPhone-Style Bottom Tab Bars in Regular Width\nTab bars at the bottom waste vertical space on iPad and look out of place. Convert to sidebar navigation in regular width. SwiftUI does this automatically with `.sidebarAdaptable`.\n\n### DO NOT: Show Popovers as Full-Screen Sheets\nOn iPad, popovers should anchor to their source element as floating panels. Only use full-screen sheets for immersive content or flows that genuinely need the full screen. Avoid the iPhone pattern of everything being a sheet.\n\n### DO NOT: Ignore Pointer Hover States\nMissing hover effects make the app feel broken when using a trackpad. Users cannot tell what is interactive. Always add hover feedback to custom interactive elements.\n\n### DO NOT: Hardcode Dimensions\nNever hardcode widths, heights, or positions based on a specific iPad model. Use Auto Layout constraints, SwiftUI flexible frames, and `GeometryReader` for dynamic sizing.\n\n### DO NOT: Forget Drag and Drop\nOn iPad, drag and drop between apps is a core workflow. Not supporting it makes your app a dead end for content. At minimum, support dragging text, images, and URLs in and out.\n\n### DO NOT: Override System Keyboard Shortcuts\nClaiming Cmd+H, Cmd+Tab, Cmd+Space, or Globe shortcuts will not work and confuses users who expect system behavior. Check Apple's reserved shortcuts list before assigning.\n\n### DO NOT: Present Dense Content Without Scrolling\nLarge iPad screens tempt designers to show everything at once. Content should still scroll when it exceeds the visible area. Never truncate content to avoid scrolling.\n",{"name":5,"license":15,"metadata":54,"description":7},{"author":55,"version":56},"platform-design-skills","1.0.0","main","7a940b8e5af16c95e5c190a524421d32fc7445a9",".claude\u002Fskills\u002Fipados","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui","https:\u002F\u002Fneuroads.com.br","2026-08-12 00:42:44",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add headmktlucca-ui\u002Fneuroads-lp --skill ipados-design-guidelines",{"tool":70,"command":71},"bunx","bunx skills add headmktlucca-ui\u002Fneuroads-lp --skill ipados-design-guidelines",{"tool":73,"command":74},"pnpm","pnpm dlx skills add headmktlucca-ui\u002Fneuroads-lp --skill ipados-design-guidelines","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fipados\u002FSKILL.md",true,[78,84,88],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"AGENTS.md","REFERENCE","参考文档",2784,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fipados\u002FAGENTS.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"metadata.json",688,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fipados\u002Fmetadata.json",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":90,"sourceHtmlUrl":91},"rules\u002F_sections.md",2830,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fipados\u002Frules\u002F_sections.md",[93,115,138,162,180,205],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":105,"publishedAt":49},"01M6PTDCZTXTGSTX4RFK901YSZ","xunit-skill","Generates xUnit.net tests in C#. Covers Fact\u002FTheory, constructor injection, IClassFixture, and FluentAssertions. Use when user mentions \"xUnit\", \"[Fact]\", \"[Theory]\", \"Assert.Equal\", \"C# xUnit\". Triggers on: \"xUnit\", \"[Fact]\", \"[Theory]\", \"Assert.Equal C#\", \"xUnit.net\".","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fxunit-skill\u002FSKILL.md",[99,102],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[106,107,108,109,110,45,111,39,112,113,114],"xunit","xunit skill","testing","injection","user","tests","unit","unit-testing","C#",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":123,"publishedAt":49},"01M6PTCB59ZTG5FTMWGPYEMMBP","xcuitest-skill","Generates XCUITest UI tests for iOS\u002FiPadOS apps in Swift. Apple's native testing framework for reliable, fast UI automation. Supports local simulators and TestMu AI cloud real devices. Use when user mentions \"XCUITest\", \"XCTest\", \"iOS UI test\", \"Swift test\", \"XCUIApplication\". Triggers on: \"XCUITest\", \"XCTest UI\", \"iOS UI test\", \"Swift UI test\", \"XCUIApplication\", \"TestMu\".","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fxcuitest-skill\u002FSKILL.md",[121,122],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[124,125,108,126,127,128,129,130,45,131,132,133,134,32,111,39,135,136,33,137],"xcuitest","xcuitest skill","automation","test","testing framework","ios","devices","mobile","mobile-testing","ui test","local","apps","native","objective",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":146,"publishedAt":49},"01M6PTATMNTY9NF4J7KSR76YK6","world-builder","Create and manage generative game zones for Dorothy's Pokemon-style world. Use this skill when creating, updating, or designing game worlds via MCP tools.","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fworld-builder\u002FSKILL.md",[144,145],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[147,148,149,150,151,152,153,154,45,155,156,157,158,159,160,33,161],"builder","world","world builder","MCP","create","mcp tools","Tools","game","pokemon","manage","style","via","theme","zone","generative",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":170,"publishedAt":49},"01M6PT9Z92JTSQEHE1QR0NNW5F","webdriverio-skill","Generates WebdriverIO (WDIO) automation tests in JavaScript or TypeScript. Supports local and TestMu AI cloud. Use when user mentions \"WebdriverIO\", \"WDIO\", \"wdio.conf\", \"browser.url\", \"$\", \"$$\". Triggers on: \"WebdriverIO\", \"WDIO\", \"wdio\", \"browser.$\".","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwebdriverio-skill\u002FSKILL.md",[168,169],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},[171,108,172,126,173,174,175,176,110,45,177,134,111,39,178,179],"webdriverio skill","typescript","javascript","browser","cloud","e2e","e2e-testing","URL","conf",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":191,"publishedAt":49},"01M6PT9NVK36ZWCQ69YXK3FR4K","web-design-guidelines","Web platform design and accessibility guidelines. Use when building web interfaces, auditing accessibility, implementing responsive layouts, or reviewing web UI code. Triggers on tasks involving HTML, CSS, web components, WCAG compliance, responsive design, or web performance.","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fweb\u002FSKILL.md",[186,189,190],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[31,192,29,193,194,195,196,197,198,47,199,200,201,202,203,204,42,40,39,34],"web","web design guidelines","web design","css","performance","components","web components","code","web performance","ui","platform design","html","responsive design",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":213,"publishedAt":49},"01M6PT9A3JKRE3X34276F2FW5R","watchos-design-guidelines","Apple Human Interface Guidelines for Apple Watch. Use when building watchOS apps, complications, or workout features. Triggers on tasks involving Watch UI, Digital Crown, glanceable interfaces, or wrist-based interactions.","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwatchos\u002FSKILL.md",[211,212],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[31,29,214,47,201,45,215,44,32,40,216,39,135,37,33,217,218],"watchos design guidelines","workout","watch","platform-design","features"]