ipados

Name: ipados
Author: ehmo

462stars26forks

How to install ipados?

ehmo/platform-design-skills/ipados

$npx -y skills add ehmo/platform-design-skills --skill ipados

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# iPadOS Design Guidelines
2
3	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.
4
5	---
6
7	## 1. Responsive Layout (CRITICAL)
8
9	### 1.1 Use Adaptive Size Classes
10
11	iPad presents two horizontal size classes: regular (full screen, large splits) and compact (Slide Over, narrow splits). Design for both. Never hardcode dimensions.
12
13	```swift
14	struct AdaptiveView: View {
15	@Environment(\.horizontalSizeClass) var sizeClass
16
17	var body: some View {
18	if sizeClass == .regular {
19	TwoColumnLayout()
20	} else {
21	StackedLayout()
22	}
23	}
24	}
25	```
26
27	### 1.2 Don't Scale Up iPhone UI
28
29	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.
30
31	### 1.3 Support All iPad Screen Sizes
32
33	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.
34
35	### 1.4 Column-Based Layouts for Regular Width
36
37	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.
38
39	```swift
40	struct ThreeColumnLayout: View {
41	var body: some View {
42	NavigationSplitView {
43	SidebarView()
44	} content: {
45	ContentListView()
46	} detail: {
47	DetailView()
48	}
49	}
50	}
51	```
52
53	### 1.5 Respect Safe Areas
54
55	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.
56
57	### 1.6 Support Both Orientations
58
59	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.
60
61	---
62
63	## 2. Multitasking (CRITICAL)
64
65	### 2.1 Support Split View
66
67	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.
68
69	### 2.2 Support Slide Over
70
71	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.
72
73	### 2.3 Handle Stage Manager
74
75	Stage Manager allows freely resizable windows and multiple windows simultaneously. Your app must:
76	- Resize fluidly to arbitrary dimensions
77	- Support multiple scenes (windows) showing different content
78	- Not assume any fixed size or aspect ratio
79
80	```swift
81	@main
82	struct MyApp: App {
83	var body: some Scene {
84	WindowGroup {
85	ContentView()
86	}
87	// Support multiple windows
88	WindowGroup("Detail", for: Item.ID.self) { $itemId in
89	DetailView(itemId: itemId)
90	}
91	}
92	}
93	```
94
95	### 2.4 Never Assume Full Screen
96
97	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.
98
99	### 2.5 Handle Size Transitions Gracefully
100
101	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.
102
103	### 2.6 Support Multiple Scenes
104
105	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.
106
107	---
108
109	## 3. Navigation (CRITICAL)
110
111	### 3.1 Sidebar for Primary Navigation
112
113	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.
114
115	```swift
116	struct AppNavigation: View {
117	@State private var selection: NavigationItem? = .inbox
118
119	var body: some View {
120	NavigationSplitView {
121	List(selection: $selection) {
122	Section("Main") {
123	Label("Inbox", systemImage: "tray")
124	.tag(NavigationItem.inbox)
125	Label("Dr

People who liked this also viewed

6 picks

Type

ipados

462stars26forks

View on GitHub

How to install ipados?

ehmo/platform-design-skills/ipados

$npx -y skills add ehmo/platform-design-skills --skill ipados

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# iPadOS Design Guidelines
2
3	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.
4
5	---
6
7	## 1. Responsive Layout (CRITICAL)
8
9	### 1.1 Use Adaptive Size Classes
10
11	iPad presents two horizontal size classes: regular (full screen, large splits) and compact (Slide Over, narrow splits). Design for both. Never hardcode dimensions.
12
13	```swift
14	struct AdaptiveView: View {
15	@Environment(\.horizontalSizeClass) var sizeClass
16
17	var body: some View {
18	if sizeClass == .regular {
19	TwoColumnLayout()
20	} else {
21	StackedLayout()
22	}
23	}
24	}
25	```
26
27	### 1.2 Don't Scale Up iPhone UI
28
29	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.
30
31	### 1.3 Support All iPad Screen Sizes
32
33	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.
34
35	### 1.4 Column-Based Layouts for Regular Width
36
37	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.
38
39	```swift
40	struct ThreeColumnLayout: View {
41	var body: some View {
42	NavigationSplitView {
43	SidebarView()
44	} content: {
45	ContentListView()
46	} detail: {
47	DetailView()
48	}
49	}
50	}
51	```
52
53	### 1.5 Respect Safe Areas
54
55	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.
56
57	### 1.6 Support Both Orientations
58
59	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.
60
61	---
62
63	## 2. Multitasking (CRITICAL)
64
65	### 2.1 Support Split View
66
67	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.
68
69	### 2.2 Support Slide Over
70
71	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.
72
73	### 2.3 Handle Stage Manager
74
75	Stage Manager allows freely resizable windows and multiple windows simultaneously. Your app must:
76	- Resize fluidly to arbitrary dimensions
77	- Support multiple scenes (windows) showing different content
78	- Not assume any fixed size or aspect ratio
79
80	```swift
81	@main
82	struct MyApp: App {
83	var body: some Scene {
84	WindowGroup {
85	ContentView()
86	}
87	// Support multiple windows
88	WindowGroup("Detail", for: Item.ID.self) { $itemId in
89	DetailView(itemId: itemId)
90	}
91	}
92	}
93	```
94
95	### 2.4 Never Assume Full Screen
96
97	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.
98
99	### 2.5 Handle Size Transitions Gracefully
100
101	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.
102
103	### 2.6 Support Multiple Scenes
104
105	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.
106
107	---
108
109	## 3. Navigation (CRITICAL)
110
111	### 3.1 Sidebar for Primary Navigation
112
113	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.
114
115	```swift
116	struct AppNavigation: View {
117	@State private var selection: NavigationItem? = .inbox
118
119	var body: some View {
120	NavigationSplitView {
121	List(selection: $selection) {
122	Section("Main") {
123	Label("Inbox", systemImage: "tray")
124	.tag(NavigationItem.inbox)
125	Label("Dr

People who liked this also viewed

6 picks

Type