Mobile App Typography: Font Sizes, Scales and Pairings

This guide is for founders, developers, PMs and junior designers who want app text that's easy to read and looks intentional. You'll get the exact iOS and Android type scales, the units and rules behind them, how to pick and pair fonts, how to handle accessibility and localization, and a starter scale you can copy into your project today.

TL;DR: Start from the platform defaults: 17pt body on iOS (SF Pro) and 16sp Body Large on Android (Roboto or your brand font). Use 5–7 sizes with clear jumps between them, line height around 1.2–1.3 for headings and 1.4–1.5 for body text, and support Dynamic Type and Android font scaling so your layout survives larger text.

Why typography matters more on mobile

On a phone, text competes for a small screen, is read on the move, and is resized by users who rely on larger text settings. Good mobile typography does three jobs:

1. •Readability: people can read it quickly without zooming or squinting.
2. •Hierarchy: the size, weight and color of text tell users what matters first.
3. •Resilience: the layout still works when text grows, translates or truncates.

Units: pt, dp, sp and px

Mobile typography uses device-independent units so text looks the same physical size across screen densities.

In practice: design at 1x in Figma (for example a 393 × 852 frame for a recent iPhone), and a 17px font in your design is 17pt on iOS. On Android, a 16px font in a 1x design becomes 16sp. For screen sizes by device, see the device size reference.

The iOS type scale (Apple HIG)

Apple's system font is San Francisco (SF Pro), which automatically adjusts letter spacing and optical details for each size. Apple defines text styles that map to Dynamic Type, so they scale with the user's preferred text size. At the default "Large" setting:

Apple's guidance treats 11pt as the minimum legible size. If you find yourself going smaller, the content probably belongs elsewhere.

The Android type scale (Material 3)

Material 3 defines 15 styles in five roles. The default typeface is Roboto, but Material 3 is designed for you to substitute a brand font.

Display styles are for big, short numbers or hero text, and rarely appear on everyday screens. Most app screens use Headline Small or Title Large for screen headings, Body Large or Body Medium for content, and Label sizes for buttons, chips and tabs. Title Medium, Label Large and Label Medium use a medium weight by default.

iOS vs Android side by side

Notice Android's button text is smaller than iOS's. If you build one design for both platforms with a shared scale, pick values that sit between and test on both.

Building your own type scale

Platform scales are a great default, but brand apps often want their own. A type scale is a set of sizes generated from a base size and a ratio.

Choose a base size

Your body text is the base. Use 16 or 17 for most apps. Going smaller than 16 for main reading text makes long content tiring; going larger (18) suits reading apps, older audiences and accessibility-first products.

Choose a ratio

On mobile, steep ratios run out of room quickly: a 1.333 scale from 16 reaches about 38 after three steps. Many teams use a gentler ratio and then hand-tune the top sizes. You can generate and preview scales with the free type scale generator.

Round to whole numbers and cap the count

Round every size to a whole number (or an even number if you want it to align with an 8-point grid) and keep 5–7 sizes. Each extra size is another decision every designer and developer has to make.

A starter scale to copy

This scale works on both platforms with a 16 base and a ratio close to 1.2, hand-tuned:

Seven tokens, three weights. If you're on iOS only, swap body to 17/22 to match the system.

As code tokens, the same scale looks like this:

{
  "type": {
    "display": { "size": 34, "lineHeight": 40, "weight": 700 },
    "title1":  { "size": 28, "lineHeight": 34, "weight": 700 },
    "title2":  { "size": 22, "lineHeight": 28, "weight": 600 },
    "title3":  { "size": 18, "lineHeight": 24, "weight": 600 },
    "body":    { "size": 16, "lineHeight": 24, "weight": 400 },
    "bodyStrong": { "size": 16, "lineHeight": 24, "weight": 600 },
    "caption": { "size": 13, "lineHeight": 18, "weight": 400 }
  }
}

Line height, letter spacing and line length

Line height

• •Body text: about 1.4–1.5 times the font size (16 → 22–24).
• •Headings: tighter, about 1.1–1.3 (28 → 32–36). Large text with loose line height looks disconnected.
• •Buttons and single-line labels: set line height so the text box aligns to your spacing grid, often 20 or 24.

Round line heights to multiples of 4 if you use a 4 or 8-point grid. It makes vertical rhythm much easier to keep consistent.

Letter spacing (tracking)

SF Pro adjusts tracking automatically by size, so on iOS you usually leave it alone when using the system font. For custom fonts, a common pattern is slight negative tracking on large headings (around -0.5% to -2%) and slight positive tracking on small all-caps labels (around +2% to +8%). Never add tracking to body text.

Weights and hierarchy

Hierarchy comes from size, weight, color and spacing together. You rarely need more than three weights:

• •Regular (400) for body and secondary text.
• •Semibold (600) for headings, list titles and buttons.
• •Bold (700) for screen titles and key numbers.

Use color for the second level of hierarchy instead of another size. A common setup is primary text at full strength and secondary text at a lighter grey, both still passing contrast. On iOS, the system label and secondary label colors handle this, including in dark mode.

