Hig Technologies

Apple HIG: Technologies

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

Key Principles

1. Apple technologies extend app capabilities through system integration. Each technology has established user-facing patterns; deviating creates confusion and erodes trust.

2. Privacy and user control are paramount. Especially for health, payment, and identity technologies. Request only needed data, explain why, respect choices.

3. Siri: natural, predictable, recoverable. Clear conversational intent phrases that complete quickly and confirm results. Support App Shortcuts for proactive suggestions. Handle errors with clear fallbacks.

4. Payments: transparent and frictionless. Standard Apple Pay button styles. Never ask for card details when Apple Pay is available. Clearly describe what the user is buying, the price, and whether it's one-time or subscription.

5. Health data is deeply personal. Explain the health benefit before requesting access. CareKit tasks should be encouraging. ResearchKit consent flows must be thorough, readable, and respect autonomy.

6. HomeKit: simple and reliable. Immediate response when controlling devices. Clear device state. Graceful handling of connectivity issues.

7. AR: genuine value, not gimmicks. Use AR when spatial context improves understanding. Guide setup (surface, lighting, space). Provide clear exit back to standard interaction.

8. ML and generative AI: enhance without surprising. Smart suggestions, image recognition, text prediction. Clearly attribute AI-generated content. Controls to edit, regenerate, or dismiss. Let users correct mistakes.

9. Sign in with Apple as top option. Standard button styles. Respect email hiding preference. ID Verifier: guided flows, don't store sensitive data beyond what verification requires.

10. iCloud: invisible and reliable sync. Data appears on all devices without manual intervention. Handle conflicts gracefully. Never lose data.

11. SharePlay: real-time participation. Support multiple participants, show presence, handle latency. AirPlay: appropriate Now Playing metadata.

12. CarPlay: driver safety first. Minimize interaction complexity, large touch targets, no distracting content. Only permitted app types: audio, messaging, EV charging, navigation, parking, quick food ordering.

13. Accessibility is a baseline requirement. Every element has a meaningful VoiceOver label, trait, and action. Support Dynamic Type, Switch Control, and other assistive technologies. Test entirely with VoiceOver enabled.

Reference Index

Output Format

1. Implementation checklist -- step-by-step requirements per Apple's guidelines. 2. Required vs optional features for approval. 3. Privacy and permission requirements -- data access, usage descriptions. 4. User-facing flow from permission prompt through task completion. 5. Testing guidance -- key scenarios including edge cases.

Questions to Ask

1. Which Apple technology? 2. Core use case? 3. Which platforms? 4. API requirements and entitlements reviewed? 5. What data or permissions needed?

Related Skills

• hig-inputs -- Input methods interacting with technologies (voice for Siri, Pencil for AR, gestures for Maps)
• hig-components-system -- Widgets, complications, Live Activities surfacing technology data
• hig-components-status -- Progress indicators for technology operations (sync, payment, AR loading)

---

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/airplay.

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.

AirPlay

Best practices

Prefer the system-provided media player.

Provide content in the highest possible resolution.

Stream only the content people expect.

Support both AirPlay streaming and mirroring.

Support remote control events.

Don’t stop playback when your app enters the background or when the device locks.

Don’t interrupt another app’s playback unless your app is starting to play immersive content.

Let people use other parts of your app during playback.

If necessary, provide a custom interface for controlling media playback.

Using AirPlay icons

Custom color AirPlay icon

Position the AirPlay icon consistently with other technology icons.

Don’t use the AirPlay icon or name in custom buttons or interactive elements.

Pair the icon with the name _AirPlay_ correctly.

Emphasize your app over AirPlay.

Referring to AirPlay

Use correct capitalization when using the term _AirPlay_.

Always use _AirPlay_ as a noun.

Use terms like _works with_ , _use_ , _supports_ , and _compatible_.

Use the name _Apple_ with the name _AirPlay_ if desired.

Refer to AirPlay if appropriate and to add clarity.

---

<!-- 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/airplay

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

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

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.

Always On

• On iPhone 14 Pro and iPhone 14 Pro Max, the system displays Lock Screen items like Widgets and Live Activities when people set aside their device face up and stop interacting with it.

• When people drop their wrist while wearing Apple Watch, the system dims the watch face, continuing to display the interface of the app as long as it’s either frontmost or running a background session.

Best practices

Hide sensitive information.

Keep other types of personal information glanceable when it makes sense.

Keep important content legible and dim nonessential content.

Maintain a consistent layout.

Gracefully transition motion to a resting state; don’t stop it instantly.

---

<!-- 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/always-on

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

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

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.

Apple Pay

Offering Apple Pay

Offer Apple Pay on all devices and browsers that support it.

If you use Apple Pay APIs to find out whether someone has an active card in Wallet, you must make Apple Pay the primary — but not necessarily sole — payment option everywhere you use the APIs.

If you also offer other payment methods, offer Apple Pay at the same time.

If you use an Apple Pay button to start the Apple Pay payment process, you must use the Apple-provided API to display it.

If you use a custom button to start the Apple Pay payment process, make sure your custom button doesn’t display “Apple Pay” or the Apple Pay logo.

Use Apple Pay buttons only to start the Apple Pay payment process and, when appropriate, the Apple Pay set-up process.

Don’t hide an Apple Pay button or make it appear unavailable.

Use the Apple Pay mark only to communicate that Apple Pay is accepted.

Inform search engines that Apple Pay is accepted on your website.

Streamlining checkout

Provide a cohesive checkout experience.

If Apple Pay is available, assume the person wants to use it.

Accelerate single-item purchases with Apple Pay buttons on product detail pages.

Accelerate multi-item purchases with express checkout.

Collect necessary information, like color and size options, before people reach the Apple Pay button.

Collect optional information before checkout begins.

Gather multiple shipping methods and destinations before showing the payment sheet.

For in-store pickup, help people choose a pickup location before displaying the payment sheet.

Prefer information from Apple Pay.

Avoid requiring account creation prior to purchase.

Report the result of the transaction so that people can view it in the payment sheet.

Display an order confirmation or thank-you page.

Customizing the payment sheet

Only present and request essential information.

Display the active coupon or promotional code, or give people a way to enter it.

Let people choose the shipping method in the payment sheet.

For in-store pickup, consider letting people choose a pickup window that works for them.

Use line items to explain additional charges, discounts, pending costs, add-on donations, recurring, and future payments.

• iOS
• Web

Keep line items short.

Provide a business name after the word _Pay_ on the same line as the total.

If you’re not the end merchant, specify both your business name and the end merchant’s name in the payment sheet.

Clearly disclose when additional costs may be incurred after payment authorization.

Handle data entry and payment errors gracefully.

Handling errors

Data validation

• iOS
• Web

Avoid forcing compliance with your business logic.

Provide accurate status reporting to the system.

Succinctly and specifically describe the problem when data is invalid or incorrectly formatted.

Payment processing

Handle interruptions correctly.

Supporting subscriptions

• iOS
• Web

Clarify subscription details before showing the payment sheet.

Include line items that reiterate billing frequency, discounts, and additional upfront fees.

• iOS
• Web

Clarify the current payment amount in the total line.

Only show the payment sheet when a subscription change results in additional fees.

Supporting donations

Use a line item to denote a donation.

Streamline checkout by offering predefined donation amounts.

Using Apple Pay buttons

Button types

• A button that is guaranteed to use an Apple-approved caption, font, color, and style

• Assurance that the button’s contents maintain ideal proportions as you change its size

• Automatic translation of the button’s caption into the language that’s set for the device

• Support for configuring the button’s corner radius to match the style of your UI

• A system-provided alternative text label that lets VoiceOver describe the button

Button size and position

Prominently display the Apple Pay button.

Position the Apple Pay button correctly in relation to an Add to Cart button.

Adjust the corner radius to match the appearance of other buttons.

Maintain the minimum button size and margins around the button.

Apple Pay mark

Use only the artwork provided by Apple, with no alterations other than height.

Maintain a minimum clear space around the mark of 1/10 of its height.

Referring to Apple Pay

Capitalize Apple Pay in text as it appears in the Apple Trademark list.

Never use the Apple logo to represent the name _Apple_ in text.

Coordinate the font face and size with your app.

Don’t translate _Apple Pay_ or any other Apple trademark.

In a payment selection context, you can display a text-only description of Apple Pay only when all payment options have text-only descriptions.

When promoting your app’s use of Apple Pay, follow App Store guidelines.

---

<!-- 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/apple-pay

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

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

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.

Augmented reality

Offer AR features only on capable devices.

Best practices

Let people use the entire display.

Strive for convincing illusions when placing realistic objects.

Consider how virtual objects with reflective surfaces show the environment.

Use audio and haptics to enhance the immersive experience.

Minimize text in the environment.

If additional information or controls are necessary, consider displaying them in screen space.

Consider using indirect controls when you need to provide persistent controls.

Anticipate that people will use your app in a wide variety of real-world environments.

Be mindful of people’s comfort.

If your app encourages people to move, introduce motion gradually.

Be mindful of people’s safety.

Providing coaching

Hide unnecessary app UI while people are using a coaching view.

If necessary, offer a custom coaching experience.

Helping people place objects

Show people when to locate a surface and place an object.

When people place an object, immediately integrate that object into the AR environment.

Consider guiding people toward offscreen virtual objects.

Avoid trying to precisely align objects with the edges of detected surfaces.

Incorporate plane classification information to inform object placement.

Designing object interactions

Let people use direct manipulation to interact with objects when possible.

Let people directly interact with virtual objects using standard, familiar gestures.

In general, keep interactions simple.

Respond to gestures within reasonable proximity of interactive virtual objects.

Let people initiate object scaling when it makes sense in your app.

Be wary of potentially conflicting gestures.

Strive for virtual object movement that’s consistent with the physics of your app’s AR environment.

Explore even more engaging methods of interaction.

Offering a multiuser experience

Consider allowing people occlusion.

When possible, let new participants enter a multiuser AR experience.

Reacting to real-world objects

When a detected image first disappears, consider delaying the removal of virtual objects that are attached to it.

Limit the number of reference images in use at one time.

Limit the number of reference images requiring an accurate position.

Communicating with people

If you must display instructional text, use approachable terminology.

In a three-dimensional context, prefer 3D hints.

Make important text readable.

If necessary, provide a way to get more information.

Handling interruptions

Consider using the system-provided coaching view to help people relocalize.

Consider hiding previously placed virtual objects during relocalization.

Minimize interruptions if your app supports both AR and non-AR experiences.

Allow people to cancel relocalization.

Indicate when the front-facing camera is unable to track a face for more than about half a second.

Suggesting problem resolutions

Let people reset the experience if it doesn’t meet their expectations.

Suggest possible fixes if problems occur.

Icons and badges

Use the AR glyph as intended.

Maintain minimum clear space.

Use the AR badges as intended and don’t alter them.

Prefer the AR badge to the glyph-only badge.

Use badging only when your app contains a mixture of objects that can be viewed in AR and objects that cannot.

Keep badge placement consistent and clear.

Maintain minimum clear space.

---

<!-- 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/augmented-reality

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

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

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.

CareKit

Data and privacy

Provide a coherent privacy policy.

HealthKit integration

Request access to health data only when you need it.

Clarify your app’s intent by adding descriptive messages to the standard permission screen.

Manage health data sharing solely through the system’s privacy settings.

CareKit views

Tasks

Use the simple style for a one-step task.

Use the instructions style when you need to add informative text to a simple task.

Use the log style to help people log events.

Use the checklist style to display a list of actions or steps in a multistep task.

Use the grid style to display a grid of buttons in a multistep task.

Consider using color to reinforce the meaning of task items.

Combine accuracy with simplicity when describing a task and its steps.

Consider supplementing multistep or complex tasks with videos or images.

Charts

Consider highlighting narratives and trends to illustrate progress.

Label chart elements clearly and succinctly.

Use distinct colors.

Consider providing a legend to add clarity.

Clearly denote units of time.

Consolidate large data sets for greater readability.

If necessary, offset data to keep charts proportional.

Contact views

Consider using color to categorize care team members.

Notifications

Minimize notifications.

Consider providing a detail view.

Symbols and branding

• Designs that coordinate with CareKit’s visual design language

• Support for creating custom symbols to represent the unique content in your app

Design a relevant care symbol.

Incorporate refined, unobtrusive branding.

---

<!-- 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/carekit

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

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

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.

CarPlay

iPhone interactions

Eliminate app interactions on iPhone when CarPlay is active.

Never lock people out of CarPlay because the connected iPhone requires input.

Make sure your app works without requiring people to unlock iPhone.

Audio

Let people choose when to start playback.

Start playback as soon as audio has sufficiently loaded.

Display the Now Playing screen when audio is ready to play.

Resume audio playback after an interruption only when it’s appropriate.

When necessary, automatically adjust audio levels, but don’t change the overall volume.

Layout

Provide useful, high-value information in a clean layout that’s easy to scan from the driver’s seat.

Maintain an overall consistent appearance throughout your app.

Ensure that primary content stands out and feels actionable.

Color

In general, prefer a limited color palette that coordinates with your app logo.

Avoid using the same color for interactive and noninteractive elements.

Test your app’s color scheme under a variety of lighting conditions in an actual car.

Ensure your app looks great in both dark and light environments.

Choose colors that help you communicate effectively with everyone.

Icons and images

Supply high-resolution images with scale factors of @2x and @3x for all CarPlay artwork in your app.

Mirror your iPhone app icon.

Don’t use black for your icon’s background.

Error handling

Report errors in CarPlay, not on the connected iPhone.

---

<!-- 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/carplay

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

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

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.

Game Center

• Discover new games their friends are playing.

• Seamlessly invite friends to play.

• See the latest activity from their games across the system, in the Apple Games app, the App Store, notifications, and more.

Accessing Game Center

Integrating the access point

Display the access point in menu screens.

Avoid placing controls near the access point.

Consider pausing your game while the Game Overlay or dashboard is present.

Using custom UI

Use the artwork Game Center provides in custom links.

Use the correct terminology in custom links.

Achievements

Integrating achievements into your game

Align with Game Center achievement states.

Determine a display order.

Be succinct when describing achievements.

Give players a sense of progress.

Creating achievement images

Design rich, high-quality images that help players feel rewarded.

Create artwork in the appropriate size and format.

• iOS, iPadOS, macOS, visionOS
• tvOS

Leaderboards

Choose a leaderboard type.

• A _classic leaderboard_ tracks a player’s best all-time score. Classic leaderboards are always active with no ending. The following are examples of goals you might include in a classic leaderboard:

• Strive for the most perfect score in a rhythm game.

• Collect the most coins in a single dungeon run.

• Achieve the longest continuous time in an endless runner.

• A _recurring leaderboard_ resets based on a time interval you define, such as every week or every day. Recurring leaderboards can increase engagement by giving players more chances to take the lead. The following are examples of features that work well with recurring leaderboards:

• Daily rotating puzzles

• Seasonal or holiday-themed events

• Weekly leaderboards for different battle modes

Take advantage of leaderboard sets for multiple leaderboards.

• Difficulty modes (Easy, Standard, Hard)

• Activity types (Combat, Crafting, Farming)

• Genres and themes (Disco, Pop, Rock)

Add leaderboard images.

• iOS, iPadOS, macOS
• tvOS

Challenges

Create engaging challenges.

• Complete the fastest lap in a racing level.

• Defeat the most enemies in a single round.

• Solve a daily puzzle with the fewest mistakes.

Avoid creating challenges that track overall progress or personal best scores.

Make it easy to jump into your challenge.

Create high-quality artwork that encourages players to engage with your challenges.

Multiplayer activities

Use party codes to invite players to multiplayer activities.

• Allow players to join gameplay late, leave early, and return later.

• Provide a way for players to view the current party code in your game.

• Allow players to enter a party code manually.

Support multiplayer activities through in-game UI.

Provide engaging activity artwork.

Platform considerations

tvOS

Display an optional image at the top of the dashboard.

watchOS

Be aware of Game Center support on watchOS.

---

<!-- 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/game-center

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

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

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.

Generative AI

Best practices

Design your experience responsibly.

Keep people in control.

Ensure an inclusive experience for all.

Design engaging and useful generative features.

Ensure a great experience even when generative features aren’t available or people opt not to use them.

Transparency

Communicate where your app uses AI.

Set clear expectations about what your AI-powered feature can and can’t do.

Privacy

Prefer on-device processing.

Ask permission before using personal information and usage data.

Clearly disclose how your app and its model use and store personal information.

Models and datasets

Thoughtfully evaluate model capabilities.

Be intentional when choosing or creating a dataset.

Inputs

Guide people on how to use your generative feature.

Raise awareness about and minimize the chance of hallucinations.

Consider consequences and get permission before performing destructive or potentially problematic tasks.

Outputs

Help people improve requests when blocked or undesirable results occur.

Reduce unexpected and harmful outcomes with thoughtful design and thorough testing.

Strive to avoid replicating copyrighted content.

Factor processing time into your design.

Consider offering alternate versions of results.

Continuous improvement

Consider ways to improve your model over time.

Let people share feedback on outputs.

Design flexible, adaptable features.

---

<!-- 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/generative-ai

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

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

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.

HealthKit

Privacy protection

Provide a coherent privacy policy.

Request access to health data only when you need it.

Clarify your app’s intent by adding descriptive messages to the standard permission screen.

Manage health data sharing solely through the system’s privacy settings.

Activity rings

Use Activity rings for Move, Exercise, and Stand information only.

Use Activity rings to show progress for a single person.

Don’t use Activity rings for ornamentation.

Don’t use Activity rings for branding.

Maintain Activity ring and background colors.

Maintain Activity ring margins.

Differentiate other ring-like elements from Activity rings.

Provide app-specific information only in Activity notifications.

Apple Health icon

Use only the Apple-provided icon.

Display the name _Apple Health_ close to the Apple Health icon.

Display the Apple Health icon consistently with other health-related app icons.

Don’t use the Apple Health icon as a button.

Don’t alter the appearance of the Apple Health icon.

Maintain a minimum clear space around the Apple Health icon of 1/10 of its height.

Don’t use the Apple Health icon within text or as a replacement for the terms _Health_ , _Apple Health_ , or _HealthKit_.

Don’t display Health app images or screenshots.

Editorial guidelines

Refer to the Health app as _Apple Health_ or _the Apple Health app_.

Don’t use the term _HealthKit_.

Use correct capitalization when using the term _Apple Health_.

Use the system-provided translation of _Health_ to avoid confusing people.

---

<!-- 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/healthkit

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

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

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.

HomeKit

• Help people set up, name, and organize their accessories

• Allow fine-grained accessory configuration and control

• Provide access to custom accessory features

• Show people how to create powerful, hands-free automations

• Provide support

Terminology and layout

Acknowledge the hierarchical model that HomeKit uses.

Make it easy for people to find an accessory’s related HomeKit details.

Recognize that people can have more than one home.

Don’t present duplicate home settings.

Setup

Use the system-provided setup flow to give people a familiar experience.

Provide context to explain why you need access to people’s Home data.

Don’t require people to create an account or supply personal information.

Honor people’s setup choices.

Carefully consider how and when to provide a custom accessory setup experience.

Help people choose useful names

Suggest service names that suit your accessory.

Check that the names people provide follow HomeKit naming rules.

• Use only alphanumeric, space, and apostrophe characters.

• Start and end with an alphabetic or numeric character.

• Don’t include emojis.

Help people avoid creating names that include location information.

Siri interactions

Present example voice commands to demonstrate using Siri to control accessories during setup.

After setup, consider teaching people about more complex Siri commands.

Recommend that people create zones and service groups, if they make sense for your accessory.

Offer shortcuts only for accessory-specific functionality that HomeKit doesn’t support.

If your app supports both HomeKit and shortcuts, help people understand the difference between these types of voice control.

Custom functionality

Be clear about what people can do in your app and when they might want to use the Home app.

Defer to HomeKit if your database differs from the HomeKit database.

Ask permission to update the HomeKit database when people make changes in your app.

Cameras

Don’t block camera images.

Show a microphone button only if the camera supports bidirectional audio.

Using HomeKit icons

Use only Apple-provided icons.

Styles

Custom color HomeKit icon

Position the HomeKit icon consistently with other technology icons.

Use the HomeKit icon noninteractively.

Don’t use the HomeKit icon within text or as a replacement for the word HomeKit.

Pair the icon with the name _HomeKit_ correctly.

Referring to HomeKit

Emphasize your app over HomeKit.

Adhere to Apple’s trademark guidelines.

• Use Apple product names in singular form only; do not make Apple product names possessive.

• Don’t translate Apple, Apple Home, HomeKit, or any other Apple trademark.

• Don’t use category descriptors. For example, say iPad, not tablet.

• Don’t indicate any kind of sponsorship, partnership, or endorsement from Apple.

• Attribute Apple, HomeKit, and all other Apple trademarks with the correct credit lines wherever legal information appears within your app.

• Refer to Apple devices and operating systems only in technical specifications or compatibility descriptions.

Referencing HomeKit and the Home app

Use correct capitalization when using the term _HomeKit_.

Don’t use the name _HomeKit_ as a descriptor.

Don’t suggest that HomeKit is performing an action or function.

Use the name _Apple_ with the name _HomeKit_ , if desired.

Use the name _HomeKit_ for setup, configuration, and instructions, if desired.

Use the app name _Apple Home_ whenever referring specifically to the 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/homekit

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

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

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.

iCloud

Best practices

Make it easy to use your app with iCloud.

Avoid asking which documents to keep in iCloud.

Keep content up to date when possible.

Respect iCloud storage space.

Make sure your app behaves appropriately when iCloud is unavailable.

Keep app state information in iCloud.

Warn about the consequences of deleting a document.

Make conflict resolution prompt and easy.

Include iCloud content in search results.

For games, consider saving player progress in iCloud.

---

<!-- 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/icloud

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

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

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.

ID Verifier

• Customers only present the minimum data needed to prove their age or identity, without handing over their ID card or showing their device.

• Apple provides the key components of the certificate issuance, management, and validation process, simplifying app development and enabling a consistent and trusted ID verification experience.

• Display Only request. Use a Display Only request to display data — such as a person’s name or age alongside their photo portrait — within system-provided UI on the requester’s iPhone, so the requester can visually confirm the person’s identity. When you make a Display Only request, the customer’s data remains within the system-provided UI and isn’t transmitted to your app. For developer guidance, see `MobileDriversLicenseDisplayRequest`.

• Data Transfer request. Use a Data Transfer request only when you have a legal verification requirement and you need to store or process information like a person’s address or date of birth. You must request an additional entitlement to make a Data Transfer request. To learn more, see Get started with ID Verifier; for developer guidance, see `MobileDriversLicenseDataRequest` and `MobileDriversLicenseRawDataRequest`.

Best practices

Ask only for the data you need.

If your app qualifies for Apple Business Register, register for ID Verifier to ensure that people can view essential information about your organization when you make a request.

Provide a button that initiates the verification process.

In a Display Only request, help the person using your app provide feedback on the visual confirmation they perform.

---

<!-- 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/id-verifier

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

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/imessage-apps-and-stickers.

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.

iMessage apps and stickers

Best practices

Prefer providing one primary experience in your iMessage app.

Consider surfacing content from your iOS or iPadOS app.

Present essential features in the compact view.

In general, let people edit text only in the expanded view.

Create stickers that are expressive, inclusive, and versatile.

For each sticker, provide a localized alternative description.

---

<!-- 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/imessage-apps-and-stickers

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

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

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.

In-app purchase

• _Consumable_ content like lives or gems in a game. After purchase, consumable content depletes as people use it, and people can purchase it again.

• _Non-consumable_ content like premium features in an app. Purchased non-consumable content doesn’t expire.

• _Auto-renewable subscriptions_ to virtual content, services, and premium features in your app on an ongoing basis. An auto-renewable subscription continues to automatically renew at the end of each subscription period until people choose to cancel it.

• _Non-renewing subscriptions_ to a service or content that lasts for a limited time, like access to an in-game battle pass. People purchase a non-renewing subscription each time they want to extend their access to the service or content.

Best practices

Let people experience your app before making a purchase.

Design an integrated shopping experience.

Use simple, succinct product names and descriptions.

Display the total billing price for each in-app purchase you offer, regardless of type.

Display your store only when people can make payments.

Use the default confirmation sheet.

Supporting Family Sharing

Prominently mention Family Sharing in places where people learn about the content you offer.

Help people understand the benefits of Family Sharing and how to participate.

Aim to customize your in-app messaging so that it makes sense to both purchasers and family members.

Providing help with in-app purchases

Provide help that customers can view before they request a refund.

Use a simple title for the refund action, like “Refund” or “Request a Refund”.

Help people find the problematic purchase.

Consider offering alternative solutions.

Make it easy for people to request a refund.

Avoid characterizing or providing guidance on Apple’s refund policies.

Auto-renewable subscriptions

Call attention to subscription benefits during onboarding.

Offer a range of content choices, service levels, and durations.

Consider letting people try your content for free before signing up.

• Freemium app
• Metered paywall
• Free trial

Prompt people to subscribe at relevant times, like when they near their monthly limit of free content.

Encourage a new subscription only when someone isn’t already a subscriber.

Making signup effortless

Provide clear, distinguishable subscription options.

Simplify initial signup by asking only for necessary information.

In your tvOS app, help people sign up or authenticate using another device.

Give people more information in your app’s sign-up screen.

• The subscription name, duration, and the content or services provided during each subscription period

• The billing amount, correctly localized for the territories and currencies where the subscription is available for purchase

• A way for existing subscribers to sign in or restore purchases

Clearly describe how a free trial works.

Include a sign-up opportunity in your app’s settings.

Supporting offer codes

• A _one-time use code_ is a unique code you generate in App Store Connect. People can redeem a one-time use code through a redemption URL (a shareable link), within your app (when you support redemption), or by entering it in the App Store, where they’re prompted to install your app if they haven’t already. Consider using one-time use codes when your distribution is small or when you need to restrict access to a code.

• A _custom code_ is a code you create, such as NEWYEAR or SPRINGSALE. People can redeem a custom code through a redemption URL or within your app (when you support redemption). Consider using a custom code when you want to support a large campaign that requires a mass distribution of codes.

Clearly explain offer details.

Follow guidelines for creating a custom code.

Tell people how to redeem a custom code.

Consider supporting offer redemption within your app.

Supply an engaging and informative promotional image.

Help people benefit from unlocked content as soon as they complete the redemption flow.

Helping people manage their subscriptions

Provide summaries of the customer’s subscriptions.

Consider using the system-provided subscription-management UI.

Consider ways to encourage a subscriber to keep their subscription or resubscribe later.

Always make it easy for customers to cancel an auto-renewable subscription.

Consider creating a branded, contextual experience to complement the system-provided management UI.

Platform considerations

watchOS

Clearly describe the differences between versions of your app that run on different devices.

Consider using a modal sheet to display the required information.

Make subscription options easy to compare on a small screen.

• Display each option in a separate button. Using one button per payment option lets people start the signup process with one tap. In this design, it’s important to lock up each button with its description so that people can see how these elements are related, especially while scrolling.

• Display a list of options, followed by a button people tap to start the signup process. Using a list to display one option per row gives you a compact design that minimizes scrolling while making subscription choices easy to scan and understand. In this design, the button’s title can update to reflect the chosen option.

---

<!-- 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/in-app-purchase

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

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

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.

Live Photos

Best practices

Apply adjustments to all frames.

Keep Live Photo content intact.

Implement a great photo sharing experience.

Clearly indicate when a Live Photo is downloading and when the photo is playable.

Display Live Photos as traditional photos in environments that don’t support Live Photos.

Make Live Photos easily distinguishable from still photos.

Keep badge placement consistent.

---

<!-- 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/live-photos

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

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

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.

Mac Catalyst

Before you start

Drag and drop.

Keyboard navigation and shortcuts.

Multitasking.

• Pointer interactions and keyboard-based focus and navigation

• Window management

• Toolbars

• Rich text interaction, including copy and paste as well as contextual menus for editing

• File management

• Menu bar menus

• App-specific settings in the system-provided Settings app

• Split view

• File browser

• Activity view

• Form sheet

• Contextual actions

• Color picker

Choose an idiom

When you adopt the Mac idiom, thoroughly audit your app’s layout, and plan to make changes to it.

Adjust font sizes as needed.

Make sure views and images look good in the Mac version of your app.

• iPad idiom
• Mac idiom

Limit your appearance customizations to standard macOS appearance customizations that are the same or similar to those available in iPadOS.

Integrate the Mac experience

Navigation

• Split views. A split view supports hierarchical navigation, which consists of a two- or three-column interface that shows a primary column, an optional supplementary column, and a secondary pane of content. Frequently, apps use the primary column to create a sidebar-based interface where changes in the sidebar drive changes in the optional supplementary column, which then affect the content in the content pane.

• Tab bars. A tab bar supports flat navigation by displaying top-level categories in a persistent bar at the bottom of the screen.

• Page controls. A page control displays dots at the bottom of the screen that indicate the position of the current page in a flat list of pages.

• A split view with a sidebar displays a list of top-level items, each of which can disclose a list of child items. Using a sidebar streamlines navigation, because each tab’s contents are available within the sidebar. By using a sidebar on both iPad and Mac, you create a consistent layout that makes it easy for iPad users to start using the Mac version of your app.

• A segmented control and a tab bar both accommodate similar interactions, such as mutually exclusive selection. In general, using a split view instead of a tab bar works better than using a segmented control. However, a segmented control can work well on the Mac if your app uses a flat navigation hierarchy.

Make sure people retain access to important tab-bar items in the Mac version of your app.

Offer multiple ways to move between pages.

App icons

Create a macOS version of your app icon.

Layout

• Divide a single column of content and actions into multiple columns.

• Use the regular-width and regular-height size classes, and consider reflowing elements in the content area to a side-by-side arrangement as people resize the window.

• Present an inspector UI next to the main content instead of using a popover.

Consider moving controls from the main UI of your iPad app to your Mac app’s toolbar.

As much as possible, adopt a top-down flow.

Relocate buttons from the side and bottom edges of the screen.

---

<!-- 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/mac-catalyst

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

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

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.

Machine learning

The role of machine learning in your app

Critical or complementary

• The keyboard uses machine learning to provide QuickType suggestions. Because the keyboard still works without these suggestions, machine learning plays a complementary role in the app.

• Face ID relies on machine learning to perform accurate face recognition. Without machine learning, Face ID would not work.

Private or public

• If a health app misinterprets data and incorrectly recommends a visit to the doctor, people are likely to experience anxiety and may lose trust in the app.

• If a music app misinterprets data and recommends an artist that people don’t like, they’re likely to view the result as an inconsequential mistake.

Proactive or reactive

• QuickType suggests words in reaction to what people type.

• Siri Suggestions can proactively suggest a shortcut based on people’s recent routines.

Dynamic or static

• Face ID improves dynamically as people’s faces gradually change over time.

• Photos improves its object recognition capabilities with every new iOS release.

Explicit feedback

Request explicit feedback only when necessary.

Always make providing explicit feedback a voluntary task.

Use simple, direct language to describe each explicit feedback option and its consequences.

• Suggest less pop music

• Suggest more thrillers

• Mute politics for a week

Add icons to an option description if it helps people understand it.

Consider offering multiple options when requesting explicit feedback.

Act immediately when you receive explicit feedback and persist the resulting changes.

Consider using explicit feedback to help improve when and where you show results.

Implicit feedback

Always secure people’s information.

Help people control their information.

Don’t let implicit feedback decrease people’s opportunities to explore.

When possible, use multiple feedback signals to improve suggestions and mitigate mistakes.

Consider withholding private or sensitive suggestions.

Prioritize recent feedback.

Use feedback to update predictions on a cadence that matches the person’s mental model of the feature.

Be prepared for changes in implicit feedback when you make changes to your app’s UI.

Beware of confirmation bias.

Calibration

Always secure people’s information.

Be clear about why you need people’s information.

Collect only the most essential information.

Avoid asking people to participate in calibration more than once.

Make calibration quick and easy.

• Prioritize getting a few pieces of important information and infer the rest from other sources or by getting people’s feedback.

• Avoid asking for information that most people would have to look up.

• Avoid asking people to perform actions that might be difficult.

Make sure people know how to perform calibration successfully.

Immediately provide assistance if progress stalls.

Confirm success.

Let people cancel calibration at any time.

Give people a way to update or remove information they provided during calibration.

Corrections

Give people familiar, easy ways to make corrections.

Provide immediate value when people make a correction.

Let people correct their corrections.

Always balance the benefits of a feature with the effort required to make a correction.

Never rely on corrections to make up for low-quality results.

Learn from corrections when it makes sense.

When possible, use guided corrections instead of freeform corrections.

Mistakes

• Anticipate mistakes. As much as possible, design ways to avoid mistakes and mitigate them when they happen.

• Help people handle mistakes. Mistakes can have a wide range of consequences, so the tools you provide to handle a mistake must be able to address those consequences.

• Learn from mistakes when doing so improves your app. In some cases, learning from a mistake might have undesirable effects, such as causing unpredictability in the user experience. When it makes sense, use each mistake as a data point that can refine your machine learning models and improve your app.

• Limitations help you set people’s expectations about the accuracy of your suggestions.

• Corrections give people a way to be successful even when your results are wrong.

• Attribution gives people insight into where suggestions come from, which can help them understand mistakes.

• Confidence helps you gauge the quality of your results, which can impact how you present them.

• Feedback — both explicit and implicit — lets people tell you about mistakes that you might not be aware of.

Understand the significance of a mistake’s consequences.

Make it easy for people to correct frequent or predictable mistakes.

Continuously update your feature to reflect people’s evolving interests and preferences and help avoid mistakes.

When possible, address mistakes without complicating the UI.

Be especially careful to avoid mistakes in proactive features.

As you work on reducing mistakes in one area, always consider the effect your work has on other areas and overall accuracy.

Multiple options

• Suggested options, a proactive feature that suggests content to people based on the their past interactions. For example, For You recommendations from Apple Music.

• Requested options, a reactive feature that suggests potential next steps to people based on their recent actions. For example, Quick Type suggestions.

• Corrections, which are actions people take to fix mistakes your app has made when it’s acting on their behalf. For example, the Photos Auto-Crop feature.

Prefer diverse options.

In general, avoid providing too many options.

List the most likely option first.

Make options easy to distinguish and choose.

Learn from selections when it makes sense.

Confidence

Know what your confidence values mean before you decide how to present them.

In general, translate confidence values into concepts that people already understand.

In situations where attributions aren’t helpful, consider ranking or ordering the results in a way that implies confidence levels.

In scenarios where people expect statistical or numerical information, display confidence values that help them interpret the results.

Whenever possible, help people make decisions by conveying confidence in terms of actionable suggestions.

Consider changing how you present results based on different confidence thresholds.

When you know that confidence values correspond to result quality, you generally want to avoid showing results when confidence is low.

Attribution

• Encourage people to change what they do in your app

• Minimize the impact of mistakes

• Help people build a mental model of your feature

• Promote trust in your app over time

Consider using attributions to help people distinguish among results.

Avoid being too specific or too general.

Keep attributions factual and based on objective analysis.

In general, avoid technical or statistical jargon.

Limitations

• Photos to perform a search that covers every category they can imagine

• Siri to respond to queries that aren’t well defined, like “What is the meaning of life?”

• FaceID to work from every angle

• Set people’s expectations before they use the feature.

• Show people how to get the best results while they’re using the feature.

• When inferior results occur, explain why so that people can understand the feature better.

Help people establish realistic expectations.

Demonstrate how to get the best results.

• Use placeholder text to suggest input. In Photos, the search bar displays the text “Photos, People, Places…” to help people understand what they can search for before they begin typing. Photos also displays a description of how it scans the photo library to offer search suggestions.

• As people interact with the feature, provide feedback on their actions to guide them towards a result without overwhelming them. For example, while people are interacting with Animoji, the feature responds to current conditions and suggests how people can improve their results by adjusting the lighting or moving closer to the camera.

• Suggest alternative ways to accomplish the goal instead of showing no results. To do this successfully, you need to understand the goal well enough to suggest alternatives that make sense. For example, if people ask Siri to set a timer on a Mac, Siri suggests setting a reminder instead, because timers aren’t available in macOS. This suggestion makes sense because people’s goal is to receive an alert at a certain time.

Explain how limitations can cause unsatisfactory results.

Consider telling people when limitations are resolved.

---

<!-- 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/machine-learning

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

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

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.

Maps

Best practices

In general, make your map interactive.

Pick a map emphasis style that suits the needs of your app.

• The _default_ style presents a version of the map with fully saturated colors, and is a good option for most standard map applications without a lot of custom elements. This style is also useful for keeping visual alignment between your map and the Maps app, in situations when people might switch between them.

• The _muted_ style, by contrast, presents a desaturated version of the map. This style is great if you have a lot of information-rich content that you want to stand out against the map.

Help people find places in your map.

Clearly identify elements that people select.

Cluster overlapping points of interest to improve map legibility.

Help people see the Apple logo and legal link.

• Use adequate padding to separate the logo and link from the map boundaries and your custom controls. For example, it works well to use 7 points of padding on the sides of the elements and 10 points above and below them.

• Avoid causing the logo and link to move with your interface. It’s best when the Apple logo and legal link appear to be fixed to the map.

