# Release process

No release is authorized by the existence of these scripts. No workflow publishes
to either store. A debug APK or unsigned archive is not a production release.

1. Complete every outstanding gate in `validation.md` and `security-review.md`.
   Obtain independent human review of authentication, navigation, file handlers,
   local erasure and privacy disclosures. Run actual supported device/OS tests.
2. Resolve bundle/application identifier ownership. `community.yuvomi.mobile` is
   a provisional community identifier, not proof of registry/store ownership.
   Confirm use of the Yuvomi name, required attribution and independent status.
3. Bump version/name/code in Android and the iOS project spec; update CHANGELOG.
4. Run JVM/emulator/real-upstream HTTPS tests, portable Swift and Xcode simulator
   tests, static checks, OSV scan, release builds and artifact inspection. Record
   upstream revision, app SHA, OS/WebView/Xcode versions, results and checksums.
5. Produce signed artifacts only using an authorized maintainer's credentials.
6. Review store privacy/Data Safety answers for the app AND selected-server model,
   permission rationale, encryption/export compliance, screenshots, support URL,
   vulnerability contact, and device demonstrations. A functional web companion
   is not guaranteed to pass Apple's minimum-functionality review.
7. Create a release/tag and publish artifacts/store submissions manually only
   after explicit maintainer authorization. Never force-push or rewrite history.

## Android

The manual `.gitea/workflows/release.yml` workflow runs on `ubuntu-latest` and
emits **unsigned** artifacts only. Gitea ignores GitHub environment approval gates,
so this workflow does not load signing secrets or offer a signing toggle.

An authorized maintainer must separately sign the verified APK/AAB using their
own keystore, alias and passwords with `zipalign`, `apksigner`, and `jarsigner`.
Keep private material in a protected signing environment, never on the general
validation runners. Securely back up the real upload key and use Play App Signing
according to the owner's policy. No production key is generated here.
Manually verify APK/AAB signatures and inspect
the final manifest: no debuggable flag, HTTP/test CA or unintended exported component.
Never distribute an `.integration` package or include its generated test resources.
Run `python3 scripts/collect-android-artifacts.py` immediately after the clean-source
build to inspect unsigned outputs and record local hashes/source identity. This
collector intentionally rejects signed release outputs; collect before signing.

## iOS

The CI archive is unsigned and cannot be uploaded to App Store Connect. An owner
needs Apple Developer Program membership, a registered app ID, distribution
certificate/private key, provisioning profile and App Store Connect permissions.

Generate/open the project, choose the authorized team, set the owned bundle ID,
select a physical/generic iOS destination, and use Product -> Archive. Validate
the archive in Organizer and export using the owner's distribution method. For
CLI export use a **locally supplied** ExportOptions.plist with the correct team,
method and provisioning mappings:

```sh
xcodebuild -exportArchive -archivePath artifacts/Yuvomi.xcarchive \
  -exportPath artifacts/ios -exportOptionsPlist /secure/path/ExportOptions.plist
```

Do not add distribution certificates, profiles, App Store keys or passwords to the
repository. Device camera, Files, VoiceOver, memory pressure and app-switcher
privacy need physical-device validation beyond simulator tests.

## CI hosting

Gitea Actions workflows are provided in `.gitea/workflows/`, using the supplied
`ubuntu-latest` and `macos-arm64` runner labels. See [runner setup](ci-runners.md)
for SDK, KVM, Xcode, simulator and security requirements. Repository Actions must
be enabled. Inspect actual runs before claiming CI is operational; no GitHub
mirror or store destination is created. CI is not an application dependency.