# 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:

```kotlin
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.