Does React Native create a native application or a website inside an app?

React Native uses components backed by native Android and iOS interfaces and can access platform APIs. A WebView may be used for a specific case, but it does not define the framework.

Does Expo limit access to native features?

Expo provides many modules and supports development builds, config plugins, and custom native code. Each feature still needs to be checked against the platforms and versions in use; Expo Go has a fixed native runtime and is not the product build.

Does one codebase mean the same effort on iOS and Android?

No. Shared code reduces duplication, but permissions, behaviors, devices, distribution, and some components require platform-specific implementation and testing.

Can we update the application without an app-store review?

Some non-native changes can be delivered through EAS Update within a compatible runtime. Native changes require a new build, and distribution must comply with platform rules. The update strategy needs to be defined and tested, not assumed.

Who should own the Apple, Google, and Expo accounts?

As a sound practice, the organization that owns the product should control the accounts and grant roles to the implementation team. The contract and handover should include the code, documentation, credentials, and release process.

React Native app with Expo: what is included

What React Native and Expo are

React Native is an open-source framework for Android and iOS applications built with React and platform capabilities. JavaScript or TypeScript code describes the interface and behavior, while the components are backed by native system elements. The application can access device APIs and include native modules written in Swift, Kotlin, Objective-C, Java, or C++ when the product requires them.

Expo is a framework and toolset for React Native projects: tested modules, configuration, routing, builds, and optional services for distribution and updates. Expo does not mean that the application is merely a packaged web page, nor does it make every native feature automatic. The team still needs to select modules, configure each platform, and test behavior on real devices.

What the client is buying

The installable file is only one version of the product. The client is buying research into the flow, design for touch interaction, application code, API contracts, environments, the authentication mechanism, account configuration, and a repeatable path from a change to a published version.

Product: objective, users, flows, empty states, errors, and accessibility.
Application: interface, navigation, local storage, synchronization, and offline behavior proportionate to the need.
Backend: accounts, data, rules, permissions, administration, and integrations.
Platforms: identifiers, certificates, keys, permissions, deep links, and notifications.
Quality: test builds, devices, scenarios, crash reporting, and performance checks.
Distribution: Apple and Google accounts, store listings, declarations, review, and launch.
Operations: alerts, support, updates, compatibility, and documented handover.

A proposal that only counts screens usually omits the greatest areas of risk: data, exceptions, and publication. Two applications with twenty screens can have radically different costs when one simply displays content while the other handles payments, geolocation, the camera, notifications, and offline synchronization.

The app is a system, not an isolated interface

Most mobile products depend on a backend and an administrative interface. Users create accounts, receive data, submit actions, and expect that data to remain correct on another device. The internal team needs to manage content, users, orders, or reports without direct access to the database.

What is the system of record for each type of data?
What can the application do without a connection, and how does it resolve a conflict when it reconnects?
How is a session, device, or access right revoked?
Which operations can be safely retried after a timeout?
What can the client's team administer, and what requires a new release?
How is data deleted, exported, and retained under the approved policies?

React Native does not dictate the backend. The application can consume a Node.js API, FastAPI, or another service suited to the domain. The server and database are chosen according to the rules, data, and team—not to force the same acronym across every layer.

Where native differences emerge

The camera, location, maps, Bluetooth, biometrics, files, payments, widgets, and notifications interact directly with the operating system. Some have Expo modules or mature libraries; others require native configuration or custom code. React Native provides APIs for connecting native modules and components, but compatibility must be checked against the specific versions used by the project.

Permissions have different copy, timing, and states; asking too soon can undermine trust and prevent the feature from working.
Notifications depend on the application, backend, Apple or Google services, and the device's state; delivery should never be treated as absolute.
Deep links and external authentication must be tested at installation, in the background, and after a session expires.
The performance of lists, images, and animations needs to be tested on real phones, including slower devices.
Any module containing native code may require a new build, even when the interface changes through JavaScript.

Testing, builds, and publication

EAS Build can produce installable binaries for Android and iOS and can optionally manage signing credentials, but the service does not replace testing or app-store requirements. Apple associates builds through the bundle ID and version, after which the selected application is submitted for review. Google Play uses Android App Bundles and requires signing, application information, and completion of the release workflow.

Create separate development, preview, and production variants.
Distribute internal builds to the team and a representative group of testers.
Test a new account, updates, session expiry, denied permissions, and an unstable connection.
Prepare screenshots, descriptions, category, policies, declarations, and genuine contact details.
Keep the backend and demo account available throughout the review process.
Release in a controlled way, monitor errors, and retain a version that can be investigated.

Developer accounts should be controlled by the company that owns the product, with access granted to the implementation team. A later transfer is possible under certain conditions, but getting ownership right from the beginning reduces supplier dependency and operational risk.

Updates and operations after launch

EAS Update can deliver the non-native parts of an application that includes expo-updates over the network, such as JavaScript, styles, and images. A change to the native runtime—for example, adding a native library or changing the configuration—requires a new compatible build. Channels and runtimeVersion must be managed so that a JavaScript bundle never reaches an incompatible binary.

There are separate channels and a clear rule for promotion to production.
The update is observable, reaches a controlled cohort first, and has a verification and rollback procedure.
Native changes go through the required build, testing, and distribution process.
Crashes, API errors, and active versions can be correlated.
The backend remains compatible with the application versions still in use.
The React Native, Expo SDK, and module update cycle has an owner.

What the proposal needs to clarify

Before estimating, describe how the product will be used in context. A product used in a warehouse, in the field, or with one hand has different constraints from one browsed at home. Native features and the supporting operations need to be inventoried before counting screens.

Who uses the application, on which devices, and under what connectivity conditions?
What complete journey must deliver value in the first version?
What backend, data, administration, and integrations already exist?
Which native capabilities, permissions, notifications, and deep links are required?
Who supplies the content, legal copy, and app-store materials?
Whose name will appear on the Expo, Apple, Google, cloud, and third-party accounts?
What does the remediation period include, and what falls under ongoing maintenance?
How will the code, credentials, documentation, and release process be handed over?

The right answer might be React Native with Expo, native development, or even a well-designed web experience. An installed application is justified when the mobile context, device capabilities, retention, or distribution provide enough value to warrant its operating cost.

Official technical sources consulted

The documentation below was checked on September 8, 2026. It supports the frameworks' capabilities and distribution workflows; the commercial framework and recommendations are AGE ONE's editorial analysis.

A mobile app with React Native and Expo: what the client is really buying