Build uncompromising high-performance, high-fidelity apps with React. What you see is not the Apple Messages app, nor is it meant to be 1:1. Rather it serves as an aspirational and real example of UI/UX that is possible. Every detail from the bubble animations to keyboard gestures to scroll view... insets and safe areas to parallax timestamps required care and attention. Quality UIs come from caring hard. The little chat bubble tails that morph away when the next message animates in. Timestamps that scroll at a different rate than the bubbles. Peek gestures powered by UIKit that lift a chat bubble, tail and all, with a gentle haptic pulse. The subtle shadow of the text composer and responsively sliding down the keyboard in pixel-perfect concert. The composer shrinking its width to fit iPhone’s rounded bezel. The beautiful Liquid Glass refractions have the level of glassiness chosen by the user (new in iOS 27). Scroll view insets that adjust to fit the home bar and keyboard dynamically, creating a sense of depth as the chat bubbles are slightly visible as they scroll under the keyboard. Keeping the keyboard on screen if the prior screen already presented it. Sliding the keyboard and composer with the screen when the user drags to navigate back. I am excited to explore using the new iPhone Duo view controllers natively with React when the time comes. There is always room for innovation and improvement. This chat demo runs at 120 FPS on iOS 27 even on my phone that’s four versions old now. There are several approaches to high-performance lists. I explored a new Expo scroll view that uses the native gesture systems along with react-native’s VirtualView (codenamed “Fling” to reflect the speed of flinging a scroll view), which Meta’s React team designed to prioritize scroll momentum with React’s scheduler. There are tradeoffs with other scroll strategies for how the scroll views gracefully degrade, and they can be swapped out based on what’s best for your app’s use case. And, by virtue of using modern React, high-priority events like user gestures can preempt lower-priority ones like a network response. Let us dispel any myth that using React requires compromising on beautiful, smooth, user-friendly UI/UX that Uses the Platform. Let us dispel any myth frame-perfect UI coordination is not achievable. The Hermes thread and the UI thread can coordinate when needed, like for controlled text inputs. Let us dispel any myth that React Native’s performance is impacted by a bridge, let alone has a bridge. Bridgeless JSI and the Fabric renderer are here for apps that use the New Architecture. What about Android? The app runs and I’ll share a screenshot from my cloud agent’s emulator. With some attention to detail dedicated to Android I’m confident crafted UX is attainable. I’ve spent my tokens once and have a structural head start everywhere. One more thing! Most of this chat’s application code is written with , , , and other familiar elements. The styling is mostly CSS, including linear-gradient(), background-attachment: fixed, and semantic platform colors that adapt to dark mode. Not just appearance - CSS Animations and CSS Transitions run entirely natively. There are a handful of custom native components written in Swift and Kotlin, like the chat bubbles and a custom CAShapeLayer and UIBezierPath for the tails. Native coding is a first-class feature. The way to think about building beautiful apps this way is React and Native, not React vs. Native. Aspire high and raise your ambitions for what is possible!show more

Running on Android. I don’t think this is what people expected when they asked for Android to get blue bubbles :P

Wow, this looks insane! If you ever need rich formatting inside those custom bubbles without tanking performance, we built react-native-enriched-markdown for this exact use case:

beautiful

Thank you!

@reactjs Beautiful UI Beautiful Writing Beautifully React Beautifully Native

The thing I am actually most astonished by is James’s laser-like accuracy when typing on the virtual keyboard during a recorded demo

Is this legal

Oh dear

Incredible work! Just a little nit-pick :) The send animation which transforms the input box into the message bubble needs a bit of polishing 1. bubble needs to stay visible at all times 2. bubble needs to stay on top of the input box 3. input box needs to slowly shrink in height

can you link to the repo? I want to steal some optimisations 😂

There’s a lot of code, what part do you want to know more about?

