Large Text in Mobile Apps: A Pre-Launch Test Checklist

Pick one complete journey, not a screenshot

Use a beta or dedicated test build you are allowed to test. Choose one important task and keep its starting records consistent between runs. For the fictional reading-log specification in this guide, a reader creates an entry, corrects a missing title, saves it, edits it and opens the saved result. No Moocsoft app has been tested as part of this example.

Agree on the intended behavior before testing. For example: an empty title produces a readable instruction, the user can correct it, and Save stores the completed entry. If that behavior has not been decided, write it as a product decision in the first-release checklist, not as a confirmed defect.

Record the exact build, device model, operating-system version, orientation and text setting. “Looks broken on mobile” is not enough to reproduce a layout state. Use fictional data and avoid collecting account details or personal notifications in screenshots.

Change system text, then note display size separately

Apple’s text-size instructions distinguish the regular Text Size control from the larger options under Accessibility → Display & Text Size → Larger Text. Use the settings available on the test device and record the chosen position; do not assume every app supports every text-size behavior.

On Android, open the device’s font-size controls and test the largest available setting as well as the default. Menu names vary by device and system version. Android’s nonlinear font-scaling guidance explains that Android 14 introduced scaling up to 200%, with a curve rather than one multiplier for all text. A title and a small label need not grow by the same proportion.

Font size and display size or display zoom are different conditions. First change text alone, then add a separate display-size run if it is in scope. Record both settings rather than calling either one “200%”. A browser zoom demonstration on this website is not a simulation of the installed app’s system text behavior.

For a Flutter maintainer, check the current MediaQuery.textScalerOf API when reviewing custom text measurement. Do not assume that multiplying every dimension by one text-scale number reproduces a nonlinear layout. The acceptance question remains practical: can the person finish the task?

Run this six-case matrix on each target setup

This is a proposed test matrix for the fictional task, not a claim of passing results. Copy it for each device/build/text-setting combination you actually intend to cover. Run the baseline first, then the larger-text case. Keep expected behavior, observation and status separate.

Try the error and keyboard states deliberately; they can need more space than a filled form. Include the longest relevant label or realistic translated phrase available in the project. Do not claim multilingual coverage from a single English string.

A long screen is not automatically a failure. Scrolling can be appropriate when it is clear and the required controls remain reachable. Record specific problems—clipped meaning, overlapping controls, a missing action or lost focus—instead of rejecting all wrapping or extra height.

If a validation error prevents saving, test its layout and report that outcome. Do not label the persistence step passed without a saved record to reopen. Likewise, seeing an entry after reopening does not establish that every label was legible.

Write one observable issue and a safe retest note

Describe the state and action that expose the problem, rather than diagnosing a widget or framework. Use the mobile app bug report template for a detailed issue. The short record below is intentionally blank: replace fields with what you observed, not with the expected result.

If Save is hidden behind a keyboard, say which field had focus and whether scrolling made it reachable. “Save is unreachable while the notes field has focus” is more actionable than “Large text breaks the app.” Attach only the evidence needed through the project’s approved private feedback route.

Retest the original steps on the changed build, then a nearby state such as the same form without an error. Keep the device and settings recorded. Do not uninstall a production app, erase its records or repeat a payment to recreate a layout problem; ask the maintainer for a safe test setup.

Know what this check does not cover

A large-text pass is one part of usability testing, not an accessibility certification. It does not prove screen-reader navigation, contrast, touch-target sizing, switch access or all device/language combinations. Flutter’s accessibility release checklist treats large text alongside other checks, including platform screen readers and actionable errors. Plan those separately.

Nor does this checklist prove that an app saves offline, handles camera refusal or syncs correctly. If those actions belong to the chosen journey, use a separate scenario such as the camera-permission test plan and identify which conditions you have actually tested.

For a handover, keep unresolved cases and coverage gaps visible: “tested on this build and device at these settings” is useful; “accessible everywhere” is not supported by this small matrix. Bring the journey, intended behavior and current evidence to your Flutter project discussion.