How builds work
A build turns your configuration into a real Flutter app and compiles it. This page explains what runs, so the log makes sense and a failure tells you something.
What is compiled
Section titled “What is compiled”Your app configuration is not interpreted at runtime. It is used to generate Dart source, which is then compiled like any other Flutter app. The navigation you placed becomes real widgets; your colours become real theme values.
That has two consequences:
- The app is as fast as a hand-written Flutter app, because that is what it is.
- Changing anything in the builder needs a new build before it reaches a phone. The preview updates live; the installed app does not.
The steps
Section titled “The steps”The log narrates each one:
- Preflight. Check the Flutter toolchain is the expected version.
- Create or reuse the workspace. Each app keeps a persistent Flutter project, so later builds are incremental and faster than the first.
- Generate
lib/main.dartfrom your configuration. - Update
pubspec.yamlwith the packages your placed features need. - Copy your app icons and branding assets.
- Set the Android application ID from the app’s own identifier.
- Update
AndroidManifest.xml— internet permission, and cleartext traffic. - Set the display name shown under the icon.
flutter pub get.- Generate launcher icons at every density.
flutter build appbundle --release, then repack that into a universal APK.
Timing
Section titled “Timing”Five to fifteen minutes is normal. The first build for an app is the slowest, because the workspace is created from scratch and every package is downloaded.
The job is capped at twenty minutes and does not retry. A half-finished Gradle workspace is not safe to resume, so a failed build is final and you start another. That is also why the allowance counts attempts rather than successes.
You can close the tab. The build runs on Memberside’s servers and continues.
Reading the log
Section titled “Reading the log”Expand a build row to see it. Each step logs a line as it starts, so the last line before a failure names the step that failed.
The lines worth knowing:
| Line | Meaning |
|---|---|
🔧 Configuring Android application ID | Your app’s package name is being written |
📥 Running flutter pub get | Packages are being fetched — slow on a first build |
🔑 Signing certificate SHA-1: … | The certificate the APK was signed with, cached for Google sign-in setup |
Reading a build log
record → src/assets/media/build-log.mp4
What comes out
Section titled “What comes out”An .aab and an .apk. The AAB is built first and the APK is repacked
from it, so they are the same app. See APK and AAB for
which to use when.
Branding on the splash screen
Section titled “Branding on the splash screen”Free apps show a “Made with Memberside” splash. Removing it is a paid-plan feature, and it is decided from the account’s plan at build time rather than from your saved configuration — so it cannot be turned off in settings and it changes the moment the plan does.
When it does not work
Section titled “When it does not work”| Symptom | Cause | Fix |
|---|---|---|
Stuck at pending, never running | The build queue is not consuming jobs | Get in touch; this is server-side |
| Fails within seconds | Usually an invalid icon or a malformed setting | When a build fails |
| Fails at twenty minutes exactly | The build hit its ceiling | Retry; if it recurs, get in touch |
| Succeeds but the app is out of date | You are running an older download | Download from the newest build row |
Your build allowance explains the metering.