Custom Fonts in Unity Mobile Games: From Import to Pixel-Perfect Text Rendering

You need a practical, mobile-safe pipeline that takes a .ttf or .otf through SDF atlas generation to crisp runtime text. This article on PlayMobile.online by George Jones gives a direct, hands-on route you can follow now.

Pixel-perfect here means consistent point sizing and sharp glyph edges across iOS and Android DPIs, not a magic checkbox. TextCore (the UI Toolkit renderer) leverages TextMesh Pro tech and SDF to keep text crisp at varied scales.

Expect an immediate working runtime FontAsset creation snippet in the next section, since that is where builds often fail. I will also call out three stacks you may use: TextMesh Pro in UGUI, UI Toolkit TextCore, and legacy UnityEngine.Font, each with different asset needs.

Throughout you will weigh performance tradeoffs: atlas texture memory, material count and draw calls, and runtime atlas rebuild cost for battery and thermals. The clear goal is a repeatable project structure and settings so fonts don’t vanish on device builds.

Runtime font asset creation from a file path (working, device-safe example)

Build a device-safe FontAsset at runtime by loading a source file and generating an SDF atlas on demand. The pattern below copies a shipped file to persistent storage (or reads StreamingAssets), checks the path, then calls CreateFontAsset with SDFAA so text scales crisply.

Use conservative defaults: samplingPointSize ≈ 60, atlasPadding ≈ 6, and start with 1024×1024; move to 2048×2048 only if you need many glyphs. Keep a strong reference to the created asset so the GC does not reclaim it.

using TMPro; using UnityEngine;
public class RuntimeFontLoader : MonoBehaviour {
  public TMP_Text targetText;
  FontAsset runtimeAsset;
  void Start() {
    string path = System.IO.Path.Combine(Application.persistentDataPath, "custom.ttf");
    if(!System.IO.File.Exists(path)) { Debug.LogError("Missing file: " + path); return; }
    runtimeAsset = FontAsset.CreateFontAsset(path, 0, 60, 6, GlyphRenderMode.SDFAA, 1024, 1024);
    if(runtimeAsset == null) { Debug.LogError("CreateFontAsset failed"); return; }
    targetText.font = runtimeAsset;
  }
}

• Pre-warm needed characters (ASCII, punctuation, currency) to avoid runtime stalls.
• Common failures: wrong path, file not included in build, access restrictions, overly large sampling sizes.
• Memory note: a 2048×2048 atlas can cost many MB; multiple atlases multiply that impact.

Atlas size	When to use	Tradeoff
1024×1024	Small UI sets, ASCII-only	Low RAM, fits most mid-range phones
2048×2048	Large glyph ranges, many languages	Higher memory, fewer atlases needed
Multi-atlas	Dynamic user fonts or UGC	Complexity and memory growth

Know which text system you’re targeting: TextMesh Pro, UGUI, or UI Toolkit TextCore

Decide on your target text system early so you don’t mix incompatible pipelines. Pick one path and keep its data types consistent to avoid runtime conversion and mysterious rendering failures.

How TextCore and TextMesh Pro relate

TextCore is a modern renderer built from TextMesh Pro concepts. It brings the same SDF approach and advanced styling across newer frameworks. That means workflows converge: the same SDF workflow gives consistent, crisp results across different rendering stacks and helps avoid surprises when you move content between editors.

When a UnityEngine.Font is acceptable

You can use a legacy Font for simple labels or quick prototypes. Expect fewer styling options and a conversion hit on first use, which shows up on slower phones. If you need scalable, predictable text at runtime, standardize on SDF type data instead.

• Map stacks: TMP components in UGUI, TextCore in UI Toolkit, and legacy UGUI/IMGUI using UnityEngine.Font.
• Feeding the wrong data type triggers conversion or broken rendering; keep types matched to components.
• Mixing systems often duplicates atlases and materials, which fragments batching and raises draw calls on device.

Use case	Recommended stack	Runtime type	Notes
Rich, scalable UI	TextMesh Pro in UGUI	textmeshpro font	Best SDF fidelity and styling control
Modern panel-based UI	UI Toolkit (TextCore)	SDF FontAsset via -unity-font-definition	Converged TMP tech, reliable styling
Simple labels / legacy screens	Legacy UGUI / IMGUI	UnityEngine.Font	Works but fewer styles and initial conversion cost
Runtime imports	Any stack needing runtime glyphs	Generate SDF FontAsset	Predictable scaling and lower runtime surprises

Rule of thumb: if you want crisp, scalable text in a predictable way, standardize on SDF FontAsset workflows. This minimizes cross-system friction and keeps draw calls and memory use under control on device.

Importing font files correctly for mobile builds

Before you open the Font Asset Creator, check how your source files are imported and where they live. Small differences in import flags and folder placement are what usually break text on devices. Do this once, not after a failed build.

TTF vs OTF in practical terms

Both TTF and OTF can work. Test on device. Hinting, advanced tables, and small-size rendering may differ across platforms, which can create artifacts at UI scale.

Inspector toggles that actually matter

Enable Include Font Data so the file ships with the build. Set Character to Dynamic if you expect runtime glyph growth. Static sets save memory but will miss characters if not generated.

Project layout and Resources expectations

Keep sources in Assets/Fonts/ and generated outputs in a clear folder, so references survive refactors. If you use Panel Text Settings default paths, place resources where the runtime expects them or the system will not find these entries.

• Avoid relying on OS fonts; vendors vary and fallbacks are inconsistent.
• Copy custom files into the Assets folder before generating outputs.

Item	Action	Why it matters
Source format	Test TTF and OTF on device	Rendering and hinting differ
Include Font Data	Enable	Makes file ship in build
Character mode	Dynamic for runtime growth	Avoid missing glyphs
Folder layout	Assets/Fonts & Resources/Fonts	Keeps references stable

Preflight checklist:

• Font file imported?
• Include Font Data on?
• Character set Dynamic if needed?
• Placed in Resources if defaults expect it?

Opening and using the Font Asset Creator in Unity

Start by launching the dedicated window that guides SDF atlas generation and material output. In the top menu go to Window > TextMeshPro > Font Asset Creator and open the editor panel. You should see fields for Font Source, Sampling Point Size, Padding, and buttons to Generate Font and Save.

Find the correct source and why drag-drop is safer

Drag the specific file from your Project view into Font Source rather than typing or picking by name. This prevents selecting a similar file or a fallback that lives elsewhere in the repo. A correct source avoids build surprises and missing glyphs at runtime.

What gets produced and what matters on device

When you generate font you get three outputs: a FontAsset, an atlas texture, and a material. The atlas texture stores glyph bitmaps. The material is what actually affects draw calls on device.

• Name outputs so duplicates are obvious. Example: FontName_UI_SDF_2048_Static.
• Keep one material per visual variant to limit extra batches and draw calls.
• Remember that more atlases and materials increase build size and runtime memory.

Output	Why it matters	Quick check
New Font Asset	Referenced by TMP objects	Assign to a TMP text and confirm rendering
Atlas Texture	Holds glyphs; affects RAM	Inspect size (1024/2048) and padding
Material	Drives batching and draw calls	Compare materials across scenes for duplicates

Sanity step: after saving, assign the new font asset to a TMP text object and type a test string. If you see missing glyph squares, regenerate with the needed characters or switch to Dynamic character mode.

Choosing Font Asset Creator settings for crisp SDF text

Focus on the settings that control how glyphs sample and pack into an atlas for crisp on-device text. Small, deliberate changes here give consistent edges and predictable memory use.

Sampling point size: why 50–70 works

Sampling changes how the distance field captures edge detail. It does not mean bigger is always better. Aim for a sampling point in the 50–70 range for most UI labels and menus.

Too large a sampling point reduces how many glyphs fit. The symptom is obvious: many characters are missing from the atlas during QA.

Font padding and the 1:10 rule

Padding reserves space for effects and the distance field. Start with a 1:10 ratio: sampling 60 → padding 6.

Too little padding clips outlines and glows. Too much wastes atlas area and increases texture memory.

Packing: Fast while iterating, Optimum for ship

Use Fast packing for quick iterations. Switch to Optimum before final builds to pack more glyphs into fewer textures and save RAM.

Render mode guidance

Prefer SDF modes like SDFAA for scalable text and stable edge quality across scale. Bitmap modes are only for fixed 1:1 text that never scales.

• Beginner pitfall: overly large sampling point causes missing glyphs.
• Quick test plan: generate an atlas, check mixed text (upper/lower, numbers, punctuation), then scale the UI up and down to watch for halos or edge break-up.

