feat: Google sign-in on iOS (Flutter client + iOS OAuth client ID)

[shukebeta]

Problem

Google sign-in ships on Android + Web (backend SHUKE-LABS/HappyNotes.Api#28, credentials #29). The iOS client has no Google sign-in. The Flutter app builds for iOS directly and iOS is on the roadmap, so iOS needs Google sign-in wired to the existing backend.

Conclusion

Extend the existing Android/Web Google sign-in stack to iOS. The Flutter-side change is small and well understood; it reuses the existing backend /Account/GoogleLogin (#28) and the same JWT storage + request-interceptor flow already used on Android/Web. No backend change is needed.

Approach

• Make the Google sign-in path available on iOS: the service's availability guard must include iOS (currently Android/Web only), keeping the credentials-empty → button-hidden behaviour.
• On iOS, initialise the plugin with the iOS OAuth clientId while continuing to pass the existing server/web ID as serverClientId, so the returned idToken's audience remains the backend. On the native authenticate() path, send the resulting Google ID token to /Account/GoogleLogin and store the returned HappyNotes JWT exactly as on Android.
• Add a config accessor for the iOS client ID (empty default, so the button stays hidden until the credential is provided), parallel to the existing server-client-id accessor.
• Wire the iOS URL scheme: add a CFBundleURLTypes entry in ios/Runner/Info.plist with the reversed-client-id URL scheme for the OAuth redirect.

(File-by-file steps are the planner's job; the implementation-grounding comment on this issue names the exact seams.)

Pickup inputs (required before claiming)

• iOS Google OAuth client ID (extends feature/refactoring #29, which provisioned Android/Web only) — supplied to the delivery agent at pickup as configuration (never committed). The reversed-client-id URL scheme and the runtime clientId both need this value.
• A macOS delivery/verification environment (Xcode + iOS Simulator). The sole acceptance criterion is Simulator-based; a Linux-only environment can run flutter analyze and unit tests but cannot exercise or verify acceptance. Claim only from an iOS-capable environment.

Acceptance criteria

• On the iOS Simulator, using the supplied OAuth client ID, a user can sign in with Google and receive a HappyNotes JWT, reusing the existing account link/create behaviour.
• No regression to Android or Web Google sign-in.

Non-goals

• Real-device testing and App Store submission — these require the Apple Developer Program account (feat: Sign in with Apple (backend verification + Flutter iOS client) — blocked on Apple Developer account HappyNotes.Api#30, enrollment in progress) and are deferred to when it is active. Not part of this ticket's acceptance.
• No change to Android/Web sign-in.
• Apple sign-in itself is tracked in API Find Notes improvement: #30, not here.

Related

• Offering Google sign-in on iOS triggers App Store Review Guideline 4.8 → Sign in with Apple (feat: Sign in with Apple (backend verification + Flutter iOS client) — blocked on Apple Developer account HappyNotes.Api#30) must ship alongside this before any App Store submission.

[shukebeta]

Blocked at pickup — cannot proceed with implementation

Picked up implement #53, grounded the plan against the existing Google sign-in stack (lib/services/google_auth_service.dart, lib/app_config.dart, lib/screens/account/login_controller.dart, ios/Runner/Info.plist, test/services/google_auth_service_test.dart). The Flutter-side wiring is well understood and small:

• GoogleAuthService.isAvailable → also return true on Platform.isIOS.
• _ensureInitialized → pass the iOS OAuth client ID as clientId on iOS while keeping the existing serverClientId (server/web ID 58546417130-…) so the returned idToken's audience remains the backend.
• New AppConfig.googleServerClientId-style accessor for the iOS client ID (e.g. GOOGLE_SIGN_IN_IOS_CLIENT_ID), empty default → button stays hidden.
• ios/Runner/Info.plist → CFBundleURLTypes entry with the reversed-client-id URL scheme for the OAuth redirect.

Two hard blockers stop delivery, neither resolvable by me:

1. iOS Google OAuth client ID not in hand. The ticket makes this a required pickup input ("Do not claim this ticket until it is in hand", "never committed"). After the cold-start rebirth the value is not in my context, and no .env*, Info.plist, or config in the tree carries an iOS client ID — only the committed server/web ID. The reversed-client-id URL scheme in Info.plist and the runtime clientId both need this value; a credential can't be invented.

2. No iOS build/verification environment here. This duo Dev runs on Linux with no Xcode / simctl / macOS. The sole acceptance criterion — "on the iOS Simulator, using the supplied OAuth client ID, a user can sign in with Google and receive a HappyNotes JWT" — cannot be exercised or verified in this environment. flutter analyze / unit tests would pass, but that does not satisfy acceptance.

Awaiting shuke's decision on how to proceed (supply the client ID + designate a macOS verification path, or defer the ticket to an iOS-capable delivery environment). Lock retained; ticket parked.

[shukebeta]

Refinement pass — decision trail

Reworked the body to stand alone (problem / conclusion / approach / acceptance / non-goals) and folded the previously comment-only Flutter-side grounding into the body. Also promoted the macOS verification environment from an implicit assumption to an explicit required pickup input, so a Linux-only picker doesn't claim an un-verifiable ticket.

Implementation grounding (verified current against the tree at refine time):

• lib/services/google_auth_service.dart:17 — isAvailable guards on AppConfig.googleServerClientId.isNotEmpty && (kIsWeb || Platform.isAndroid); add || Platform.isIOS.
• lib/services/google_auth_service.dart:22-25 — _ensureInitialized() passes clientId: kIsWeb ? … : null / serverClientId: kIsWeb ? null : …. iOS needs clientId = iOS OAuth client ID while keeping serverClientId = the server/web ID so the idToken audience stays the backend.
• lib/app_config.dart:90-93 — googleServerClientId reads env GOOGLE_SIGN_IN_SERVER_CLIENT_ID; add a parallel GOOGLE_SIGN_IN_IOS_CLIENT_ID accessor (empty default) plus its app_constants.dart key + _overrides wiring (lib/app_constants.dart:18, lib/app_config.dart:211).
• ios/Runner/Info.plist — no CFBundleURLTypes entry today; add the reversed-client-id URL scheme.
• lib/screens/account/login_controller.dart:20,70-108 — already drives the button off isAvailable and the native signInWithButton() path; no controller change expected once isAvailable returns true on iOS.
• test/services/google_auth_service_test.dart — extend for the iOS availability + init branch.

Gate outcome: blocked (scope/environment decision for shuke)

The ticket quality is now high, but it cannot move to ready for this duo. Two external dependencies gate it, neither invent-able and neither caucus-eligible (missing credential + environment fact, not a design question answerable from mainline):

1. iOS OAuth client ID — required pickup input, not in hand.
2. macOS/Xcode/Simulator environment — this duo Dev runs on Linux; the sole acceptance criterion (Simulator sign-in) is unverifiable here. flutter analyze + unit tests would pass but do not satisfy acceptance.

shuke's decision needed: supply the client ID and designate a macOS-capable delivery path, or relax acceptance to code-complete + analyze/tests with Simulator verification deferred, or defer the ticket until an iOS-capable environment is available.