Description

OAuth client IDs for Google and Apple sign-in (IOS_GOOGLE_CLIENT_ID, IOS_GOOGLE_REDIRECT_URI, ANDROID_GOOGLE_CLIENT_ID, ANDROID_GOOGLE_SERVER_CLIENT_ID, ANDROID_APPLE_CLIENT_ID) were previously sourced from process.env, requiring manual environment variable configuration and risking misconfiguration across different build types.

This PR moves those client IDs into the existing OAUTH_CONFIG object in config.ts, keyed by build type (development, main_prod, main_uat, main_dev, flask_prod, flask_uat, flask_dev). The constants in constants.ts now read from CURRENT_OAUTH_CONFIG instead of process.env, ensuring the correct client IDs are automatically selected based on the build type. The corresponding environment variable entries have been removed from .js.env.example.

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

Feature: Seedless onboarding OAuth login

  Scenario: user signs in with Google on iOS
    Given the app is built with a main production build type
    When user taps "Sign in with Google" during onboarding
    Then the Google OAuth flow uses the correct production client ID
    And the user is authenticated successfully

  Scenario: user signs in with Google on Android
    Given the app is built with a main production build type
    When user taps "Sign in with Google" during onboarding
    Then the Google OAuth flow uses the correct production server client ID
    And the user is authenticated successfully

  Scenario: user signs in with Apple on Android
    Given the app is built with a main production build type
    When user taps "Sign in with Apple" during onboarding
    Then the Apple OAuth flow uses the correct production Apple client ID
    And the user is authenticated successfully

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.