# Mobile apps (iOS and Android)

> ESTAGE builds real React Native apps from the same AI chat — preview them on your phone with a QR code and publish to the App Store, TestFlight, and Google Play.

Source: https://support.estage.com/platform-mobile-apps
Part of the ESTAGE Support help center (https://support.estage.com). Full knowledge base: https://support.estage.com/llms-full.txt

---

**ESTAGE includes an AI mobile app builder.** Describe the app you want and Genesis builds a real
**React Native (Expo)** application for iOS and Android — not a web page in a shell, not a
progressive web app. It is the same chat, the same live preview, and the same visual editing you
use for a website, pointed at a different target.

## Starting an app

Two ways in:

- **A new app** — start a new project and choose **Mobile app** in the "What are you building?"
  chooser on the [dashboard](https://support.estage.com/workspace-dashboard).
- **An app next to an existing site** — add a *Mobile app* to a project you already have. One
  project can hold a Website, a Web app, a Mobile app and a
  [Desktop app](https://support.estage.com/platform-desktop-apps) side by side; each keeps its own chat, its own files, and
  its own preview, while sharing the project's team and domain.

The mobile builder is part of the **ESTAGE Atlas** plan. If it isn't on your account yet, the
Mobile app card says so and unlocks it in place — pick monthly or annual, and the builder is
available straight after.

You can also start from someone else's work: mobile apps published to the ESTAGE marketplace
install into your account as a full, editable project, the same way site templates do.

## Seeing it on your phone

Apps preview through **Expo Go**, the free Expo client from the App Store or Google Play. The
builder shows two QR codes:

- **Live preview** — points at your running build. Scan it and every change you ask for appears on
  the phone as you work.
- **Shareable QR** — a published snapshot of the app. It keeps working after you close the
  builder, so you can send it to a client or a tester and they can open the app whenever they
  like. Publish again to update what they see.

Both need Expo Go installed on the phone. This is a preview tier, not a store install.

## Publishing to the stores

The **Publish app** button in the builder header opens a three-step wizard, and everything it does
is also in **Settings → App Stores**, where the build history lives.

1. **Where** — the App Store, Google Play, or both.
2. **Store keys** — connect the account you publish under. For Apple that is an **App Store
   Connect API key** (`.p8` file plus its Key ID and Issuer ID); for Google, a **service account
   key** (`.json`) and the release track you want. Keys are verified when you save them,
   encrypted, and never leave the server.
3. **Build and submit** — a real, signed binary is built in the cloud (usually 10–20 minutes),
   then submitted. You can close the wizard and come back; the status keeps updating.

iOS goes to **TestFlight** first, so you can test with real people before the App Store review.
Android goes to the track you chose in **Google Play**.

**Signing is handled for you.** ESTAGE creates and reuses the iOS distribution certificate and
provisioning profile from your App Store Connect key, and Android uses a managed upload keystore —
there is no certificate dance to do by hand. The app is still published under *your* developer
identity, because the app belongs to you.

> **Caution: Create the app in the store first**
>
> Neither Apple nor Google lets anyone create the app record through their API, so this one step is
> manual and only happens once: add the app in **App Store Connect** and/or the **Google Play
> Console** using the bundle id / package name the wizard shows you. Submitting before that fails
> with "app not found".

## What the app can use on the device

Mobile projects are native, so they reach the phone's own hardware and system views. The AI picks
versions of these libraries that are compatible with your app's Expo build, so you ask for the
feature rather than for a package:

| Ask for | What lands in the app |
| --- | --- |
| *"let people take a photo"* | The device **camera** |
| *"let them pick an image from their phone"* | The system **photo picker / gallery** |
| *"play this video in the app"* | Native **video playback** |
| *"use these icons / this logo"* | **SVG** graphics rendered natively |
| *"show our help center inside the app"* | An embedded **web view** |

## What's different from the website target

The app is native, so the web-shaped pieces of the platform don't apply to it — order forms, the
tracking pixels, and one-click localization are website features. What stays the same is the way
you work: describe changes in chat, watch them appear, revert a turn you didn't like, and open the
code when you want to.