Skip to content

[iOS 1.0] Qualify the signed build through TestFlight on iPhone and iPad #52

Open

Description

@HemSoft

Outcome

Qualify the signed build through TestFlight on iPhone and iPad.

Release tracker: [iOS 1.0] First App Store release tracker

Acceptance criteria

  • Upload an approved signed candidate tied to a clean commit and exact version/build. Confirm App Store Connect processing, symbols, manifest/export-compliance results, and TestFlight availability. Upload success is not App Review submission or public release.
  • Prepare beta app description, What to Test, feedback destination, test groups, and any required beta-review information. Use internal testing first; invite external testers only with owner approval and complete Beta App Review where required.
  • Install the actual TestFlight build on an iPhone and iPad, including a supported older device/OS when available. Record the tested matrix and any concrete coverage gap rather than claiming universal native validation.
  • Test first launch, airplane mode, every approved dice count, solo/AI play, hold/reroll/score, bonus boundaries, recommendations, complete results, replay, quit/discard, and duplicate-save prevention.
  • Test background/foreground, force termination and resume, device lock, interruptions, low storage, corrupted/migrated data, fresh install, and upgrade from the previous beta while preserving saves.
  • Verify VoiceOver, large text, contrast, Reduce Motion, touch targets, safe areas, rotation/multitasking policy, support/privacy links, and realistic performance/battery behavior. Collect crash feedback without introducing undeclared analytics.
  • Triage all blocking defects into linked issues, retest the same candidate or its replacement, and record explicit release-candidate acceptance. No blocker may be waived silently.

Dependencies

Validation and completion

A signed TestFlight candidate passes documented device journeys with screenshots/recordings, crash review, and restoration evidence. Record tester sign-off without publishing tester emails or device identifiers.

Record the exact source revision, commands/artifacts, or sanitized App Store evidence as appropriate. Keep credentials and private contact/identity details out of this issue. Implementation changes must pass affected repository gates and receive review.

References

Activity

  1. added this to the iOS 1.0 milestone on Sep 27, 2026
  2. added
    enhancementNew feature or request
    iosiPhone and iPad app work
    app-storeApp Store release preparation and submission
    on Sep 27, 2026
  3. HemSoft commented on Sep 27, 2026

    @HemSoft
    CollaboratorAuthor

    Mission completion blocker

    Approved signing/upload access, a processed TestFlight candidate and physical iPhone/iPad testing.

    Evidence and two self-serve paths checked:

    1. Checked repository artifacts, workflows and release records: no signed candidate or TestFlight build ID exists.
    2. Checked execution/access alternatives: local Xcode is absent and the target runner is Linux. Unsigned hosted simulation or the mobile web adapter cannot install a TestFlight build on physical devices; external tester invitations also need owner approval.

    Safe default: Keep beta notes in draft and do not upload, invite testers or claim device acceptance.

    Owner action: Provide the authorized Apple/TestFlight route and device testers after implementation, and explicitly approve upload/invitations. TestFlight qualification has not started.

    This is a blocker to this issue's full acceptance contract, not a claim that its unfinished implementation is complete. Repository-only preparation continues through the linked PRs; this issue stays open.

  4. HemSoft commented on Oct 1, 2026

    @HemSoft
    CollaboratorAuthor

    Updated acceptance blocker, October 1, 2026 EDT

    This supersedes the September 27 preimplementation assumptions. Native local saves/resume/UI, original development assets, unsigned CI and packaged privacy inspection are now delivered. The static companion site is prepared but unpublished. Screenshot and release/reporting preparation exists in the open PRs, not as accepted store material.

    Native foundation #57 and postmerge delivery, unpublished site #58, draft capture preparation #61, and draft release/reporting preparation #62. The last two PRs remain open; connected review capacity was explicitly refused on #61 and on #62. No purchase or substitute reviewer was used.

    Remaining need: Authorized processed TestFlight candidate, explicit upload/invitation permission and actual iPhone/iPad testers.

    Two self-service paths checked:

    1. Delivered unsigned build/native simulator qualification and retained draft TestFlight notes. Source/build/effect evidence is now real, not merely JavaScript export.
    2. Refreshed candidate/issue52: TestFlight build ID and accepted signed archive are null, and no upload/invitation/device route is approved. Hosted simulators cannot install or qualify a TestFlight candidate on physical devices.

    Safe reversible result: Keep beta notes draft; do not invite testers or upload under inferred authority.

    Exact owner action: Approve the signed-candidate TestFlight upload and testing route, explicitly approve any tester invitations, and provide authorized physical iPhone/iPad qualification.

    This issue remains open. Simulator, browser, fictional-fixture and unsigned evidence do not replace signed physical-device or legal/publication acceptance. CI waits and driver failures are still engineering work, not the owner block stated above. No credentials, private contacts or legal declarations are requested in this public issue.

  5. HemSoft commented on Nov 11, 2026

    @HemSoft
    CollaboratorAuthor

    Held: this step needs App Store Connect access for Third Roll, which the repository doesn't have and an agent can't obtain without a new login.

    Checked on 2026-11-11 (merge mission, Chief dispatch 022804d6):

    1. The repository has no Actions secrets or variables at all, so there is no App Store Connect API key, signing identity or team configuration to use.
    2. Even with an API key, the App Store Connect API can't create the app record; that is done in the App Store Connect website by the account holder. Every later step (metadata sync, screenshot upload, TestFlight, App Review, release) depends on that record. App Review submission also contacts Apple on the owner's behalf.

    The repository-side preparation for this item is on main (release records, metadata drafts, screenshot automation, privacy audit, unsigned archives). Nothing here spends money or needs a new account, but it does need Franz's App Store Connect session, so later sweeps should skip this issue until that access exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    app-storeApp Store release preparation and submissionenhancementNew feature or requestiosiPhone and iPad app work

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions