WWDC 22 Digital Design Lounge — Human Interface Guidelines

Design - Apple Developer
Find documentation and resources for designing great apps for Apple platforms.


I have a question about color.

On this page: https://developer.apple.com/design/human-interface-guidelines/foundations/dark-mode there's the advice "At a minimum, make sure the contrast ratio between colors is no lower than 4.5:1. For custom foreground and background colors, strive for a contrast ratio of 7:1, especially in small text."

I aim for high contrast as much as possible, but 4.5:1 is pretty limiting, and I don't think Apple always follows this rule themselves. Specifically I'm wondering about the systemColors such as systemOrange, systemMint etc, many of which have quite low contrast against white (i.e., in Light Mode). What is the intended purpose of these colours? Is it meant for text/SF Symbols? Because if so, systemMint comes in at 2.02:1 against white. Should we ever even use systemYellow? Or can we just rely on users turning on Increase Contrast if they need to? But maybe someone doesn't want to have to increase contrast for everything just so they can see that darn yellow text.

Any insight on the intended use of these systemColors would be greatly appreciated.

Awesome questions! I could take the next 45 minutes trying to answer. 🙂

In short, the rules about color contrast are a bit tricky, it’s not black and white (forgive the pun)

Higher contrast is always better but there are mitigating circumstances that make it OK to have lower contrast. For example, text size. The larger or bolder the font, the easier it is to read given the same color value.

But a color choice that works for large type can be too low contrast for smaller text.

The same applies for icons or glyphs (symbols): Finer features are harder to naturally harder to discern so boosting contrast is useful.

As for system colors, they don’t all work equally well in every circumstance. Orange or mint on a light background probably isn’t the best choice. Definitely not as legible as blue or purple.

I also feel like I could spend the next hour speaking about this 😅 so GREAT question. As you might know, the 4.5:1 contrast ratio comes from WCAG 2.0 guidelines. While WCAG 3.0 is still not officially "out" they have an improved way of calculating contrast that I find incredibly interesting: https://www.w3.org/TR/wcag-3.0/#visual-contrast-of-text.

I’m imagining a future accessibility feature that allows you to increase contrast per colour 😛😉

Hahahahah, yes. Providing high-contrast colors in the asset catalog is a good thing. 🙂 We do have some technical solutions after all. And of course the system colors provide high-contrast colors for free.

How can I measure contrast in my apps?

There are good tools online for measuring color contrast. Searching for “color contrast calculator” will return good results:




You're listing the nice looking ones – I've always used this  😅 https://webaim.org/resources/contrastchecker/

Xcode has a built-in Color Contrast Calculator. To open it:

  1. Open the Accessibility Inspector by choosing Xcode > Open Developer Tool > Accessibility Inspector.
  2. In Accessibility Inspector, choose Window > Show Color Contrast Calculator

Any design guidelines for EDR color on Apple platforms?

Mostly we just want people to add color profiles to their images. If we could do that, it’d be a huge win.

We don’t really have guidance specifically about EDR in the HIG. Might be some good documentation elsewhere on developer.apple.com but I’m not familiar with it.

In your guidance around colors, have you all started digging into color spaces like LCH and perceptual color contrast much yet? Maybe not something you can discuss yet but it's a super interesting area and trying to choose colors with a matching human perceptual contrast across the palette is super useful and something I'd love to see Apple push as well.

I also think it's a great area to explore! I posted this in another question but the WCAG 3.0 perspective on color contrast is fascinating and something that addresses our issues with how color contrast is calculated now.

Best Practices

Are there good examples that come to mind of intentionally breaking the HIG for good reason (after knowing it well)?

