How should I design an iPad app using Apple's HIG?

Apple's HIG recommends using sidebars instead of bottom tab bars on iPadOS, supporting split views for multitasking, and adding pointer interactions. Apple HIG Skills provides instant, AI-ready guidance on all iPadOS conventions.

What are Apple's guidelines for adding Apple Pay?

Apple's HIG specifies exact payment button placement, flow design, error states, and UX patterns required for App Store approval. Apple HIG Skills gives your AI agent access to the full Apple Pay design guidelines.

How do I make my Apple app accessible?

Apple's HIG requires support for VoiceOver, Dynamic Type, sufficient color contrast ratios, and motor accessibility features like Switch Control. Apple HIG Skills covers all accessibility foundations and requirements.

How do I design for visionOS and Apple Vision Pro?

Apple's HIG for visionOS covers ornaments, volumes, immersive spaces, eye tracking, and spatial interaction patterns. Apple HIG Skills includes dedicated visionOS platform guidance and spatial layout references.

What are Apple's dark mode design guidelines?

Apple's HIG specifies using system semantic colors, material backgrounds, elevated surfaces, and vibrancy for dark mode. Apps should test in both modes and avoid hard-coded color values. Apple HIG Skills covers the full dark mode specification.

How should I design notifications for iOS apps?

Apple's HIG covers notification grouping, Live Activities, action buttons, and respecting user attention. Apple HIG Skills provides guidelines for the full notification system including widgets and complications.

VoiceOver

VoiceOver is a screen reader that lets people experience your app’s interface without needing to see the screen.

A sketch of the VoiceOver icon. The image is overlaid with rectangular and circular grid lines and is tinted blue to subtly reflect the blue in the original six-color Apple logo.

By supporting VoiceOver, you help people who are blind or have low vision access information in your app and navigate its interface and content when they can’t see the display.

VoiceOver is supported in apps and games built for Apple platforms. It’s also supported in apps and games developed in Unity using Apple’s Unity plug-ins. For related guidance, see Accessibility.

Descriptions

You inform VoiceOver about your app’s content by providing alternative text that explains your app’s interface and the content it displays.

Provide alternative labels for all key interface elements. VoiceOver uses alternative labels (which aren’t visible onscreen) to audibly describe your app’s interface. System-provided controls have generic labels by default, but you should provide more descriptive labels that convey your app’s functionality. Add labels to any custom elements your app defines. Be sure to keep your descriptions up-to-date as your app’s interface and content change. For developer guidance, see Accessibility modifiers.

Describe meaningful images. If you don’t describe key images in your app’s content, people can’t use VoiceOver to fully experience them within your app. Because VoiceOver helps people understand the interface surrounding images too, such as nearby captions, describe only the information the image itself conveys.

Make charts and other infographics fully accessible. Provide a concise description of each infographic that explains what it conveys. If people can interact with the infographic to get more or different information, make these interactions available to people using VoiceOver, too. The accessibility APIs offer ways to represent custom interactive elements so that assistive technologies can help people use them. For guidance, see Charts.

Exclude purely decorative images from VoiceOver. It’s unnecessary to describe images that are decorative and don’t convey useful or actionable information. Excluding these images shows respect for people’s time and reduces cognitive load when they use VoiceOver. For developer guidance, see accessibilityHidden(_:), accessibilityElement, and isAccessibilityElement.

Use titles and headings to help people navigate your information hierarchy. The title is the first information someone receives from an assistive technology when arriving on a page or screen in your app. Offer unique titles that succinctly describe each page’s content and purpose. Likewise, use accurate section headings that help people build a mental model of each page’s information hierarchy.

Specify how elements are grouped, ordered, or linked. Proximity, alignment, and other visible contextual cues help sighted people perceive the relationships between elements. Examine your app for places where relationships among elements are visual only. Then, describe these relationships to VoiceOver.

VoiceOver reads elements in the same order people read content in the their active language and locale. For example, in US English, this is top-to-bottom, left-to-right. In the ungrouped example below, VoiceOver describes each image before moving on to the captions. In the grouped example, VoiceOver describes each image with its respective caption.

Ungrouped related elements make it hard for VoiceOver to accurately describe the UI.

An X in a circle to indicate incorrect usage.

Grouped related elements help VoiceOver accurately describe the UI.

A checkmark in a circle to indicate correct usage.

For developer guidance, see shouldGroupAccessibilityChildren.

Inform VoiceOver when visible content or layout changes occur. People may find an unexpected content or layout change confusing because it means their mental map of the content is no longer accurate. It’s crucial to report visible changes so VoiceOver and other assistive technologies can help people update their understanding of the content. For developer guidance, see AccessibilityNotification.

Support the VoiceOver rotor when possible. People can use an interface element called the VoiceOver rotor to navigate a document or webpage by headings, links, and other content types. You can help people navigate content in your app by identifying these elements to the rotor. The rotor can also bring up the braille keyboard. For developer guidance, see AccessibilityRotorEntry (SwiftUI), UIAccessibilityCustomRotor (UIKit), and NSAccessibilityCustomRotor (AppKit).

Platform considerations

No additional considerations for iOS, iPadOS, macOS, tvOS, or watchOS.

visionOS

Be mindful that custom gestures aren’t always accessible. When VoiceOver is turned on in visionOS, apps and games that define custom gestures don’t receive hand input by default. This ensures people can explore the interface using their voice, without an app responding to hand input at the same time. A person can opt out of this behavior by enabling Direct Gesture mode, which disables standard VoiceOver gestures and lets apps process hand input directly. For developer guidance, see Improving accessibility support in your visionOS app.