DEV Community: Nexona

React Native Isn't Slow. Careless Builds Are.

Nexona — Wed, 30 Sep 2026 07:02:02 +0000

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.

Why OCR Breaks the Moment You Point a Phone Camera at a Real Document

Nexona — Mon, 28 Sep 2026 05:48:06 +0000

Every OCR demo handles a clean PDF beautifully. Feed it a crisp, flat, well-lit digital document and accuracy numbers look great. Nobody's demo handles a photo of a delivery challan taken at a warehouse gate, one-handed, at 6pm, under a flickering tube light.

That gap — between "OCR works" and "OCR works on what actually shows up" — is where most document-automation projects quietly fail.

The problem isn't the text. It's everything around the text.

Naive OCR pipelines assume conditions that real-world documents rarely meet:

Skew — the phone wasn't held perfectly parallel to the page
Uneven lighting — a shadow falls across half the invoice, or an overhead light blows out one corner
Low resolution and motion blur — quick phone snaps, not scans
Creased or crumpled paper — especially with anything that's been folded in a pocket or a file
Mixed content — a printed template with handwritten quantities or a stamp overlapping the text

None of these are edge cases. In practice, they're the majority case. A pipeline tuned only on clean digital PDFs will look production-ready in a demo and then fall apart on day one with real input.

What doesn't actually help

A few things that look like solutions but mostly aren't:

Throwing raw images at an OCR engine and hoping — Tesseract (or any OCR engine) run on an unprocessed photo will confidently produce garbage. It won't tell you it's guessing.
Cranking up image resolution — more pixels don't fix skew or bad lighting; they just make the same problems bigger.
Generic denoising — aggressive noise reduction often smooths away the thin strokes that distinguish a "1" from a "7," trading one error type for another.

The failure mode that catches people off guard is that these pipelines don't fail loudly. They return a result — it's just wrong, and nothing in the output tells you that.

What actually moves the needle

Perspective correction and deskew before anything else.
Detecting the document's edges (or at least its dominant text-line angle) and warping it back to a flat, axis-aligned rectangle fixes more downstream errors than any amount of tuning the OCR engine itself.
Adaptive thresholding instead of global thresholding.
A single brightness cutoff across the whole image fails the moment lighting isn't uniform — which, in a real photo, it never is. Adaptive thresholding recalculates the cutoff per region, so a shadowed corner and a glare-lit corner both get read correctly.

A minimal version of the first two steps, in OpenCV:

python
import cv2
import numpy as np

def preprocess(image_path):
img = cv2.imread(image_path)
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)

# Adaptive threshold handles uneven lighting
thresh = cv2.adaptiveThreshold(
    gray, 255,
    cv2.ADAPTIVE_THRESH_GAUSSIAN_C,
    cv2.THRESH_BINARY,
    blockSize=35,
    C=15
)

# Estimate skew from text line angles and rotate to correct it
coords = np.column_stack(np.where(thresh > 0))
angle = cv2.minAreaRect(coords)[-1]
if angle < -45:
    angle = -(90 + angle)
else:
    angle = -angle

(h, w) = thresh.shape
center = (w // 2, h // 2)
M = cv2.getRotationMatrix2D(center, angle, 1.0)
deskewed = cv2.warpAffine(thresh, M, (w, h),
                           flags=cv2.INTER_CUBIC,
                           borderMode=cv2.BORDER_REPLICATE)
return deskewed

This is the floor, not the ceiling — real pipelines add document-edge detection, perspective warping (not just rotation), and often a light denoising pass tuned specifically to preserve thin strokes. But this alone typically fixes the majority of failures you'll see from phone-captured documents.

Treat accuracy as the wrong top-line metric. A model that's 94% accurate sounds fine until you realize the 6% isn't randomly distributed — it clusters on exactly the fields where being wrong is expensive (quantities, amounts, dates). What matters more than raw accuracy is whether the system knows when it's unsure.

The part people skip: what happens when it's still wrong

It will be wrong sometimes. No preprocessing pipeline gets you to zero, and pretending otherwise is how a small extraction error turns into a bad ledger entry three steps downstream.

The fix isn't a better model — it's routing:

Every extraction gets a confidence score, not just an output
Anything below a set threshold goes to a short human-review queue instead of straight into the system of record
Every automated decision gets logged with what the system saw and why, so a wrong result can be traced instead of argued about
Anything irreversible — a payment, a price change — goes through draft-and-approve rather than straight-through processing, no matter how confident the model is

This is how we've handled this in production, and it's the part that actually determines whether a document-automation system is trustworthy, not the OCR accuracy number in the pitch deck.

The takeaway

OCR-on-a-clean-PDF is a solved problem. OCR-on-a-photo-of-a-real-document is a different, harder problem that mostly gets treated as an afterthought — and it shouldn't still be surprising people this far into 2026, but it does, every time a project jumps straight from demo to production without building for the version of the document that actually shows up.

Every automated decision gets logged with what the system saw and why, so a wrong result can be traced instead of argued about
Anything irreversible — a payment, a price change — goes through draft-and-approve rather than straight-through processing, no matter how confident the model is

This is how we've handled this in production, and it's the part that actually determines whether a document-automation system is trustworthy, not the OCR accuracy number in the pitch deck.

The takeaway