Developers need text APIs that respect culture

Text APIs still carry habits from the Macintosh Toolbox era. A developer passes a string, selects a font, adds size and style attributes, then asks the system to measure or draw the result.

That model served Latin desktop software for decades. It now strains under emoji, OpenType features, mixed scripts, compact screens, and AI systems that generate long passages with structure and tone. Text reflects culture, and users bring culture into software through names, dates, units, scripts, symbols, and writing direction.

Developers need APIs that treat text as shaped, contextual material, rather than a row of code points with paint on top.

Grapheme clusters should replace code point thinking

Unicode code points give software a stable way to identify characters, yet users often see several code points as one symbol. A flag emoji can combine two regional indicators. A base letter can combine with a mark. A family emoji can combine several people with joiners.

A text API that lets a developer style half of a Swiss flag has exposed the wrong unit. The browser may show a broken flag, or it may apply italic style to one regional marker. The user sees an error because the system allowed an operation that had no cultural meaning.

The Unicode Consortium defines extended grapheme clusters to solve that boundary problem. Swift moved in that direction by treating String as a collection of characters that match user-perceived characters rather than raw code points. Developers still need access to scalars for parsers, encoders, and diagnostics, but user-facing text editing should use grapheme clusters as the default unit.

That change affects selection, cursor movement, deletion, styling, spell check, search, and accessibility. A user who presses backspace expects the system to remove one visible unit. A developer who highlights text expects the highlight to respect the same boundary. APIs should make the correct operation easy and force code point access to look intentional.

Rich font features need first-class controls

OpenType gives fonts a broad feature system: ligatures, alternates, small caps, color glyphs, variable axes, and script-specific substitutions. Many UI frameworks expose a thin subset because most application code treats font choice as family, size, weight, and slant.

Font creation tools now reduce the cost of building large feature sets. Designers can generate alternates, interpolate axes, and test scripts with more automation than past font workflows allowed. As feature-rich fonts reach more products, developers will need APIs that list, select, preview, and combine those features without relying on private font knowledge.

A font based on the Codex Gigas could expose decorated initials, scribal abbreviations, spacing variants, and script-specific forms. A UI toolkit that treats those details as invisible loses expressive power. A layout engine that can inspect them can choose variants based on space, contrast, locale, and user preference.

Developers need feature introspection

A style request should return evidence. If a developer asks for italic on text that contains emoji, Chinese characters, and Latin letters, the API should tell the developer which clusters changed and which clusters kept their base form.

The same need applies to color, title case, width variants, accessibility contrast, and vertical layout forms. A request for emphasis may map to slant in one font, weight in another, color in a terminal, or a mark in an educational script. HTML started with semantic tags such as strong and em, but browsers and authors narrowed those concepts into visual conventions.

A modern API can separate intent from implementation. The developer can ask for emphasis, contrast against a blue surface, or a compact label. The renderer can return the chosen font features and a confidence signal. That contract helps component authors build controls that adapt without guessing.

Text components should adapt like layout components

UI frameworks let containers stretch, wrap, shrink, and reflow. Text elements still often expose a width, a line height, and a wrapping mode. That rigidity forces developers to truncate labels, squeeze spacing, or ship separate strings for narrow surfaces.

Fonts can offer better choices. Zapfino on macOS includes alternates that change a word’s width without changing its content. A compact form and an expanded form of the same name can differ by dozens of pixels.

A serious interface font could expose the same idea with restrained shapes. A family emoji could use a wide lineup or a stacked arrangement. A fraction could use a diagonal form, a stacked form, or a slash form. The component would choose variants based on available width and height, then report the geometry it used.

Developers already ask layout systems to solve constraints. Text should participate in that negotiation as a component with internal choices, not as a fixed bitmap after shaping.

Subglyph styling exposes a representation problem

Users often treat a composed symbol and its expanded form as the same idea. A half can appear as 1/2, ½, or a MathML fraction. A developer can color the numerator in the expanded form, yet the single Unicode fraction blocks the same operation in many systems.

