← All

React Native chat app: solo builder guide

Anything
Anything
React Native chat app: solo builder guide

Building a React Native chat app gets hard once the basics appear. You have to make decisions about:

  • Real-time messages
  • Push notifications
  • Offline sync
  • App Store compliance

Those decisions can stall a solo project fast. The usual traps are practical: a backend that does not fit the job, a slow message list, or review risk from missing report-and-block features.

A solo React Native chat app needs a managed real-time backend, an optimized message list, push notifications, and a publishing checklist tied to current store rules.

A first-version estimate put pricing at $15K-$40K pricing and timing at two to six months. Those numbers can push a solo builder toward AI-assisted tooling, but a chat app still needs careful handling of auth, storage, and moderation. The fastest practical path is a managed real-time backend, an optimized message list, and a publishing checklist tied to current store rules.

The pieces every chat app needs

A production React Native chat app runs on several components working together. Miss one and the app feels broken to users, even if the code compiles.

The pieces are:

  1. The React Native mobile app that displays messages and handles notifications
  2. A real-time transport layer such as WebSockets, Firebase Firestore, or Supabase Realtime
  3. A backend service that manages connections, stores messages, and triggers notifications
  4. Push notification services, meaning Firebase Cloud Messaging for Android and the Apple Push Notification service for iOS

A key distinction trips up new builders. Push notifications are one-way alerts that fire when the app is closed. WebSockets and real-time listeners handle two-way live communication while the app is open.

You need both in most chat apps. A chat app without notifications is a good way to get zero users.

Choosing a real-time backend that fits a solo budget

A managed service bundles real-time sync, auth, and offline support so you write product code instead of infrastructure. A self-hosted WebSocket server gives you control, but it also makes you build more support systems yourself.

Firebase remains a strong first-version fit for new React Native chat apps. It bundles real-time sync and authentication. It also covers offline persistence and push notifications through one software development kit with no backend server required.

Supabase gives you open-source and database control. Firebase gives more mobile pieces in one kit, which usually matters more for a solo launch.

Free-tier limits that actually matter

The free tier determines how far you can validate before paying anything. Here is what the main solo-builder options give you at zero cost:

Firebase charges per document operation, which can be harder to predict than Supabase. Supabase free tier details include unlimited API requests and 500 MB database storage.

When a self-hosted WebSocket makes sense

A self-hosted setup gives you control, but you build the product infrastructure yourself. A plain self-hosted WebSocket server only handles live transport.

You still need separate systems for:

  • Authentication
  • Message persistence
  • Push notifications
  • Offline sync

For most solo builders, that overhead is not worth it for a first launch. Start with a managed backend and switch later if scale or cost demands it.

Building the message list without performance bugs

The wrong list component will lag and drop frames. It can also burn memory on long chats. This is a common chat performance mistake in React Native.

Use FlatList for long message lists. A ScrollView renders all child components, which slows rendering and inflates memory on long lists. FlatList renders items lazily as they approach the screen and removes items that scroll off. That reduces memory use and processing time.

FlatList settings that prevent lag

These settings separate a smooth list from a janky one, and each one addresses a specific render cost:

  • keyExtractor setting: required for caching and tracking item re-ordering
  • getItemLayout: when all items share the same height, this removes async layout calculations, described in the docs as desirable optimization
  • React.memo() memoization: memoize message components so they re-render only when props change
  • useCallback renderItem: avoid anonymous functions inside the JSX renderItem prop

A minimal optimized setup looks like this:

<FlatList
  keyExtractor={item => item.id}
  renderItem={({ item }) => <MessageBubble {...item} />}
  initialNumToRender={20}
  maxToRenderPerBatch={20}
/>

If you scroll fast, content is rendered asynchronously offscreen, so blank content may momentarily appear. When that becomes noticeable, FlashList and Legend List are third-party list libraries tuned for performance.

For pagination in large chats, query Firestore with orderBy('createdAt', 'desc') and limit(20), then load older messages with cursor pagination.

Adding push notifications the practical way

Expo simplifies enough of this to make it manageable solo. The practical flow has three parts:

  1. Your app registers with Firebase Cloud Messaging on Android or the Apple Push Notification service on iOS and receives a device token.
  2. Your backend sends a notification request with that token and a payload.
  3. The push service delivers it to the device.

