Type Scale Generator for Mobile Screens

Use a type scale generator workflow that starts at 17pt for iOS body text or 16sp for Android body text, then multiply upward five times to create no more than six sizes. Use a 1.2 minor-third ratio for dense product screens or 1.25 major-third ratio for editorial screens. Assign each size to one UI role, set body line height near 1.4–1.5×, and test every role with iOS Dynamic Type and Android font-size scaling before shipping.

Key takeaways

•Apple’s iOS Body text style uses a 17pt default size.
•Material Design 3 Body Large uses 16sp as its default size.
•A 1.2 minor-third ratio produces compact type steps for dense mobile UI.
•A 1.25 major-third ratio creates stronger contrast for editorial reading screens.
•Keep a phone-screen type scale to six steps so each token has one enforceable role.

This guide is for mobile UI/UX designers, founders, and engineers who already work with iOS and Android text styles.

Time: 20 minutes · You'll need: A calculator or spreadsheet with exponent formulas, An iOS screen frame and an Android screen frame, A device or simulator with iOS Dynamic Type controls, An Android device or emulator with Font size controls

What's on this page

•Choose the mobile type scale base
•Select a ratio for the screen’s reading density
•Map the font size hierarchy to six UI roles
•Test the typography scale app behaviour at larger text
•Publish the six tokens in design and code
•Reference table

•Common mistakes
•FAQs

Build a mobile type scale, step by step

1. Choose the mobile type scale base

Set the body-reading size before calculating headings. For an iOS-first screen, start at 17pt because Apple’s Body text style defaults to 17pt. For an Android-first screen, start at 16sp because Material Design 3’s Body Large style is 16sp. Keep the native unit in the implementation token: pt in iOS design specifications and sp for Android text.

Do not average the two values into a shared 16.5-size token. A design file may show equivalent visual sizes, but platform typography is tied to platform scaling behaviour. Make body copy your first token, such as body = 17pt or body = 16sp; then calculate display sizes from that token. This gives settings labels, descriptions, messages, and long-form reading a stable reference point.

Use a smaller base only for a constrained, secondary text role after validating it at enlarged user text settings. It is not a substitute for making a dense screen scroll.

Tip: Treat 17pt and 16sp as platform-specific starting points, not as a demand for pixel-identical rendering.

2. Select a ratio for the screen’s reading density

Choose one ratio for a screen family. Use 1.2, the minor third, when the screen contains controls, values, chips, and short labels that need a restrained font size hierarchy. Use 1.25, the major third, when article titles, recipe steps, course lessons, or other editorial content need a clearer jump between body and headings.

Calculate each upward step with size = base × ratio^n, where n begins at 0 for body and ends at 5 for the sixth token. Round only after calculation. For example, a 16sp base at 1.2 produces 16, 19.2, 23.0, 27.6, 33.2, and 39.8sp. A 16sp base at 1.25 produces 16, 20, 25, 31.25, 39.06, and 48.83sp.

Do not mix 1.2 for one heading and 1.25 for another because it “looks better” in isolation. Change the role, weight, line length, or layout first; reserve a ratio change for a distinct content family.

Tip: Use 1.2 for a banking or settings app; choose 1.25 only when headings need to interrupt longer reading flow.

3. Map the font size hierarchy to six UI roles

Cap the system at six steps, including body. Six tokens are enough to distinguish navigation, labels, body, section headings, screen titles, and hero titles without creating arbitrary one-off values. Name the tokens by role rather than by number: label, caption, body, sectionTitle, screenTitle, and heroTitle are easier to review than type-1 through type-6.

Start body at step 1, then allocate the two smaller needs through weight or an approved smaller supporting style only when content requires it. For a six-step upward scale, a practical mapping is: step 1 body copy; step 2 prominent controls or card titles; step 3 section headings; step 4 screen titles; step 5 feature headings; step 6 hero or empty-state titles. A tab label does not need a seventh size; it should normally reuse a label token.

Set body copy near 1.4–1.5× its font size for line height. A 16sp body token therefore starts around 22.4–24sp line height. Tighten display text relative to body because large headings have fewer lines; check that ascenders, descenders, and diacritics do not collide.

Tip: If a role needs a unique size on only one screen, it is a layout exception to remove, not a new scale token.

4. Test the typography scale app behaviour at larger text

Test the same six roles with user text resizing enabled. On iOS, use semantic Dynamic Type text styles where possible; SwiftUI text styles such as .body participate in Dynamic Type, while custom UIKit fonts need adjustsFontForContentSizeCategory and a font scaled through UIFontMetrics. Do not lock a heading with a fixed visual size if it communicates essential content.

On Android, specify text in sp, not dp or px. The sp unit scales with the user’s font-size preference; in Jetpack Compose, TextUnit in sp incorporates the current font scale. Test the largest supported setting on a real device or emulator, then inspect a two-line title, a filled button, a bottom navigation label, and a settings row. Let text wrap or increase container height before reducing text size.

Check that body text still has roughly 1.4–1.5× line height after scaling, and verify that no essential label clips. WCAG 2.2 Success Criterion 1.4.4 requires text to resize to 200% without assistive technology or loss of content or functionality, except for captions and images of text.

