palmoil-mobile/PRODUCTION_OPTIONS.md

Production Options

This app is a field tool for FFB harvesters, not a public consumer app, so the distribution strategy should optimize for controlled rollout to a known user base rather than App Store/Play Store discoverability.

Current blocker

android/app/build.gradle.kts still points the release build type at the debug signing config:

buildTypes {
    release {
        signingConfig = signingConfigs.getByName("debug")
    }
}

A real release keystore (generated once, kept private, referenced via a key.properties file that is not committed to git) is required before any of the options below produce a distributable build. flutter build apk today produces a debug-signed APK that will install fine for testing but should not be handed out as "production."

Option 1 — Direct APK distribution

Sign a release build with a real keystore and share the APK directly (email, internal file share, Firebase App Distribution, or a private download link).

• Pros: no store review, no delay, full control over rollout timing, works for a small/known group of harvesters.
• Cons: users must enable "install unknown apps" for the source; you own update delivery (no auto-update) unless paired with a tool like Firebase App Distribution or an in-app update check; no Play Protect scanning reassurance for end users.
• Best fit: pilot rollout, a handful of estates/harvesters, fast iteration during early field testing.

Option 2 — Google Play (Internal or Closed Testing track)

Upload a signed release build (AAB preferred) to Play Console under an Internal Testing or Closed Testing track, and invite harvesters by email or a shareable opt-in link.

• Pros: auto-updates, no "unknown sources" friction, Play Protect scanning, easy to promote the same build to a wider track later without re-signing.
• Cons: requires a Play Console account (~$25 one-time), a privacy policy URL, and a short review pass per release (usually fast for testing tracks, slower for public production).
• Best fit: once the app is stable enough for ongoing use across many harvesters/estates and update convenience matters more than rollout speed.

Recommendation

Start with Option 1 for the current field-testing phase (small, known audience, fast iteration), then move to Option 2 once the app stabilizes and the user base grows enough that manual APK distribution becomes a bottleneck.

Next steps

1. Generate a release keystore and store it outside the repo (e.g. a password manager or secure ops storage) — never commit it.
2. Add a key.properties file (gitignored) referencing the keystore, and wire android/app/build.gradle.kts to use it for the release build type instead of the debug config.
3. Build and smoke-test a signed release APK (flutter build apk --release) on a real device before distributing.
4. Decide on update delivery (manual re-share vs. Firebase App Distribution vs. Play Console track) based on how many harvesters are testing at that point.