React Native for Frontend Developers: What I Wish I'd Known

by Hannah Goodridge ~ 7 min read

Like this post?

00

So I've been given a shiny new project at work - building a mobile app with React Native and Expo Go. Coming from years of web development, I thought "How hard can it be? It's still React, right?"

Wrong!

The stuff nobody mentions when you're learning React Native

1. The Button Betrayal

Me: "Hey, let's build some buttons..."

React Native: "LOL no, you want PRESSABLE components. Button is trash."

Seriously, the <Button> component in React Native is like that mate who offers to help you move house but only brings a single carrier bag. Technically helpful, but you're going to need a lot more. Want custom styling? Not a chance. Want to add an icon? In your dreams. Want it to look like anything other than the platform default? Time to meet your new best friend: <Pressable>.

2. CSS? What CSS?

Me: "Ok let me copy this CSS from Figma..."

React Native: "Haha cute. We don't do 'CSS' here. It's StyleSheet.create() or nothing."

Gone are the days of just pasting CSS properties. Instead, you get to learn a whole new syntax where backgroundColor replaces background-color, and don't even think about using shorthand properties. Want margin: 10px 20px? Tough luck, you're writing out marginVertical and marginHorizontal like it's 2010.

3. The Font Files Fiasco

Me: "Surely fonts work the same..."

React Native: "WOFF files? What is this, 2015? TTF only, and you better useFonts() them."

Web fonts spoiled me rotten. Just link to Google Fonts or drop a WOFF2 file in and Bob's your uncle. React Native? You need TTF files, you need to register them with useFonts(), and heaven forbid you want different font weights - that's a separate file for each one, thank you very much.

4. The Styling Void

Me: "Where's my default body styling..."

React Native: "There is no body. There is no HTML. Only components in the void."

This one's a real mind-bender coming from web development. There's no <html>, no <body>, no document structure at all. And crucially, there's no shadow DOM either - everything exists in a flat component hierarchy.

In web development, you're used to the browser providing default styles, CSS inheritance cascading down through the DOM tree, and the shadow DOM encapsulating component styles. React Native throws all of that out the window. No more global CSS resets, no more inheriting styles from parent elements (well, mostly), and definitely no style encapsulation. Every single component needs explicit styling. Want consistent text styling across your app? Hope you like creating a lot of custom components or prepare for copy-paste hell.

5. Container Queries? More Like Container Nightmares

Me: "Right, what about container queries..."

React Native: "useWindowDimensions() and pray. Welcome to mobile."

Responsive design in React Native feels like going back in time. No CSS Grid, no Flexbox gap property (well, it was added in v0.71 but many projects are still catching up), and definitely no container queries. You get useWindowDimensions() and a prayer that your layout works on both a tiny iPhone SE and a massive iPad Pro.

6. The Shadow Realm

Me: "Ok just give me box-shadow..."

React Native: "Which platform? iOS gets shadowOffset, Android gets elevation. Pick your poison."

This one genuinely did my head in. Want a simple drop shadow? On iOS, you use shadowColor, shadowOffset, shadowOpacity, and shadowRadius. On Android? Nope, you get elevation and that's it. Want an inset shadow? Nervous laughter Time to create a custom component with gradients or images because that's not happening natively.

And don't get me started on trying to use images for shadows. It's like being transported back to the dark ages before SVGs were a thing, when we had to slice up Photoshop files and cross our fingers they looked right on different screen sizes.

7. Everything is a View

Me: "Surely <div> works..."

React Native: "It's <View>. Everything is <View>. <View> is life."

No more semantic HTML elements. No <header>, <main>, <section>, or <article>. Just <View> components as far as the eye can see. It's like building a website with only <div> tags, which feels wrong on so many levels when you've spent years caring about accessibility and semantic markup.

OK, OK - All This Moaning Aside...

But here's the thing - despite all my moaning, I've actually really enjoyed working with React Native and Expo. Once you get past the initial culture shock, there are some genuinely brilliant aspects:

Deployment Magic

The deployment story is absolutely brilliant. With Expo, I can build for both iOS and Android from a single codebase, test on real devices instantly with Expo Go, and push updates over the air. Coming from web development where deployment can be complex, this feels like absolute magic.

Performance Surprises

The performance is surprisingly good. Yes, it's not native-native, but for most use cases, it's more than adequate. The bridge between JavaScript and native code is well-optimised, and the user experience feels smooth and responsive.

The Component Ecosystem

Once you embrace the React Native way of doing things, the component ecosystem is actually quite rich. Libraries like React Native Elements, NativeBase, and Tamagui provide excellent building blocks that feel familiar to web developers.

Hot Reloading Heaven

Fast Refresh in React Native is even better than in web development. Seeing your changes instantly on a physical device without losing state is incredibly satisfying.

Device Testing Made Simple

One thing that absolutely blew my mind is how easy Expo makes testing on real devices. Just scan a QR code with the Expo Go app and boom - your app is running on your phone. No more mucking about with simulators that don't quite behave like real devices, no complex device provisioning, no certificates to manage. Want to test on your colleague's Android phone? Just get them to scan the code. It's genuinely revolutionary coming from web development where device testing usually means "open Chrome DevTools and pretend it's a phone".

Read the Docs First (Seriously!)

One thing I can't stress enough - and I'm saying this as someone who's been using Cursor AI throughout this project - read the React Native documentation first. I know it's tempting to just ask AI to solve everything, but the React Native docs are actually really well written and will save you hours of confusion.

AI tools like Cursor are brilliant for speeding up development once you understand the fundamentals, but they can lead you down some serious rabbit holes if you don't have a solid grasp of how React Native actually works. Trust me, spend a few hours with the official docs before you let the AI run riot - your future self will thank you.

The Learning Curve Reality

The transition from web to mobile development with React Native isn't just about learning new APIs - it's about unlearning web assumptions. You can't just think in terms of CSS and HTML anymore. You need to think in terms of native mobile patterns, platform-specific behaviours, and component-based styling.

But once you make that mental shift, React Native becomes a powerful tool. It's not trying to be web development - it's trying to be the best way to build mobile apps with React, and on that front, it succeeds admirably.

Final Thoughts

Would I recommend React Native to other frontend developers? Absolutely. Just go in with realistic expectations. It's not "React but on mobile" - it's a completely different paradigm that happens to use React concepts.

The frustrations are real (seriously, why can't I have inset shadows?), but the productivity gains and deployment simplicity more than make up for the learning curve. Plus, there's something deeply satisfying about building an app that works on both iOS and Android from a single codebase.

Now if you'll excuse me, I need to go figure out why my perfectly centred component looks completely different on Android... 🤦‍♀️


Currently wrestling with React Native at work and loving every frustrating minute of it.

Read next