Setting	Recommended	Why it matters
Sampling point	50–70	Balances SDF accuracy with atlas capacity
Font padding	1:10 ratio (e.g., 60→6)	Prevents clipping for outlines and glows
Packing	Fast (iter), Optimum (ship)	Iteration speed vs final atlas utilization
Render mode	SDFAA / SDF	Scalable edges and consistent rendering across sizes

unity font asset creator mobile ui settings that directly impact performance

A single large texture can sink runtime performance. Cap your largest atlas at 2048×2048 for most devices. Use 1024×1024 as the safer default for standard menus and small text sets.

Atlas resolution: why 2048×2048 is the cap

Keeping atlas resolution under 2048×2048 limits RAM spikes on 3–4GB devices. A 2048 atlas uses four times the pixels of 1024, so only choose it when you must pack many glyphs in one texture.

Character set strategy

Your character set choice is the main memory control knob. Pick one of these approaches depending on scope:

• ASCII — fast prototype builds, minimal coverage.
• Custom Characters — tight, predictable sets for menus.
• Unicode ranges — planned language support, medium cost.
• Characters from File — import localization strings for precise coverage.

Memory math and screen constraints

Estimate RAM: pixels × bytes per pixel. Example: 2048×2048 × 4 Bpp ≈ 16 MB, plus mipmaps and overhead. Multiple atlases stack and quickly eat memory when scenes load.

High DPI screens do not always need bigger atlases if you keep sampling sizes and on-screen scale consistent. Tune sampling point size instead of blindly enlarging textures.

Battery, thermals, and runtime rebuilds

Dynamic atlas rebuilds cost CPU and texture uploads. Frequent rebuilding during typing or fast scene changes causes heating and can trigger throttling. If you see hitching while typing into a text field, you are likely growing or creating extra atlases—prewarm glyphs or limit allowed characters.

Setting	Recommendation	Impact
Atlas size	1024 (default) / 2048 (cap)	RAM vs glyph capacity
Character set	Custom or file-based	Controls texture count and memory
Rebuild frequency	Prewarm; avoid runtime growth	CPU, battery, thermal stability

Static vs dynamic font assets: the rule of “knowns” and “unknowns”

Separate what you control from what you can’t. Known strings—menus, HUD labels, and fixed dialog—should be baked as static assets to lock memory use and avoid runtime surprises.

Static atlases for menus and fixed UI strings

Use static when you have a limited set of characters and design. A static font asset gives a fixed memory footprint and no runtime atlas churn. That reduces CPU spikes and keeps play sessions stable.

Dynamic atlases for input fields and user-generated content

Choose dynamic for chat, player names, or downloaded text. Dynamic allows glyph growth but requires the source file to be reachable so new characters can be generated.

Build implications and a practical workflow

Rule: if you pick dynamic, include the source in the final build so runtime glyphs can be produced. If you bake static, the generated file can stand alone.

• Define “knowns” as controlled strings; bake them.
• Define “unknowns” as user input or UGC; allow growth.
• Assign one primary asset per UI domain and use fallbacks instead of stuffing everything into one atlas.

Use case	Choice	Why
Menus & labels	Static	Predictable memory
Chat & names	Dynamic	Flexible characters at runtime
Long sessions	Mixed	Watch for multi-atlas growth

Warning: multi-atlas textures can work for input screens but become a memory trap if you let them grow unbounded during long play. Plan what you bake vs what you let grow before you set font choices in production.

Creating a static TextMeshPro font asset with a tight character set

For menu text that must be reliable and light on memory, create a static textmeshpro font asset that only contains what your screens need. This reduces runtime churn and keeps load times steady.

Generate only what you need using Custom Characters

Open the Font Asset Creator and set Atlas Population Mode to Static. Choose Custom Characters and paste a curated list instead of a broad Unicode range.

1. Collect all menu strings and export them to one file.
2. Add punctuation, currency symbols, bullets, and any literal rich text markers you render.
3. Use a conservative sampling point (50–70) so characters fit the atlas.

How to avoid the “missing glyph squares” bug before QA finds it

Validate coverage by rendering every menu string on a debug scene. Log any missing glyphs and regenerate if you see placeholder boxes.

• Make sure the atlas contains every glyph used in your scenes.
• Share one material across menu elements to preserve batching.
• Keep one static new font per weight/style; only create extra materials for true visual differences.

