There are a few accessibility settings you can check for, or get notifications in case these preferences change. This is especially important when developing custom components as they will mostly work with UIKit controls.

Calendar of Advent of iOS Accessibility. Day 21. Honoring users' settings. Display & Text Size Accessibility Settings Screen. There are two examples, Apple's podcast app playing an episode of Swift by Sundell and FaceTime. There are arrows pointing from some of these settings to how they take effect in these apps. When Reduce Transparency is on, in FaceTime you don't see the front camera being previewed and blurred in the background, instead, it is just opaque. When bold text is on, all text in both apps is bold. When Increase Contrast is on, the New FaceTime button is darker. When Button Shapes is on, the button for the podcast show or the playback speed (both consisting of just text with the app's tint color) is underlined so it is easier to be identified as buttons. The sleep timer button, which is an icon, gets some borders around it too. When smart invert is on, the artwork of the podcast doesn't get inverted.

You may also find interesting...

UIAccessibility is the cornerstone of any accessible UIKit app. Among others, understanding what an accessibility label, value, trait or hint are, is key. This is an example of how they could be configured for a custom rating component. #GAAD2022

You don't have to offer an alternative layout just for the accessibility category. You can actually compare content size categories. So you could tweak the UI already for anything equal to or larger than .extraExtraLarge, for example.

While you are at @shelly's "36 Seconds That Changed Everything", I would definitely also check out the Bonus Content. Including the full interview with @marcoarment. "Awareness is the biggest problem here." https://www.36seconds.org/behind-the-scenes/ "Cause iOS 7 was so inaccessible in so many ways (...) it started getting under developers’ radars this section of settings, called accessibility, that changes the way my app looks or works and I need to make sure that it doesn’t break under those settings.” "There’s so much variation out there. We no longer have just one size phone, we no longer have just one font size. It is easier for us as developers not to fall into bad assumptions of how I see it is how everyone is going to see it.” "The good thing about VoiceOver is that the accessibility framework is pretty well built-in the standard controls. For a given app you can fix any VoiceOver problems it has in one day or less. Even if it is a complex app. Even if it has a lot of custom controls." "What developers now do, if they care, is they treat that (accessibility issues) as if it was any other design flaw. If any other screen in your app broke visually or functionally you’d consider that a bug and you would try to fix it in the next update.” "I think the more that we can do as a developer community to talk about these features even existing, and these problems existing, and to tell people how easy it is to fix. That is the best any of us can do to help. Awareness is the biggest problem here."

Created in Swift with Ignite.

Supporting Swift for Swifts