The same issue appears in dotted and dotless i, Arabic and Hebrew vowel marks, and Chinese characters with visible component structure. A teacher may want to color vowel marks in a Hebrew lesson. A dictionary may want to distinguish parts inside a Han character. A math editor may want a numerator to carry a style independent of the fraction bar.

MathML handles some of this because it represents the structure. General text APIs need a way to attach attributes inside a glyph or expose a decomposition layer that preserves user intent. Unicode alone does not solve this because Unicode encodes characters, not every layout relationship that readers perceive.

A robust API would let a developer ask for addressable parts, apply attributes to those parts, and fall back when the font or renderer cannot honor the request. The fallback should come with a report, so the app can choose a different representation or inform the user through the editor UI.

Rotation belongs in the layout contract

Chinese, Japanese, and Korean writing systems use vertical text. Devices also force narrow layouts: watches, bands, car displays, and foldable screens. Latin notifications on a tall, narrow display often look awkward because the text engine assumes horizontal flow and truncates the result.

CSS Writing Modes gives web authors tools for vertical flow, glyph orientation, and related behavior. Native UI APIs need comparable controls at the component level. A label could switch from horizontal to vertical flow based on width, orientation, locale, and user setting.

Glyphs need participation in that switch. CJK punctuation often changes orientation in vertical text. Flags may rotate in specific display contexts. Fractions may choose a stacked form to save width. A text run can act like a row or a column of glyph components, and each component can choose a form that fits the layout.

This requires measurement APIs that return multiple valid layouts. Instead of asking, "How wide is this string?" the developer should ask for a set of layouts under constraints, with the renderer explaining which substitutions, rotations, and line breaks it chose.

Language-aware formatting should move into text APIs

Applications often dodge grammar. A UI says received emails: 4 because a full sentence forces the developer to handle plural forms, cases, gender, politeness, date order, unit systems, and locale rules.

Internationalization libraries already help with plural rules, dates, numbers, and measurement units. ICU gives developers a strong base. AI systems add a new pressure: users now see software generate fluent language in context, so flat labels and awkward templates feel more exposed.

A future text API could instantiate a component from structured data: a count, a date, a unit, a person, a place, and a tone. The developer would choose constraints and allowed forms. The component could produce a short label, a complete sentence, or an accessible description, then give the app a structured record of the wording it generated.

That approach needs guardrails. Developers need deterministic output for finance, health, legal, and safety contexts. They need test fixtures, locale snapshots, and controls that prevent a model from changing meaning. AI can help generate templates and variants, but product teams still need review, versioning, and fallback strings.

Page layout needs a better native API

The web became the default page layout engine for software. Teams embed web views because HTML and CSS handle rich text, links, images, floats, ruby annotations, and reflow. The browser engine brings cost: large binaries, complex security boundaries, and behavior that app developers struggle to predict.

Native graphics APIs can catch up if they treat text and layout as one problem. A page renderer should accept a graph of nodes, constraints, annotations, figures, excerpts, and semantic text runs. It should handle line breaking, justification, hyphenation, ruby, notes, and variant selection while preserving accessibility and selection behavior.

LLMs make this need sharper. They produce long text with headings, lists, citations, code, tables, and out-of-band metadata. An app that renders that output needs more than a plain text view and more than a full browser. It needs a layout engine that can accept structured content, adapt it to the device, and expose the result to assistive technologies.

The trade-off: power versus predictability

Richer text APIs can create new failures. A renderer that chooses variants may surprise a designer. A localization component may produce a phrase that clashes with brand voice. A subglyph styling model may break copy and paste if developers treat visual parts as semantic units.

API designers can reduce those risks with inspection and control. Developers should be able to lock features, query substitutions, test locales, and choose deterministic paths. Text systems should expose the decisions they make because production software needs reproducible results.

The path forward starts with units that match user perception, then adds feature discovery, layout negotiation, and language-aware formatting. Developers can keep low-level access for parsers and editors, while UI frameworks guide most apps toward grapheme-aware, font-aware, culture-aware text.

Text has never been a neutral byte stream in the user’s hands. Users read it through language, device shape, script tradition, and typographic convention. Future APIs should let developers work at that level.