Users enlarge the phone font and buttons and amounts overlap in the app — does adding a "large text mode" switch fix it?

Conclusion: When users enlarge the system font and the app UI breaks, it's usually not because a dedicated "senior-friendly version" is missing, but because the layout uses fixed font sizes, fixed heights, and single-line truncation, leaving no room for text to stretch. Based on 2026 project delivery experience, font scaling has to pass through three layers at once: native layout, H5 pages, and third-party SDKs. Adding just one large-font theme typically covers only the home screen; once users reach lists, pop-ups, and payment pages, things still break. This suits existing apps that have received senior-friendly feedback or need to pass app store accessibility evaluations.

First, tell the difference: system font scaling vs. in-app font size settings

Many teams mix up two things: one is users enlarging fonts in the phone's system settings, and the other is the app running its own large/medium/small font sizes. The former affects every app that follows system fonts; the latter only affects your own app. If the app uses fixed dp/pt for font sizes, it won't follow when the system font is enlarged, and users feel "I changed it but nothing happened." If the app does follow system fonts but the layout isn't flexible, text collides as soon as it grows, and users feel "the accessibility work broke it."

• Android: use sp instead of dp for font sizes; avoid hard-coded layout heights so text can expand its container.
• iOS: commonly use Dynamic Type and preferredFont, together with adjustsFontForContentSizeCategory.
• H5: root font-size and rem affect scaling; fixed px widths tend to overflow horizontally once fonts are enlarged.
• Third-party SDKs: map, payment, customer service, and analytics pop-ups mostly don't follow system fonts — a common blind spot.

The test is simple: after setting the system font to a commonly used large step, core pages show no truncated text, no overlapping buttons, and list row heights expand automatically. Meet those three and you've passed the first gate.

A three-layer font scaling checklist

Based on common 2026 project delivery practice, font scaling can be broken into the native layout layer, the H5 and embedded page layer, and the third-party SDK layer. Font sources differ: the native layer is under your control, the H5 layer is affected by WebView and CSS, and the third-party layer is basically decided externally. Checking them all mixed together makes it easy to fix only the home screen and think you're done.

1. Native layout layer: check font-size units, fixed heights, single-line truncation, and constraint priorities. The acceptance bar: after text is enlarged, button height expands automatically without pushing into the next row. Prioritize flexible layout rather than hard-coding every font size for the sake of adaptation.
2. H5 and embedded page layer: check rem baseline, viewport, fixed px widths, and horizontal table scrolling. The acceptance bar: after font enlargement the page is still readable without horizontal overflow covering content. Align the H5 and native font systems up front.
3. Third-party SDK layer: maps, payments, customer service, and analytics pop-ups usually don't follow system fonts. The acceptance bar: at minimum, no occlusion and no crashes; where necessary, use an in-app independent font size or a native shell as a fallback.

Run those three from native to H5 to third party, because real H5 and third-party issues surface more easily once the native layer is fixed. Don't skip a layer, or there will always be a page type users find first after release.

How do you set the pass line for font adaptation? Acceptance criteria

Acceptance can't be a screenshot of the home screen. Following delivery habits, run the core flows at the system font's default, large, and extra-large steps: login, list, detail, form, payment, and pop-ups. Log issues at each step, then fix against a checklist instead of eyeballing a few pages.

• Text not truncated: titles, buttons, amounts, and statuses show in full, or are allowed to wrap.
• Controls don't overlap: buttons, inputs, and icons keep tappable areas without covering each other.
• Row height expands automatically: list items grow with text without covering adjacent items.
• Pop-ups don't overflow: confirmation pop-ups, permission explanations, and agreement pages can scroll to the bottom after font enlargement.
• Third-party pages don't crash: payment, map, and customer service pages remain at least usable and don't crash due to font enlargement.

A common counterexample: only the home screen screenshot is sent to the client saying accessibility is done, but after release the button text on the order page is truncated. Passing isn't "the home screen looks good" — it's that the core business flows still work under enlarged fonts.

Following the system, an in-app independent font size, or local enlargement — which to choose?

There are three common approaches in 2026; more isn't always better — it depends on app type and user expectations. Compare on four dimensions: implementation cost, coverage, user expectations, and maintenance cost.

• Follow system fonts: medium cost, good coverage on native pages, but H5 and third-party SDKs often lag; suits most utility, government, and financial apps.
• In-app independent font size: lower cost, affects only your own pages, and users read it as the app's own reading setting; suits content and reading apps, but may still not follow when the system font is enlarged.
• Enlarge only on specific pages: lowest cost, suits changing only the home screen or help page; but users feel inconsistency on other pages and tend to keep raising it.