• If your custom interface can move relative to the map, use the lowest position of the custom element to determine the placement of the logo and link. For example, if your app lets people pull up a custom card from the bottom of the screen, place the Apple logo and legal link 10 points above the lowest resting position of the card.

Custom information

Use annotations that match the visual style of your app.

If you want to display custom information that’s related to standard map features, consider making them independently selectable.

Use overlays to define map areas with a specific relationship to your content.

• _Above roads_ , the default level, places the overlay above roads but below buildings, trees, and other features. This is great for situations where you want people to have an idea of what’s below the overlay, while still clearly understanding that it’s a defined space.

• _Above labels_ places the overlay above both roads and labels, hiding everything beneath it. This is useful for content that you want to be fully abstracted from the features of the map, or when you want to hide areas of the map that aren’t relevant.

Make sure there’s enough contrast between custom controls and the map.

Place cards

Displaying place cards in a map

• The _automatic_ style lets the system determine the place card style based on the size of your map view.

• The _callout_ style displays a place card in a popover style next to the selected place. You can further specify the style of a callout — the _full_ callout style displays a large, detailed place card, and the _compact_ callout style displays a space-saving, more concise place card. If you don’t specify a callout style, the system defaults to the _automatic_ callout style, which determines the callout style based on your map’s view size.

• The _caption_ style displays an “Open in Apple Maps” link.

• The _sheet_ style displays a place card in a sheet.

• Full callout
• Compact callout
• Caption
• Sheet

Consider your map presentation when choosing a style.

Make sure your place card looks great on different devices and window sizes.

Avoid duplicating information.

Keep the location on your map visible when displaying a place card.

Adding place cards outside of a map

Use location-related cues in surrounding content to help communicate that people can open a place card.

Indoor maps

• Example 1
• Example 2
• Example 3

Adjust map detail based on the zoom level.

Use distinctive styling to differentiate the features of your map.

Offer a floor picker if your venue includes multiple levels.

Include surrounding areas to provide context.

Consider supporting navigation between your venue and nearby transit points.

Limit scrolling outside of your venue.

Design an indoor map that feels like a natural extension of your app.

Platform considerations

watchOS

Fit the map interface element to the screen.

Show the smallest region that encompasses the points of interest.

---

<!-- 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/maps

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

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

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.

NFC

In-app tag reading

Don’t encourage people to make contact with physical objects.

Use approachable terminology.

Provide succinct instructional text for the scanning sheet.

Background tag reading

Support both background and in-app tag reading.

---

<!-- 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/nfc

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

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

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.

Photo editing

Best practices

Confirm cancellation of edits.

Don’t provide a custom top toolbar.

Let people preview edits.

Use your app icon for your photo editing extension icon.

---

<!-- 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/photo-editing

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

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

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.

ResearchKit

Creating the onboarding experience

Always display the onboarding screens in the correct order.

1\. Introduction

Provide an introduction that informs and provides a call to action.

2\. Determine eligibility

Determine eligibility as soon as possible.

3\. Get informed consent

Make sure participants understand your study before you get their consent.

Break a long consent form into easily digestible sections.

If it makes sense, provide a quiz that tests the participant’s understanding.

Get the participant’s consent and, if appropriate, some contact information.

4\. Request permission to access data

Get permission to access the participant’s device or data, and to send notifications.

Conducting research

Create surveys that keep participants engaged.

• Tell participants how many questions there are and about how long the survey will take.

• Use one screen per question.

• Show participants their progress in the survey.

• Keep the survey as short as possible. Several short surveys tend to work better than one long survey.

• For questions that require some additional explanation, use the standard font for the question and a slightly smaller font for the explanatory text.

• Tell participants when the survey is complete.

Make active tasks easy to understand.

• Describe how to perform the task using clear, simple language.

• Explain any requirements, such as if the task must be performed at a particular time or under specific circumstances.

• Make sure participants can tell when the task is complete.

Managing personal information and providing encouragement

Use a profile to help participants manage personal data related to your study.

Use a dashboard to show progress and motivate participants to continue.

---

<!-- 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/researchkit

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

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

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.

SharePlay

Best practices

Let people know that you support SharePlay.

If part of your app requires a subscription, consider ways to help nonsubscriber participants quickly join a group activity.

Support Picture in Picture (PiP) when possible.

Use the term _SharePlay_ correctly.

Sharing activities

Briefly describe each activity.

Make it easy to start sharing an activity.

Help people prepare to join a session before displaying the activity.

When possible, defer app tasks that might delay a shared activity.

Platform considerations

visionOS

Choose the spatial Persona template that suits your shared activity.

Be prepared to launch directly into your shared activity.

Help people enter a shared activity together, but don’t force them.

Smoothly update a shared activity when new participants join.

Maintaining a shared context

Make sure everyone views the same state of your app.

Use Spatial Audio to enrich your shared activity.

When possible, let people discover natural, social solutions to confusions or conflicts that might arise during a shared experience.

Help people keep their private and shared content separate.

• Private
• Selected
• Shared

Adjusting a shared context

Let people personalize their experience without changing the experience for others.

Consider when to give each participant a unique view of the shared content.

Make it easy for people to exit and rejoin a shared activity.

---

<!-- 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/shareplay

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

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

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.

ShazamKit

• Enhancing experiences with graphics that correspond with the genre of currently playing music

• Making media content accessible to people with hearing disabilities by providing closed captions or sign language that syncs with the audio

• Synchronizing in-app experiences with virtual content in contexts like online learning and retail

Best practices

Stop recording as soon as possible.

Let people opt in to storing your app’s recognized songs to their iCloud library.

---

<!-- 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/shazamkit

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

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

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.

Sign in with Apple

Offering Sign in with Apple

Ask people to sign in only in exchange for value.

Delay sign-in as long as possible.

If you require an account, ask people to set it up before offering any sign-in options.

Consider letting people link an existing account to Sign in with Apple.

• If people share an email address through Sign in with Apple and it matches the address in an existing account, you can suggest that they link Sign in with Apple to that account.

• If people used an existing user name and password to sign in, you can display an account-linking suggestion in their account’s settings view or another logical place.

In a commerce app, wait until after people make a purchase before asking them to create an account.

As soon as Sign in with Apple completes, welcome people to their new account.

Indicate when people are currently signed in.

Collecting data

Clarify whether the additional data you request is required or just recommended.

Don’t ask people to supply a password.

Avoid asking for a personal email address when people supply a private relay address.

• Make sure that people can view their private relay address in your app or website

• Direct people to Settings > Apple Account > Password & Security > Apps using Apple Account to retrieve their private relay address

• Use other identifying values, like an order number or phone number collected as part of a purchase

Give people a chance to engage with your app before asking for optional data.

Be transparent about the data you collect.

Displaying buttons

Prominently display a Sign in with Apple button.

Using the system-provided buttons

• A button that’s guaranteed to use an Apple-approved appearance

• Assurance that the button’s contents maintain ideal proportions as you change its style

• Automatic translation of the button’s title into the language specified by the device

• Support for configuring the button’s corner radius to match the style of your UI (iOS, macOS, and web)

• A system-provided alternative text label that lets VoiceOver describe the button

Button size and corner radius

Adjust the corner radius to match the appearance of other buttons in your app.

Maintain the minimum button size and margin around the button in iOS, macOS, and the web.

Creating a custom Sign in with Apple button

• Use the logo file to position the Apple logo in a button; never use the Apple logo as a button.

• Match the height of the logo file to the height of the button.

• Don’t crop the logo file.

• Don’t add vertical padding.

• Titles. Use only _Sign in with Apple_ , _Sign up with Apple_ , or _Continue with Apple_.

