## The build

```bash
bin/check
open mobile/android
```

Build a release App Bundle, not an APK. Play requires the bundle format for new apps, and it is what
lets Google serve device-specific downloads.

Keep the upload keystore and its password somewhere durable. With Play App Signing, Google holds the
key that actually signs what users install, so a lost upload key can be reset through support. That
is a meaningful safety net and it only exists if you enrolled.

## The listing is the long part

- Short and full description.
- Screenshots for phone, and for tablet if you declare support.
- A feature graphic.
- A privacy policy URL that resolves. Your app already serves one at `/terms`.
- The data safety form, declaring what you collect and why.

The data safety form is the one that gets rejections, because it has to match what your app actually
does. If you use analytics, say so.

## Test tracks first

Internal testing puts a build in front of a list of email addresses within minutes and does not
require review. Use it to check the real signed artifact on a real device before anything goes to
production. A bug that only appears in a release build is common enough to plan for.

## The payment rule applies here too

Digital subscriptions must use Play Billing. The shells handle it through the marker paths declared
in `config/routes.rb`, and your server verifies the receipt through
`app/adapters/play_store.rb`. Showing a Stripe button inside the app is the rejection to avoid, and
`hotwire_native_app?` is how you avoid it.

## Review times

Usually faster than Apple's, occasionally much slower for a new developer account. New accounts can
also face an extended testing requirement before production access. Check the current rules when you
create the account, because this has changed recently and affects your timeline more than anything in
the build.