Experience range: for an existing app of moderate complexity, a full font scaling check commonly takes 3 to 10 person-days; if the layout is heavily hard-coded and there are many H5 pages, it can reach 2 to 4 weeks. Estimate budget by actual change volume; quoting a full rebuild is not recommended.

Where it applies and where it doesn't

Font scaling adaptation suits projects that already have clear user feedback or evaluation requirements. If the app store runs senior-friendly or accessibility evaluations, or the industry itself requires accessibility, it's worth putting on the iteration list; if user feedback centers on "after enlarging the font I can't read it, can't tap it, text overlaps," then you can basically confirm you need to check layout flexibility.

• Worth doing: government, financial, and medical apps, or utility and content apps with a wide user age range.
• Worth doing: existing app iterations where the layout uses many fixed heights and single-line text and user feedback is concentrated.
• Not necessary: pure internal tools, or scenarios with very few users who clearly don't change system fonts.
• Not necessary: video- or game-first apps with very little UI text, where keeping the aspect ratio matters more.
• Not necessary: still in the prototype stage with pages not finalized — write with flexible layout habits first; no need for a separate large-font theme.

Boundary sentence: the investment in font scaling adaptation usually goes into flexible layout rework, not building a second app; if the original layout hard-codes many heights, rework costs will be noticeably higher than writing a new project with flexible layout from the start. So avoiding fixed heights from the start of a new project is often cheaper than fixing after release.

Common snags that stall delivery

It's common on projects for the client to get stuck at "we only tested the home screen after enlarging the system font." The usual approach: run the three-layer checklist first, then discover the order page button height is hard-coded and the H5 pop-up width is fixed, with rework concentrated in layout rather than font size. The cost shows up as concentrated user complaints after release, more rounds of revisions and releases, and in serious cases an emergency hotfix.

• Hard-coded heights: button height is fixed, so text overflows once enlarged.
• Single-line ellipsis: ellipsis truncates key information when text is enlarged, especially amounts and statuses.
• H5 with fixed px widths: horizontal scrolling or covering other elements once fonts are enlarged.
• Changing font size but not line height: text grows while line spacing stays the same, making reading cramped.
• Ignoring third-party pages: payment, map, and customer service pages don't follow system fonts and cover the action area when enlarged.
• Forgetting to test pop-ups: agreement and permission explanations can't scroll to the bottom when enlarged, so users can't tap confirm.

Delivery-floor experience: we once worked with a government app that received feedback only two weeks before its senior-friendly evaluation, with many pages and a tight schedule. The approach: run the three-layer checklist first, prioritize the native flexible layout and line heights, adjust the H5 rem baseline, and use a native shell as a fallback on the payment page; the result was that the core flows were usable under the large font step, at the cost of roughly 5 extra person-days and a release schedule pushed back a few days. The experience range here: core pages only commonly take 3 to 10 person-days, and a full overhaul can reach 2 to 4 weeks.

FAQ

Users only enlarge the font in system settings and the app doesn't follow — do we have to build a senior-friendly version?

Not necessarily. First check whether the app uses sp/dynamic type or fixed dp/pt; if font sizes are hard-coded in code, switching to follow system fonts is usually less work than building a separate large-font theme, and it doesn't change the existing look.

The app already has large/medium/small font settings — does it still need to follow system fonts?

A common approach is that the two don't conflict: in-app settings manage the app's own reading experience, while system fonts handle global accessibility. If in-app settings completely override system fonts, the app may be judged as not following the system in senior-friendly evaluations.

After enlarging fonts, do H5 pages and third-party SDK pages need changes too?

H5 can be improved with rem, viewport, and flexible layout; most third-party SDKs don't follow system fonts. The bar is no occlusion, no crashes, and scrollability after enlargement — not forcing every third-party page to grow.

How much time and budget should be reserved for senior-friendly font adaptation?

Experience range: checking core pages and adjusting flexible layout usually takes 3 to 10 person-days; if the original layout hard-codes many heights and there are many H5 pages, it can reach 2 to 4 weeks. Estimate budget by change volume; quoting a full rebuild is not recommended.

How can a new project avoid font scaling pitfalls from the start?

Write new projects with flexible layout: use scalable units for font sizes, avoid fixed heights, let list row heights adapt, and use relative units in H5. Before delivery, run the core flows at the system's large font step — cheaper than rework after release.

If the app is already live, first run the three-layer checklist at the system font's large step across login, list, detail, and payment, log the issues into a checklist, then estimate the change volume. Font scaling adaptation suits projects with senior-friendly requirements or concentrated user feedback about overlap; pure internal tools and minimal-text interfaces don't need the full set — just keep the core flows usable. When it's time to implement, verify item by item against official docs and the delivery acceptance checklist.