Font Licensing for Mobile Apps: What Most Teams Get Wrong

TL;DR

Most mobile apps contain fonts that were never cleared for app embedding. Desktop and web licenses do not cover distribution inside an .ipa or .apk. Foundries actively audit published apps, and the gap between what teams assume and what their license permits creates real legal and financial exposure. This guide covers how to identify risk, understand license types, and build a repeatable audit process.

Why font licensing matters for mobile apps

Legal exposure is real

Font licensing disputes are not hypothetical. NBC Universal faced a lawsuit from Font Bureau over the use of fonts beyond the scope of their license and settled for an undisclosed amount. Companies like Target have faced claims from foundries such as Berthold over embedding and distribution rights. Hoefler&Co and other foundries have pursued enforcement actions against companies exceeding their license scope.

These cases share a common pattern: the organization had purchased font licenses, but not the right kind of license for how the font was actually used.

App store review will not catch it

Neither Apple nor Google validate font licensing during app review. Their automated and manual checks focus on API usage, privacy compliance, and policy violations. A font embedded without proper licensing will pass review without issue and ship to millions of devices while creating ongoing legal exposure.

Foundries actively audit

Major foundries and their licensing agents routinely download apps from public stores, extract binaries, and scan for known font signatures. Font identification relies on internal font tables, glyph structure, and binary patterns rather than file names, so renaming a font file or stripping metadata does not prevent detection.

Font license types compared

License Type	Use Case	App Embedding	Modification	Typical Cost	Key Requirement
SIL OFL	Open source fonts	Permitted	Permitted	Free	Modified versions must not use the original font's Reserved Font Name without permission
Apache 2.0	Open source fonts	Permitted	Permitted	Free	Modified versions may be distributed under different terms, but the original Apache 2.0 attribution and NOTICE file requirements must be preserved
Desktop	Design tools, print	Not permitted	Varies	Per-seat	Does not extend to software distribution
Web (CSS)	Website embedding	Not permitted for apps	Varies	Per-domain or per-pageview	Scoped to browser rendering only
App / Mobile	Mobile app embedding	Permitted	Varies	Per-app, often install-based	License must match distribution model
CC-BY	Creative Commons attribution	Check specific terms	Varies	Free	Attribution required; not all CC licenses cover software embedding
CC-BY-NC	Non-commercial only	Not for commercial apps	Varies	Free	Commercial app distribution is not permitted
Proprietary	Varies by agreement	Only if explicitly granted	Rarely	Negotiated	Read the full agreement; assumptions are dangerous

How fonts end up in your binary

Understanding the entry points helps you know where to look.

Direct bundling

A designer specifies a commercial font, and a developer adds the .ttf or .otf file to the project assets folder. This is the most visible path and the easiest to audit, but teams often assume the existing desktop license covers it.

Framework defaults

UI frameworks and component libraries sometimes include font files. React Native, Flutter, and platform-specific UI kits may bundle fonts as part of their rendering pipeline. These become part of your binary through transitive dependencies.

Design system libraries

Internal or external design system packages may include font assets. When a team adopts a design system, the fonts come along without a separate licensing review.

Third-party SDKs

SDKs for analytics, chat, payment, or advertising sometimes embed custom fonts for their UI components. You inherit their font choices when you integrate the SDK.

Copy-paste from web projects

Font files from a web project get copied into a mobile project. The web font license (typically scoped to CSS embedding in browsers) does not cover distribution inside a compiled app binary.

Web, desktop, and mobile app licenses are not the same

This is the most common source of confusion. A single font can require three different licenses depending on how it is used.

Desktop licenses cover installation on workstations for use in design tools like Figma, Sketch, or InDesign. The output is static: PDFs, images, or print. The font software itself is not distributed.

Web licenses cover embedding via CSS (@font-face) for rendering in browsers. They are typically scoped by domain, pageviews, or monthly traffic. The font is served to browsers but not bundled into a downloadable application.

App or mobile licenses cover embedding the font file inside a distributed application binary. This is software distribution. Pricing is usually based on the number of apps, total installs, or monthly active users.

