React Native Framework vs No-Framework: Build Your First App with Expo, Navigation, and Native APIs

If you are starting a new React Native app, one of the first choices you will face is whether to use a framework like Expo or go bare and assemble everything yourself. The short answer from modern React Native guidance is clear: yes, you can build without a framework, but for most new apps, a framework is the better starting point.

In this tutorial, we will compare both paths in practical terms, then walk through a beginner-friendly app setup using Expo, navigation, and native device APIs. Along the way, you will see why a framework reduces setup work, simplifies maintenance, and gets you to a real app faster. You will also learn when a no-framework approach can still make sense.

React Native is designed to help JavaScript and React developers build native mobile apps with shared code. For teams that want cross-platform mobile development without duplicating every feature for iOS and Android, that is a major advantage. But the starting architecture you choose affects everything that follows: navigation, native integrations, build complexity, update flow, and debugging overhead.

The latest guidance recommends using a framework for new projects because common app needs are already solved there. React Native communities have spent years refining approaches to navigation, native APIs, and dependency management. If you skip the framework, you are responsible for recreating that skeleton yourself or stitching together multiple libraries. That is possible, but it adds setup time now and maintenance cost later.

This is exactly why many developers prefer an Expo tutorial path when beginning a fresh project. Expo gives you a productive default experience while still leaving room for native capabilities when your app needs them.

Using a framework

A React Native framework gives you core capabilities from the start:

• Navigation patterns that are ready to use
• Access to device APIs and native features
• Handling for native dependencies
• A cleaner path for app updates and maintenance

Instead of spending days wiring up your app skeleton, you can focus on building screens, business logic, and user experience.

Going bare

A no-framework setup can work well if your app has unusual constraints, or if you want full control over every native layer. In that case, you can build directly with Android Studio and Xcode. That flexibility is real, but so is the cost. You will need to manage environment setup, platform-specific configuration, and each dependency choice on your own.

For most teams, the bare approach only makes sense when the app is highly specialized, has strict integration requirements, or must fit an existing native architecture that a framework does not serve well.

We will create a simple cross-platform app that demonstrates the essentials of modern React Native app development:

• Expo project setup
• File-based navigation
• A TypeScript-friendly structure
• Access to a native device API
• A clean path for future features like push notifications, camera access, and forms

The goal is not to build a giant product in one article. The goal is to help you understand the modern starting point for React Native tutorials and see how the pieces fit together in a real app.

Expo is the fastest way to begin for most new React Native projects. It reduces friction in the setup process and gives you sensible defaults for development, testing, and iteration.

If you are building your first app, the Expo path is especially useful because it lets you move from idea to screens without spending your first session resolving environment problems.

npx create-expo-app@latest MyFirstApp

Choose a template that fits your stack. If you are comfortable with TypeScript, pick the TypeScript version so your app has typing from day one. That will help as your codebase grows and your navigation structure becomes more complex.

Then run the project:

cd MyFirstApp
npx expo start

At this point, you already have a development loop that works across devices. That is one of the biggest wins in React Native app development: less time on environment setup, more time on product.

Navigation is one of the most common reasons developers adopt a framework rather than starting from scratch. The React Native ecosystem has matured around robust navigation patterns, and Expo works especially well with current routing approaches.

If you are using Expo, the Expo Router guide approach is a natural fit for small and medium projects. It lets your app structure mirror your file structure, which makes onboarding and maintenance easier.

For example, your app can start with a few basic routes:

• Home screen
• Details screen
• Settings screen

A file-based structure is intuitive because each screen is represented by a route file. That means less boilerplate and clearer conventions for teams.

Here is a simple example of a home screen with navigation links:

import { Link } from 'expo-router';
import { View, Text } from 'react-native';

export default function HomeScreen() {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text>Welcome to MyFirstApp</Text>
      <Link href="/details">Go to details</Link>
    </View>
  );
}

This is a simple react native navigation pattern, but it reflects a larger point: framework-based routing helps you ship real structure early. That matters because navigation mistakes become expensive once your app has authentication, tab bars, modal flows, and deep links.

One reason developers choose React Native is access to native device capabilities without abandoning shared code. In a framework-driven setup, those integrations are far easier to adopt incrementally.

For a first app, you might expose a small native API such as battery state, network status, or device orientation. These are good examples because they demonstrate platform awareness without overwhelming the tutorial.

Here is a simple React Native example using a common device API pattern:

