App font licensing needs to be checked in the release build before you ship. When a font licensing problem turns up on a website, you can change the CSS, redeploy, and remove the old font from every visitor's next page load.
An app doesn't work like that. App font licensing is a distribution problem. Every install puts a copy of the font file on someone's device, and you can't reach back in and remove it. You can ship a corrected build, sure, but the version with the unlicensed font keeps running on every phone that hasn't updated – for months, and often for years.
That's the argument for checking fonts before launch rather than after. A pre-launch fix costs you a build. A post-launch fix costs you a build, a store review, and a long wait while users update – and by then, how many copies you've shipped has become part of the conversation.
Why app distribution can affect the licence price
App font licences use several pricing models. Some are limited by downloads or distributions, some by monthly active users, and others by app title, licence term or a flat multiplier on the desktop price. MyFonts' standard app EULA can cap distributions, Fontspring prices its application licence by monthly active users, and Monotype's standard marketplace model prices by app title and year. Distribution can therefore affect the bill, but it isn't the only model.
How visible that figure is depends on the platform and the licence. Some stores expose public install bands, while other distribution data stays inside the developer's analytics. Apple, for example, puts official download and installation metrics in App Store Connect Analytics. If your app licence is priced on usage, its reporting clause matters more than whatever the store displays publicly.
Enforcement is a real revenue line, too, not an afterthought. Two foundries told Communication Arts, on condition of anonymity, that revenue from chasing violations might match what they earn from normal licensing.
How unlicensed fonts end up in apps
The uncomfortable part of an app font audit is how often the answer to "why is this font in here?" is "nobody knows."
Build configuration can include fonts you never display
This is the big one, and it surprises people. Build systems package resources according to target membership, resource declarations and optimisation settings, not according to a universal rule about whether a user ever sees them. On Apple platforms, a font included in the app target is distributed in the bundle. Unity includes the font data when its Include Font Data setting is selected. Android can remove genuinely unused resources when resource shrinking is enabled, so the result varies by project and release configuration.
A build tool may warn about an unused resource, but it won't warn that a bundled font needs a different licence. Apple's custom-font guidance explains how target membership controls whether a font is distributed, while Android's resource-shrinking documentation shows why the release configuration matters. Unity's own setting says that when font data is included, "the TTF is included in the output of the build." A font added in week three for a menu that later got cut can therefore still be sitting in the version you ship unless the build removes it or someone removes it deliberately.
SDKs, UI kits and templates bring their own
You didn't add the font, your dependency did. Purchased UI templates, component libraries, embedded SDKs and white-label themes can bundle icon fonts and full text families. Those arrive under their own licence terms, which may or may not permit redistribution inside your app and should be checked during dependency review.
The design handoff
A designer licenses a font for the designs under a desktop licence, hands over the files with the rest of the assets, and a developer wires them into the build. Nothing malicious happens at any step. The font file moves; the licence terms attached to it don't, which is the same gap that makes agency and client liability so messy.
Desktop and web licences usually don't cover apps
This is the most common gap of the lot.
Adobe Fonts does not permit embedding its fonts in mobile or desktop applications. Your Creative Cloud subscription lets you design the app; it does not let you put the font inside it. For that you need a licence bought directly from the foundry or an authorised reseller.
Major foundries treat app embedding as its own product category. On Monotype's licensing page, mobile app licensing sits separately from desktop, web, embedded, ePub, server and digital marketing uses. Buying one does not automatically get you another, in the same way that a desktop licence doesn't cover web use.
Pricing varies enormously between foundries, which is itself worth knowing before you commit to a typeface. TypeTogether, at the straightforward end, charges 3x the desktop licence price for perpetual app embedding rights for one app across all platforms and devices. Other foundries price by title, term, distribution or active users. The font you picked in week two can become an unexpectedly large line item, and you'll find out at the point where changing it is most expensive.
Open-source licensing can remove the need to buy a separate app-embedding licence, but it doesn't remove the licence conditions. The SIL Open Font License FAQ confirms that OFL fonts can be bundled and redistributed with commercial software. Distributed copies must retain the required copyright and licence information, and Reserved Font Names matter if you modify the font. Our guide to free fonts for commercial use covers which licences hold up.
What the font file says about embedding
OpenType font files can carry an fsType setting that records document-embedding permissions granted by the vendor. It is part of the font's own data, which means it can be checked automatically across every font in a build. It is useful evidence, but it describes document embedding rather than granting app-distribution rights.
Four values matter, defined in the OpenType specification:
| Embedding permission | What the foundry is saying |
|---|---|
| Installable | The font may be embedded and installed remotely, subject to its licence |
| Restricted licence | Don't embed this without written permission |
| Preview and print | The font may be loaded temporarily to view or print a read-only document |
| Editable | The font may be loaded temporarily to read, edit and save a document |
Restricted licence is the one to stop for. The specification's wording is blunt: the font "must not be modified, embedded or exchanged in any manner without first obtaining explicit permission of the legal owner." A foundry that restricts embedding in a document is unlikely to be relaxed about embedding in an app you distribute to millions of phones.
One caveat matters here. This setting does not replace the licence you agreed to, and a permissive document-embedding value does not grant app rights. The specification also makes vendors responsible for setting the bits correctly. It is a fast way to find questions that need review, not proof that an app use is licensed.
Font disputes over shipped software
Beijing's Founder Group sued Blizzard Entertainment and its Chinese operator The9 over five Chinese character fonts used in the localised version of World of Warcraft, initially seeking RMB100 million. According to The9's SEC filing, China's Supreme People's Court affirmed the judgment in May 2012 and the defendants were required to compensate Founder an aggregate RMB2.2 million. The final number came in well under the claim, but the case ran for years against companies with real legal resources, over fonts distributed in a shipped game client.
The app stores add a second layer. Apple's App Review Guidelines say apps should be submitted by the person or legal entity that owns or has licensed the relevant intellectual-property rights, and warn that apps using content without permission may be removed. A foundry complaint against a distributed app isn't only a legal exposure. It can become a distribution exposure once a rights holder starts asking questions.
A pre-launch font audit, step by step
1. Inventory the release build, not the project folder
Check the file you're actually shipping, not the project it was built from. Build processes move, strip, compress and rewrite fonts late on, so a test build and a release build can genuinely differ. What's in the project folder isn't the question. What's in the package you upload to the store is.
2. Separate the fonts you use from the fonts you merely ship
Platforms and frameworks record font registration in different ways: Apple's UIAppFonts, Android font resources and Flutter's FontManifest.json are common examples. A font registered or referenced there has stronger evidence of intended use. A font sitting in the package without that evidence is a different finding – maybe loaded dynamically, maybe a leftover nobody removed. Shipping the file still needs to be permitted by its licence, but absence of a declaration does not prove the font is unused.
3. Match every font to a licence that mentions apps
For each family, find the licence document and confirm it covers app embedding specifically, on your platforms, at your expected distribution. "We bought that font" isn't an answer. "We hold an app licence for two titles covering iOS and Android" is.
4. Check the embedding permissions
Read the embedding permission on every font in the build, and check anything restrictive against the actual licence before you ship.
5. Re-run it every release
Dependency upgrades add fonts. Designers add weights. A font that wasn't in build 47 can be in build 48 without a single line in the changelog mentioning it.
How FontReport audits app packages
FontReport Enterprise inspects app packages supplied through an authorised Google Drive folder scan. Put the final file you're shipping in the shared folder – an iOS .ipa, an Android .apk or .aab, or a supported zipped app bundle – and the fonts inside it appear in the same report as your website and PDF evidence.
The distinction that matters most before launch is the one above: fonts with registration or reference evidence, versus fonts that are simply present. For each font, the report shows that evidence and marks bundled-only files as possibly unused. That group is where the surprises live – the leftovers, the extra weights, the fonts a template brought with it.
It also reads each font's embedding permission. Where a foundry prohibits embedding without an explicit licence, that font is raised as the highest priority for review, because it's the clearest sign you need to talk to someone before you ship.
Some apps can't be audited completely, and it's better to know which ones. Certain game engines package fonts in ways that are difficult to inspect from the outside, and fonts an app downloads from a server while running aren't in the package to begin with. Where coverage is partial, the report says so, so you can see which apps got a full audit and which need a closer look.
For teams shipping regularly, the Enterprise dashboard tracks which app versions have already been scanned, so a new release gets checked rather than assumed.
Audit before you ship
The economics are simple. Before launch, an unlicensed font is a build change. After launch, it may mean a retrospective licence, a forced update, and a compliance conversation you're having from behind.
If you're preparing an app for release, put the final packaged build in a shared Google Drive folder and contact FontReport about an app-package audit. For teams managing several apps or shipping on a regular cadence, FontReport Enterprise covers app scanning across the portfolio.
The best time to find a font problem is while the fix is still just a rebuild.