Step	Why	Done looks like
Create static TMP asset	Stable memory	No runtime glyph growth
Generate with Custom Characters	Minimal atlas size	All menu characters present
Automated render pass	Catch missing glyphs early	Zero missing-glyph logs

Creating a dynamic font asset that grows safely during runtime input

When users type new characters, you need a predictable way to add glyphs without causing stalls. This section shows how to configure a runtime-growing text asset, test it on phones, and limit texture bloat so gameplay stays smooth.

Set Atlas Population Mode to Dynamic in the Inspector

Follow these exact steps in the inspector so builds can generate glyphs at runtime:

1. Create a TMP Font Asset and select it in the Project view.
2. Open Generation Settings and set Atlas Population Mode to Dynamic (this is the mode that allows runtime growth).
3. Confirm the source file reference is present so the build includes the glyph source and runtime generation works.

Test dynamic glyph insertion on device, not just in Editor

Build a small scene with an input field and deploy to a mid-range phone. Type a stress string: accented letters, rare symbols, and any allowed emoji or CJK characters.

Watch for frame hitches while typing. Desktop Play mode hides many stalls because your PC has faster CPU/GPU and different texture upload behavior. On phone, image uploads and texture creation can block the main thread.

When multi-texture growth is acceptable and when it’s a problem

Multi-texture growth (creating additional textures as glyphs appear) is fine for dedicated input screens or UGC flows. It is a problem during gameplay HUDs where hitching breaks immersion.

Use	Acceptable	Problematic
Chat / names	Allowed	Only if textures kept small
Gameplay HUD	No	Causes visible hitches
Profile images / UGC	Allowed	Monitor memory growth

Guardrails you should enforce: cap allowed character ranges, prewarm common glyphs at load, and monitor atlas count so the app does not quietly allocate multiple large textures. Also keep one shared style asset per region so designers’ styling choices do not multiply materials and break batching.

UI Toolkit setup: Panel Text Settings, Resources paths, and style sheets

Set up Panel Text Settings and Resources paths first so runtime text always resolves to the assets you expect.

Create a Text Settings asset and confirm default paths

Create the Text Settings asset via Create > UI Toolkit > Text Settings. Open the asset and verify the default resource path names it expects.

Keep the values unchanged unless you adjust folder layout across the project.

Organize Resources/Fonts & Materials and Resources/Text Style Sheets

1. Create exact folders: Assets/Resources/Fonts & Materials and Assets/Resources/Text Style Sheets.
2. Place your SDF font files, materials, and text style sheets in those folders so the runtime finds them.
3. Avoid random folders; misplacement causes silent fallbacks or unexpected typography at runtime.

Apply a FontAsset via UI Builder using -unity-font-definition

In UI Builder, set the font reference using the -unity-font-definition entry. This modern approach links TextCore SDF data correctly and keeps style references stable across panels.

Rich text tags vs Text StyleSheet assets for consistent styling

Rich text tags are quick for per-string tweaks. They are handy in prototypes.

Style sheet assets give consistent branding and reduce duplicated markup. Use them to centralize color, weight, and spacing rules.

• Performance note: fewer style variants means fewer materials, better batching, and lower draw-call cost on device.
• Verify at runtime: load a panel, inspect the applied style, and check that the expected resource path resolved to your chosen asset.

Action	Why it matters	How to verify
Place files in Resources folders	Runtime resolver finds assets	Build and confirm styled text renders
Use -unity-font-definition	Correct SDF link for TextCore	Open UI Builder and confirm font mapping
Use style sheets	Consistent appearance, fewer materials	Inspect material count in profiler

TextMesh Pro setup in UGUI: making pixel-perfect text actually happen

Start by locking a stable reference resolution and scaler rules. This gives consistent on-screen sizes and prevents shimmering when you test on different devices.

Canvas Scaler

Choose Reference Resolution, set Scale With Screen Size, and pick a match value that favors height for tall layouts or width for wide ones. Test on a small and large screen to confirm legibility.

SDF scale and point size

Keep sampling point in the 50–70 range so glyphs stay crisp. Scale text via layout transforms, not by regenerating atlases for each size. That preserves sharp edges across scales.

Material costs

Outlines and glow add overdraw and often require separate materials. Too many effect materials increase draw calls and break batching. Limit effects to titles and key labels; keep body text plain.

Troubleshooting checklist

