Plan coordinated GitHub and App Store release flow

[shiny-code-bot]

Objective

Make Context Panel releases ship through a single, deliberate release lane that keeps GitHub downloads and App Store Connect uploads aligned. A release should use the same version, commit, validation evidence, and human approval for both channels.

The current paths work independently: GitHub Release can publish a signed macOS zip, and the workflow currently named TestFlight uploads an App Store Connect package. The next improvement is to make that coordination explicit, rename or wrap the confusing TestFlight path, default to no TestFlight beta distribution for now, and make GitHub downloads notarized when they are intended for direct human installation.

Finish Line

One versioned release path coordinates notarized GitHub downloads and App Store Connect uploads from the same commit, with TestFlight beta distribution disabled by default unless explicitly requested.

Current Status

State: Active
Next action: Design the orchestrated release workflow inputs and channel semantics with App Store Connect upload as the Apple default and TestFlight beta distribution as opt-in only.
Blocked by: None
Waiting for: Maintainer decision on whether every public GitHub release must require notarization.
Last verified: 2026-05-28, after GitHub release v1.0.11 and App Store Connect upload build 202605281949 both succeeded from main commit 97238144f569d3298b804a5814293e87f1a19aef; GitHub release metadata reports notarized true.

Scope

• In: GitHub Actions release orchestration, release workflow inputs, notarized GitHub release defaults, App Store Connect upload coordination, optional TestFlight beta distribution controls, release evidence, docs updates.
• Out: App Store metadata/review submission automation, mandatory TestFlight beta testing, provider behavior changes, widget/app feature work, automatic version bumping in source unless chosen separately.

Acceptance Criteria

• There is one clear workflow or scripted entry point for shipping a version across selected channels.
• GitHub Release and App Store Connect upload use the same target commit and marketing version.
• The Apple release default uploads to App Store Connect for App Store review selection without enabling or requiring TestFlight beta distribution.
• TestFlight beta distribution remains possible only as an explicit opt-in/lower-level path.
• GitHub Release artifacts are notarized by default when they are public/friend-installable builds.
• The release output records whether each channel was skipped, uploaded, notarized, signed, beta-distributed, submitted, or failed.
• Existing standalone Release and currently named TestFlight workflows either remain intentionally callable or are wrapped/renamed in a safer orchestration layer.
• docs/release.md explains the normal release path and the exceptional paths.
• Validation includes at least one dry run/export-only path and one real App Store Connect upload path before the plan is closed.

Relationships

Sub-issues cover workflow orchestration, GitHub notarization defaults, App Store Connect upload evidence, optional TestFlight beta distribution semantics, and release documentation/checklist updates.

Validation

Expected validation:

• scripts/commit-gate.sh
• GitHub Actions dry run or export-only workflow from a non-release test version
• Successful notarized GitHub release artifact on a test or real version
• Successful App Store Connect upload from the same version/commit
• Post-run inspection of release assets, workflow artifacts, and App Store Connect upload logs
• Verification that TestFlight beta distribution is not required or enabled by default

Decisions

• 2026-05-28: Keep GitHub Release and Apple distribution as separate channels, but coordinate them from one release intent.
• 2026-05-28: Default Apple flow is App Store Connect upload for App Review selection; TestFlight beta distribution is optional and should not be the normal path while there is effectively one user.
• 2026-05-28: Notarization is required for GitHub downloads intended for direct human installation; App Store Connect uses the App Store signing path instead.

Open Questions

• Should every GitHub release be treated as public/friend-installable and therefore require notarization, or should ad-hoc validation releases remain possible behind an explicit input?
• Should the orchestrator create/update the GitHub release only after App Store Connect upload succeeds, or publish each successful channel independently with explicit partial-failure status?
• Should App Store review submission remain manual for now, or should a later issue automate build selection/submission after upload processing?