Exported Your FlutterFlow Code? How to Build a Signed APK/AAB Without a Local Setup

FlutterFlow's Download Code button hands you a standard Flutter project — source code, not an installable app. To turn that export into something you can put on a phone or upload to Google Play, it still has to be compiled: either on a machine with the full Flutter + Android toolchain installed, or in a cloud build service. Code2Native does the second — upload the exported ZIP (or connect the GitHub repo), and it compiles in a clean cloud workspace and comes back as a signed APK plus a signed AAB. Source compiles need Builder or Pro.

This post covers what FlutterFlow actually gates behind which plan as of October 2026, why the “just open it in Android Studio” route burns an afternoon for most people, and exactly what happens to your export when a cloud pipeline compiles it.

The wall, precisely: what FlutterFlow gates on which plan

FlutterFlow's plan lineup has changed more than once, and a lot of older blog posts describe tiers or features that moved. As of October 2026, the pricing page lists four self-serve plans (regional discounts exist, so confirm your own number):

• Free ($0) — visual builder, up to 2 projects. No Code Download, no APK Download, no store deployment. Web publishing only; the mobile app exists only inside FlutterFlow.
• Basic ($39/mo) — adds Code Download, APK Download and One-Click Store Deployment: FlutterFlow builds the AAB for Google Play itself.
• Growth ($80/mo, 1st seat) — adds Push to GitHub and more for teams.
• Business ($150/mo, 1st seat) — more seats and team features.

So if you stay on a paid FlutterFlow plan and keep building there, FlutterFlow's own deployment is the simplest route. For the first release, its Play Store guide has you download the .aab from FlutterFlow and upload it to Play's internal testing track yourself; after that, one-click deployment takes over. This guide is for the people that route does not cover:

You paid for one month, exported, and cancelled. A popular and completely legitimate move — $39 buys your source code out. But back on the Free plan there is no code download, no APK download and no store deployment, so every future update means compiling that code somewhere, and you may not have (or want) a Flutter development machine.

Someone handed you the export. A client or a freelancer built the app in FlutterFlow, you got a ZIP, and you're the person who is supposed to make it appear on Google Play.

You changed the exported code. FlutterFlow deploys the project inside FlutterFlow, not the copy you edited outside it.

One thing to carry over before you leave FlutterFlow's deployment: its builds are signed with an upload key FlutterFlow creates for you, and its deployment settings let you download that keystore. Upload it when you create the app in Code2Native. A Google Play update signed with a different upload key is refused.

Why “just build it in Android Studio” costs an afternoon

The exported project is buildable — FlutterFlow generates legitimate Flutter code. The pain is the toolchain around it: Flutter SDK, Android SDK, a compatible JDK, and Gradle all have to agree with the era of versions pinned inside your export. They frequently don't, because current Android Studio releases bundle JDK 21, while the Gradle version pinned in many FlutterFlow exports predates JDK 21 support. The first local build attempt often looks like this:

That exact message has its own issue in the FlutterFlow issue tracker and multiple community threads. The underlying error, if you dig into the Gradle log, is usuallyUnsupported class file major version 65 — Java 21 bytecode hitting a Gradle release that has never heard of Java 21. The fix menu is well documented but tedious: install JDK 17 side by side, point Flutter at it with flutter config --jdk-dir, or edit gradle-wrapper.properties to a newer Gradle — and then discover the next wall, because a newer Gradle may want a newer Android Gradle Plugin, which wants a namespace declaration that older exports don't have.

FlutterFlow-specific extras on top: most FlutterFlow apps use Firebase, so if google-services.json didn't land in android/app/ during export, the build dies at :app:processReleaseGoogleServices. And a release build needs a signing config — a keystore plus a key.properties file — that no tutorial screenshot ever seems to include. We keep a running catalog of these failures and their fixes in our Flutter build-error guide if you want to go the local route anyway.

None of this is hard for someone who ships Flutter weekly. It is a genuinely bad afternoon for someone who chose FlutterFlow specifically to avoid this layer.

What your export actually contains (this is the good news)

Unzip the download and you'll find a standard Flutter project, exactly as FlutterFlow's own docs describe it: pubspec.yaml at the root, a lib/ folder with your pages and components as Dart files, FlutterFlow's utility layer under lib/flutter_flow/, any custom widgets under lib/custom_code/, and real android/ and ios/ platform folders.

That matters for two reasons. First, you genuinely own this code — it compiles with stock Flutter tooling, with no runtime dependency on FlutterFlow. Second, it means what we do with it is a real compile of your Dart code, the same flutter build you'd run locally — not a WebView shell around a hosted preview. (If what you have is a website rather than source code, that's our other product — see converting a website to an Android app instead. Different problem, different tool.)

What actually happens when you upload it

Honest mechanics, because “cloud magic” explanations help nobody:

