react / react/react-native

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)

オープン
#57,725 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Needs: Author Feedback Needs: Repro
主要言語
C++
スター
127k
フォーク
25.3k
平均マージ
1日 23時間
マージ済み PR(30日)
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
  • 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)

  • #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 secureTextEntry fields, 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.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

React Native のソースファイルやテストは指定されていません。まず、iOS 26.6 を実行する物理的な iPhone 上で、制御された複数行の TextInput を使って再現し、その後 JetsamEvent を調査して、予測テキストを有効にした場合と無効にした場合の入力を比較します。完了条件は、RN 側の変更が可能かどうかを確立するか、OS のリグレッションと検証済みの回避策を文書化することです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
ios, react-native
領域
mobile-dev
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
説明が足りない
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。