If you've ever tried shipping a single app to iOS, Android, and desktop, you've hit the same wall: native widgets feel right until you have to render anything more complex than a button label. The moment you need styled text — bidirectional scripts, font fallback, custom line breaking, accessibility, copy-paste — the "use the platform's stuff" strategy starts buckling. We dug into the technical reasons this happens and how the major frameworks have made different bets to work around it.
The Native UI Promise (And Where It Cracks)
The pitch for native cross-platform UI is appealing: write your business logic once, render with each platform's own widgets, get free system theming, accessibility, and rendering quality. Frameworks like Kotlin Multiplatform with native UI layers, or React Native's bridge approach, lean on this idea.
It mostly works for buttons, switches, lists, navigation bars — the boxy, predictable parts of an app. Each platform ships well-tested widgets with consistent behavior, and you can hand them off to the OS without worrying about per-pixel rendering parity.
Text is where the bottom falls out.
A Text view on iOS uses CoreText with system fonts, automatic optical sizing, dynamic type, and CoreText's hand-tuned line-breaking. The same component on Android renders through Android's TextView pipeline, which uses different shaping logic, different font metrics, different ellipsis rules. Set a paragraph in SF Pro on iOS and Roboto on Android with identical line-height and font-size values, and the result will not match: the line counts differ, the descenders sit differently, the kerning diverges. For a marketing app where text is decorative, that's tolerable. For a reading app, a chat client, or anything with rich content, the cracks become structural.
What Text Actually Demands From a Rendering Stack
Text rendering is not a solved primitive. To produce a paragraph that reads correctly, a framework needs:
- Font fallback chains — when a glyph isn't in the primary font (emoji, CJK, math symbols), the renderer needs to walk a fallback list. Each OS curates this list differently.
- Shaping — HarfBuzz or platform equivalents turn Unicode code points into positioned glyphs. Arabic, Devanagari, and Thai depend on context-sensitive shaping that varies subtly between engines.
- Line breaking — Unicode UAX #14 is a specification, not an implementation. Real systems handle hyphenation, hanging punctuation, and CJK rules differently.
- Bidirectional layout — mixing Hebrew or Arabic with Latin requires the Unicode Bidi Algorithm, and platform implementations have edge cases.
- Pixel hinting and subpixel positioning — fonts render differently on Retina iOS displays, sub-pixel-RGB Android LCDs, and high-DPI desktop monitors.
- Selection, cursor, and accessibility — the OS needs to expose runs of text for screen readers, VoiceOver, TalkBack, and IME composition.
If your "native" cross-platform layer hands text off to each OS, you inherit all of this for free — but you also inherit different layout outputs for the same string on every platform you ship.
The hidden cost: Every QA pass on a text-heavy native cross-platform app ends up being a separate visual pass per platform. Designers who haven't worked on multi-platform shipping consistently underestimate how much spec drift accumulates from text alone.
How Each Framework Picks Its Poison
Each of the major cross-platform UI toolkits has made an explicit, defensible bet on this tradeoff. Here's the rough taxonomy:
SwiftUI sidesteps the problem entirely by not being cross-platform — it commits to CoreText and inherits everything Apple builds.
Jetpack Compose for Android uses Android's text engine. Compose Multiplatform extends that to desktop and iOS by drawing through Skia, which gives you portability but means iOS text in a Compose app does not look or behave identically to UIKit text in a sibling SwiftUI app. JetBrains has been narrowing this gap with iOS-specific text fixes, but it isn't closed.
Flutter chose the opposite extreme: own the entire rendering pipeline. Flutter ships with its own font shaping, line breaking, and rendering through Skia (now migrating to Impeller). Text looks identical across iOS, Android, web, and desktop because Flutter does not delegate. The price is a multi-megabyte engine in your binary, and text never matches the platform's native widgets exactly — which sometimes surfaces in keyboard behavior and IME quirks.
React Native bridges to native components, so text rendering uses each platform's engine. That gives you fidelity per platform but means a paragraph laid out in React Native on iOS and Android will measure differently — a common source of "why is this list scrolling weirdly" bugs that only show up after a TestFlight build.
Choosing Your Tradeoff
There's no framework that gives you native widget behavior, pixel-identical rendering across platforms, and a small binary all at once. Pick the constraint that hurts least:
- You want the best per-platform feel and have engineering capacity for two UI codepaths: SwiftUI + Compose, with shared business logic in Kotlin Multiplatform.
- You want pixel parity across platforms and ship designs from a single source of truth: Flutter.
- You want maximum web-developer reuse and don't mind RN-specific quirks: React Native, ideally with the new architecture (Fabric / TurboModules).
- You're targeting Apple platforms only: SwiftUI, full stop.
Practical signal: If your app has dense reading content (long-form articles, chat threads, document editing), favor frameworks that own their text engine — pixel parity tends to beat native feel here. If your app is task-oriented (forms, lists, settings), native delegation usually wins.
The "native all the way" dream is real for everything except text. Once you accept that text is the place you'll pay a tax — either in engineering effort to align platforms, or in a heavier rendering stack — the framework choice reduces to which tax fits your team and product.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.