• General shape. Buttons that combine the logo with text are always rectangular; logo-only buttons can be circular or rectangular.

• Logo and title colors. Within a button, both items must be either black or white; don’t use custom colors.

• Title font. You can also adjust the font’s weight and size.

• Title case. You can capitalize every letter in the title.

• Background appearance. The overall color needs to remain black or white. If necessary, you can include a subtle texture or gradient to help the button harmonize with your interface.

• Button corner radius. You can use a corner radius value that matches the other buttons in your UI.

• Button bezel and shadow. For example, you can use a stroke to emphasize the button bezel or add a drop shadow.

Custom buttons with a logo and text

Choose the format of the logo file based on the height of your button.

Prefer the system font for the title — that is, Sign in with Apple, Sign up with Apple, or Continue with Apple.

In general, preserve the capitalization style of the title.

Keep the title and logo vertically aligned within the button.

Inset the logo if necessary.

Maintain a minimum margin between the title and the right edge of the button.

Maintain the minimum button size and margin around the button.

Custom logo-only buttons

Choose the format of the logo file based on the size of your button.

Don’t add horizontal padding to a logo-only image.

Use a mask to change the default square shape of the logo-only image.

Maintain a minimum margin around the button.

---

<!-- 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/sign-in-with-apple

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

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

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.

Siri

• Ask Siri to perform a system-defined task that your app supports, like send a message, play a song, or start a workout.

• Run a _shortcut_ , which is a way to accelerate actions your app defines through onscreen interactions or by voice.

• Use the Shortcuts app to adjust what a shortcut does, including combining several actions to perform one multistep shortcut.

• Tap a _suggestion_ to perform a shortcut with your app (Siri can _suggest_ shortcuts that people might want to perform, based on their current context and the information you provide).

• Use Siri to control an accessory that integrates with your app.

• Identify key tasks in your app that people might want to perform on a regular basis.

• Drive engagement by telling the system about your app’s key tasks and by supporting suggestions.

• For actions that people can perform through voice interaction, design functional conversational flows that feel natural.

• Explore the various ways people might perform your app’s tasks — such as in a hands-free situation — and the devices they might be using, such as Apple Watch or iPad.

Integrating your app with Siri

Provide information about actions and support suggestions

• Shortly before 7:30 a.m., Siri might suggest the _order coffee_ action to people who use the coffee app every morning.

• After people use a box office–type app to buy tickets to a movie, Siri might remind them to turn on Do Not Disturb shortly before showtime.

• Siri might suggest an automation that starts a workout in a person’s favorite workout app and plays their favorite workout playlist as they enter their usual gym.

• When people enter the airport after a home-bound flight, Siri might suggest they request a ride home from their favorite ride-sharing app.

System intents

Design responses to system intents

Whenever possible, complete requests without leaving Siri.

When a request has a financial impact, default to the safest and least expensive option.

When people request media playback from your app, consider providing alternative results if the request is ambiguous.

On Apple Watch, design a streamlined workflow that requires minimal interaction.

Enhance the voice experience for system intents

Create example requests.

Define custom vocabulary that people use with your app.

Consider defining alternative app names.

Design a custom interface for a system intent

Avoid including extraneous or redundant information.

Make sure people can still perform the action without viewing your custom interface.

Use ample margins and padding in your custom interface.

Minimize the height of your interface.

Refrain from displaying your app name or icon.

Custom intents

Custom intent categories and responses

• Confirmation. Confirms that people still want to perform the action.

• Success. Indicates that the action has been initiated.

• Error. Tells people that the action can’t be completed.

Design a custom intent

If your app’s action requires a custom intent, pick the category that most closely matches the action.

Design custom intents that accelerate common, useful tasks.

Ensure that your intent works well in every scenario.

In general, design custom intents for tasks that aren’t overly complex.

Design your intents to be long-lived.

Don’t request permission to use Siri.

Support background operation.

Help people customize their requests

Design intents that require as few follow-up questions as possible.

List the smallest number of options possible, and sort the items in a way that makes sense.

Make sure each follow-up question is meaningful.

Design parameters that are easy for people to understand and use.

Ask for confirmation only when necessary.

Support follow-up questions when it makes sense.

Prioritize the options you offer based on the context in which people run your shortcut.

Consider adjusting the parameter values you offer when people set up your shortcut.

• You can find and present parameter values that are relevant to the context people are in while they’re setting up the shortcut. For example, if people use the Shortcuts app to choose a value for a store-location parameter, the parameter can dynamically generate a list of stores that are currently closest to the device.

• You can present a comprehensive list of parameter values. When people set up a shortcut, having an extensive list of parameter values can help them create the shortcut they want. In contrast, when people use a shortcut to accelerate an action, they generally prefer the convenience of having a shorter list of choices.

Enhance the voice experience for custom intents

Aim to create conversational interactions.

Help people understand errors and failures.

Strive for engaging voice responses.

Create voice responses that are concise, descriptive, and effective in voice-driven scenarios.

Avoid unnecessary repetition.

Help conversations with Siri feel natural.

Exclude your app name.

Don’t attempt to mimic or manipulate Siri.

Be appropriate and respect parental controls.

Avoid using personal pronouns.

Consider letting people view more options in your app.

Keep responses device-independent.

Don’t advertise.

Shortcuts and suggestions

• Siri can suggest a shortcut for an action people have performed at least once by offering it in search results, on the lock screen, and in the Shortcuts app.

• Your app can supply a shortcut for an action that people haven’t done yet but might want to do in the future, so that the Shortcuts app can suggest it or it can appear on the Siri watch face.

• People can use the Shortcuts app to view all their shortcuts and even combine actions from different apps into multistep shortcuts.

• People can also use the Shortcuts app to automate a shortcut by defining the conditions that can run it, like time of day or current location.

Make app actions widely available

• In search results

• Throughout the Shortcuts app

• On the lock screen as a Siri Suggestion

• Within the Now Playing view (for recently played media content)

• During Wind Down

Make a donation every time people perform the action.

Only donate actions that people actually perform.

Remove donations for actions that require corresponding data.

If your app handles reservations, consider donating them to the system.

Create shortcut titles and subtitles

Be concise but descriptive.

Start titles with a verb and use sentence-style capitalization without punctuation.

Lead with important information.

Exclude your app name.

Localize titles and subtitles.

Consider providing a custom image for a more engaging suggestion.

• 60x60 pt (180x180 px @ 3x) to display in an iOS app

• 34x34 pt (68x68 px @2x) to display on the Siri watch face on the 44mm Apple Watch (watchOS scales down the image for smaller watches)

Provide default phrases for shortcuts

Keep phrases short and memorable.

Make sure the phrases you suggest are accurate and specific.

Don’t commandeer core Siri commands.

Make shortcuts customizable

Provide a parameter summary for each custom intent you support.

Craft a short parameter summary that’s clearly related to your intent’s title.

Aim for a parameter summary that reads like a sentence.

Provide multiple parameter summaries when necessary.

Provide output parameters for information that people can use in a multistep shortcut.

Consider defining an input parameter.

Help people distinguish among different variations of the same action.

Avoid providing multiple actions that perform the same basic task.

Editorial guidelines

Use correct capitalization and punctuation when using the term _Hey Siri_.

In a localized context, translate only the word _Hey_ in the phrase _Hey Siri_.

Referring to Shortcuts

When referring to the Shortcuts feature or app, always typeset with a capital S and make sure that _Shortcuts_ is plural.

When referring to individual shortcuts (that is, not the feature or the Shortcuts app), use lowercase.

Use the right terminology when describing how people can use Shortcuts in your app.

