Stats
Actions
Tags
From craft-workspace-webconsulting-skills
Guidelines for building iPad-optimized interfaces following Apple HIG. Covers multitasking, adaptive layouts, pointer support, keyboard shortcuts, and responsive design.
How this skill is triggered — by the user, by Claude, or both
Slash command
/craft-workspace-webconsulting-skills:ipados-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Comprehensive 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.
Comprehensive 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.
iPad presents two horizontal size classes: regular (full screen, large splits) and compact (Slide Over, narrow splits). Design for both. Never hardcode dimensions.
struct AdaptiveView: View {
@Environment(\.horizontalSizeClass) var sizeClass
var body: some View {
if sizeClass == .regular {
TwoColumnLayout()
} else {
StackedLayout()
}
}
}
iPad 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.
Design for the full range: iPad Mini (8.3"), iPad (11"), iPad Air (11"/13"), and iPad Pro (11"/13"). Use flexible layouts that redistribute content rather than simply scaling.
In 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.
struct ThreeColumnLayout: View {
var body: some View {
NavigationSplitView {
SidebarView()
} content: {
ContentListView()
} detail: {
DetailView()
}
}
}
iPad 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.
iPad 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.
Your app must function correctly at 1/3, 1/2, and 2/3 screen widths in Split View. At 1/3 width, your app receives compact horizontal size class. Content must remain usable at every split ratio.
Slide 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.
Stage Manager allows freely resizable windows and multiple windows simultaneously. Your app must:
@main
struct MyApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
// Support multiple windows
WindowGroup("Detail", for: Item.ID.self) { $itemId in
DetailView(itemId: itemId)
}
}
}
The 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.
When 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.
Use UIScene / SwiftUI WindowGroup to let users open multiple instances of your app showing different content. Each scene is independent. Support NSUserActivity for state restoration.
In 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.
struct AppNavigation: View {
@State private var selection: NavigationItem? = .inbox
var body: some View {
NavigationSplitView {
List(selection: $selection) {
Section("Main") {
Label("Inbox", systemImage: "tray")
.tag(NavigationItem.inbox)
Label("Drafts", systemImage: "doc")
.tag(NavigationItem.drafts)
Label("Sent", systemImage: "paperplane")
.tag(NavigationItem.sent)
}
Section("Labels") {
// Dynamic sections
}
}
.navigationTitle("Mail")
} detail: {
DetailView(for: selection)
}
}
}
SwiftUI TabView with .sidebarAdaptable style automatically converts to a sidebar in regular width. Use this for seamless iPhone-to-iPad adaptation.
TabView {
Tab("Home", systemImage: "house") { HomeView() }
Tab("Search", systemImage: "magnifyingglass") { SearchView() }
Tab("Profile", systemImage: "person") { ProfileView() }
}
.tabViewStyle(.sidebarAdaptable)
Use NavigationSplitView with three columns when your information architecture has three levels: category > list > detail. Examples: mail (accounts > messages > message), file managers, settings.
On 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.
.toolbar {
ToolbarItemGroup(placement: .primaryAction) {
Button("Compose", systemImage: "square.and.pencil") { }
}
ToolbarItemGroup(placement: .secondaryAction) {
Button("Archive", systemImage: "archivebox") { }
Button("Delete", systemImage: "trash") { }
}
}
When no item is selected in a list/sidebar, show a meaningful empty state in the detail area. Use a placeholder with icon and instruction text, not a blank screen.
Keep 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.
All tappable elements should respond to pointer hover. The system provides automatic hover effects for standard controls. For custom views, use .hoverEffect().
Button("Action") { }
.hoverEffect(.highlight) // Subtle highlight on hover
// Custom hover effect
MyCustomView()
.hoverEffect(.lift) // Lifts and adds shadow
The pointer should snap to (be attracted toward) button bounds. Standard UIKit/SwiftUI buttons get this automatically. For custom hit targets, ensure the pointer region matches the tappable area using .contentShape().
Right-click (secondary click) should present context menus. Use .contextMenu which automatically supports both long-press (touch) and right-click (pointer).
Text(item.title)
.contextMenu {
Button("Copy", systemImage: "doc.on.doc") { }
Button("Share", systemImage: "square.and.arrow.up") { }
Divider()
Button("Delete", systemImage: "trash", role: .destructive) { }
}
Support 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.
Change cursor appearance based on context. Text areas show I-beam. Links show pointer hand. Resize handles show resize cursors. Draggable items show grab cursor.
Pointer users expect click-and-drag for rearranging, selecting, and moving content. Combine with multi-select via Shift-click and Cmd-click.
Every primary action must have a keyboard shortcut. Standard shortcuts are mandatory:
| Shortcut | Action |
|---|---|
| Cmd+N | New item |
| Cmd+F | Find/Search |
| Cmd+S | Save |
| Cmd+Z | Undo |
| Cmd+Shift+Z | Redo |
| Cmd+C/V/X | Copy/Paste/Cut |
| Cmd+A | Select all |
| Cmd+P | |
| Cmd+W | Close window/tab |
| Cmd+, | Settings/Preferences |
| Delete | Delete selected item |
Button("New Document") { createDocument() }
.keyboardShortcut("n", modifiers: .command)
When 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.
Support 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.
struct FormView: View {
@FocusState private var focusedField: Field?
var body: some View {
Form {
TextField("Name", text: $name)
.focused($focusedField, equals: .name)
TextField("Email", text: $email)
.focused($focusedField, equals: .email)
TextField("Phone", text: $phone)
.focused($focusedField, equals: .phone)
}
}
}
Do 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.
Adapt 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.
Support arrow keys for navigating lists, grids, and collections. Combine with Shift for multi-selection. This is essential for productivity-focused apps.
Do 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.
iPadOS 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.
Apple 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.
For drawing apps, respond to force (pressure) and altitudeAngle/azimuthAngle (tilt) from pencil touch events. Use these for variable line width, opacity, or shading.
Apple 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.
// UIKit hover support via UIHoverGestureRecognizer
let hoverRecognizer = UIHoverGestureRecognizer(target: self, action: #selector(pencilHoverChanged(_:)))
hoverRecognizer.allowedTouchTypes = [NSNumber(value: UITouch.TouchType.pencil.rawValue)]
canvas.addGestureRecognizer(hoverRecognizer)
@objc func pencilHoverChanged(_ hover: UIHoverGestureRecognizer) {
let location = hover.location(in: canvas)
showBrushPreview(at: location)
}
For 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.
import PencilKit
struct DrawingView: UIViewRepresentable {
@Binding var canvasView: PKCanvasView
func makeUIView(context: Context) -> PKCanvasView {
canvasView.tool = PKInkingTool(.pen, color: .black, width: 5)
canvasView.drawingPolicy = .anyInput
return canvasView
}
}
iPad 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.
// As drag source
Text(item.title)
.draggable(item.title)
// As drop destination
DropTarget()
.dropDestination(for: String.self) { items, location in
handleDrop(items)
return true
}
Users 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.
When 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.
Provide clear visual states:
Universal Control lets users drag between iPad and Mac. If your app supports drag and drop with standard NSItemProvider and UTTypes, Universal Control works automatically.
Use DropDelegate for fine-grained control over drop behavior: validating drop content, reordering within lists, and handling drop position.
struct ReorderDropDelegate: DropDelegate {
let item: Item
@Binding var items: [Item]
@Binding var draggedItem: Item?
func performDrop(info: DropInfo) -> Bool {
draggedItem = nil
return true
}
func dropEntered(info: DropInfo) {
guard let draggedItem,
let fromIndex = items.firstIndex(of: draggedItem),
let toIndex = items.firstIndex(of: item) else { return }
withAnimation {
items.move(fromOffsets: IndexSet(integer: fromIndex),
toOffset: toIndex > fromIndex ? toIndex + 1 : toIndex)
}
}
}
When 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.
@main
struct MyApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
// Additional scene for external display
WindowGroup(id: "presentation") {
PresentationView()
}
}
}
Observe external display lifecycle via UIWindowScene events in your SceneDelegate or by listening for UIScene session notifications (UIApplication.didConnectSceneSessionNotification / UIApplication.didDisconnectSceneSessionNotification). Transition gracefully — if the external display disconnects mid-presentation, bring content back to the iPad screen without data loss.
// SceneDelegate: detect when a scene (external display window) connects or disconnects
func scene(_ scene: UIScene,
willConnectTo session: UISceneSession,
options connectionOptions: UIScene.ConnectionOptions) {
guard let windowScene = scene as? UIWindowScene else { return }
configureExternalDisplay(for: windowScene)
}
func sceneDidDisconnect(_ scene: UIScene) {
restoreContentToiPad()
}
Use 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.
Impact: CRITICAL
Every button, control, and interactive element must have a meaningful accessibility label. Icon-only toolbar items and custom views must use .accessibilityLabel().
Correct:
Button(action: compose) {
Image(systemName: "square.and.pencil")
}
.accessibilityLabel("Compose new message")
Incorrect:
Button(action: compose) {
Image(systemName: "square.and.pencil")
}
// VoiceOver reads "square.and.pencil" — meaningless to users
Use 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.
Text("Section Header")
.font(.headline) // Scales with Dynamic Type automatically
Hover 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.
With 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.
struct FormView: View {
@FocusState private var focusedField: Field?
var body: some View {
VStack {
TextField("Name", text: $name)
.focused($focusedField, equals: .name)
TextField("Email", text: $email)
.focused($focusedField, equals: .email)
}
}
}
In 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/3 or 1/2 split width. Do not hide actionable content outside the visible region without also removing it from the accessibility tree.
When 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.
Correct:
// SwiftUI — handled automatically for standard text styles
Text("Section Header")
.font(.headline)
// SwiftUI — custom rendering respects legibilityWeight
@Environment(\.legibilityWeight) var legibilityWeight
var body: some View {
Text("Custom Label")
.fontWeight(legibilityWeight == .bold ? .bold : .regular)
}
Incorrect:
// Hardcoded weight ignores Bold Text preference
label.font = UIFont.systemFont(ofSize: 17, weight: .regular)
// Missing: re-query font when UIAccessibility.boldTextStatusDidChangeNotification fires
When the user enables Increase Contrast in Settings, custom colors must provide higher-contrast variants. Use @Environment(\.colorSchemeContrast) in SwiftUI or UIAccessibility.isDarkerSystemColorsEnabled in UIKit.
Correct:
// SwiftUI
@Environment(\.colorSchemeContrast) var contrast
var separatorColor: Color {
contrast == .increased ? Color.primary : Color.secondary
}
// UIKit
let useHighContrast = UIAccessibility.isDarkerSystemColorsEnabled
let borderColor: UIColor = useHighContrast ? .label : .separator
Incorrect:
// Static color ignores Increase Contrast setting
let borderColor = UIColor.separator // Always low-contrast; ignores user preference
Use this checklist to verify iPad-readiness:
horizontalSizeClassUIAccessibility.isBoldTextEnabled)colorSchemeContrast or isDarkerSystemColorsEnabled)Stretching 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.
Never 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.
Many 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.
Tab 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.
On 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.
Missing 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.
Never hardcode widths, heights, or positions based on a specific iPad model. Use Auto Layout constraints, SwiftUI flexible frames, and GeometryReader for dynamic sizing.
On 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.
Claiming 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.
Large 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.
This skill is based on the excellent work by ehmo.
Original repository: https://github.com/ehmo/platform-design-skills
Special thanks to ehmo for their generous open-source contributions, which helped shape this skill collection. Adapted by webconsulting.at for this skill collection
npx claudepluginhub dirnbauer/webconsulting-skillsiPadOS platform-specific development with adaptive layouts, keyboard shortcuts, multitasking, and Stage Manager. Use when building iPad apps with split views, external keyboard support, or multi-window features.
Applies Apple Human Interface Guidelines for iPhone UI design, layout, safe areas, touch targets, screen sizes, and typography in SwiftUI/UIKit.
Generates SwiftUI and UIKit components for iOS apps following Apple's HIG. Validates designs, ensures accessibility compliance for iPhone, iPad, and Apple Watch.