• If text looks blurry, verify canvas scaling and reference resolution.
• Check sampling point and padding in the source font asset file.
• Avoid fractional scales; render at whole-pixel multiples when possible.

Setting	Recommended	Impact
Canvas mode	Scale With Screen Size	Predictable layout across resolutions
Sampling point	50–70	Crisp SDF edges, atlas capacity balance
Effect use	Titles only	Lower draw calls and better batching

Fallback fonts and weights without surprises

Plan fallbacks and weights early so your text behaves the same across scenes and languages.

Set fallbacks locally on a font asset when you need behavior contained to one menu or module. Local settings avoid global changes that suddenly affect other scenes. Use the global TMP Settings only when you truly want the same chain everywhere.

Real weights vs faked styles

Load real bold and italic assets for small on-screen text. Real weights preserve stroke balance and hinting. Faked weight or slant can look uneven or clip glyph corners, especially at small sizes or on high DPI displays. Reserve faux styles for prototypes, not shipped builds.

Localization and targeted fallbacks

Plan localization as a content step. Generate per-language subsets from your string tables so each build packs only required characters. Avoid one mega-atlas that bloats memory and slows startup.

• Design patterns: primary UI font asset + small targeted fallbacks (symbols, CJK, emoji).
• Keep fallbacks minimal and scoped to reduce extra atlases and memory pressure.
• When adding a new font, test that fallback chains resolve without swapping styles unexpectedly.

Verification step: render your top 200 strings in each language and confirm fallbacks never trigger unexpectedly.

Scope	Recommended use	Pros	Cons
Local fallback	Module-specific panels	Contained behavior, fewer surprises	Requires per-asset setup
Global settings	Project-wide defaults	Consistent baseline across scenes	Can cause unexpected scene changes
Per-language subsets	Localized builds	Small atlases, predictable memory	More build variants to manage
Single mega-atlas	All languages & weights	Single lookup, fewer runtime fetches	High memory use, long load times

Performance checklist for mobile UI text rendering

A short performance checklist helps you spot and fix text-related stalls before QA. Follow the quick checks below and apply the matching fixes when you see the listed symptoms.

Draw calls and material fragmentation

If you see many small batches or stuttering during scene load, do this: check how many different materials your text uses. Each extra material can break batching and raise draw calls.

Do Y: Consolidate styles, share materials across panels, and avoid per-label effects. Do X long-term: limit visual variants and prefer baked styles for common labels.

Overdraw and alpha-blended paragraphs

If long paragraphs or translucent text slow frames, you likely have heavy overdraw. Alpha-blended glyphs over complex backgrounds cost more on weaker GPUs.

Do Y: Use opaque backplates, reduce paragraph layering, or rasterize static long passages. Do X long-term: simplify backgrounds and limit transparent effects.

Atlas churn, GC spikes, and hitching

If typing or opening chat causes frame drops, that signals dynamic atlas updates and possible GC pressure. Frequent texture uploads heat the device and trigger throttling.

Do Y: Prewarm common glyphs at load, cap allowed ranges, and avoid regenerating atlases during gameplay. Do X long-term: scope dynamic growth to isolated screens and monitor atlas count.

Screen size and DPI strategy

If text looks inconsistent across phones, check your reference resolution and scaler rules. Mixed scaling or mismatched systems cause scaling chaos at different DPI settings.

Do Y: Pick one reference resolution, test on a small handset, and avoid fractional transforms. Do X long-term: standardize scaler rules and test lettering at target DPIs.

Symptom	Likely cause	Immediate fix	Long-term fix
High frame cost on menus	Multiple materials splitting batches	Share a single material across labels	Reduce style variants and bake common effects
Typing causes stutter	Dynamic atlas updates / texture uploads	Prewarm glyphs for expected characters	Limit dynamic ranges; preload common sets
Large paragraphs slow rendering	Excess overdraw from alpha text	Use opaque backplates or flatten text to sprite	Simplify layering and reduce transparency
Text blurs across devices	Inconsistent scaler or DPI handling	Test at target screen sizes and adjust sampling	Set a project-wide reference and validate per DPI

Final note: continuous atlas churn wastes memory, raises CPU and battery use, and can throttle FPS. Keep dynamic work scoped, prewarm where possible, and measure draw calls to keep performance predictable on real devices.

Common beginner mistakes with Font Asset Creator and how you avoid them

If text breaks on device but looks fine in the Editor, start with the checks below. These errors show up on phone builds as missing glyphs, stalled input, or large memory spikes.

