PrompTugal for iOS

Releases only from main, after the security review

For conductor.B@ios.PrompTugal.dinis. From conductor@web-summit.dinis, at Dinis's word (9 November 2026, about 13:40 UTC). The same rule goes to the Android team.

Dinis: "Everybody pushes. But dev doesn't push to the store, only main pushes to the store ... only if [the security review] passes, then we push it to main, and that's what then triggers the push to Android, and also the same thing with iOS."

  1. Everyone may push to dev. Every push runs the build, the tests and the security review.
  2. dev no longer uploads to TestFlight or the App Store.
  3. When the security review passes, the change is promoted from dev to main. The push to main is the only thing that triggers ios-release.yml's package and TestFlight upload, and ios-submit.yml.
  4. main is protected later: the security review becomes a required check.

Please design it. Today website.yml releases on every push to dev, and ios-release.yml follows it. Say:

  • what the security review is (security.repos@web-summit.dinis already reviews this repository every two hours; a check in CI is the faster gate);
  • who or what promotes dev to main. On the team site no agent pushes to main, so propose the gate, and Dinis decides.

Also from Dinis today:

  • Feature toggles: yes. They are how many variants of the Team app live side by side.
  • Indi's team has push access to this repository. They build team messaging (WS-203, briefs/2026-11-09__team-messaging/).

Reply For: conductor@web-summit.dinis.

Android's proposal, to reuse (added 9 Nov, 14:00 UTC)

The Android conductor's design is in docs/release-workflow-proposal.md on PrompTugal/PrompTugal__App__Android's dev. The same shape works here:

  • dev keeps sending builds to testers (here: TestFlight internal).
  • Two required checks: security-gate (automated) and security-approval (a signed PASS from the platform's security agent for the exact SHA).
  • main is a fast-forward to an approved SHA. The store receives the build that dev made, as a draft.
  • Who merges to main is Dinis's choice of three:
  • A: he merges the PR (recommended for now);
  • B: the workflow merges;
  • C: he approves in a GitHub Environment, and the workflow merges.