In dark mode, text can look heavier and slightly blurry due to light bleeding into dark backgrounds. Some teams reduce weight by one step for large text in dark mode, or use off-white instead of pure white to soften it.

Choosing fonts for an app

When to use the system font

The system font (SF Pro on iOS, Roboto or the device default on Android) is the safest choice for most apps. It's optimised for screens, supports many languages, has excellent numerals, scales with accessibility settings and adds no download size. Apps like Airbnb and Spotify use custom brand typefaces, but plenty of polished apps simply use the system font with strong hierarchy.

When a custom font is worth it

Choose a custom font when the brand voice depends on it (editorial, food, kids, luxury) or when you ship the same identity across iOS, Android and web and want them to look identical. Check before you commit:

• •Licensing: app embedding licenses differ from web and desktop licenses. Google Fonts are released under open licenses that permit embedding in apps; commercial fonts often need a specific app license.
• •Language support: does it cover every script you'll localise into?
• •Weights: at least regular, semibold and bold, ideally as a variable font.
• •Numerals: tabular (fixed-width) figures for prices, timers and tables, so numbers don't jump as they change.
• •Legibility at 12–13pt: many display fonts look great in headings and fall apart in captions.

Font pairings that work in apps

In apps, pairing usually means one font for headings and the system font or a neutral sans for everything else. Restraint wins.

Use the font pairing tool to preview combinations at real mobile sizes before deciding. If you'd rather see your pairing in context, you can generate full screens in floow with a heading and body font specified in the prompt and compare a few directions side by side.

Accessibility: Dynamic Type and font scaling

Large numbers of people increase their text size. Designing for it is not optional if you want your app to work for everyone.

iOS Dynamic Type

Dynamic Type lets users choose from seven standard sizes, plus five larger accessibility sizes if they enable them. At the largest accessibility setting, Body text grows to more than three times its default size. To support it:

1. •Use Apple's text styles (or scale custom fonts with them) instead of fixed sizes.
2. •Let labels wrap to multiple lines rather than truncating.
3. •Switch horizontal layouts to vertical at large sizes (for example, an icon beside text becomes icon above text).
4. •Don't put text inside fixed-height containers.

Android font scaling

Android users can scale fonts in system settings, and Android 14 raised the maximum to 200% with nonlinear scaling, so large text grows less than small text to avoid breaking layouts. Always use sp for text sizes, test at the largest setting, and avoid fixed heights on anything containing text.

Contrast

WCAG 2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18pt regular or 14pt bold and above). Light grey secondary text is the most common failure. Check every text color against its background with the contrast checker, in both light and dark mode.

Localization and real content

Text that fits in English often breaks elsewhere. German and Finnish strings tend to run long, while Chinese and Japanese can be much shorter but need larger sizes for complex characters. Arabic and Hebrew read right to left. Practical rules:

• •Design with real content, not "Lorem ipsum". Long names, large prices and two-line titles reveal problems early.
• •Allow buttons and tabs to grow or wrap; test with the longest language you support.
• •Avoid putting text in images; it can't be translated, scaled or read by screen readers.
• •Use the system font when you support many scripts, since it falls back gracefully.

Typography patterns by screen

Mobile typography checklist

• • Body text is 16–17 (pt or sp), never under 11 anywhere.
• • 5–7 sizes total, defined as tokens or text styles.
• • No more than three weights.
• • Line height about 1.4–1.5 for body, 1.1–1.3 for headings, rounded to your grid.
• • Text sizes use pt with Dynamic Type on iOS and sp on Android.
• • Layouts tested at the largest accessibility text sizes.
• • Every text color passes 4.5:1 (or 3:1 for large text) in light and dark mode.
• • Tabular figures for prices, timers and tables.
• • Custom fonts licensed for app embedding and cover all target languages.
• • Real, long content used in designs, including the longest translations.

FAQ

What font size should I use for a mobile app?

Use 17pt for body text on iOS and 16sp on Android, which match the platform defaults. Headings typically range from 20 to 34, and captions shouldn't go below 11–12.

What is the best font for mobile apps?

For most apps, the system font (SF Pro on iOS, Roboto on Android) is the best choice because it's optimised for screens, supports accessibility scaling and many languages, and adds no file size. Choose a custom font like Inter or a brand typeface when your identity depends on it.

How many fonts should an app use?

One or two. A single family with three weights is enough for most apps; if you add a second font, use it only for headings.

What's the difference between sp and dp on Android?

Both are density-independent units, but sp also scales with the user's font size preference. Use sp for all text and dp for everything else, such as spacing, icons and containers.

What line height should mobile text have?

About 1.4–1.5 times the font size for body text and 1.1–1.3 for headings. Round to a multiple of 4 if you use a 4 or 8-point spacing grid.

Design it with floow

Want to see a type scale on real screens? Describe your app on floow.design with the fonts and sizes you've chosen and refine the result through chat. Try: "Design an iOS reading app home screen and article screen using Fraunces for headings and SF Pro for body: 34pt bold large title, 22pt section headers, 17pt body with 1.5 line height, 13pt captions in secondary grey, supporting Dynamic Type."