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 Play-ready AAB. The first build is free.

This post covers what FlutterFlow actually gates behind which plan as of mid-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 changed in mid-2025, and a lot of older blog posts describe tiers that no longer exist. As of mid-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. Your app exists only inside FlutterFlow.
• Basic ($39/mo) — adds Code Download and APK Download. This is the cheapest tier where you can get your source out.
• Growth ($80/mo, 1st seat) — adds Push to GitHub, the VS Code extension, and One-Click App Store Deployment — which is where FlutterFlow's Google Play (AAB) pipeline lives.
• Business ($150/mo, 1st seat) — team seats, CLI access, Figma frame import.

Three walls fall out of that matrix, and they map to the three kinds of people who land on this page:

Wall 1: you're on Basic and need an AAB, not an APK. The Download APK button gives you exactly that — an APK, fine for sideloading onto a test device. But Google Play has required the AAB format for new apps since August 2021, and FlutterFlow only produces an AAB through its Play Store deployment flow, which sits on the Growth plan. There is a FlutterFlow community thread literally titled “is it possible to download app bundle instead of APK with the standard plan?” — and the answer is no. On Basic, the intended path is: download the code, build the AAB yourself.

Wall 2: you paid for one month, exported, and cancelled. A popular and completely legitimate move — $39 buys your source code out. But now every future update means compiling that code somewhere, and you may not have (or want) a Flutter development machine.

Wall 3: 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.

Worth knowing even if you dopay for Growth: as of mid-2026, FlutterFlow's one-click Play deployment only works after the very firstAAB has been manually uploaded to Google Play Console's internal testing track. So a real compile of your project happens at least once regardless of plan — the only question is where.

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 eraof 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.jsondidn'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 buildyou'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 a failed build automatically refunds the credit.
• 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.
• Ephemeral workspace.The build runs in a clean, single-use environment, and your source is deleted after the build completes. We return binaries; we don't retain code.

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 mid-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. Pay for Growth and use one-click deploy — 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 mid-2026: the Basic plan ($39/mo) is the cheapest tier with Code Download and APK Download. The Free plan has neither. Growth ($80/mo) adds GitHub push, which is the nicer workflow if you plan to rebuild regularly. FlutterFlow offers regional pricing, so your exact number may differ.

FlutterFlow has a Download APK button — why isn't that enough?

Because Google Play doesn't accept APKs for new apps — it requires the AAB format, and FlutterFlow only produces an AAB through its Play deployment pipeline on the Growth plan. The Basic-plan APK is for sideloading and testing. If you want a Play-ready AAB without the $80/mo tier, compiling the exported source — locally or in a cloud build — is the intended route.

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: your source is deleted after the build finishes, pass or fail. We store the signed binaries for you to download, and your keystore (encrypted) so future updates are signed consistently — but not your code.

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

Usually yes, with one wrinkle: updates must be signed with the upload key Google Play expects, and if FlutterFlow's pipeline handled your deployments, that key lives in their system. Because virtually all of these apps use Play App Signing (Google holds the true app signing key), you can request an upload key reset in Play Console, generate a fresh keystore, and sign future AABs with it. It's a one-time piece of admin, not a dead end — but budget a day or two for Google to process the reset.