When the screen has to stay where you expect

Scrolling backwards through a personal forest longer than fits in memory is the hard problem every chat-style app eventually has to solve.

The promise is small but inflexible:

Newest message at the bottom when you open the screen.
Scrolling up loads older messages without anything jumping.
New messages arrive, but never push what you’re looking at out of view.
A message you find via search lands in the right place — not under the chrome, not behind the keyboard.

Each one is straightforward on its own. Holding all of them at once, while the user is actively scrolling, is the hard part.

Why it cascades

Variable-height messages change the scroll math. The scroll math changes which message sits at the visible bottom. Which message sits at the visible bottom decides whether a new arrival is welcome or intrusive. Whether the arrival is welcome decides whether you snap, queue, or do nothing. Whether you snap depends on whether anything else just snapped.

A bug in one layer manifests in another. The chat screen is the cascading-renders problem most apps eventually face.

What we ended up with

A bounded window of messages in memory. Scrolling backwards fetches older pages and evicts the newest; scrolling forward fetches the other direction. Real-time arrivals while you’re scrolled away wait behind a small “new messages” cue. The anchor — what sits at the bottom, where a search lands — is derived from the chrome’s actual size each render, not a hand-picked number.

None of these are individually clever. The clever part is making them hold together while you’re using the screen.

Tech notes

Most chat-style apps reach for a virtualized list — React Native’s FlatList, Shopify’s FlashList, the equivalents in other ecosystems — and let the library handle the windowing. This screen doesn’t, because the same surface morphs between a vertical chat layout and a spatial canvas. Virtualized lists assume one-dimensional flow; a canvas needs bubbles that pan in two dimensions, zoom independently, and share position state with a separate rendering layer. The windowing here is hand-rolled.

The shape is a sliding window: a bounded array of roughly a hundred messages kept in memory at any moment. The initial fetch returns the most recent N. When the user scrolls up far enough that the oldest quarter of the loaded slice enters the viewport, the screen fetches the next-older page from the server, prepends it, and if the total exceeds the cap, evicts the newest end and captures its cursor for later. Symmetric the other way: scroll back down toward what was evicted and the same machinery runs in reverse.

Pagination is cursor-based keyset pagination. The cursor is an opaque token built from the row’s timestamp and id, and the server uses it to seek into a sorted index rather than walking from offset zero. Tie-breaking on id matters — two messages posted in the same microsecond would otherwise be ambiguous to the ordering and risk appearing on two consecutive pages.

Real-time arrivals branch on window state. When the loaded window includes the live edge, incoming WebSocket messages merge straight into the in-memory array and the canvas reconciles. When the head has been evicted — the user is scrolled deep into history — incoming messages don’t bypass their view; they bump a counter that surfaces as a small ”↓ N new” pill. Tap it and the screen refetches the newest page and snaps.

The chrome height — what counts as “the bottom” for the snap-to-latest behavior, and where a find-in-canvas tap lands — is measured at render time via React Native’s onLayout callback rather than computed from a hardcoded constant. The top header, member chips, and bottom composer all change height with the device’s font scale, the keyboard’s visibility, and whether the conversation has one peer or six. Capturing the real height every render is the only way to avoid the message landing under the chrome on the next device profile we hadn’t tested.

Underneath, the surface itself is drawn with @shopify/react-native-skia for the connection lines and dots and React Native Animated.View overlays for the message bubbles. Position state lives in react-native-reanimated shared values, with worklets driving the pan / zoom / snap math. The windowing logic is plain React state on top of those primitives — nothing custom on the rendering side, just the bookkeeping that decides what to load and what to evict.