import { useEffect, useState } from 'react';
import { Text, View } from 'react-native';
import * as Battery from 'expo-battery';

export default function BatteryScreen() {
  const [level, setLevel] = useState<number | null>(null);

  useEffect(() => {
    async function loadBattery() {
      const batteryLevel = await Battery.getBatteryLevelAsync();
      setLevel(batteryLevel);
    }

    loadBattery();
  }, []);

  return (
    <View>
      <Text>Battery level: {level === null ? 'Loading...' : `${Math.round(level * 100)}%`}</Text>
    </View>
  );
}

This example shows the core promise of React Native app development: you can create a native-feeling experience while writing familiar React code. From here, it becomes easier to expand into more advanced areas such as React Native push notifications, camera access, or sensor-driven UX.

If you are building with React Native TypeScript, you gain useful safeguards as your app grows. Types are especially helpful when you start passing params through navigation, handling form validation, or working with API responses.

TypeScript also makes refactoring less risky. That matters in React Native because app requirements tend to change quickly. As routes, native modules, and shared UI components multiply, typed code helps you catch mistakes before they become runtime bugs.

A simple typed component might look like this:

type Props = {
  title: string;
  subtitle?: string;
};

export function Header({ title, subtitle }: Props) {
  return (
    <>
      <Text>{title}</Text>
      {subtitle ? <Text>{subtitle}</Text> : null}
    </>
  );
}

When paired with Expo and a clear route structure, TypeScript becomes one of the simplest ways to improve reliability without adding much overhead.

Once your app skeleton works, you can layer in the features that most production apps need. Framework-based React Native tutorials are useful because they give you an expandable base rather than a one-off demo.

Some of the most common next steps are:

• React Native form validation for sign-up and settings screens
• React Native authentication tutorial patterns for login and protected routes
• React Native bottom sheet interactions for actions and filters
• React Native dark mode support for theme-aware UI
• React Native FlatList example patterns for long lists and feeds

Starting with a framework makes these additions easier because you are not building the app skeleton at the same time. The more time you save on plumbing, the more time you have for product polish.

Even though a framework is the recommended default for new apps, there are valid exceptions.

Go bare if:

• You have unusual native requirements that do not fit the framework model
• You need tight control over Android and iOS project configuration
• Your team already has strong native engineering workflows in place
• You are integrating with a legacy codebase and must preserve a custom setup

In those cases, starting from Android Studio and Xcode may be the correct choice. But this should be intentional, not accidental. If your app does not have special constraints, using a framework will usually get you to a better result faster.

One of the strongest arguments for using a framework is long-term maintenance. When you assemble everything yourself, every update becomes your responsibility: dependency compatibility, native module upgrades, navigation behavior, and build stability.

That maintenance burden matters because React Native evolves quickly. If you are focused on React Native performance and React Native debugging, you already know how much time can be spent tracking down platform-specific issues. A framework reduces the surface area for those issues by standardizing the app foundation.

It also helps with app startup time and app size optimization because the framework ecosystem tends to align around tested defaults and shared best practices. You still need to measure, profile, and tune, but you are starting from a stronger baseline.

If you want a solid first app, a simple architecture is usually enough:

1. Expo for project setup and tooling
2. Expo Router for navigation structure
3. TypeScript for safer refactoring
4. Reusable UI components for screens and layout
5. Native APIs only when the product needs them

This approach balances speed and control. It gives you a production-friendly foundation without overengineering the early stages of the app.

After your first app is running, you can expand in several practical directions:

• Add authentication and protected routes
• Build a feed with performant list rendering
• Implement push notifications
• Integrate the camera for capture workflows
• Set up testing with React Native Testing Library
• Prepare builds for iOS and Android release pipelines

If you are exploring more advanced mobile experiences, it is also worth reading about adaptive camera UX, foldable-ready layouts, tablet-first design, and battery-aware experiences. Those topics become much easier to tackle once you have a clean framework-based starting point.

For most new React Native apps, the framework-first path is the smartest choice. Expo accelerates setup, navigation is easier to structure, native APIs are accessible without heavy configuration, and long-term maintenance is far simpler than stitching together everything yourself.

No-framework React Native still has a place, especially when your app has unusual constraints or an existing native architecture. But if you are starting fresh and want the fastest path to a real cross-platform app, begin with Expo, add navigation early, and layer in native APIs only as needed.

That is the modern React Native tutorial mindset: optimize for shipping, keep the foundation simple, and choose tools that let you spend more time building the app than building the framework around it.