Understand how React Native differs from web React, how the JS bridge/runtime model works at a high level, and how to organize a mobile app project. This sets the foundation for discussing rendering, native modules, and app lifecycle trade-offs in interviews.
React Native is like building a TV show set, not a website
Think of React DOM like building a house where every part is made for browsers: walls, windows, and doors all fit the web. React Native is more like building a TV show set that looks like a house, but is actually made from stage pieces the phone understands.
You still describe the UI in React, but the final result is made from native mobile parts instead of HTML. That’s why the same React mindset works, yet the platform details matter much more. When interviewers ask about React Native basics, they want to know you understand that mobile apps are not just “web apps on a phone.”
What React Native is and why it exists
React Native lets you build mobile apps using React-style code, but it renders to native UI components rather than browser DOM nodes. This matters because mobile apps need smoother touch handling, platform-specific controls, and access to device capabilities.
Compared with React DOM:
React DOM targets div, span, button, and the browser layout engine.
React Native targets View, Text, Image, ScrollView, and touchable components.
A key interview idea is the JavaScript runtime + native side split. Your app logic runs in JavaScript, while the platform handles actual rendering and device APIs. At a high level, React Native coordinates updates between those two sides, which is why native modules, performance, and app lifecycle can become important trade-offs.
Metro bundles your app for the device
Metro is React Native’s JavaScript bundler and dev server. Its job is to take your source files, follow imports, and package the JavaScript so the app can load it on the device or simulator.
In practice, Metro matters because it powers the fast developer loop:
It watches files and rebuilds quickly.
It serves the JS bundle to the app during development.
It understands React Native-specific module resolution better than a generic web bundler.
Interviewers often check whether you understand that Metro is not the renderer itself. It prepares and serves the code, while the app still needs the native runtime and UI layer to actually display components.
Core components map React ideas to mobile UI
React Native gives you a small set of core components that act like the building blocks of mobile screens. These are not browser tags; they are abstractions over native views.
Common ones:
View: the basic layout container, similar in spirit to a div.
Text: required for rendering text on screen.
Image: displays local or remote images.
ScrollView: a scrollable container for content that can exceed the screen.
Touchable components: such as TouchableOpacity or Pressable, used for taps and gestures.
The why is important: mobile UI is touch-first and constrained by screen size, so these components are designed around native behaviors, not browser semantics.
Expo vs bare React Native
Expo is a higher-level toolchain that abstracts away much of the native setup. It is great when you want to move fast, avoid Xcode/Android Studio friction, and stay within the set of APIs Expo supports.
Use Expo when:
You are prototyping or shipping a typical app.
You want easier onboarding and simpler builds.
You do not need custom native code right away.
Use bare React Native when:
You need custom native modules or deep platform integration.
You must tweak native project files directly.
Your app depends on a library that requires native setup outside Expo’s managed flow.
Interviewers like this question because the trade-off is speed and simplicity versus full control.
How to think about app structure
A React Native project is usually organized around features and shared UI, not around web pages. The goal is to keep screen code, reusable components, and platform-specific logic easy to find.
A common structure is:
src/screens/ for top-level screens.
src/components/ for reusable UI pieces.
src/navigation/ for routing and stack/tab setup.
src/assets/ for images, fonts, and icons.
src/services/ or src/api/ for data access.
src/utils/ for small shared helpers.
This matters because mobile apps often grow into many screens and states. Good structure helps isolate UI composition from business logic, and it makes it easier to discuss lifecycle, performance, and native integration later in interviews.
A simple mobile screen using core components
Here is a small example of how React Native UI is composed from core components.
This screen uses a View as the layout container, Text for labels, Image for a logo, and Pressable for a tap target. The important thing is that none of these are HTML elements; they are mobile-friendly primitives.
A realistic mental model is: the screen file owns the layout, reusable pieces live in shared components, and data or actions are pulled in through services or hooks. That separation keeps the app understandable as it grows.
Suppose you are building a food delivery app. If the first version needs login, lists, maps, and push notifications, Expo is often the fastest path because it reduces setup overhead and lets the team iterate quickly.
Now suppose the app later needs a custom Bluetooth integration, a proprietary SDK, or a native camera pipeline that depends on direct platform changes. At that point, the bare workflow may be the better fit because you need full access to native project configuration.
The interview signal here is not “Expo good, bare bad.” The real answer is that Expo optimizes for velocity, while bare React Native optimizes for control.
Common interview traps and mistakes
Watch for these traps:
Confusing React Native with React DOM and saying they render the same way.
Calling View a div exactly; it is analogous, but it is still a native abstraction, not HTML.
Thinking Metro is the UI renderer. It bundles and serves code, but it does not draw pixels.
Saying Expo means you can never use native code. Expo abstracts a lot, but workflow choices and prebuilt native support still matter.
Assuming mobile app structure should mirror a web app one-to-one. Mobile usually benefits from screen-centric organization and clear separation of shared UI from platform-specific pieces.
In interviews, a strong answer explains the trade-offs: web React targets the browser, React Native targets native mobile components, and the project structure should support mobile screens, navigation, and device-driven concerns.