Typography in mobile applications: limitations and brand adaptation
System font versus custom font: where branding really loses
The first thing a team encounters is the choice between the operating system font (San Francisco for Apple, Roboto for Google) and a unique brand design. Marketing usually demands the second: «this is our voice, we pay designers for it». Development answers the first — because the system font is already optimized for rendering, anti-aliasing, and power consumption of a specific device.
| Criterion | System font | Custom brand font |
|---|---|---|
| Loading speed | Instant, already in the system | Requires embedding a file, increases app weight |
| Readability at small sizes | Optimized by OS manufacturer | Requires hinting and kerning adjustments |
| Brand recognition | Low, a font «like everyone else's» | High, if the design is not distorted by the system |
| Support for Dynamic Type / accessibility | Built-in by default | Need to set up manually |
Practice shows: a fully custom font is justified for headers, logo in the interface, key screens — where there is little text and it works as a visual accent. Main interface text — buttons, lists, notifications — is almost always better left to a system font or its adapted analogue with similar proportions.
iOS and Android — not the same adaptation
Even experienced teams make mistakes here: they adapt the font once and apply it identically to both platforms. This is incorrect because the platforms have different text scaling logic.
| Parameter | iOS | Android |
|---|---|---|
| Unit of text measurement | points (pt) | scale-independent pixels (sp) |
| Mechanism of adaptive scaling | Dynamic Type — 12 pre-set style sizes (7 standard + 5 for Larger Accessibility) | Font settings in system Accessibility Settings, less strict grid |
| Minimum recommended base text size | 17pt (Body style) | 16sp |
| Tolerance to bold weights at small sizes | Average, strokes 'merge' earlier | Higher, due to Roboto/Skia rendering |
Minimum size: where branding ends and ergonomics begins
The brand font may look impressive on a banner with a 60px size and completely fall apart at 12px in a notification list. Thin strokes, decorative serifs, experimental ligatures — all of these are the first sacrifices in adaptation for the mobile screen.
- Body text in a mobile interface rarely goes below 14–16px — this is not an aesthetic choice, but a readability requirement at arm's length.
- Condensed variants of the brand font are almost always replaced with a wider version of the same typeface for small sizes.
- Letter spacing (tracking) for small sizes is usually increased by 1–3%, otherwise letters visually 'merge' on low-resolution displays.
Variable fonts as a working compromise
A variable font is one file that contains a range of typefaces along axes of weight, width, and slant. Instead of loading an app with five to seven static files (Light, Regular, Medium, Bold, Condensed), the team embeds one smaller-sized file and selects the needed variant programmatically.
For branding, this is not just a technical economy. A variable font allows you to subtly adjust the corporate typeface to a small point size—slightly wider, slightly lighter—without developing a separate file and without losing the brand's letter proportions. Not all brand font pairs support variability, and this should be checked at the stage of selecting the typeface, not after the logo has already been approved by the board of directors.
Accessibility: why a brand cannot ignore Dynamic Type
A user with poor vision increases the system font to 200%—and if the interface is rigidly tied to a fixed point size of the corporate font, the layout 'breaks': the text is clipped, buttons overlap each other. This is not a hypothetical situation—Apple and Google require support for text scaling as a condition for passing review in the stores for a number of app categories.
Proper brand adaptation does not involve just one fixed font size, but rather a system of proportions: a heading is always larger than the body text by a certain coefficient, regardless of the scale to which the user has zoomed in the settings. These are design tokens, not rigid pixel values.
How this looks in practice: a checklist for adaptation
- Check whether the brand font has a license for embedding in a mobile application — a web license and a desktop license are different rights.
- Evaluate the font file size: if it pulls in 300–500 KB for each style, discuss with developers a variable version or a subset (trimming unused characters).
- Determine where a custom font is used as an accent (headings, onboarding, splash screen), and where it is better to switch to a system or adapted analog (main interface text).
- Set up support for Dynamic Type / font scaling at the level of the design system, not point-by-point on each screen.
- Test readability on real devices with low pixel density — an emulator distorts how a thin style is rendered.
The bottom line is simple and not the most pleasant for those who want 'everything exactly as in the brand book': a mobile application is not required to be an exact copy of printed materials. The goal is to preserve the character of the font where it actually works for recognition, and without regret let it go in favor of readability where usability is at stake for users with poor vision or slow internet.
System font versus custom font: where branding really loses
The first thing a team encounters is the choice between the operating system font (San Francisco for Apple, Roboto for Google) and a unique brand design. Marketing usually demands the second: «this is our voice, we pay designers for it». Development answers the first — because the system font is already optimized for rendering, anti-aliasing, and power consumption of a specific device.
| Criterion | System font | Custom brand font |
|---|---|---|
| Loading speed | Instant, already in the system | Requires embedding a file, increases app weight |
| Readability at small sizes | Optimized by OS manufacturer | Requires hinting and kerning adjustments |
| Brand recognition | Low, a font «like everyone else's» | High, if the design is not distorted by the system |
| Support for Dynamic Type / accessibility | Built-in by default | Need to set up manually |
Practice shows: a fully custom font is justified for headers, logo in the interface, key screens — where there is little text and it works as a visual accent. Main interface text — buttons, lists, notifications — is almost always better left to a system font or its adapted analogue with similar proportions.
iOS and Android — not the same adaptation
Even experienced teams make mistakes here: they adapt the font once and apply it identically to both platforms. This is incorrect because the platforms have different text scaling logic.
| Parameter | iOS | Android |
|---|---|---|
| Unit of text measurement | points (pt) | scale-independent pixels (sp) |
| Mechanism of adaptive scaling | Dynamic Type — 12 pre-set style sizes (7 standard + 5 for Larger Accessibility) | Font settings in system Accessibility Settings, less strict grid |
| Minimum recommended base text size | 17pt (Body style) | 16sp |
| Tolerance to bold weights at small sizes | Average, strokes 'merge' earlier | Higher, due to Roboto/Skia rendering |
Minimum size: where branding ends and ergonomics begins
The brand font may look impressive on a banner with a 60px size and completely fall apart at 12px in a notification list. Thin strokes, decorative serifs, experimental ligatures — all of these are the first sacrifices in adaptation for the mobile screen.
- Body text in a mobile interface rarely goes below 14–16px — this is not an aesthetic choice, but a readability requirement at arm's length.
- Condensed variants of the brand font are almost always replaced with a wider version of the same typeface for small sizes.
- Letter spacing (tracking) for small sizes is usually increased by 1–3%, otherwise letters visually 'merge' on low-resolution displays.
Variable fonts as a working compromise
A variable font is one file that contains a range of typefaces along axes of weight, width, and slant. Instead of loading an app with five to seven static files (Light, Regular, Medium, Bold, Condensed), the team embeds one smaller-sized file and selects the needed variant programmatically.
For branding, this is not just a technical economy. A variable font allows you to subtly adjust the corporate typeface to a small point size—slightly wider, slightly lighter—without developing a separate file and without losing the brand's letter proportions. Not all brand font pairs support variability, and this should be checked at the stage of selecting the typeface, not after the logo has already been approved by the board of directors.
Accessibility: why a brand cannot ignore Dynamic Type
A user with poor vision increases the system font to 200%—and if the interface is rigidly tied to a fixed point size of the corporate font, the layout 'breaks': the text is clipped, buttons overlap each other. This is not a hypothetical situation—Apple and Google require support for text scaling as a condition for passing review in the stores for a number of app categories.
Proper brand adaptation does not involve just one fixed font size, but rather a system of proportions: a heading is always larger than the body text by a certain coefficient, regardless of the scale to which the user has zoomed in the settings. These are design tokens, not rigid pixel values.
How this looks in practice: a checklist for adaptation
- Check whether the brand font has a license for embedding in a mobile application — a web license and a desktop license are different rights.
- Evaluate the font file size: if it pulls in 300–500 KB for each style, discuss with developers a variable version or a subset (trimming unused characters).
- Determine where a custom font is used as an accent (headings, onboarding, splash screen), and where it is better to switch to a system or adapted analog (main interface text).
- Set up support for Dynamic Type / font scaling at the level of the design system, not point-by-point on each screen.
- Test readability on real devices with low pixel density — an emulator distorts how a thin style is rendered.
The bottom line is simple and not the most pleasant for those who want 'everything exactly as in the brand book': a mobile application is not required to be an exact copy of printed materials. The goal is to preserve the character of the font where it actually works for recognition, and without regret let it go in favor of readability where usability is at stake for users with poor vision or slow internet.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