Animations: sending a chat bubble and revealing the timestamps on the side use Animated with the native driver. Reanimated would work well too. The Delivered/Read statuses and animating the bubbles’ positions use CSS Transitions. But without that API you could use (Re)Animated. Incoming chat messages and the typing indicator (not shown) use CSS Animations. The peek and pop effect is UIKit, including the way chat bubbles are lifted out of the scroll view and animate back to their original position when done. List: powered by VirtualView: There is some additional logic to make the chat bubbles cheap, like React.memo() and initializing the animated values only if a chat bubble is being sent and needs animation. The new scroll view I mentioned is for precise keyboard and safe area/inset handling and is not for speed. There is also some code to get the softly blurred headers on iOS 27. Native components: the chat bubbles are native because of the tails and animations. You could do this with SVG but it is likely faster to use CALayerPaths and there are potentially a lot of chat bubbles. The other native components are related to the keyboard and text composer because they are intrinsically coupled to UIKit’s delegate methods and must be frame-perfect. These pieces are infrastructure and I could see them maturing over time and being usable in most apps, instead of each developer rewriting their own implementation.

Thanks for the explanation

@expo Well said, and completely agree. “React and Native, not React vs. Native” Put that on a billboard.

Great post. An application is only as great as the level of polish and attention you give it.

Proving you can lock in 120 FPS by blending custom Swift layers with React Native completely buries the old bridge performance myth. Are you planning to package up that custom VirtualView scroll strategy as an open-source library?

VirtualView is open source and implements the cell rendering behavior: import {unstable_VirtualView as VirtualView} from 'react-native'; Docs: Stress test it with a few thousand views and work on making your cells as lightweight as you can. You’ll find it prioritizes rendering blanks (I believe this is also SwiftUI’s strategy) when the app can’t keep up. For real-world scrolling, it does a nice job of keeping scroll momentum and balancing how much off-screen content to pre-render.

Is the data static? Try fetching it from the backend using an infinite query, like you would in a real-world application. Or better yet, store it in expo-sqlite and read from there, with a background sync to keep it up to date. Will you still get 120 FPS?

The data is static which acts as a stress test for UI rendering since there is no network or data store to act as a bottleneck. The UI would have an easier time maintaining its frame rate when waiting for data with non-blocking fetches. I do think SQLite can perform very well, especially with the massive speed improvements in Expo Modules 2 and tuning how messages are fetched in batches. Would be good to measure it, I was focused just on the pure UI parts.

Well said! The UI work is beautiful.

does voiceover still read the bubbles in order with the timestamps moving separately??

Expo always delivers

Serious wow factor

aspirational examples are great, but they can set unrealistic expectations for developers

Can you please make an actual dummy build of this kit so we can play around with it and experience it before we signup? Just a mock iOS app in the AppStore that users can download and see the view in action. I don’t want to commit to anything without know if it will work for my project. It looks really great!

"Uncompromised performance" is less impressive when it's only demonstrated on flagship hardware.

Wish apple cared about the messages app as much as you did.

Very nice, GitHub link?

“Cofounder at expo” ah I see

Why you do not use legend list, also can you share code so we can learn from it

I wanted to try VirtualView. Legend List is great too I’m sure. It would be good to ship a lot of the infrastructural code into react-native core and Expo core upstream.

Great! Only that's bothering me is that sent message bubble animation

imo 'uncompromising' always loses to the reconciler the moment bubble animations hit real message volume

GitHub repo?

Make it open source 🥹

Those interaction details are my favorite part of building @PanolsApp too. Especially making the controls feel good while keeping the photos front and center.

@jamonholmgren good example demo for the recent debates you’ve been in? This can help widen the perspective of some blindly obsessed people you talk to 😊

React lookin' like Apple Messages and it ain't even tryin' to cosplay. This is the bar for mobile UI now.

What are the specific tradeoffs of the new scroll strategy during graceful degradation? Knowing these limitations would help determine when to swap it out for other options.

VirtualView skips rendering in favor of keeping scroll momentum. It will display blanks when it predicts the app will not meet its frame deadline, and the scroll view will keep moving with minimal stutter. In contrast, UIKit’s UITableView will freeze the scroll position until it has enough cells to display. This means there is always content on the screen but the scroll view is more likely to stutter when the app can’t keep up. Both approaches are valid and could share optimization strategies. For instance, in either case you could render a very cheap placeholder if you expect to miss your frame deadline. It would make VirtualView look better and UITableView perform better. And for the user, they’re often scrolling so fast in this scenario, it could be a good tradeoff to make.