How to Get Your APK Out of Firebase Studio Before It Shuts Down

Short answer: Firebase Studio has never had an “Export APK” button — its App Prototyping agent generates full-stack web apps, and no export path Google offers produces an Android binary. The fastest way to a real APK is to deploy your prototype to a live URL (many already run on Firebase App Hosting) and wrap that URL into a signed APK/AAB, which takes a few minutes. If your workspace holds a Flutter project, export the code as a zip and have it compiled directly instead.

The situation, without the panic

Google announced the Firebase Studio sunset on March 19, 2026. Since June 22, 2026, new workspace creation and new signups have been disabled — if you have a workspace, you can keep working in it, but nobody new gets in. The hard deadline is March 22, 2027: Firebase Studio shuts down and, per Google's own migration docs, all remaining workspace data is permanently deleted and cannot be recovered.

Two things worth saying plainly, because the anxiety around shutdowns tends to blur them. First, this is not Firebase dying. Cloud Firestore, Authentication, App Hosting — the backend services your prototype talks to — are unaffected. Only the Studio development environment is going away. Second, you have months, not days. As of mid-2026 there is no reason to make a rushed decision at 2 a.m.

But there is a reason not to procrastinate: the code sitting in a workspace you haven't opened since spring is on a countdown, and Google's official migration paths — moving web prototypes to Google AI Studio, or exporting code into the Antigravity IDE — keep your project alive as a project. Neither of them turns it into an installable Android app. If “can I put this on my phone?” is the question that brought you here, migration alone won't answer it. We wrote about the same gap on the destination side in Google AI Studio app to APK — the place Google is pointing you toward doesn't output APKs either.

Step 0: export your code today, whatever else you do

Before any app-building decision, do the ten-minute thing that removes all deadline pressure. In your Firebase Studio workspace, either sync the project to GitHub or use Zip and Download to pull the full source to your machine. Do both if you're paranoid; we are. Once the code lives somewhere you control, March 2027 stops being a threat and becomes a calendar entry.

While you're in there, note which kind of project you actually have, because it determines your route below. Most Firebase Studio prototypes are Next.js web apps generated by the App Prototyping agent. Some workspaces hold Flutter projects instead — Studio shipped Flutter templates, and plenty of people built real apps on them. The two get treated very differently by any build pipeline, ours included.

Route 1: wrap your deployed URL (most prototypes end up here)

If your prototype is a web app — and if the App Prototyping agent built it, it is — the shortest path to Android is the same one we recommend for every web-first builder: deploy it to a live HTTPS URL, then wrap that URL in a native Android shell. Concretely:

1. Deploy the app. Firebase App Hosting is the natural home for a Studio-generated Next.js app and survives the Studio shutdown; Vercel or Cloud Run work just as well. If your prototype already has a published App Hosting URL, this step is done.
2. Paste the URL into a wrapper build. You configure the app name, package ID, icon, and splash screen in a dashboard — no Android Studio, no SDK.
3. Get back a signed APK and AAB. The APK installs directly on most Android phones; the AAB is the format Google Play requires for store submission. For Google Play, create the app as a Google Play app and upload your own keystore while you create it; without one, a website app is signed with a Code2Native platform key that many apps share. Either way the key is fixed from the first build on, so update five installs cleanly over update one. A build typically finishes in about three minutes.

The wrapper is a real Android application — push notifications via OneSignal, hardware back button that follows your app's history, offline screen, native handling of mailto: and tel: links. And because it renders your live site, every change you deploy reaches installed phones instantly, with no rebuild and no store review. For a prototype you're still actively migrating and editing, that matters more than it sounds.

One honest caveat that applies to every wrapped web app, not just Firebase Studio's: a URL, even a polished PWA, is not itself something you can submit to Google Play. Play wants a signed AAB from a real Android project. That gap — between “works in a browser” and “installable, store-submittable binary” — is precisely the thing the wrapper closes. The mechanics are the same as in our website to Android app guide, which walks the process step by step.

Route 2: you have Flutter source (build it directly)

If your Firebase Studio workspace holds a Flutter project, you can skip deployment entirely: zip the exported project, upload it, and get a compiled, signed APK/AAB of your actual code (on a Builder or Pro plan). Our pipeline builds Flutter and native Android (Gradle) projects on machines with the SDK, JDK, and Gradle already installed — and it auto-repairs the failures AI-generated projects hit constantly: missing Gradle wrappers, stale Android Gradle Plugin and Kotlin versions, missing namespace declarations, dead jcenter() repositories. If a build fails anyway, you see the actual failing Gradle task in plain language; a failure on our side is refunded, one caused by your own code is not.

Two boundaries, stated plainly so you don't waste an upload. First, a Next.js export from the App Prototyping agent is not buildable Android source — there is nothing Android in it to compile, which is why Route 1 exists. Second, React Native, Ionic, and Expo source builds are on our waitlist, not live. If your project is one of those, wrap the deployed URL today and join the waitlist for the source path; we won't pretend otherwise.

Your options, side by side

Google's details below are accurate per their migration documentation as of mid-2026 — confirm current specifics on their site, since sunset logistics can shift.

Note that the rows aren't mutually exclusive. The sane default is: export your code now, migrate the prototype wherever you plan to keep iterating, and wrap the deployed URL so people can actually install the thing this week.

Who should do what

• You prototyped a web app and it's deployed (or trivially deployable). Wrap the URL. You'll have a signed APK on a real phone today, and every future edit ships without a rebuild. This is the strong, boring, correct path for most Firebase Studio users.
• You built Flutter in Studio. Zip and upload the source. You get a compiled build of your exact code, signed with a keystore that stays consistent across every rebuild.
• You want to keep vibe-coding. Take Google's migration to AI Studio — it's the anointed successor for web prototyping — and come back for the wrapper when you want an installable build. The same URL-wrapping route works from there too.
• You enjoy toolchains or need deep native customization. DIY with Capacitor and Android Studio is free and legitimate. Budget real time for the SDK, Gradle, and keystore learning curve, and remember every app update repeats the build-and-sign cycle.
• You're coming from another sunsetting or limited builder. The playbook generalizes — we wrote the same honest walkthrough for Glide apps, and the pattern holds: deployed URL in, signed binary out.

What this costs, exactly

Your first build is free — one Preview APK with the Powered by Code2Native mark on the bottom strip, so you can judge the result on a real device before paying anything. After that, an App license is $69 one-time ($39 in some regions) for the release APK and AAB of a wrapped site, with unlimited Android rebuilds at no credit cost. Compiling Flutter source needs Builder ($39/month) or Pro ($99/month; $390 and $990 a year). We take cards via Stripe and USDT (TRC20 or Arbitrum).

And the iOS disclaimer we put in every post, because it's true: on Apple's side we build an unsigned .ipa on real Apple silicon that you re-sign with your own Apple Developer certificate, or a zero-signing Web Clip. We do not submit to the App Store for you, and we never need your Apple ID. Anyone promising one-click App Store publishing without your own Apple account is selling something that doesn't exist.

FAQ