iOS 26.6 (23G71): app jetsam-killed at ~3.5 GB (per-process-limit) while typing in a multiline controlled TextInput; Auto-Correction/Predictive Text implicated (Fabric, 0.85.3)

[rptrainor]

Description

After updating a physical iPhone to iOS 26.6 (23G71, released 2026-07-27), our React Native chat app is killed by jetsam while typing in the chat composer (a controlled, multiline <TextInput>). Memory balloons to the per-process cap (~3.5 GB) within a single typing session and iOS terminates the app mid-keystroke. There is never a JS or native exception: no app-named .ips crash log is ever written, only a JetsamEvent log.

The same code, dependency lockfile, and build toolchain typed fine on the same device on 2026-07-24 on the prior iOS version (verified: the EAS build image, Xcode version, and every dependency were byte-identical between the working and failing builds). That points at an iOS 26.6 regression in the system autocorrect / predictive-text (QuickType) layer interacting with RN's Fabric TextInput, rather than app or RN code that changed.

Key data from the device's JetsamEvent log:

• reason: per-process-limit
• rpages 215,899 × 16 KB pages ≈ 3.5 GB footprint, with lifetimeMax equal to the value at death (the process died at its peak, i.e. monotonic growth)
• app state: active, frontmost (user was mid-typing)
• system memory not starved; no other process under pressure
• zero app-named .ips files on the device: never an exception, never a watchdog — always jetsam

Strong evidence for the autocorrect/predictive vector: with Settings → General → Keyboard → Predictive Text and Auto-Correction turned OFF, the same build types fine on the same device (verified on-device). We are shipping autoCorrect={false}, spellCheck={false}, and smartInsertDelete={false} on the composer as an app-side mitigation, which disables the same text services per-field.

Filing for visibility and searchability: any RN app with a chat-style multiline TextInput is likely affected as users update to iOS 26.6, and the failure mode (silent jetsam kill, no crash report, only reproducible on physical devices) is easy to misattribute to app code.

Steps to reproduce

1. Physical iPhone on iOS 26.6 (23G71). Keyboard settings at defaults (Predictive Text and Auto-Correction ON).
2. React Native 0.85.3 app (Fabric / new architecture, Hermes) with a controlled multiline <TextInput> (value + onChangeText), e.g. a chat composer.
3. Type continuously into the input (a few hundred characters, including words that trigger autocorrect/predictions), while the app does normal work (state updates per keystroke).
4. Watch the app's memory footprint (Xcode Debug navigator or Instruments): it grows unboundedly until the ~3.5 GB per-process limit, then the app is killed by jetsam.

The iOS Simulator cannot reproduce it: the newest available simulator runtime is 26.4, which predates the regression (we reproduced the non-crash there extensively: Debug and Release, hardware and software keyboard, same commit). A Snack can't demonstrate it for the same reason; it needs a physical device on 26.6.

Expected behavior

Memory stays bounded while typing; typing in a multiline TextInput does not depend on the user's keyboard autocorrect settings for process survival.

Actual behavior

Process footprint grows to the jetsam per-process cap (~3.5 GB on this device) during a single typing session and iOS kills the app. Reproduces on every typing session with autocorrect/predictive enabled; never reproduces with them disabled.

Environment

• React Native 0.85.3, Fabric / new architecture, Hermes
• Expo SDK 56.0.16 (issue appears to live in the RN TextInput ↔ UIKit text-services interaction, not Expo-specific)
• Built with Xcode 26.4 (17E202) on EAS macos-tahoe-26.4 image
• Device: iPhone on iOS 26.6 (23G71)
• Working baseline: identical code and lockfile on the same device on the prior iOS version (2026-07-24)

I have the full JetsamEvent .ips files from the device and can attach them (or share privately) on request.

Workarounds

• App-side: autoCorrect={false} + spellCheck={false} (+ smartInsertDelete={false}) on the affected TextInput — disables autocorrection and the predictive bar for that field.
• User-side: Settings → General → Keyboard → turn off Predictive Text and Auto-Correction (verified on-device).

Related issues (not duplicates)

• TextInput cursor lags behind text when component is controlled if Auto-Correction and Predictive Text are enabled #44157 — the controlled-TextInput × Auto-Correction/Predictive-Text interaction has prior history in core (cursor lag, fixed around 0.76/0.77). Same subsystem pairing, different symptom.
• [iOS] App termination on more than one secureTextEntry, iOS >= 26 #54658 — iOS 26 TextInput-triggered termination that only reproduces on physical devices, never the simulator. Same repro-environment signature, but that one is an instant kill on focusing multiple secureTextEntry fields, not memory growth while typing.
• iOS 26.5 + Fabric: RCTGetBorderImage allocates thousands of CG raster surfaces, OOMing Hermes during JS bundle eval #56980 — precedent that an iOS 26.x point release alone (26.5 there) flipped an unchanged RN 0.85.3 app into multi-GB memory growth, in a different subsystem (border rendering).

Corroborating context that Apple's iOS 26.x keyboard/text-services stack has been churning (native, non-RN): UIInputView focus regression on 26.0, predictive text degrading during sustained typing since 26.0, and Apple's own 26.6 release note for the build/date.

Since the evidence points OS-side, this likely needs an Apple fix (a Feedback Assistant report is planned in parallel); opening this here so RN users searching the symptom (jetsam per-process-limit while typing on iOS 26.6) find the workaround and so the RN team is aware.

[react-native-bot]

Warning

Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:

• For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template

You can read more about about it on our website: How to report a bug.