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
📱 One thing I check before building any React Native app: what actually needs to be native? Not every feature needs custom native code.
A lot of MVPs can move much faster with:
• Expo
• Firebase Auth
• push notifications
• RevenueCat / Stripe
• REST APIs
• shared iOS + Android codebase
But if the product needs Bluetooth, complex background services, advanced camera logic, heavy native SDKs, or custom platform behavior — that changes the architecture early.
The mistake is choosing Expo or bare React Native because one is “better.”
The right choice depends on the product.
Good mobile architecture starts with constraints, not preferences. ⚙️
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
🔥 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. 🚀
🔥 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. 🚀
Design that ships in days, not months 👀
Web UI, mobile apps, social and ad visuals. Clear interfaces that make the next step obvious.
Open to new projects. What are you building?
Making the next step obvious is a useful goal. How do you check that before shipping?