Hig Components Content

Apple HIG: Content Components

Check for .claude/apple-design-context.md before asking questions. Use existing context and only ask for information not already covered.

Key Principles

1. Adapt to different sizes and contexts. Content components must work across screen sizes, orientations, and multitasking configurations. Use Auto Layout and size classes.

2. Make content accessible. Charts need audio graph support. Images need alt text. Collections need proper VoiceOver navigation order. All content components need labels and descriptions.

3. Maintain visual hierarchy. Use spacing, sizing, and grouping to establish clear information hierarchy. Primary content should be visually prominent.

4. Use system components first. Evaluate UICollectionView, SwiftUI Charts, WKWebView before building custom. System components come with built-in accessibility and platform adaptation.

5. Respect platform conventions. A collection on tvOS uses large lockups with parallax. The same collection on iOS uses compact cells with touch targets. On visionOS, content gains depth and hover effects.

6. Handle empty states. Show a meaningful empty state with guidance on how to populate it, not a blank screen.

7. Optimize for performance. Use lazy loading, cell reuse, pagination, and prefetching for large datasets.

Reference Index

Component Selection Guide

Output Format

1. Component recommendation with rationale, referencing the relevant HIG reference file. 2. Configuration guidance -- key properties and setup. 3. Accessibility requirements for the recommended component. 4. Platform-specific notes for targeted platforms.

Questions to Ask

1. What type of content? (Quantitative data, images, web content, browsable collection, share action?) 2. Which platforms? 3. Static or dynamic content? 4. How much content? (Few items vs hundreds/thousands affects component choice and optimization.)

Related Skills

• hig-foundations -- Color, typography, accessibility, and image guidelines
• hig-patterns -- Data visualization, sharing, and loading patterns
• hig-components-layout -- Structural containers (scroll views, lists, split views) hosting content
• hig-platforms -- Platform-specific component behavior (lockups on tvOS, web views on macOS)

---

Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/activity-views.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Activity views

Best practices

Avoid creating duplicate versions of common actions that are already available in the activity view.

Consider using a symbol to represent your custom activity.

Write a succinct, descriptive title for each custom action you provide.

Make sure activities are appropriate for the current context.

Use the Share button to display an activity view.

Share and action extensions

• In iOS and iPadOS, share and action extensions are displayed in the share sheet that appears when people choose an Action button.

• In macOS, people access share extensions by clicking a Share button in the toolbar or choosing Share in a context menu. People can access an action extension by holding the pointer over certain types of embedded content — like an image they add to a Mail compose window — clicking a toolbar button, or choosing a quick action in a Finder window.

If necessary, create a custom interface that feels familiar to people.

Streamline and limit interaction.

Avoid placing a modal view above your extension.

If necessary, provide an image that communicates the purpose of your extension.

Use your main app to denote the progress of a lengthy operation.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/activity-views

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/charts.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Charts

• Learn how upcoming weather conditions might affect their plans.

• Analyze stock prices to understand past performance and discover trends.

• Review fitness data to monitor their progress and set new goals.

Marks

Choose a mark type based on the information you want to communicate about the data.

Consider combining mark types when it adds clarity to your chart.

Axes

Use a fixed or dynamic axis range depending on the meaning of your chart.

Define the value of the lower bound based on mark type and chart usage.

Prefer familiar sequences of values in the tick and grid-line labels for an axis.

Tailor the appearance of grid lines and labels to a chart’s use cases.

Descriptive content

Write descriptions that help people understand what a chart does before they view it.

Summarize the main message of your chart to help make it approachable and useful for everyone.

Best practices

Establish a consistent visual hierarchy that helps communicate the relative importance of various chart elements.

In a compact environment, maximize the width of the plot area to give people enough space to comfortably examine a chart.

Make every chart in your app accessible.

Let people interact with the data when it makes sense, but don’t require interaction to reveal critical information.

Make it easy for everyone to interact with a chart.

Make an interactive chart easy to navigate when using keyboard commands (including full keyboard access) or Switch Control.

Help people notice important changes in a chart.

Align a chart with surrounding interface elements.

Color

Avoid relying solely on color to differentiate between different pieces of data or communicate essential information in a chart.

Aid comprehension by adding visual separation between contiguous areas of color.

Enhancing the accessibility of a chart

Consider using Audio Graphs to give VoiceOver users more information about your chart.

Write accessibility labels that support the purpose of your chart.

• Prioritize clarity and comprehensiveness. In general, it’s rarely enough to merely report a data value unless you also include context that helps people understand it, like the date or location that’s associated with it. Aim to concisely describe the context for a value without repeating information that people can get in other ways, like an axis name that Audio Graphs or your overview provides. Follow context-setting information with a succinct description of the element’s details.

• Avoid using subjective terms. Subjective words — like rapidly, gradually, and almost — communicate your interpretation of the data. To help people form their own interpretations, use actual values in your descriptions.

• Maximize clarity in data descriptions by avoiding potentially ambiguous formats and abbreviations. For example, using “June 6” is clearer than using “6/6”; similarly, spelling out “60 minutes” or “60 meters” is clearer than using the abbreviation “60m.”

• Describe what the chart’s details represent, not what they look like. Consider a chart that uses red and blue colors to help people visually distinguish two different data series. It’s crucial to create accessibility labels that identify what each series represents, but describing the colors that visually represent them can add unnecessary information and be distracting.

• Be consistent throughout your app when referring to a specific axis. For example, if you always mention the X axis first, people can spend less time figuring out which axis is relevant in a description.

Hide visible text labels for axes and ticks from assistive technologies.

Platform considerations

watchOS

In general, avoid requiring complex chart interactions in your watchOS app.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/charts

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/collections.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Collections

Best practices

Use the standard row or grid layout whenever possible.

Consider using a table instead of a collection for text.

Make it easy to choose an item.

Add custom interactions when necessary.

Consider using animations to provide feedback when people insert, delete, or reorder items.

Platform considerations

iOS, iPadOS

Use caution when making dynamic layout changes.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/collections

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/color-wells.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Color wells

Best practices

Consider the system-provided color picker for a familiar experience.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/color-wells

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/image-views.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Image views

Best practices

Use an image view when the primary purpose of the view is simply to display an image.

If you want to display an icon in your interface, consider using a symbol or interface icon instead of an image view.

Content

Take care when overlaying text on images.

Aim to use a consistent size for all images in an animated sequence.

Platform considerations

macOS

If your app needs an editable image view, use an image well.

Use an image button instead of an image view to make a clickable image.

watchOS

Use SwiftUI to create animations when possible.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/image-views

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/image-wells.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Image wells

Best practices

Revert to a default image when necessary.

If your image well supports copy and paste, make sure the standard copy and paste menu items are available.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/image-wells

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/lockups.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Lockups

Best practices

Allow adequate space between lockups.

Use consistent lockup sizes within a row or group.

Monograms

Prefer images over initials.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/lockups

<!-- hig-doctor:attribution -->

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/web-views.

This file is a structured index of that content, snapshot 2025-02-02.

Apple HIG text and imagery are © Apple Inc.; this repository provides organization and cross-referencing for AI agent consumption only.

Web views

Best practices

Support forward and back navigation when appropriate.

Avoid using a web view to build a web browser.

---

<!-- hig-doctor:canonical-footer --> For the complete guidance, including worked examples and illustrations, see the canonical page: https://developer.apple.com/design/human-interface-guidelines/web-views