Building with Next.js and React Native

In the modern development landscape, users expect a seamless experience whether they are on their laptop or their phone. Achieving this consistency used to require two separate teams, two different codebases, and a massive amount of coordination (and frustration). Today, we have a better way.

By leveraging Next.js for the web and React Native for mobile, I can share business logic, types, and design tokens while still delivering platform-native experiences. This is the ultimate “Full-Stack” superpower.

Shared Logic, Specialized UI

The key to a successful multi-platform strategy isn’t “write once, run everywhere.” That’s a myth that usually leads to subpar experiences on both platforms. The better approach is “learn once, write anywhere,” with a focus on shared logic and specialized UI.

1. The Core: Shared Business Logic

Your state management, data fetching, and validation logic can be identical across platforms. I use tools like:

• Zustand or Redux: For global state that doesn’t care about the UI.
• TanStack Query (React Query): For data fetching and caching. The way you fetch a list of products from your API is exactly the same on a website as it is in an iOS app.
• Zod: For schema validation. If a username must be at least 3 characters, that rule should live in a shared package.

2. The Bridge: TypeScript and Design Tokens

TypeScript acts as the source of truth. By using a monorepo structure (like Turborepo), I can ensure that if a backend engineer changes an API response, both the web and mobile apps will throw type errors immediately.

Design tokens are equally important. I don’t design “screens”; I design “systems.” A PrimaryButton component might use a <button> tag in Next.js and a <TouchableOpacity> in React Native, but the spacing, color (hex codes), and typography tokens (font sizes, weights) come from the same shared JSON or CSS variable file.

The Challenge of Platform Differences

While you can share a lot, you must respect the unique affordances of each platform.

• Routing: Next.js uses file-based routing with URLs. React Native (usually via React Navigation or Expo Router) uses a stack-based or tab-based paradigm. Trying to force one into the other is a mistake.
• Layout: Flexbox works differently on the web (where it’s an addition to the box model) than in React Native (where it is the box model).
• Interactions: The web has hovers and clicks; mobile has taps and long-presses. Your shared components need to handle these variations gracefully.

Why This Wins for Startups and Solo Devs

This approach allows a solo developer or a small team to move at the speed of a much larger organization. It reduces the surface area for bugs, simplifies maintenance, and most importantly, provides the user with a familiar interface regardless of their entry point.

When you can build a feature once in your backend and shared logic layer, and then “skin” it for both Next.js and React Native, you are working at peak efficiency. It’s not about cutting corners; it’s about building a cohesive ecosystem for your product.