Taking a project from Firebase Studio to mobile app means an export and a second build.
Going from Firebase Studio to mobile app is two jobs, not one, and the first surprise is what the tool produces. The App Prototyping agent, the part that turns a prompt into a working product, generates Next.js apps. Next.js is a web framework. A phone can open the result in a browser, and neither app store will take it. If you landed here from a roundup of AI app generators, that single distinction is most of the story.
There is a second thing to know before planning anything. Firebase Studio is closing. New workspace creation and user signup were disabled on June 22, 2026, and the environment shuts down on March 22, 2027, at which point remaining data is permanently deleted. This page covers what Studio outputs today, how to get your code out, and what is left to do before an app is on a phone.
See what each workspace hands youThe short version
The agent makes web apps, so the mobile app is still yours to build.
Firebase Studio is a cloud development environment with two different halves. The App Prototyping agent takes a prompt and generates a Next.js web app, and Google's own documentation says other platforms and frameworks are planned rather than available. The template gallery is the other half: Flutter, Android Studio, React Native and React Native with Expo all appear there. A template is a configured empty project, not a generated app. You write it.
So there is no control that turns a Studio prototype into an iOS or Android build. Reaching a real mobile app means exporting the code and doing the mobile work somewhere else. Since the workspace itself closes in March 2027, that export is not optional anyway.
What Firebase Studio outputs today
Start with the part people get wrong. The App Prototyping agent, the piece that makes Firebase Studio feel like magic, generates Next.js apps. Google's documentation states that plainly and adds that other platforms and frameworks are planned for the future. What comes out is a website with a backend behind it. It is not a React Native project and it is not a Flutter project.
The agent wires that app into Firebase as it goes. It can add Authentication and Firestore, and it uses Genkit flows for the AI parts. Publishing runs through Firebase App Hosting, which needs a Cloud Billing account on the Blaze plan. All of that is real and useful. None of it is a mobile build.
The Firebase Studio mobile story lives in the template gallery instead, and templates are a different kind of thing. The Firebase Studio React Native template sits in that gallery next to React Native with Expo, Flutter and Android Studio. Each one gives you a configured project and an editor in the browser. None of them writes your app for you, and none of them produces a signed release.
Preview deserves the same precision. The documentation describes web previews on Chrome, and Android emulators in Flutter workspaces that install your app on the preview environment. There is no iOS preview and no iOS build. If you are on a Windows machine hoping Studio solves the Mac problem for iOS, it does not.
Firebase Studio docs, get started with the App Prototyping agent
Try it
What your workspace actually hands you
Pick how the project started. The gap between that and an app on a phone is the work nobody budgets for.
What you get
A Next.js web app generated from your prompt.
On a phone
Opens in a mobile browser. There is no iOS or Android binary.
Still to do
Rebuild the screens in a mobile project, or keep it as a website.
The dates that decide your plan
Firebase Studio is sunsetting, and Google announced it on March 19, 2026. On June 22, 2026 new workspace creation and user signup were disabled, so a reader without a workspace today cannot make one. On March 22, 2027 the environment is shut down and all remaining data is permanently deleted.
Two things survive that date. Apps you already deployed to Firebase keep running, and the core Firebase products are not affected: Cloud Firestore, Authentication and App Hosting carry on as normal. What disappears is the development environment, which is to say the place your source code is sitting right now.
Firebase Studio app export is therefore a deadline rather than a preference. The documentation gives three routes out. A Move now control at the top of the workspace offers Zip and Download. In the terminal you can run npx firebase-tools@latest studio:export followed by a path. You can also export the workspace to GitHub, which is the one worth taking because you keep the history instead of a folder.
Google's own suggested destinations are Google AI Studio for a web based path and Google Antigravity for a code first one, with exporting and hosting the result yourself listed as a third option. None of those three is a mobile app builder, which is what the rest of this page is about.
Why a web export is not a mobile app
Say you have the zip. It holds a Next.js project: pages, API routes, components, a package.json. Everything in it assumes a browser. Routing is URLs, layout is CSS, and anything that touches the device does it through web APIs with whatever permission the browser allows.
A mobile app is a different target. Screens are native views, navigation is a stack rather than an address bar, the camera and push notifications and the keyboard all behave differently, and the whole thing has to be compiled, signed and submitted. None of that is a setting you flip. It is a rewrite of the front end against the same data.
That is not a reason to feel the work was wasted. The schema, the security rules, the copy, the flows and every decision about what the product does are the expensive part, and all of it carries over. What does not carry over is the code. If a phone app was the goal from the start, a text to app tool that targets mobile directly skips this step completely.
So the real choice is porting or restarting. Porting means reading your Next.js app and writing the same screens again in React Native or Flutter. Restarting means describing the product once more to a tool that outputs a mobile project. For a prototype of a handful of screens, restarting is usually the faster of the two, and you get to fix what the prototype got wrong.
The data layer travels, the app shell does not
This is less painful than it sounds because the half you keep is the half that is hard to rebuild. Firestore collections, security rules, Authentication providers and any Cloud Functions you wrote live in your Firebase project, not in the Studio workspace. They are untouched by the sunset, and a mobile client talks to them with the standard Firebase SDKs.
So the port is front end only. Point a new mobile project at the same Firebase project, keep the collection names and the rules, and the data your prototype has been writing is already sitting there. If you have not settled the data layer yet, or you are wondering whether Firebase is the right home for it at all, the tradeoffs are laid out in this guide to a vibe coding backend database.
One warning about rules. A rule set that was fine while only your own prototype touched it is not automatically fine once the app is in a store and strangers are holding the client. Rules are the only thing between a public app and your collections, and a generated prototype is not a security review.
What each route out of Firebase Studio gives you
| Route out | Source you can download | Preview while you build | Ships to a store | Still there after March 2027 |
|---|---|---|---|---|
| App Prototyping agent | Yes | web preview | No | No |
| Flutter template workspace | Yes | web and Android emulator | you build it elsewhere | No |
| React Native or Expo template | Yes | not documented | you build it elsewhere | No |
| Export to GitHub, then build it yourself | Yes | No | once you set up builds | Yes |
| Describe it again to a mobile app builder | Yes | Yes | with your own Apple account | Yes |
Building the mobile app rather than porting one
If the prototype proved the idea and the idea is a phone app, the shortest path is usually to describe it again to something that outputs a mobile project. You already know what the screens are, what the data looks like and which parts the prototype got wrong. That is a far better brief than the one you started with.
Newly is an AI app builder. You describe the app in plain English, it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It also produces a standalone production APK with the JavaScript bundled. Plans are $25 a month and there is no free plan. iOS goes through TestFlight and App Store Connect, so you need your own Apple Developer account. There is no built-in payments layer. You can connect a GitHub repository you own from the Deploy tab and keep the two in step, or pull the code out with npm i -g @newly/cli and then newly pull with your project id.
Whatever you use, the step people underestimate is the one after the code compiles on a laptop. Signing, provisioning, store listings and review all sit between a working project and a tester holding it, and turning it into an installable build is worth reading before you promise anyone a date.
Questions people ask about moving off Firebase Studio
Not from a prompt. The App Prototyping agent generates Next.js apps, which are web apps, and Google's documentation says other platforms and frameworks are planned rather than available. The template gallery does list Flutter, Android Studio, React Native and React Native with Expo, but those are starter projects you write yourself, and the build and signing happen outside Studio.
Describe the app you prototyped, this time for a phone
You already know the screens, the data and where the prototype was wrong. Start from that brief and get a mobile project out the other end.
Start building