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)
还没有人认领这个 Issue。
- 主要语言
- C++
- 星标
- 127k
- 派生
- 25.3k
- 平均合并
- 1 天 23 小时
- 30 天内合并 PR
- 4
描述
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 rpages215,899 × 16 KB pages ≈ 3.5 GB footprint, withlifetimeMaxequal 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
.ipsfiles 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
- Physical iPhone on iOS 26.6 (23G71). Keyboard settings at defaults (Predictive Text and Auto-Correction ON).
- React Native 0.85.3 app (Fabric / new architecture, Hermes) with a controlled
multiline<TextInput>(value+onChangeText), e.g. a chat composer. - 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).
- 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.4image - 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)
- #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.
- #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
secureTextEntryfields, not memory growth while typing. - #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.
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
未指定任何 React Native 源文件或测试。首先,在运行 iOS 26.6 的实体 iPhone 上,使用受控的多行 TextInput 重现该问题,然后检查 JetsamEvent,并比较启用和禁用预测文本时的输入。完成的标准是确定是否可以进行 RN 侧的更改,或记录 OS 回归问题和经过验证的解决方法。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- ios, react-native
- 领域
- mobile-dev
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 活跃
- 描述清晰度
- 需要澄清
- 新手友好度
- 35/100