fix(ios): center TextInput text when lineHeight > fontSize on Fabric

[janicduplessis]

Summary

On iOS, when a TextInput has lineHeight > fontSize, UIKit anchors typed text and the placeholder to the bottom of the paragraph line box, and sizes the single-line caret to the full line-box height instead of the font height.

Before	After

fontSize: 16, lineHeight: 80. iOS 26 simulator, Fabric.

Why

The fix splits two ways because UIKit's draw paths don't all honor the same attributes:

Surface	Honors NSBaselineOffsetAttributeName?
Multi-line typed text (UITextView)	yes
Placeholder (single + multi, UILabel)	yes
Single-line typed text + caret (UITextField / UIFieldEditor)	no

• Multi-line typed text + placeholder: apply a baseline offset to re-center the glyph. Multi-line typed text reuses the existing RCTApplyBaselineOffset helper that <Text> already uses, so per-fragment fonts (nested <Text> with different fontSize) are handled correctly.
• Single-line typed text + caret: zero paragraphStyle.minimumLineHeight / maximumLineHeight per range on the attributed string handed to UIKit. UITextField then renders at the font's natural line height and its built-in vertical centering positions the glyph in the bounds; the caret rect — derived from the same line box — shrinks to match. Other paragraphStyle fields (alignment, indent) are preserved per range. The shadow node measures from TextInputState, so _updateState re-inflates stripped line heights from defaultTextAttributes before pushing — without that step the cell would shrink to the font's natural height after the first keystroke.

The typed-text fix lives in RCTTextInputComponentView._setAttributedString: (single Fabric entry point, preserves the _textOf:equals: early-return). The placeholder fix lives in _placeholderTextAttributes of each backing view.

Performance

When lineHeight ≤ font.lineHeight (common case): zero allocations — guarded out before any mutation.

Changelog:

[IOS] [FIXED] - Center typed TextInput text, placeholder, and single-line caret when lineHeight > fontSize.

Test Plan

RN Tester → TextInput → lineHeight baseline. Verified on iOS 26 simulator (iPhone 16 Pro / iPhone 17 Pro Max) on Fabric, including nested <Text> mixed-font cases. Confirmed cell height stays stable across edits.

Related: #38359, #39145, #53092.

[thanhnd1o2]

Looking for it

[github-actions]

Warning

JavaScript API change detected

This PR commits an update to ReactNativeApi.d.ts, indicating a change to React Native's public JavaScript API.

• Please include a clear changelog message.
• This change will be subject to additional review.

This change was flagged as: POTENTIALLY_BREAKING

[yefim]

Has there been any movement here? We rolled out Fabric recently and noticed that it's breaking all of our TextInput placeholders.

[janicduplessis]

Haven’t had any feedback on this, I would recommend to avoid line height as a workaround.

[yefim]

We ended up updating our TextInput wrapper to float a placeholder on top of the input.

function BaseTextInput() {
  // ...
  return (
    <View style={wrapperStyle}>
      {input}
      {hasPlaceholder && (
        <Animated.View
          style={[StyleSheet.absoluteFill, placeholderAnimatedStyle]}
          pointerEvents="none"
        >
          <Text style={placeholderStyle} numberOfLines={props.multiline ? undefined : 1}>
            {placeholder}
          </Text>
        </Animated.View>
      )}
    </View>
  );
}

[emmanuelchucks]

Tested this, and it fixes the issue in every case I tried. I didn't find any regressions.

Setup: current main (1c6e0c7) with this PR rebased on top. The only conflicts were the two RCTTextAttributes.h imports, which main has since removed. RNTester built from source, New Architecture, iOS 18.5 and iOS 27 simulators.

The test screen puts a Text, a TextInput with a value and an empty TextInput with a placeholder side by side, all with the same style (fontSize 16, paddingVertical 8). I measured how far the capital letters sit from the vertical centre of each box, in points; positive means too low. Text is within 0.33pt of centre in every case, so it's the reference. Each cell is typed text / placeholder:

	main	this PR
single-line, lineHeight 22	+2.83 / +1.50	+0.17 / +0.17
single-line, lineHeight 32	+12.83 / +6.50	+0.17 / +0.17
multiline, lineHeight 22	+1.50 / +1.17	+0.17 / -0.17
multiline, lineHeight 32	+6.50 / +6.17	+0.17 / -0.17
single-line, lineHeight 32, text size XXXL	+18.83 / +9.50	0.00 / 0.00

• Text renders exactly the same with and without this PR. Inputs with no lineHeight, or one smaller than the font's own, don't change.
• Georgia gives the same results, and iOS 27 matches 18.5.
• While typing, the text stays centred and the input keeps its height, also after typing an emoji. The caret is centred on the text: font height in single-line, line height in multiline.

Before (left) and after (right):

The caret with this PR:

I also tried the simpler fix first: adding the baseline offset to the input's text attributes, the way Text does with RCTApplyBaselineOffset. It fixes multiline and the placeholder, but single-line typed text only moves halfway (+6.50 at lineHeight 32). So handling UITextField separately, as this PR does, looks necessary.

We also backported this to our app on 0.88.0-rc.3 and built it from source. The chat input's text is centred without the manual offset we've been using, and typing an emoji doesn't change its height.

The test screen, if anyone wants to repeat this: https://gist.github.com/emmanuelchucks/40bc34ce0538ee6410b0455e4b5d4ad4