The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
🔥 Most React Native performance problems don’t actually come from React Native.
They usually start much earlier — with a few architecture decisions that look harmless during MVP development 👇
⚠️ Unnecessary re-renders
One small state update shouldn’t refresh half the app.
🧱 Heavy logic inside components
If your UI is also doing business logic, API transformations, and calculations, performance gets messy fast.
🌍 Oversized global state
Not everything belongs in Redux or Context. Global state should stay global.
📜 Poorly optimized FlatLists
Large lists need pagination, memoization, stable keys, and proper rendering strategies.
🔌 Too many native / bridge calls
Crossing between JS and native layers unnecessarily can become expensive.
🖼️ Images without proper caching
Huge images + no caching = slower screens, higher memory usage, worse UX.
I’ve seen React Native apps with only 20–30 screens feel slow, while significantly larger products stay smooth because performance was considered from day one.
My rule is simple:
Don’t wait for users to report performance problems. Design for performance before you start stacking features. ⚡
React Native + TypeScript + Expo + Firebase can handle serious production products.
The stack is rarely the real bottleneck.
Architecture and implementation are. 🚀
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Challenges
View all
Related posts
🔥 5 React Native mistakes that cost more to fix later
After working on multiple mobile products, I keep seeing the same problems:
1️⃣ Using global state for everything
Not every screen needs Redux. Keep local state local.
2️⃣ Ignoring list performance
A badly configured FlatList can make a simple app feel broken. Memoization, pagination and stable keys matter.
3️⃣ Building before defining navigation
Auth flow, onboarding, tabs, deep links — decide this early. Refactoring navigation later gets painful fast.
4️⃣ Treating Firebase as “just a backend”
Firestore structure, indexes, security rules and listeners need architecture too. Otherwise costs and complexity grow quickly.
5️⃣ Testing only on one device
An app can feel perfect on a new iPhone and terrible on a mid-range Android.
React Native lets you move fast.
Good architecture lets you keep moving fast after version 1.0. 🚀
🍳 Darakai Live Kitchen — Reimagining Food Delivery
What if customers didn't have to simply wait for their food?
I designed Darakai Live Kitchen, a new concept for the Darakai Food Delivery app that lets customers watch their food being prepared live by the chef.
Instead of a simple “Preparing your order” status, customers can:
🔴 Watch the kitchen live
💬 Interact with the chef
❤️ Send reactions
🍽️ Follow the cooking → plating → ready journey
🚴 Track the transition from kitchen to delivery
On the restaurant side, chefs get a dedicated Kitchen Dashboard to manage orders, start a live cooking session, communicate with customers, and end the stream when the order is ready.
The experience
Order → Confirmed → Cooking Live → Plating → Ready → Pickup → Delivered
The idea is to transform food delivery from a simple transaction into a more transparent, engaging, and human experience.
Technical direction
The concept is designed around a Flutter customer app + restaurant interface + .NET API, with real-time video handled by dedicated streaming infrastructure while the backend manages orders, live sessions, permissions, chat, notifications, and session status.
More than delivery. A closer connection.
#Flutter #DotNet #FoodDelivery #UXDesign #ProductDesign #LiveStreaming #MobileApp #Darakai
If the kitchen stream drops, will the order timeline stay visible? Customers could still follow their order while the video is unavailable.
Good UI gets attention. Good UX keeps people using the product.
I focus on designing interfaces that feel simple, clear, and intentional, from the first interaction to the final action.
That means:
• Clear user flows
• Strong visual hierarchy
• Consistent design systems
• Responsive interfaces
• Less friction, fewer unnecessary steps
The goal isn’t to make a product look good.
It’s to make it feel easy to use.
