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。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 35/100
- Issue 類型
- 缺陷
- 描述清晰度
- 需要釐清
- 活躍度
- 活躍
- 技術堆疊
- ios, react-native
- 領域
- mobile-dev
研究方向
未指定任何 React Native 原始碼檔案或測試。首先,在執行 iOS 26.6 的實體 iPhone 上,使用受控的多行 TextInput 重現問題,然後檢查 JetsamEvent,並比較啟用與停用預測文字時的輸入。完成的標準是確定是否可以進行 RN 端的變更,或記錄 OS 回歸問題與經過驗證的因應方法。
由索引模型根據 Issue 內容生成。
描述
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.
- 主要語言
- C++
- 星號
- 127k
- 分支
- 25.3k
- PR 合併指標
- 30 天內沒有已合併 PR
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
react/react-native 的其他 Issue
-
Needs: Author Feedback Needs: Repro
難度 1/5 1 小時以內 新手友好度 92/100
react/react-native#58621 · 1 則留言 ·
-
Needs: Author Feedback Needs: Repro
難度 2/5 1-3 小時 新手友好度 85/100
react/react-native#58610 · 1 則留言 ·
-
Needs: Triage :mag:
難度 2/5 1-3 小時 新手友好度 82/100
react/react-native#58565 · 1 則留言 · 2 個 reaction ·
-
Needs: Author Feedback Needs: Repro
難度 2/5 1-3 小時 新手友好度 88/100
react/react-native#58555 · 5 則留言 · 2 個 reaction ·
-
Needs: Attention Needs: Repro
難度 2/5 1-3 小時 新手友好度 85/100
react/react-native#58526 · 2 則留言 ·
查看 react/react-native 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 70/100
google/libultrahdr#485 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
godotengine/godot#123776 ·
-
bug
難度 1/5 1 小時以內 新手友好度 60/100
-
good first issue
難度 1/5 1 小時以內 新手友好度 90/100
-
good first issue
難度 2/5 1-3 小時 新手友好度 75/100
ros2/common_interfaces#344 ·