--- title: "Delete account? This action cannot be un..." source: "/writing/delete-account-this-action-cannot-be-un/" --- Article # Delete account? This action cannot be un... ## Designing for Dynamic Type in your iOS App Huy Mai November 9, 2026 That last word was "undone," but you probably filled it in without giving it a second thought. In this case, it was pretty simple. You've probably seen that dialog a hundred times; in many other instances, your users won't always have that advantage. Many truncated strings in a real world app are unfamiliar territory for users. They can be product names, a price total, or an important notice that cannot be missed. The title above is what happens when a user turns up their text size in an app that was never designed for it. The sentence still renders, but it's original meaning now changes or is completely lost. Subscription splash screen in the Citizen App at AX5. This is the splash screen you are met with when you open the Citizen App. You are prompted to subscribe to premium, _but you can't fully see the prices._ There's a secondary option to "Subscribe with A...." _Subscribe with what exactly?_ You decide this is too much information, yet too little at the same time, so you want to close this sheet. _Too bad, the close button is just off the screen at the top, and you can't scroll the page._ This is not a bug from a fringe user. This is a simple device setting that [roughly a fourth of people turn on and never turn off](https://appt.org/en/stats/font-size) . Designers can and will spend hours iterating on a design, perfecting the interactions and experience at the default text size. But the moment someone opens the app with larger text enabled, the carefully designed app falls apart. Buttons clip their labels, two-column layouts crush into slivers, and a title truncates to three words and an ellipsis. The solution to this problem isn't hard. Intentionality and a set of working habits are all you need to stop producing screens that break. This article explains what Dynamic Type actually is, why it deserves more attention than it usually gets, and how to design for it without doubling your work. ### What is Dynamic Type? Dynamic Type is an iOS system-level setting that allows users to choose their text size. This can be device-wide or at an individual application level. According to the World Health Organization [at least 2.2 billion people globally have a near or distance vision impairment](https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment) . Impairment is also not something that you either have or you don't have. The single largest contributor, which accounts for 826 million people, is presbyopia, the far-sightedness typically seen in the aging population. Scalable type allows your app to be usable for people who need text sizes beyond the default. Support for Dynamic Type may mean the difference between someone being able to use the app at all and someone else closing and deleting it entirely. Beyond accessibility, scalable type also allows for user preference. Plenty of users will increase type size to make text more legible. Others may go in the opposite direction and shrink text to see more content. Supporting Dynamic Type benefits all users, not just those with vision impairments. Users make a choice by setting their desired text size -- it's important that we honor that choice. ### How can we design for it? ### Start with the default scale Apple's default typography automatically supports Dynamic Type. You can reference the typography portion of Apple's [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/typography#Specifications) to see how each semantic style changes between sizes. If you're building your design system in Figma from scratch, you can copy the text styles directly from the [iOS and iPadOS UI Kit community file](https://www.figma.com/community/file/1651309003795292092/ios-and-ipados-27) . By no means do you need to stick to the default scale. But as scaling is not proportional, keeping Apple's semantic naming tells the system how to properly scale your title versus your caption. If your library needs an additional text style, annotate the nearest default style. This will allow your custom style to still scale at a proper rate. ### Build flexible layouts Nothing that contains text should have a fixed height. Containers should hug their content and let their content push them. Favor vertical stacking over horizontal stacking. Two elements that work side by side at default sizing may no longer work at AX5. If elements need to be horizontally stacked, determine and annotate what happens when they can no longer do so -- typically they become vertically stacked. In Figma, use auto-layout on all containers. Ensure there are not fixed values -- Figma can sometimes quietly convert settings if there are elements trying to reference each other. ### Maintain hierarchy beyond size Because headings grow slower than body text, type size becomes less of a distinguishing factor at higher accessibility sizes This can be factors like weight, color or opacity, spacing, or even a visual divider. These will continue to communicate hierarchy when type size does not. As a litmus test, set all your text sizes in Figma to their AX3 value (or higher). If you can't tell what's a heading anymore, there needs to be a stronger hierarchy. ### Deliberately choose wrapping over truncation Setting a text layer to truncate at default sizing typically reads fine. At AX5, the same truncation may show a handful of characters in a much longer message. Avoid using truncation unless there is a separate view where the full information can be seen. Truncation still may be the correct choice in certain applications, but it should be a conscious decision, not an accident. For example, a table row may become 10 lines tall if text is set to wrap. If you are using truncation, you should know how much you are hiding at the largest sizes. Stress test your truncation at larger sizes to see what information is being lost. ### Remember what doesn't scale on its own SF Symbols, Apple's native icon library, scales automatically alongside the text style they're paired with. Custom icons and raster images don't, unless explicitly defined. Without that, you get 53pt text sitting next to a 16pt icon. Annotate which elements should grow. Padding stays constant unless defined otherwise. Screen margins don't grow, but a gap sometimes should. Annotate these changes intentionally. ### Know what iOS handles for you You don't have to worry about everything. Native components like tab bar items, navigation bar items, toolbar items, and the status bar are examples of instances that don't scale at larger accessibility sizes. Instead, iOS shows a Large Content Viewer: a full-screen HUD with the item's icon and label when you touch and hold it. You'll never need to take extra time designing a five-tab bar at AX5 because it will never render that way. Other native components scale and reflow on their own. Alerts restack their buttons vertically when they no longer fit side by side. Large navigation titles collapse to the inline title. Menus scale and become scrollable. In SwiftUI, label-value rows in a List or Form stack vertically at accessibility sizes without anyone asking them to. It's important to note that this only holds true for native components. A hand-built row or a custom tab bar inherits none of it, which is worth considering the next time you are debating to build a custom component. ### Testing Your Designs ### Design at 4 sizes, not 1 Default, xxxL, AX5, and xSmall. xxxL and xSmall allow you to check behavior at both ends of the default type scale, while AX5 is the true stress test. ### Use the smallest supported device An iPhone SE has much less screen real estate than an iPhone 17 Pro Max. Smaller screens with AX5 will allow you to test the worst-case scenario a user could face. ### Use real content Always use realistic content over placeholder text like Lorem Ipsum. Finding and testing with the longest realistic string you can find helps determine where your designs fall short. In Figma, Apple's default text styles already have Dynamic Type built-in. Adjusting the Dynamic Type mode will let the text automatically resize. Adjust the Dynamic Type mode in Figma. ### Handoff Annotate and use semantic text styles, not pixel values. "Headline" tells an engineer everything, whereas "17pt semibold" only gets you the default sizing. Flag what's expected to grow and what's fixed. If you want icons to scale with a label, say so. If an avatar should stay at 48pt regardless, note that too. Any changes, or lack thereof, should be noted explicitly and intentionally. When reviewing designs in a real build, make sure you check sizes beyond the default: real text, real content, and real devices. Do all these things and users will thank you. People make an intentional choice to set a text size that works for them on their devices. For many of them, this is not just a choice, it's a necessity. It's important to be intentional about honoring that. None of this is foreign. It's mostly auto layout discipline, honest content, and the intentionality and commitment to look at your work at a size beyond the default. The screens you make will get used by people whose settings you'll never see. Design for them. - Huy Mai Product Designer [More from Huy](/team/huy-mai/) Huy Mai ### Tags [Accessibility](/insights/all/?topic=accessibility) [Digital Engineering](/insights/all/?topic=digital-engineering) [Experience Design](/insights/all/?topic=experience-design) [Mobile Apps](/insights/all/?topic=mobile-apps) [Product Engineering](/insights/all/?topic=product-engineering) [UX/UI Design](/insights/all/?topic=uxui-design) ### Share - Copied ## View these next. [See all](/insights/all/?type=writing) - [ Article I Ditched User Personas -- And Here's Why You Should Too Ali Joaquin ](/writing/i-ditched-user-personas-and-heres-why-you-should-too/) - [ Article The (best) way to perform online user testing with Principle Andy Davis ](/writing/the-best-way-to-perform-online-user-testing-with-principle/) - [ Article Design Audits: Adding One More Hat to the Product Design Haberdashery Chris Wodicka ](/writing/design-audits-adding-one-more-hat-to-the-product-design-haberdashery/)