Huge sampling size prevents glyphs from fitting the atlas

Problem: people crank sampling very high and the pack fails to include many characters. On device you see empty boxes or missing symbols.

How you avoid it: keep sampling in the 50–70 range and use padding ~1:10. Repack with Optimum packing if you need more glyphs, not a bigger sampling point.

Forgetting characters when switching to Static

Problem: switching to Static without a full list omits punctuation or localized symbols in a scene.

How you avoid it: collect all menu strings, export them, paste as Custom Characters, then render those strings in a test scene before QA.

Shipping redundant atlases per scene

Problem: multiple SDF outputs for the same style bloat memory and increase load times.

How you avoid it: standardize a shared file per weight and reuse it across scenes. Share one material when possible to preserve batching.

Relying on Editor-only or OS fonts

Problem: the Editor has local fonts that phones lack, so text falls back or vanishes on device.

How you avoid it: include the shipped font file in the build and add compact fallbacks for special ranges. Make sure the source is referenced so runtime growth works.

Misplacing assets outside Resources paths for UI Toolkit

Problem: wrong folder layout causes silent fallbacks at runtime.

How you avoid it: verify Panel Text Settings paths, place files under the expected Resources folders, and confirm in the inspector that references point to the intended asset before building.

Check	Why	Quick verify
Build contains font file	Prevents editor-only fallbacks	Inspect build output listing
References target shared asset	Avoids duplicates per scene	Search project for duplicate materials
No extra materials	Keeps draw calls low	Run profiler on device

Where to verify details in official Unity docs and what to bookmark

When you need authoritative references, go straight to the official Unity documentation. Bookmark the TextMesh Pro Font Asset Creator workflow and the UI Toolkit “Work with text” pages so you can check exact settings, menu paths, and folder conventions when you generate or troubleshoot text assets.

TextMesh Pro Font Asset workflows and the Font Asset Creator reference

Bookmark: “TextMesh Pro – Font Asset Creator” and “TextMesh Pro – Font Asset workflow” from the Unity docs. These pages list the menu path, recommended sampling/padding ranges, static vs dynamic modes, and how to set fallbacks. Use them for atlas generation and to confirm the exact inspector flags you must set before building.

UI Toolkit “Work with text” docs for TextCore, Panel Text Settings, and styling

Bookmark: “UI Toolkit – Work with text” and “Panel Text Settings” pages. They explain TextCore SDF behavior, the Resources folder layout, -unity-font-definition mapping, and Text StyleSheet usage. Use these docs when wiring style sheets, validating resource paths, and confirming how TextCore resolves assets at runtime.

TextCore/TMP convergence notes and practical pipeline impact

Unity’s docs and the TextMesh Pro tutorial note that TextCore and TMP are converging. That improves asset compatibility, but package and editor versions still matter. Verify your package versions before locking a pipeline.

Apply the “knowns vs unknowns” rule from the docs: bake static sets for controlled strings and allow dynamic growth only for user input. Keep a one-page internal pipeline doc in your repo with your chosen sampling, padding, and atlas caps so team members follow the same process.

Doc	What to bookmark	Why it helps
TextMesh Pro – Font Asset Creator	Menu path, sampling/padding, static/dynamic modes	Authoritative settings for atlas generation and fallbacks
UI Toolkit – Work with text	TextCore behavior, Panel Text Settings, Resources paths	Explains runtime resolution and style sheet mapping
TextMesh Pro tutorial	Practical steps, fallback chains, inspector flags	Hands-on examples to reproduce generation steps

Conclusion

.

Design your text pipeline like any other performance subsystem: cap textures, share materials, and preflight character sets.

Keep the “knowns vs unknowns” pattern. Bake static sets for menus and prewarm dynamic sets for input. Use one primary font asset plus small, targeted fallbacks instead of a single mega-atlas.

Remember that a font asset is a container: it owns an atlas texture and a material. Those two choices control crispness, memory, and draw calls.

On phones, follow blunt priorities: cap atlas size (1024 default, 2048 cap), reuse materials, avoid extra outlines/glows, and test dynamic glyph growth on real devices.

Final checklist before ship: verify files are included in the build, confirm character coverage per language, lock consistent canvas scaling, and ensure no atlas churn during gameplay. Revisit the TextMesh Pro and UI Toolkit docs and the linked tutorials while you work.