Great question! I think that starts coming down to the customization you'd love to do for the app. For example there's no hard and fast rule that you have to use SF Symbols, or Apple Typefaces or a specific aesthetic for your app (and that's even more true for games).Think of the HIG as a great "base" for what you're doing, and tailor the guidance based on what makes the most sense for your users!

Kathryn Y’s also done a great job at wording the language of the HIG so we rarely ever say "don't" or "never" unless that's really true.

What are best practices when designing an app that is cross platform? Should the app design's adapt to the respective OS' design guidelines e.g. HIG on iOS, Material You on Android, and Fluent on Windows, or stick with one for a consistent user experience across different platforms (even though it might look slightly out of place depending on the OS)?

The best approach is to follow the relevant platform conventions. Many of them exist because of how the hardware functions. So ignoring that leads to software that feels disconnected from the hardware.

Apps that are designed once for all platforms will never feel right everywhere.

I also wonder to what extent it's applicable to the web, especially considering seeing more web apps coming from Apple! I'll definitely share them with my team who insists on having the same design across different platforms (hamburger menus and FABs everywhere!)

It does apply, there are differences in conventions between web and apps.

Some of the difference are pretty easy to address. Like not using “Click this button” in an app that only runs on touch screen devices.

^ huge pet peeve! Also Android and iOS differ a lot in how "back" functionality works for example. So making sure that the design patterns follow system conventions helps quite a bit to not make your app feel like it's alien to the platform

Look I love a good FAB but only when I've designed for Android in the past! Thanks for the question @Willey hope that helps because yes, you can be 80%-90% consistent where you can but those platform details matter.

How do ADA-winning apps balance the best practices and standards in the HIG with the novelty that makes them...well...ADA-winning?

Well you hit on the two, sometimes opposing, forces that define ADA winners.

In my view, an ADA winner has to embody the spirit of the HIG, even if there are details that might not conform to the letter of the HIG.

But an equally important thing is the voice, or personality, of the app.

The categories that we introduced last year (2021) try to add a bit more substance and clarity around the qualities that define winning apps.

Can you elaborate on the voice/personality please?

I guess I just see those terms as representing two things — (1) a cohesiveness across the app — the app feels like a single experience, and is internally consistent, and (2) the app has a character or look or feel that is memorable.

Yes there's being consistent with the platform experience, and then there's taking that to the next level by differentiating your app/game as a stellar example of one of our categories. That means you don't necessarily need a visually-heavy custom branded app but you offer something by way of your design/UX that sets you apart (I'm thinking Slopes here as a great example of this).

The HIG for watchOS subscription paywall show buttons for T&C and Privacy Policy. But we cannot open these in a website like on iOS. What is the recommended way to show these, potentially very large, text elements on the Apple Watch?

This is a great question. The recommendation at this point is to display the T&C and Privacy Policy text in (likely very long) modal sheets or detail views on watchOS. If you haven’t already, can you file feedback for this?

Do you follow an 8-point grid? For example, Table row padding would be 16 on either side, but 44 in height? I understand tap states need to be large enough, but why not 48?

Yes, an 8-point grid is used in many circumstances. However, there are some exceptions. For example, layout margins are 16pt in compact size class but 20pt in regular…. 24pt would’ve been too much. Sticking at 16 would look too thin.

The grid is mostly about width, not height.

IIRC, the decision about 44pt goes back further than the use of an 8pt grid for layout.


Throughout the OS, there's often times when a temporary sheet appears at the bottom of the screen. For example, when connecting your AirPods to the iPhone - I've made my way through the guidelines and can't find any write ups about that view. Is this view actually just a "Medium sheet" that is styled differently?  

Yep, a medium height sheet is the closest system-provided element.

Curious what your pov is on link buttons, specifically buttons embedded within text content on native.  There are some cases where this type of treatment can make sense and then others where it feels like we’re just pulling over from web.  Do you have any formalized process around when to use and not use this treatment?

Good question! My sense is that links inline commonly get overlooked because (a) not expected in apps and (b) the color distinction is often too subtle. In general they should be avoided. But there are cases where it can work. One that comes to mind are “More >” links at the end of a paragraph of text where you navigate to a child view to see more. Or expand a partially revealed block of text.

But it’s almost always more clear to use a proper button or table row with a chevron.

Probably the biggest issue with link style buttons, especially when presented in context of other text, is that the tap target size is too small (not 44pt tall) so tapping accuracy is compromised.

I have recently come across a component that the native iOS Maps app uses to filter/refine searched results which I can't seem to find reference of in the HIG. I am not sure it if is a combination of a segmented controls and pull-down buttons.

Is this filtering component something that will be added to the guidelines in the near future?

I had also noticed during the WWDC Keynote on Monday that the updated Home app on iOS adopts a similar component with different functionality. So my question expands to this as well.

Toggle-able filters / buttons. Something like this may be the beginning of a pattern that is adopted across Apple apps, or these may be one-off solutions within particular apps. From a HIG POV, there is a bit of push-pull with this. If it turns into a pattern, and if that pattern is formalized as a specific element in a framework, that is typically the criteria for arrival in the HIG.

This is an interesting one, though.

Thanks for raising it.

Makes me realize that, for a concrete control like this, the HIG is relatively conservative; something really needs to be a component that is defined in a framework to get guidance at this level. But for bigger picture, experiential things, the HIG is a bit more predictive? Or proactive?

Outline views are in the HIG as being macOS only but the need for a nested outline can still occur on iOS. The HIG just says _not supported_ but that's from a control aspect. I've implemented them by using different list cell layout to provide a nesting but would welcome other suggestions. https://developer.apple.com/design/human-interface-guidelines/components/layout-and-organization/outline-views

