Text + Text concatenation via Compose AnnotatedString

[vincentborko]

What

Implements Text + Text concatenation with per-segment styling on Android, rendered as a single Compose AnnotatedString.

static func + (Text, Text) was previously fatalError(), so any SwiftUI that builds a multi-style inline string by concatenation (per-segment color / weight / size / italic / monospaced / underline / strikethrough / gradient foreground) could not run on Android.

How

Both runtimes feed one ordered [TextRun] model, folded into a single AnnotatedString (each run's styling as a SpanStyle) and rendered by the shared _Text.Render path — so environment-level concerns (text alignment, line limit + truncation, tracking, line spacing, material3Text) behave like a normal Text, with no duplicated render logic:

• Skip Lite (transpiled) — a native + operator (Text.plus, // SKIP DECLARE: operator fun plus). A styled Text applies its style as an environment modifier that can't be read back at render time, so each operand's styling is captured as TextRunStyle data where the modifier is applied (.foregroundColor, .font, .bold, …), mirroring SkipSwiftUI's TextRun.
• SkipFuse — // SKIP @bridge public init(bridgedRuns:colors:fontSizes:fontWeights:flags:) accepts primitive-only per-run descriptors and folds them into the same [TextRun]. The foreground resolves to a solid color when it is one, otherwise a Compose brush (gradients via SpanStyle(brush:)). localizedTextString(), asColor, and asBrush are @Composable, so they're resolved in the @Composable scope before the (non-composable) builder lambda.

Note (supersedes the original draft): the native Skip Lite + operator is implemented here now. Earlier this PR left + unimplemented and reached the run model only via the bridge; it has since been unified so Text + Text works in both Skip Lite and SkipFuse through the one _Text-with-runs path.

Dependencies / pairing

• Requires Compose statement-level View operators (e.g. Text + Text) skipstone#255 — the transpiler fix that composes a bare, statement-level Text + Text. Without it, an unconstrained concatenation (e.g. directly in a VStack) is constructed but never composed (zero size); it only renders when wrapped in another view modifier like .frame(...).
• Pairs with Text + Text concatenation via a run model skip-fuse-ui#118 — the SkipSwiftUI side that captures styling as data and calls the bridgedRuns initializer.

Testing

Verified on an Android emulator (Showcase "Text Concatenation" playground): per-run colors, weights, sizes, italic/monospaced, underline/strikethrough, gradient foreground, and multi-line wrapping all render as a single flowing styled block — both bare/unconstrained and width-constrained.

---

• AI was used to assist with this PR.

🤖 Generated with Claude Code

[marcprux]

We might consider merging this work with #434 to support the + operator in Skip Lite as well as Fuse.

[vincentborko]

Nice idea, I'll update with the best of both worlds shortly! ;)

[vincentborko]

all working cleanly now 👍

[marcprux]

This looks good overall, but I'd love to see one or two test cases in SkipUI to demonstrate the concatenation.

[marcprux]

All of these #if SKIP additions aren't necessary: the #else condition if never used, since this package is never compiled or used in a non-SKIP context. You should be able to just change everything to use the return styled(…) rather than gating them within the #if SKIP blocks.

[vincentborko]

Added the two test cases in Tests/SkipUITests/TextTests.swift:

• testTextConcatenationLaysOutAsSingleString — Text("Hello") + Text("World") renders identically to Text("HelloWorld"), i.e. the concatenation is one laid-out string rather than two adjacent views.
• testTextConcatenationAppliesPerSegmentFont — a concatenation of .largeTitle runs draws at the same height as the equivalent styled plain text, so each operand's captured style reaches the SpanStyle instead of falling back to the environment font.

Both stack the two subjects in one VStack(spacing: 0) and compare the halves of a single pixmap, since the compose test rule allows one setContent per test.

Verified by mutation rather than by a green run alone, each case failing only for its own reason:

mutation	single-string	per-segment font
plus() drops the rhs runs	fails	passes
flattenedRuns drops capturedStyle	passes	fails

swift test is green on the unmutated branch: 63 tests, 7 skipped, 0 failures, including the transpiled Robolectric suite, with :SkipUI:compileDebugKotlin succeeding.

One observation from writing these, not addressed here: a concatenation of identically styled runs is a couple of pixels narrower than the equivalent plain Text, so it centres slightly differently — Text("A").font(.largeTitle) + Text("B").font(.largeTitle) against Text("AB").font(.largeTitle). The glyphs are the same size; only the advance width differs, and only once a font is set explicitly per run (the default-font case in the first test is pixel-identical). Native SwiftUI renders the two identically, so it looks like Font.system(size:) in the SpanStyle resolving to slightly different metrics than the environment font does through the material3 path. That is why the second test compares drawn height rather than the whole pixmap. Happy to look into it separately if you would like it addressed.

[vincentborko]

Correction to the note above: as first pushed, both cases failed the connected emulator step, and I have amended them to skip there.

They compare rendered pixmaps, so they run into the same per-emulator font rasterisation differences that testDrawMessage and testDrawTextMonospacedFont already opt out of in this file — on stable_default_28 the drawn height came out one row short of the reference (22 != 23) while rendering at the correct size. Both now carry the same guard and the same wording as the existing cases:

if isAndroid {
    throw XCTSkip("Disabled on Android due to inconsistent font rendering on different emulators")
}

So, precisely: the two cases execute natively and under Robolectric, and are skipped on a connected Android device or emulator. isAndroid is false on the JVM, so the Robolectric run still executes them in full — verified in the gradle report (tests=15 failures=0 errors=0 skipped=0, both cases with non-zero runtime), and the mutation results in the previous comment were measured there and still hold.

Everything else in that run was green on the emulator, including all eleven existing testTextSize* cases against the merge of this branch with current main, so the failure was specific to these two.