Tip: At large text settings, a fixed-height 48dp list row is usually the constraint to change—not the user’s font size.

5. Publish the six tokens in design and code

Record each token with five fields: role name, iOS point size, Android sp size, line-height rule, and allowed use. For example: body / 17pt iOS / 16sp Android / 1.45× / paragraphs and descriptions. Put these tokens in the component library, then prohibit local type overrides in production components except for a documented accessibility or localization case.

Export the values into the code system used by the app: SwiftUI text styles or scaled custom fonts for iOS, and Material or Compose typography for Android. Preserve the role names even if the numerical values differ by platform. This avoids the common mistake of making a single pixel-based design token that ignores Dynamic Type or Android font scaling.

You can calculate the progression by hand with the formula in step 2, then use floow.design’s free Type Scale Generator at /free-tools/type-scale-generator to generate and export the same six-step scale to CSS, Tailwind, SwiftUI, Compose, or Flutter. Compare the export against your role map before committing it.

Tip: Version typography tokens with component tokens; a changed body size can alter every row height and modal layout in the app.

Reference table

Six-step compact mobile scale

UI role	iOS base: 17pt at 1.2	Android base: 16sp at 1.2
Body	17pt / 16sp	Step 1, n = 0
Prominent control	20.4pt / 19.2sp	Step 2
Section title	24.5pt / 23.0sp	Step 3
Screen title	29.4pt / 27.6sp	Step 4
Feature heading	35.3pt / 33.2sp	Step 5
Hero title	42.3pt / 39.8sp	Step 6

Do it with the free Type Scale Generator

Build a modular type scale sized for phone screens, and export it to CSS, Tailwind, SwiftUI, Compose or Flutter.

Open the Type Scale Generator → — free, no sign-up.

Common mistakes

Starting with an attractive hero size instead of the body-reading size.

Start at 17pt on iOS or 16sp on Android, then calculate upward. A hero-led scale often makes body copy too small or forces more than six tokens.

Using px or dp for Android text.

Use sp for Android text because it responds to the user’s font-size preference. Use dp for container dimensions, not for font sizing.

Keeping buttons and list rows at fixed heights when text grows.

Allow vertical padding and container height to grow, or permit text to wrap where the action remains understandable. Test at enlarged iOS and Android text settings.

Adding a new type size for every component variant.

Map components to one of the six named roles. Change weight, case, spacing, or layout before introducing a new size token.

Frequently asked questions

What is the best base size for a mobile type scale?

Use 17pt as the iOS body-text starting point and 16sp as the Android body-text starting point. Apple’s Body text style defaults to 17pt, while Material Design 3 Body Large is 16sp. Build headings upward from the platform’s body token rather than forcing a shared pixel value.

Which ratio should I use in a type scale generator?

Use a 1.2 ratio for dense mobile product UI and a 1.25 ratio for editorial mobile screens. The 1.2 minor third keeps labels, controls, and section headings closer together, while the 1.25 major third makes heading levels more visibly distinct. Use one ratio per screen family.

How many font sizes should a mobile app use?

A mobile app type scale should usually contain no more than six named sizes for a screen family. Six steps let you assign stable roles from body text through hero titles without creating component-specific exceptions. Smaller supporting text can be a documented role, but it should not trigger a new size for every component.

Does Dynamic Type work with a custom iOS font?

Dynamic Type can scale a custom iOS font when you scale it with UIFontMetrics and enable adjustsFontForContentSizeCategory in UIKit. In SwiftUI, prefer semantic text styles and use custom-font APIs that scale relative to a text style. Test the largest accessibility text size because line wrapping changes component height.

Why should Android text use sp instead of dp?

Android text should use sp because sp scales with the user’s font-size preference, while dp does not. A 16sp body token can therefore grow when a user increases Font size in system settings. Size containers in dp, then let the layout accommodate the scaled text.

Where this leaves you

A usable mobile type scale begins with the platform body size, not a headline chosen from a mood board. Use 17pt for iOS body text or 16sp for Android body text, choose 1.2 or 1.25 once, and stop after six named roles. That constraint makes design reviews faster because every title, label, and paragraph has an approved destination. It also makes accessibility testing concrete: each role must reflow under Dynamic Type and Android font scaling. Your next action is to calculate the six values from your chosen base, assign each one a UI role, and add those tokens to the app’s component library.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

•Placeholder Image Generator — Build placeholder images at any size as PNG, WebP or a sub-kilobyte SVG data URI — no third-party service.
•Font Pairing Tool — Try real Google Fonts pairings at mobile sizes, then export the type code for six platforms.
•Font Pairing Tool: Pair Fonts for Mobile Apps — Use a font pairing tool to select two mobile app fonts, test 13pt text on iOS and Android,
•Microcopy Generator Guide for Mobile Apps — Use a microcopy generator workflow to rewrite mobile buttons, errors and empty states with
•MVP Mobile App Design: From Concept to Clickable Prototype in One Day — A step-by-step guide to building your MVP mobile app prototype in one day using AI design