React Native feels sluggish" is one of the most repeated lines in mobile dev. I think it's incomplete. A careless React Native build feels sluggish. A careless native build does too.
We recently shipped a React Native D2C app for a clothing brand: 120ms hot launch, 900ms cold launch, on Android and iOS from one codebase. The client asked us not to name them, so I can't show you the store listing. What I can share is what the app is made of and how I think about speed.
The stack
React Native, one codebase for both platforms
FastAPI and PostgreSQL on the backend, with Redis caching the catalogue
Razorpay for checkout
A custom admin panel, built from scratch, that works on a phone
Categories run along the top, product pages carry a size guide and a share button, and checkout goes straight to payment. It's deliberately plain. The result comes from many small decisions, not one clever trick.
Which "launch" are we talking about?
Cold launch means the app isn't in memory. You tap the icon and wait. Hot launch means it's already there. Ours are 900ms cold and 120ms hot.
Cold is the number that matters. It's what a customer experiences after the phone has killed the app in the background, which happens all the time on cheaper devices. If someone quotes you a launch time, ask which kind, on what device, and until when: the first frame, or a screen you can actually tap.
Where I look first when an app feels slow
I'm not going to pretend there's a single fix. This is the order I check things in:
Is the first screen waiting on the network? If the app shows a spinner until an API responds, your launch time is your API latency. On patchy mobile data that's a bad deal. Show something useful from stored data first, then refresh quietly.
Is the API doing more work than it needs to? A catalogue is read far more than it's written. That's why we cache it in Redis instead of hitting the database on every open. The catch is stale data, so decide early how edits from the admin panel reach the cache.
Are the lists and images the problem? Product grids are where React Native usually gets blamed. Row components that re-render too often and images far larger than the card they sit in are the usual culprits.
Is too much happening before the first render? Large initial state, SDKs that initialise up front and screens loaded before anyone needs them all add up.
Are you measuring the right build? Debug builds are slow and misleading. Measure release builds.
Test on the phone your customers own
This matters more than any code change. Flagship phones hide most performance mistakes. If you test only on the newest iPhone and a recent Pixel, your customers on budget Android phones will find the problems for you.
For delivery and field apps we keep a 3GB-RAM Android in mind, because that's what the driver actually carries, not the flagship on the developer's desk.
Why React Native here, and when I wouldn't pick it
The framework depends on the project. This is how I'd put it:
React Native fits when you already run a React website. You share logic and engineers, and that was the situation with this client's existing site. The catch is that performance takes discipline. A careless build feels sluggish, which is the point of this whole post.
Flutter fits when the design has to look identical on every phone and there's no web codebase to share. The catch is a bigger app size, and some native SDKs need a bridge written by hand.
Native (Kotlin and Swift) fits when the app lives on hardware: Bluetooth printers, barcode scanners, background location. The catch is two codebases and every feature built twice.
If an agency gives the same answer for every project, you're hearing what their team knows, not what your app needs.
Takeaways
Don't block the first screen on the network.
Cache what's read often, and plan how it gets cleared.
Treat lists and images as your main performance surface.
Measure cold launch, in release mode, on a budget Android phone.
Choose the framework per project.
What's the slowest thing you've had to fix in a React Native app? The list, the images, the startup, something else? I'd like to hear.
I work at Nexona, where we build mobile apps and the backends behind them.
Top comments (0)