The Expo push layer handles much of the Firebase Cloud Messaging and Apple Push Notification service complexity. That lets you treat Android and iOS notifications the same way.

Token handling has a choice. getExpoPushTokenAsync() returns an Expo-managed token that routes through Expo service. getDevicePushTokenAsync() returns the native token for direct delivery. On iOS, your server must pass the device token unmodified back to APNs when sending notifications.

Set up a notification handler and notification listeners early:

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldPlaySound: true,
    shouldSetBadge: true,
    shouldShowBanner: true,
    shouldShowList: true,
  }),
});

What the New Architecture changes for you

The React Native New Architecture transition is finished, and new projects start on it by default. For a fresh build, you usually do not need to turn anything on before you start.

The timeline moved fast. React Native 0.76 in October 2024 made the New Architecture the default setting. React Native 0.82 in October 2025 made it the only architecture, with newArchEnabled=false flags silently ignored.

The versions page listed React Native 0.86 as stable in June 2026. For chat apps, the New Architecture removes asynchronous bridge between JavaScript and native. It replaces that bridge with a JavaScript Interface that allows synchronous layout access.

In January 2026, roughly 83% adoption among SDK 54 projects built with Expo build tooling used the New Architecture. If you start today, you are already on it in most fresh React Native workflows.

Where AI app builders fit a solo workflow

AI app builders work best as scaffold generators and iteration accelerators when you do not want to write every line yourself.

Use a hybrid workflow:

  1. Generate a scaffold.
  2. Sync it to a GitHub repository.
  3. Customize the code with an AI assistant.
  4. Prepare the app for submission.

During submission prep, review the app by hand across auth, notifications, storage, and moderation. When you evaluate a builder, prioritize:

  • Source-code export
  • GitHub sync
  • Expo output for iOS mobile builds
  • Clear ownership of the generated code

That protects you from getting trapped in a proprietary runtime. With us, you get full GitHub Sync and complete code ownership. Our current mobile path is iOS deployment through Expo, with Android in development.

We do not yet support offline-first apps, and WebSocket support is limited. For a chat app, that means you should plan to export code when custom real-time or offline behavior matters.

Be realistic about AI assistants. They can help with boilerplate and extending existing structure, but deep problems often need several back-and-forth rounds. Leaning too hard on agent workflows can make it harder to know your code.

Pair TypeScript with an assistant so static checking and human review catch problems before code ships. Try Anything free if you want a builder that exports real code and syncs to GitHub.

Passing App Store and Google Play review

Apple tightened rules for random and anonymous chat. Google Play requires report-and-block functionality to be readily accessible within the app. A missing feature can mean rejection, so map these requirements before you submit.

Apple reviews 90% of submissions in under 24 hours, and over 40% of unresolved issues relate to Guideline 2.1, covering crashes and placeholder content. The February 6, 2026 guideline revision put apps with random or anonymous chat under the Guideline 1.2 user-generated content rule.

Check support and privacy links before submission. Broken or placeholder pages create avoidable review risk.

Google Play adds its own gates for chat apps:

On security, do not store sensitive API keys in app code, since anything in code can be read in plain text by anyone inspecting the bundle. Treat access tokens and refresh tokens as sensitive. Private user content needs the same care, and the app should persist as little of it locally as possible.

What a realistic outcome looks like

A realistic launch path stays narrow: working messages first, then speed, notifications, and store readiness. The first milestone is usage from real people, and revenue can follow.

Indie Hackers examples include app revenue in the $500-$5,000 monthly range. One solo developer grew Habit Pixel to $1K MRR in eight months after a May 2025 launch.

If you are building your first chat app, keep the path narrow:

  • Start with Firebase for bundled real-time sync and offline support.
  • Optimize your FlatList from the beginning.
  • Wire push notifications through Expo before you polish the interface.
  • Map report-and-block and privacy requirements into the build early.

Ship the smallest version that lets users message each other, then improve it based on what real users actually do. If you want to scaffold the first version before wiring the chat backend, start in Anything.

More from Anything