Sometimes, with large font sizes, there's no other way around it but to offer an alternative layout. Small tweaks are often enough. Otherwise, the text will be barely readable. Larger text shouldn't mean less content or a worse experience.

Apple music app. It shows a hypothetical case where the app scales text but doesn't change the layout. Only a few letters of the name of the song fit in each cell and there is no room for the name of the artist. In the other one, it shows how it actually works. The cover art comes above the text, instead of to the left, and the name of the song has three lines instead of just one. The code shows a way of doing this. You can override traitCollectionDidChange to get notified if the user changes the dynamic type size. In there, you can check the preferredContentSizeCategory from the trait collection, and it has a property called isAccessibilityCategory. In that case, you can offer an alternative layout.

One thing you can do is to check if the preferred content size category of a view is an accessibility category. And, in that case, move things around to make room for the text, offer more lines of text, etc.

https://developer.apple.com/documentation/uikit/uicontentsizecategory/isaccessibilitycategory

You may also find interesting...

Reminder to enable Larger Accessibility Sizes, so you can pick from one of the five extra accessibility sizes when configuring text sizes. You can do it from Settings, Accessibility, Display & Text Size, and Larger Text.

Anything representing a heading in the app should have the header trait. It allows for a faster way of exploring a screen and jumping to the part of the app you are interested in. Screens should also start with a header.

Hacks are accessibility’s worst enemy. An example. There is a ‘trick’ floating on the internet: if you want a button with an icon to the right of the text, set the semantic content attribute to force right to left. Great way to create focus traps.

Created in Swift with Ignite.

Supporting Swift for Swifts