An invited tester reported that Apple sign-in was not offered. The expected first-use sequence remains: backend invitation validation, choice of Apple or email/password, authentication, backend admission, then app access. Invited email registration does not add a Brevo email-code step. Existing admitted accounts retain their access, and password recovery still uses its email code.

Verified findings

Read-only production checks on 2026-11-03 found:

• The running API and https://snag-app.io/api/auth/oauth/providers, the public endpoint used by the app, both return HTTP 200 with providers: ["apple"].
• The public response is JSON with Cache-Control: private, no-store.
• Anonymous /auth/beta/status returns required: true, admitted: false.
• Apple OAuth core routes and exchange code are unchanged from the previously working version. Provider discovery, start, completion and callback are not blocked by the beta admission guard.

Two app defects were reproduced. A network/HTTP/malformed response during provider discovery was converted into an empty provider list, silently hiding Apple without recovery. Registration also placed provider buttons after the email form and automatically opened the keyboard. These are verified defects; the exact condition on the reporting tester's device has not been established.

Change

The app now renders backend-enabled providers before the email fields on login and registration. Registration leaves the keyboard closed initially. Loading has an explicit state; discovery failure offers retry while email remains usable. A successful, explicitly empty provider list still hides provider controls. The backend remains the authority on provider availability.

Existing authentication locks, provider callback handling, invitation admission and email/password behavior are retained. No native changes, dependencies, database migration, production restart or account mutation are required.

Validation and delivery

Issue: mobile #1010. Implementation: mobile PR #1011, targeting staging.

Three regressions were observed failing before their respective fixes: failed discovery mistaken for an empty list, missing retry after a discovery error, and Apple ordered after email with automatic registration focus. Additional tests cover malformed responses, an explicitly disabled provider list and the authentication lock during retry. Existing integration tests retain the invitation/admission ordering for Apple and email flows.

ESLint and TypeScript pass. The full Jest run passes 350 suites and 3,432 tests; 2 suites and 11 tests remain skipped. The documentation build also passes.

The .maestro/apple-signin-choice.yaml smoke flow uses a dedicated signed-out installation and an unused test invitation. It stops after verifying that Apple and email choices are visible; it does not authenticate, create an account or consume the invitation. Maestro is unavailable on the connected hosts, so this flow has not been run. A real iPhone Apple authorization has not been tested here.

Merging this app fix into staging does not update an installed TestFlight binary. Build and distribute a new iOS version containing the fix, then check the choice screen after invitation validation on an iPhone. No backend deployment is needed for this visibility correction. Personal accounts and collections were not modified.