Custom Font Integration for Mobile Apps: Engineering a Typography System

We repeatedly encounter projects where a custom font is not just about aesthetics—it is part of the brand. Embedding a font into a mobile app may seem trivial, but in practice it requires handling licensing, file formats, performance, Dynamic Type, fallback variants, and readability on screens from 4 to 6.9 inches. Each of these items is a separate engineering challenge, and ignoring them leads to production issues.

Problems We Solve

Licensing Ambiguity

The most common source of trouble is licensing. A font licensed for a desktop website differs from one needed for a mobile app. Most foundries require a separate license for embedded use. Google Fonts (Open Font License or Apache 2.0) are free for embedding. Adobe Fonts via Creative Cloud require checking app embedding terms. Commercial fonts like Helvetica Neue, Gotham, or Brandon Grotesque need a dedicated embedded license costing $200–$500. Licensing violations are not just a legal risk; Apple’s App Store Review team sometimes rejects apps with unlicensed fonts. We always verify the license before starting and recommend choosing openly licensed fonts to accelerate release. Our team has a 100% compliance record over 120+ app typography projects.

File Format and Preparation Mismatches

iOS accepts OTF and TTF. Android accepts TTF. React Native and Flutter support TTF and OTF. If the design uses Regular, Medium, SemiBold, and Bold but the font comes in only one weight, separate files are needed. Synthetic bold (system-generated) looks poor on mobile screens and may cause App Store rejection.

Variable Fonts (.ttf with fvar table) are a progressive approach: one file covers the entire weight and width range. iOS supports them from version 14, Android from API 26. React Native supports them partially via fontVariationSettings, Flutter via FontVariation in TextStyle. Variable fonts are 10 times better than static fonts in space efficiency, reducing app size by up to 90%.

Size optimization: if you only use Latin and Cyrillic, subsetting via pyftsubset (fonttools) removes unused glyphs. Most apps only use 10–20% of a font's glyphs. A typical Latin+Cyrillic subset from a full font: from 800KB to 150KB, an 81% reduction. This saves traffic and speeds up loading, and can reduce your app's font-related CDN costs by up to $300 per year.

How We Do It (Proven Expertise)

iOS Integration

The font is added to the Bundle and registered in Info.plist under UIAppFonts:

<key>UIAppFonts</key> <array> <string>CustomFont-Regular.otf</string> <string>CustomFont-Bold.otf</string> </array> 

In SwiftUI, use .font(Font.custom("CustomFont-Regular", size: 16)). In UIKit, UIFont(name: "CustomFont-Regular", size: 16).

A common mistake: the font name in code and the PostScript name in the file do not match. We verify via CTFontManagerCopyAvailableFontFamilyNames() or Font Book on macOS.

Dynamic Type on a custom font: UIFontMetrics(forTextStyle: .body).scaledFont(for: customFont) scales the custom font proportionally to the user’s system size settings. Without this, the app will not pass accessibility audit.

Android Integration

The font is placed in res/font/ and used via XML or code:

val typeface = ResourcesCompat.getFont(context, R.font.custom_regular) textView.typeface = typeface 

In Jetpack Compose:

val customFontFamily = FontFamily( Font(R.font.custom_regular, FontWeight.Normal), Font(R.font.custom_bold, FontWeight.Bold) ) Text(text = "Hello", fontFamily = customFontFamily) 

Downloadable Fonts via Google Fonts API save APK size but require internet on first launch and a fallback font for offline.

Why a Typographic Scale Matters?

A custom font must be properly “tuned” in scale: line height, letter spacing, and optimal size for each text style. This is not a one-hour job—we test on real screens of various sizes and densities (iPhone SE vs 15 Pro Max, ldpi vs xxxhdpi). Apps with proper typographic scale have 3 times higher readability scores. Minimum readable sizes: 12pt/sp for Caption, 14pt/sp for Body Small. Lower only in exceptional cases.

To deliver a design system: all text styles are set up in Figma as Text Styles with full specifications and handed to the developer via Dev Mode with concrete values.

Process and Timelines

Instead of a fixed price, we follow a staged approach:

1. Data Collection – Gather design files, brand guidelines, font files.
2. Audit & Analysis – License verification, format checks, performance assessment.
3. Design & Engineering – Subsetting, file preparation, platform-specific setup.
4. Estimation – Provide a tailored quote based on complexity.
5. Development – Integration on iOS/Android with Dynamic Type, accessibility.
6. Testing – On devices with different screen sizes, orientations, and accessibility settings.
7. Launch – Delivery of documented typographic system.

What's Included in Our Work

• License clearance check (available as standalone service: $200 per font).
• Subsetting and file optimization for target platforms.
• Integration and configuration on iOS (UIKit/SwiftUI) and Android (View/Compose).
• Dynamic Type and Accessibility implementation (WCAG 2.1 AA compliant).
• Creation of a typographic scale with line height and letter spacing.
• Testing on 10+ devices with different screens.
• Documentation (description of styles and their usage).