• Era-matched toolchain. The pipeline reads your pubspec.yaml, gradle-wrapper.properties, and AGP/Kotlin versions, then picks a Flutter + Gradle + JDK image from the same era instead of forcing everything onto today's versions. An export generated a year ago builds against a year-ago toolchain — the entire JDK-21-vs-old-Gradle class of failure never happens, and you don't downgrade anything on your machine.
• Automatic repair of the common walls. A missing Gradle wrapper gets synthesized. AGP and Kotlin get bumped to a known-working floor when they're below it. A missing namespace (the AGP 8 requirement) gets filled in from your manifest. If a build fails on a JDK quirk, it retries across the JDK 17 matrix. These fixes cover the frequent failures, not every possible one — which is why platform faults refund; customer compile errors do not.
• A real Flutter build. A FlutterFlow export is a standard Flutter project, so the pipeline runs flutter build appbundle --release and flutter build apk --release — which drive Gradle under the hood; Flutter's Android build is a Gradle build. You get both a signed APK for sideloading and an AAB for Google Play.
• Your keys, your app. Upload your own release keystore — it's reused for every future build of that project, so updates install cleanly over the old version — or let us generate one and keep it pinned to the project.
• Temporary workspace. The build runs in a clean, single-use environment that is cleaned up within days. A ZIP you upload is kept so you can rebuild (email support to have it deleted); a Git source is fetched fresh for each build.

For a normal FlutterFlow export you don't configure anything. If you do want to override the build command — say your repo keeps the Flutter project in a subdirectory — drop a code2native.json in the repo root:

Step by step: FlutterFlow export → signed APK + AAB

Your five real options, honestly compared

Competitor and FlutterFlow details below are accurate to the best of our knowledge as of October 2026 — verify current pricing before committing.

For a broader look at the cloud-compile approach beyond FlutterFlow specifically, see our guide to building Flutter APKs online.

When NOT to use us

• You iterate in FlutterFlow daily and the app changes weekly. Stay on a paid FlutterFlow plan and use its one-click deployment — round-tripping exports through any external build service will annoy you.
• You already have a working local Flutter setup. Then flutter build appbundle --release is free and instant. We add nothing to your life.
• Your project is React Native, Ionic, or Expo — those source builds are waitlist-only with us right now, not live. This post is about Flutter exports; FlutterFlow qualifies, those stacks don't yet.
• Your build needs interactive debugging or an exotic toolchain — custom Gradle plugins, NDK forks, private artifact repositories. A CI you fully control (or a local machine) serves that better than any managed pipeline.

FAQ

Which FlutterFlow plan do I need to download my code?

As of October 2026: the Basic plan ($39/mo) is the cheapest tier with Code Download, APK Download and One-Click Store Deployment. The Free plan has none of them. Growth ($80/mo) adds Push to GitHub, the nicer workflow if you plan to rebuild regularly. FlutterFlow offers regional pricing, so your exact number may differ.

Do I need a separate build if FlutterFlow can deploy?

Not while you are on a paid FlutterFlow plan and building there: Google Play needs an AAB, and FlutterFlow's store deployment builds one on every paid plan, Basic included. A separate build is for an export you took with you: you left the paid plan, someone handed you the code, or you changed it outside FlutterFlow. Then compile the exported source, locally or in a cloud build.

Is FlutterFlow's exported code really standard Flutter?

Yes. The export is a conventional Flutter project — pubspec.yaml, lib/ with your pages as Dart files, real android/ and ios/ folders — plus FlutterFlow's generated utility layer under lib/flutter_flow/. It compiles with stock Flutter tooling and has no runtime dependency on FlutterFlow. That's exactly why a real cloud compile of it is possible.

Do you modify my code during the build?

Build-configuration repairs only, applied inside the ephemeral workspace: synthesizing a missing Gradle wrapper, raising AGP/Kotlin to a working floor, adding a missing namespace. Your Dart code — pages, logic, custom widgets — is compiled exactly as exported. The repairs exist so that a project which fails on a fresh local machine still builds here.

What happens to my source code after the build?

The workspace is single-use and is cleaned up within days, pass or fail. We keep the signed binaries for you to download (for as long as our retention schedule allows), your keystore (encrypted) so future updates are signed consistently, and a ZIP you uploaded so you can rebuild — email [email protected] to have it deleted.

My app is already on Google Play via FlutterFlow's deploy — can I update it with your builds?

Usually yes. Updates must be signed with the upload key Google Play expects, which is the one FlutterFlow's deployment created. Before you leave FlutterFlow's deployment, download its upload keystore (the key button in its Play deployment settings) and upload it when you create the app in Code2Native. If you can no longer get it, request a Play upload key reset for a new keystore and upload that one before your first build; budget a day or two for Google to process the reset.