This is a great question — we're aware of the need for better guidance around outline views on platforms other than macOS, and it's on our radar for an update over the summer.

I often struggle with trying to minimize the amount of submenus, while not making the interface look too bloated (especially since I work on photo editing apps that get somewhat complex). Do you maybe have some thoughts on how to balance those things (how many controls there should be visible at once, how many submenus deep you can go, etc)?

Not sure whether a Slack answer will even scratch the surface of this question, but I have a couple of quick thoughts.

(1) The person. Is this photo editing for … professionals? influences? some specific person? … I really would start here, even though it’s the obvious designery thing to say, because I think it helps shape what level of detail and density is appropriate.

(2) The platform will dictate your heuristics around detail and density. Designing for Mac and iPad, I would push the density, and try to deliver sets of controls as completely as possible — i.e., i’d try to avoid submenus, and where I had them, I would try to make them “similar” or at least similarly labeled across controls.

How do I know when a small button is ok? 🙂 Do I just need to ensure they have appropriate clearance of 44px all the way around to meet the guidelines?

It’s OK to have smaller button but you definitely want to have a tap area that extends to 44pts in height. So, yes, padding can be a factor. In general though, a physical background height of 44pt is a good idea. Even if the tap target is taller, users don’t know that. So they’ll naturally slow down to aim accurately.


With dynamic type is it expect that all text based content on the interface will scale? Is there a time where that's not appropriate such as in button containers?

Great question. It’s really not possible for ALL text to scale in some cases. Tab bars, for instance, don’t scale because text would truncate immediately which defeats the purpose. And there is an AX setting for showing the tab icon and label in a bezel on tap.

The general approach is to make sure all text in the content area / scroll views scales.

Text in fixed height elements (like tab / toolbars) is trickier.

Sparked by a previous thread, are yall changing any recommendations for when to use title-case vs sentence-case capitalization style?

Great question! Although the guidance is to use title case in components like button labels and menu items, it also comes down to stylistic choices for the text content within your app.

100%! And when it comes to the content within your app, it — and your style guide — is going to evolve over time. As folks in this channel noted, we decided to move to sentence case in the HIG after many years. :slightly_smiling_face: The most important thing is to be consistent — if you’re going to use title case for your content headers, make sure you’re doing that everywhere in your app. If you change that style, make sure you’re adopting it across the board. And final tip: Even if you largely follow the paradigms of a guide like AP or Chicago Style, it’s super helpful to maintain a separate personal style guide for your content — that way, you have a great reference document.


I'd love to know more about the process of evolving the HIG. How do you identify things that feel out of date and less relevant, as well as spotting new design trends within Apple that you feel need documenting?

This is a great question. Multiple things influence this. One is our work (in evangelism) with developers. Questions that we get during this work can often spark ideas for new areas of guidance, or new details to add to pages.

Another thing that influences the HIG is the work of our design and engineering teams, naturally. As the platforms evolve, there are needs to overhaul pages, or whole sections, to match the direction of the platform (or multiple platforms).

I am resisting the urge to point out the various sections that are in need of work now, although I’d like to illustrate the point I’m making by doing so.

+1 to what Doug said! We talk with so many designers throughout the year and for this particular redesign we reached out specifically to the community to get input on where we could improve the HIG.

What’s stayed the same in the HIG over the past decades?

Although many details have changed, I think it's the keen focus on keeping the user experience at the center of design that's at the heart of the HIG, from the earliest days to the present.

Yes the earliest HIG (I believe from 1977???) continually emphasized the human nature of computers. How computer should conform to people and not the other way around. We are still very much firm believers of this, but with more nuance on what that means ergonomically, inclusively, as a holistic experience.

Were there any topics/areas that were completely, or mostly rewritten? Any specific portions that you are most proud of that you'd really like to call out?

That's a great question! I want to say that almost every section was rewritten to take out old, missing, or revised guidance 😅 It was a huge haul.

Two sections that I personally love:

Inclusion: We're SO happy this page is here because it speaks not only to good design guidance but our values.

The new Platform pages: These are brand spanking new and give a nice overview of "getting started with designing for [ios/mac/etc]" that also speak to how many people use these devices and the considerations you need to have.

Because we were working with content that ranged in age from months to more than a decade (in a few cases), I'm certain that there were places where in rewriting, we made significant changes to the guidance. But honestly, I'm not sure I can point to specific ones offhand! 🧐

When filing feedback related to the HIG in Feedback Assistant, should it be under the “documentation” category or “design resources”?

First of all, thank you SO much for filing feedback!! For the HIG, please use the "documentation" category; for issues or requests related to Apple Design Resources, please use the "design resources" category.

