Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jpoindexter/platform-conventions
Reference guide to native UI conventions across iOS (Apple HIG), Android (Material 3), macOS, Windows 11 Fluent, and web — with concrete numbers, comparison tables, and when to adapt vs. when to ship a custom cross-platform brand system.
Passed 23 of 23 test cases with the skill, and 22 of 23 without it.
1 fixed22 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
A developer porting a legacy Win32 application to Windows 11 kept square 0px corners across all primary cards and window frames to maintain maximum screen real estate. What corner radius standard should be applied for modern Fluent Design cards and windows?
| Checked | Without skill | With skill |
|---|---|---|
| Apply an 8 px corner radius to windows and cards. | Missed | Passed |
The instructions your model reads when the skill loads.
A platform convention is a contract the OS already taught the user. SF Symbols, the back-swipe, the FAB, the menu bar — these are muscle memory, not decoration. When you honor them your app feels native and invisible; when you fight them you spend the user's attention re-teaching things they already know. This skill is the cross-platform bible: what each platform expects, the exact numbers, and the trade-off of when to break with convention on purpose.
The recurring decision in every section below is the same: inherit the platform's pattern (cheaper, familiar, accessible-by-default) or impose your own (coherent, branded, but you pay to re-teach and re-implement). Read each platform's section as the catalog of what you get for free if you conform, so you know exactly what you're spending when you don't.
Respect them when: the value is in the content/task, not the chrome (productivity, utility, system-adjacent apps); you want App Store / Play Store reviewer goodwill; your users span ability levels (native controls inherit accessibility for free); you're a small team that can't afford to re-solve solved problems.
Use a custom cross-platform brand system when: the brand is the product (games, creative tools, immersive media, strongly-branded consumer apps like Spotify/Notion/Linear); a consistent identity across platforms outweighs per-platform familiarity; you control onboarding enough to teach novel patterns. Spotify, Discord, and Figma deliberately look identical everywhere — that consistency is the point.
The trade-off, stated plainly: Native = lower learning cost, free accessibility, store goodwill, but per-platform engineering and a fragmented brand. Custom = one design language and brand coherence, but you re-implement accessibility, you fight platform reflexes (back gesture, share sheet), and stores scrutinize you harder. The mature answer is almost always hybrid: a shared brand token layer (color, type scale, spacing, motion personality) with platform-native navigation, controls, and gestures. Never ship an iOS app that looks Android, or vice versa — that's the one thing users universally read as "cheap port."
Store reality: Apple's App Store Review Guidelines reject apps that feel like a "repackaged website" or ignore platform paradigms (§4.0 Design); Apple expects you to use system controls, the native share sheet, and standard navigation. Google Play is more permissive on UI but still rejects on broken back behavior, deceptive patterns, and accessibility failures. Conforming isn't only good UX — it materially lowers rejection risk and speeds review.
Type: SF Pro (SF Pro Text < 20pt, SF Pro Display ≥ 20pt; New York is the serif). Dynamic Type is mandatory — use the 11 text styles (LargeTitle 34, Title1 28, Title2 22, Title3 20, Headline 17 semibold, Body 17, Callout 16, Subhead 15, Footnote 13, Caption1 12, Caption2 11). Never hardcode point sizes for body content; users set their own scale (xSmall→AX5), and respecting it is an accessibility requirement, not an option.
Touch & grid: Minimum tap target 44×44 pt (HIG hard floor). Layout on an 8 pt grid (4 pt for fine tuning). Standard screen margin 16–20 pt. Points are density-independent; the system rasterizes @1x/@2x/@3x.
Navigation:
.medium/.large, drag-to-dismiss grabber) over full-screen modals. Use full-screen cover only for self-contained tasks. Action sheets for destructive choices anchored to context.System feel:
safeAreaInsets, never the raw screen rect.UIFeedbackGenerator (selection / impact / notification): expected on toggles, pickers, and success/error moments..ultraThinMaterial→.thickMaterial vibrancy for bars, popovers, sidebars — don't fake translucency with a flat alpha fill..label, .systemBackground, .separator), never hardcoded hex.Standard components — reach for these first: UIDatePicker (wheel/compact/inline), segmented control, stepper, switch (green capsule), context menus (long-press), swipe actions on rows, and the system share sheet (UIActivityViewController) — never roll your own share UI.
iPadOS is its own interaction model, not a big iPhone:
UISplitViewController: sidebar / supplementary / secondary) collapses to a stack on iPhone-width.test cases passed, vs 22 / 23 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.