A desktop license and a web license together still do not cover mobile app embedding. Each is a separate grant.

Cross-platform frameworks note: If you use Flutter, React Native, Kotlin Multiplatform, or .NET MAUI, a single codebase may produce both iOS and Android binaries. Each platform's binary contains the embedded font. Verify that your app embedding license covers all target platforms and distribution channels.

How to audit your app fonts

Step 1: Extract your compiled binary

Work from the actual .ipa, .apk, or .aab file, not your source repository. The compiled binary reflects what users receive and may contain fonts that are not visible in your source tree.

Step 2: Inventory all font files

List every .ttf, .otf, and .woff file in the extracted binary. Include fonts embedded inside frameworks, libraries, and SDK bundles. Check nested archives and asset catalogs.

Step 3: Identify each font

For every font file, determine the font name, foundry, and version using the font's internal name table. Do not rely on file names, as they are often abbreviated or renamed.

Step 4: Map fonts to licenses

For each identified font, locate the applicable license:

• Open source fonts: verify the license file (OFL.txt, LICENSE) is present and the usage complies
• Commercial fonts: check purchase records for an app embedding license that matches your distribution model
• Unknown fonts: treat as unlicensed until verified

Step 5: Remediate and document

For any font without a valid app embedding license:

• Purchase the correct license from the foundry
• Or replace with an open-source alternative that meets your design requirements

Document your font inventory and license status. Keep it updated as dependencies change.

Ongoing monitoring

One-time audits go stale. Dependencies update, SDKs change, and new assets enter the project. AppCompliance detects fonts in compiled app binaries and maps them to foundries and license types, making it straightforward to catch licensing gaps before they ship.

Safe font choices for mobile apps

OFL (SIL Open Font License) fonts

The SIL Open Font License explicitly permits embedding in software, including mobile apps, at no cost. Modified versions must not use the original font's Reserved Font Name without permission from the original author.

Popular choices: - Inter, used by GitHub and widely adopted in modern UI design - Roboto, the default Android system font, maintained by Google - Noto Sans, extensive multilingual support across hundreds of scripts - Source Sans Pro, designed by Adobe for UI readability

Apache 2.0 licensed fonts

Some Google Fonts are available under the Apache 2.0 license. These are also safe for app embedding. Modified versions may be distributed under different terms, but the original Apache 2.0 attribution and NOTICE file requirements must be preserved.

System fonts

Using the platform's built-in system font (San Francisco on iOS, Roboto on Android) avoids embedding entirely. No font file is included in your binary, and no additional license is needed. The trade-off is reduced design control and platform-specific rendering differences.

Frequently asked questions

Do I need a separate license for each platform?

It depends on the foundry's terms. Some app embedding licenses cover all platforms; others are per-platform or per-binary. Check the specific license agreement.

What if a font came from a third-party SDK?

You are still responsible for everything in your binary. If an SDK bundles a commercially licensed font, verify that the SDK's license grants you redistribution rights. If not, contact the SDK vendor.

Are Google Fonts always safe for app embedding?

Most Google Fonts are licensed under the SIL OFL or Apache 2.0, both of which permit app embedding. However, always verify the specific font's license file rather than assuming.

Can I use a web font license for my mobile app?

No. Web font licenses are scoped to browser rendering via CSS. Embedding a font inside a compiled app binary is a different use that requires an app or mobile embedding license.

Does modifying a font change the licensing?

No. Modifying a font (subsetting, renaming, converting formats) does not change the original license terms. A modified commercial font still requires the same license. For OFL fonts, modifications are permitted but you must not use the Reserved Font Name.

What if I only use a font for a splash screen or single view?

The scope of use within the app typically does not change the license requirement. If the font is embedded in the binary, you need the appropriate license regardless of how prominently it appears.

How do foundries calculate damages?

Approaches vary. Common models include retroactive licensing fees based on the period of use, the number of installs, and the number of fonts involved. Some foundries also pursue statutory damages under copyright law.

Can I use free font download sites safely?

Exercise caution. Some free font sites redistribute commercial fonts without authorization. Always trace a font back to its original source and verify the license directly from the foundry or an official distribution channel like Google Fonts.