Referring to Apple products

Adhere to Apple’s trademark guidelines.

• Use Apple product names in singular form only; don’t make Apple product names possessive.

• Don’t translate Apple, Siri, or any other Apple trademark.

• Don’t use category descriptors. For example, say iPad, not tablet.

• Don’t indicate any kind of sponsorship, partnership, or endorsement from Apple.

• Attribute Apple, Siri, and all other Apple trademarks with the correct credit lines wherever legal information appears within your app.

• Refer to Apple devices and operating systems only in technical specifications or compatibility descriptions.

---

<!-- 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/siri

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

Source: Apple Inc. Canonical content at https://developer.apple.com/design/human-interface-guidelines/tap-to-pay-on-iphone.

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.

Tap to Pay on iPhone

Enabling Tap to Pay on iPhone

Help merchants accept Tap to Pay on iPhone terms and conditions before they begin interacting with their customers.

Present Tap to Pay on iPhone terms and conditions only to an administrative user.

If necessary, help merchants make sure their device is up to date.

Educating merchants

Provide a tutorial that describes the supported payment types and shows how to use Tap to Pay on iPhone to accept each type.

• Including it in a Learn More option in your in-app messaging

• Automatically presenting it after merchants accept the Tap to Pay on iPhone terms and conditions

• Automatically presenting it to new users of your app

• Making it easy to find in a consistent place like your app’s help content or settings area

• Launch a checkout flow for each type of payment

• Help a customer position their contactless card or digital wallet on the merchant’s device for payment

• Handle PIN entry for a card, including accessibility mode

Checking out

• Offer payment options in addition to Tap to Pay on iPhone, as necessary

• Respond quickly if a merchant initiates checkout before enabling Tap to Pay on iPhone

• Help merchants perform checkout even if device configuration is still in progress

• Present pre-payment actions that affect the final total before checkout completes

Provide Tap to Pay on iPhone as a checkout option whether the feature is enabled or not.

Avoid making merchants wait to use Tap to Pay on iPhone.

Make sure the Tap to Pay on iPhone checkout option is available even if configuration is continuing in the background.

If your app supports multiple payment-acceptance methods, make the Tap to Pay on iPhone button easy to find.

Make it easy for merchants to switch between Tap to Pay on iPhone and the hardware accessories you support.

Design your Tap to Pay on iPhone button to match the other buttons in your app.

Determine the final amount that customers need to pay before merchants initiate the Tap to Pay on iPhone experience.

If you support pre-payment options in your checkout flow, display them before the Tap to Pay on iPhone screen.

Displaying results

Start processing a transaction as soon as possible.

Display a progress indicator while payment is authorizing before you show your transaction result screen.

Clearly display the result of a transaction, whether it’s declined or successful.

Help merchants complete the checkout flow when a payment can’t complete with Tap to Pay on iPhone.

• Present a new screen or reuse your checkout screen, letting merchants accept an alternate form of payment, like cash

• Support checkout with a different method, like external hardware or a payment link

• Relaunch Tap to Pay on iPhone, if a customer has another card they want to try

• Some regions require Strong Customer Authentication (SCA) support, which means that although the payment card might not require a card PIN during a tap, the bank that issues the card can request a PIN after receiving the transaction processing request. In this scenario, your app may need to display the PIN entry screen instead of the transaction result.

• In some regions your app may need to meet additional requirements to address the limitations of some cards, such as those in Offline PIN markets. Some PSPs support additional PIN fallback functionality to collect partial data from a tap, letting merchants continue the payment with another method such as a payment link.

If the system returns an error that the merchant must address, display a clear description of the problem and recommend an appropriate resolution.

Make it easy for merchants to get help with issues they can’t resolve.

Additional interactions

Use a generic label in a button that opens the Tap to Pay on iPhone screen to read a payment card when there’s no transaction amount.

If your app supports an independent loyalty card transaction, distinguish this flow from a payment-acceptance flow that uses Tap to Pay on iPhone.

---

<!-- 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/tap-to-pay-on-iphone

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

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

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.

VoiceOver

Descriptions

Provide alternative labels for all key interface elements.

Describe meaningful images.

Make charts and other infographics fully accessible.

Exclude purely decorative images from VoiceOver.

Navigation

Use titles and headings to help people navigate your information hierarchy.

Specify how elements are grouped, ordered, or linked.

Inform VoiceOver when visible content or layout changes occur.

Support the VoiceOver rotor when possible.

Platform considerations

visionOS

Be mindful that custom gestures aren’t always accessible.

---

<!-- 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/voiceover

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

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

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.

Wallet

Passes

Offer to add new passes to Wallet.

Help people add a pass that they created outside of your app.

Add related passes as a group.

Display an Add to Apple Wallet button to let people add an existing pass that isn’t already in Wallet.

Let people jump from your app to their pass in Wallet.

Tell the system when your pass expires.

Always get people’s permission before deleting a pass from Wallet.

Help the system suggest a pass when it’s contextually relevant.

Update passes as needed.

Use change messages only for updates to time-critical information.

Designing passes

Design a pass that looks great and works well on all devices.

Avoid using device-specific language.

Make your pass instantly identifiable.

Keep the front of a pass uncluttered so people can get important information at a glance.

Prefer an NFC-compatible pass.

Reduce image sizes for optimal performance.

Provide an icon that represents your company or brand.

Pass styles

Display text only in pass fields.

Boarding passes

• Example
• Layout

Coupons

• Example
• Layout

Store cards

• Example
• Layout

Event tickets

• Example
• Layout 1
• Layout 2

• Example
• Layout

Create a vibrant and engaging background.

Position your background image in the safe area.

Ensure sufficient contrast so that ticket information is easy to read.

Consider using the additional information tile for extra event details.

Continue to support event tickets for earlier versions of iOS.

Generic passes

• Example
• Layout 1
• Layout 2

Passes for Apple Watch

• Boarding
• Coupon
• Store
• Event
• Generic

Order tracking

Make it easy for people to add an order to Wallet.

Make information about an order available immediately after people place it.

Provide fulfillment information as soon as it’s available, and keep the status up to date.

Supply a high-resolution logo image that uses a nontransparent background.

Supply distinct, high-resolution product images that use nontransparent backgrounds.

In general, keep text brief.

Use clear, approachable language, and localize the text you provide.

Displaying order and fulfillment details

Provide a link to an area where people manage their order.

Clearly describe each item so people can verify that their order contains everything they expect.

Supply a prioritized list of your apps that might be installed on the device.

Avoid sending duplicate notifications.

Make it easy for customers to contact the merchant.

Help people track their order.

• A link that opens the carrier’s website to a page with information about a shipping fulfillment. When possible, provide a direct link — in addition to a tracking number — so people can easily view the most up-to-date shipping information. If necessary, display this link on any intermediate order-tracking page you open.

• A scannable barcode when one is required to pick up the order in a pickup fulfillment. It’s convenient when people can offer the barcode from within Wallet instead of finding it in an email or webpage.

• Clear, detailed instructions that can help people receive or pick up their order.

Keep the fulfillment screen centered on order tracking.

Choose shipping-fulfillment values that match the details you have about the shipping process.

Keep customers informed through relevant fulfillment status descriptions.

Be direct and thorough when describing an Issue or Canceled status.

Identity verification

Present a Wallet verification option only when the device supports it.

Ask for identity information only at the precise moment you need it.

Clearly and succinctly describe the reason you need the information you’re requesting.

Ask only for the data you actually need.

Clearly indicate whether you will keep the data and — if you need to keep it — specify how long you’ll do so.

Choose the system-provided verification button that matches your use case and the visual design of your 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/wallet