Codex iOS app slow scrolling often blocking for seconds

What version of the Codex App are you using (From “About Codex” dialog)?

cli v0.137.0 + iOS app 1.2026.146

What subscription do you have?

pro

What platform is your computer?

MacOS 26.5 m1 pro

What issue are you seeing?

## ChatGPT iOS: remote-control scrolling is extremely slow in long conversations

When using remote control from the ChatGPT iOS app, scrolling through a long conversation becomes so slow that the feature is almost unusable.

I’m seeing this on an iPhone 12 Pro. Scroll gestures often feel delayed or blocked, and the UI appears to hitch as though expensive rendering or layout work is happening on the main
thread. This is most noticeable in conversations with a lot of history and rich rendered elements.

I realize the implementation is closed source, so this is only speculation, but the behavior looks consistent with too much of the conversation history being active in the render/layout
tree during scrolling, or with expensive rich-content layout being recomputed during normal scroll. Even on an older phone, mostly-text scrolling should stay responsive if the transcript
is correctly virtualized/windowed and expensive views are reused, cached, or deferred.

### Expected behavior

Long conversations should remain scrollable and responsive, especially during remote-control sessions. Older devices may not hit perfect frame rates in every case, but basic transcript
navigation should not be blocked by long main-thread stalls.

### Actual behavior

Scrolling in long ChatGPT conversations is very slow. During remote control, this makes the feature difficult or effectively impossible to use because the UI cannot keep up with basic
navigation.

### Device

• iPhone 12 Pro
• ChatGPT iOS app
• Issue occurs in long conversation histories, especially when using remote control

### Possible direction

We ran into a similar class of problem in the Delight iOS app and solved it by making the transcript view much more list-like and paging-friendly.

The relevant implementation is here:

• Delight uses a UICollectionView-backed transcript rather than a plain SwiftUI ScrollView/LazyVStack, specifically because large variable-height Markdown transcripts were causing

unstable or slow scroll behavior:
https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalTranscriptCollectionView.swift#L4-L11

• The transcript is hosted as a UIKit collection view with self-sizing reusable cells:

https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalTranscriptCollectionView.swift#L69-L99

• Cells are provided through a diffable data source and dequeued via dequeueConfiguredReusableCell, so the visible transcript can reuse row views instead of treating the whole history

as one giant live view tree:
https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalTranscriptCollectionView.swift#L252-L295

• Updates are applied through snapshots, with changed message IDs explicitly reconfigured and animations disabled because streaming updates can happen frequently:

https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalTranscriptCollectionView.swift#L298-L340

• When older history is prepended, the view captures and restores the visible scroll anchor so loading more history does not jump the user around:

https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalTranscriptCollectionView.swift#L142-L176
https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalTranscriptCollectionView.swift#L348-L409

• The transcript view is used directly in the terminal detail screen and loads older history on demand:

https://github.com/bhandras/delight/blob/main/ios/DelightApp/TerminalUI.swift#L434-L447

• On the data side, Delight fetches the latest transcript page first and then loads older pages with a beforeSeq cursor instead of requiring the whole history up front:

https://github.com/bhandras/delight/blob/main/ios/DelightApp/SDKBridge.swift#L1974-L1979
https://github.com/bhandras/delight/blob/main/ios/DelightApp/SDKBridge.swift#L2011-L2033
https://github.com/bhandras/delight/blob/main/cli/sdk/sdk.go#L923-L933

• The server supports that cursor-based transcript pagination:

https://github.com/bhandras/delight/blob/main/server/internal/api/handlers/sessions.go#L522-L609
https://github.com/bhandras/delight/blob/main/server/internal/api/handlers/sessions.go#L721-L775

• Delight also avoids rendering huge code/tool outputs inline during normal scroll. Large preformatted blocks are truncated in the transcript and opened fully only on demand:

https://github.com/bhandras/delight/blob/main/ios/DelightApp/MessageRendering.swift#L521-L532
https://github.com/bhandras/delight/blob/main/ios/DelightApp/MessageRendering.swift#L820-L849

This combination made Delight’s iOS transcript fast even with long histories:

• page transcript history instead of loading everything eagerly
• render the transcript through a reusable list/collection view
• keep only visible cells actively hosted/layouted
• preserve scroll anchors when prepending older history
• reconfigure only rows whose content changed
• avoid expensive inline rendering for very large rich blocks
• defer full rendering of large outputs until explicitly opened

I suspect the ChatGPT iOS app could benefit from a similar approach, particularly for remote-control sessions where scroll responsiveness is critical.

What steps can reproduce the bug?

I just remote to a long conversation.

What is the expected behavior?

_No response_

Additional information

_No response_