Could you elaborate on any user research (quantitive or qualitative) processes the team uses to shape HIG guidelines?

(These questions are good!)

We meet with developers to ask them for feedback on existing content (qualitative). We also regularly talk with developers throughout the year about their apps and, in those conversations, common questions come up that we realize we haven’t really answered in the HIG (or videos). So those turn into ideas about how we can improve the HIG.

And the HIG is really a massive collective effort involving design and engineering teams throughout Apple. This HIG is the product of internal experiences where people had misconceptions or questions during the design process that we anticipate designer and developers will have once we ship new features.

Does the team do any old school, Bruce Tognazzini-style quantitative experiments when designing new features? I’m thinking of the equivalent of Fitts’s Law, but for touch.

Depends on the team! We always nerded out about that and other things (catmull rom) on the Prototyping team, but other teams keep their process more intuitive/empathy-based vs. scientific.

How long has the team been working on this huge HIG update?

The bulk of the work started late 2021 and ran to last Sunday or so! 😅 Seriously, this project has been our hearts for a long time and we're ecstatic to deliver this update.

Hahaha, yes we've been working on it consistently for about a year now!

Do the HIG and Apple Style Guide influence each other?

Yes! If you’re interested in knowing more about writing for apps, we have this session coming up tomorrow: https://developer.apple.com/wwdc22/10037.

Yes, definitely: Even though the use cases differ for these documents, both try to stay aligned with the other.


What are the key changes in the advice being given in the revised HIG, if any?

A lot of the content in the HIG carries through from previous versions. But a lot of the older content was adjusted for clarity and we removed things that no longer seemed all that relevant. It’s hard to go through all the specifics but pretty much every page needed to be edited.

We also started adding in new guidance for iOS 16, macOS Ventura, and watchOS 9 (though there’s still a lot more coming this summer.

One example I recall was the Buttons page. There was content in there about placard buttons and bezel buttons but those really aren’t used these days.

We also removed some of the content about full color icons in toolbars, for example, since that’s not something modern apps do all that much of.

We added a lot of new information in the Patterns section for things like Searching or Sharing. That kind of content was spread out in component pages previously and missed a lot of important information and context when it was tied to specific controls.

Another key change is in perspective: Rather than starting with guidance for an iOS experience, the revised HIG encourages designing the experience first and then adjusting it as needed to run great on each platform.

Is the latest version of the HIG the first time I've seen Apple adopt sentence case for headings?!

Ha! Nice catch 😁 We also use sentence-casing throughout the developer app.

Love the attention to detail! Also WWDC videos. It’s the future!

A web based HIG is great as documentation but right now—wanting to read the entire revised HIG—I want to reach for an ePUB that would keep track of where I’m up to, and lead me linearly from start to finish, to ensure I read the whole thing. Is an ePUB available, or is there another solution for this use case?

Thanks for the question! Could you submit this idea using http://feedbackassistant.apple.com? Right now there isn't mostly because we've found folks stop by the HIG because they're looking for specific documentation vs. reading it like a whole book.

Is there any design files or design system in Figma / Sketch?

We currently don't support Figma at this time but updates to the Sketch and XD libraries and templates are coming later this summer.

I’m a big believer in Human Interface Guidelines. However, I’d like to have some sincere feedback.

1. The all-new version seems dominated by texts. The older version contains a lot of illustrations and animation along with the content, and maybe it would be better to add more images and animation in the new version.

2. I’m so confused that even though this is an all-new version, there are still some images coming from macOS 10.x, with the design from Yosemite. Please update these images to the design after Big Sur.

Appreciate you feedback and we full agree. We have a huge list of to-do items when it comes to making illustrations for the HIG. We’re a small team and there’s a lot of pages. But this is a top priority for us. As is fixing all those old screenshots! It bothers us too 🙂

Yup we feel the same way! Luckily now that the redesign is out we can focus on these tasks and more exciting things we're planning! 🙂


What prototyping app would you recommend?

Such a good question. There are lots of good methods and tools out there that there’s really no one good answer. It depends on what you like. Principle, Figma, Sketch, XD, Keynote, paper and pencil... We use Sketch a lot at Apple. XD. Keynote.

That one you're fastest in!

Xcode and SwiftUI may also be great for prototyping.

Would the paper and pencil prototyping be used in the initial phase of the design process at Apple?

You bet! Some people love paper sketches first (me) others go straight to SwiftUI because they're lightning fast in it

It’s a super fun detail that the Design page on developer.apple.com changes colour. How many different looks are there?

Yep, six colors. They’re meant to be read in order matching the old 6 colors logo. Tells a little bit of a story about making a button.

Show Comments