Expo mobile development pitfalls and how to avoid them

Hey there 👋,

If you're new to Expo mobile development or feeling like it's out to get you, here are the things I really wish someone had told me from the start.

Your navigation structure is everything

Expo Router is great until it suddenly isn't. Throwing <Stack/> together without thinking and you will spend hours wondering why route.goBack() won't work properly.

Plan your routes structure first, set up one main folder for your routes and keep it simple, use shared routes to organize your app

• Use Typed Routes to type check your navigation params and avoid not found screens.
• Use Expo Sitemap to debug your navigation structure, should be enabled in development at http://localhost:8081/_sitemap.
• Set up deep linking early before launch, you will need it trust me.

Not everything goes to React Context

Avoid using React's Context for everything with no real reason, changing one tiny thing will make the entire app re-render and slow down.

• Use tools like React Query or TRPC for server data, much better at handling data from APIs.
• Try Zustand for simple state or you need global state, it's easier to use and doesn't cause unnecessary re-renders.

const useFavoritesStore = create((set) => ({
  favorites: [],
  addFavorite: (item) => set((state) => ({ 
    favorites: [...state.favorites, item] 
  })),
  removeFavorite: (id) => set((state) => ({ 
    favorites: state.favorites.filter(item => item.id !== id) 
  })),
  isFavorite: (id) => (state) => state.favorites.some(item => item.id === id),
  clearFavorites: () => set({ favorites: [] })
}))

It's not just 'Javascript'

React Native promises you can write once and run everywhere. That's not true, and your app will break because of it.

You use a fancy module that worked perfectly on Android, then the app crashed on iOS or froze on iOS. The module uses different native code on each platform, and iOS had its own weird bugs that JavaScript couldn't fix.

Don't trust any library until you test it on both platforms. Use platform-specific modules strategies to isolate third-party packages for potential headaches waiting to happen.

Debugger won't help when real users' devices crash

You'll spend hours debugging your app, then get a message: It crashes on my Samsung Galaxy S7.

Your app may have worked fine on 12 different test devices. Then it kept crashing on one user's cheap Android phone.

The problem? A simple SVG background was eating up all the memory on phones with only 2GB of RAM.

Test on old, crappy phones. Ask friends for their old devices, buy cheap ones on Amazon, or borrow from clients. Your app needs to work on the worst phones, not just the newest ones.

Performance problems can't be fixed later

• Always use FlashList for big lists: It only renders what's visible on screen set estimatedItemSize if all your items are the same height.
• Enable React Compiler if your project is compatible though it's still experimental.
• Enable EXPO_ATLAS=true to give you an overview of the bundle, source and output code of individual modules, especially if you are using Expo Router to deploy your Router API on Cloudflare which runs on serverless limited functions size.

You're probably making things too complicated

I once saw a to-do app with folders nested so deep you needed a map to find the components. Simple code beats clever code. That fancy animated button might break on Android. Use proven libraries instead (but check their GitHub issues first).

Starting from scratch is not always the best idea, use a boilerplate to get started. These boilerplates can now be imported to Bolt or used in Cursor to save you tokens and time.

Don't build features you don't need yet

Developers love building fancy, reusable code. Customers just want their app to work on time. Only solve the problem you have right now. Don't build something "reusable" until you actually need it in 3+ places.

It gets easier

Mobile development with Expo can be frustrating, exciting, and sometimes feels broken. But everyone struggles with it at first. The sooner you accept that your first apps won't be perfect, the faster you'll start building apps that actually work.