@clerk/expo: add a googleSignIn opt-out flag (ClerkGoogleSignIn pod is unconditionally linked)

[MrJune15]

Summary

@clerk/expo ships a separate ClerkGoogleSignIn.podspec that hard-declares s.dependency 'GoogleSignIn', '~> 9.0'. Because Expo autolinking discovers all podspecs in @clerk/expo/ios/, the Google Sign-In native module — and its transitive chain GoogleSignIn → AppCheckCore → GoogleUtilities + RecaptchaInterop — is compiled into every iOS build, even for apps that never use Google sign-in.

The config plugin (@clerk/expo/app.plugin.js) gates appleSignIn (withClerkExpo(config, { appleSignIn })) and other features, but provides no equivalent flag to disable Google sign-in. Its Google logic only adds an Info.plist URL scheme when EXPO_PUBLIC_CLERK_GOOGLE_IOS_URL_SCHEME is set; the native module/pod itself is always linked.

Why this matters

AppCheckCore is a Swift pod depending on GoogleUtilities and RecaptchaInterop, which don't define modules. With static linking (the Expo SDK 55 default) pod install fails:

The Swift pod `AppCheckCore` depends upon `GoogleUtilities` and `RecaptchaInterop`,
which do not define modules. To opt into those targets generating module maps ...
you may set `use_modular_headers!` globally, or specify `:modular_headers => true`
for particular dependencies.

Consumers who don't use Google sign-in are forced to either add expo-build-properties modular_headers workarounds or carry unused SDKs (extra binary size, an extra third-party SDK in the supply chain, and a higher iOS deployment floor).

Request

Add a googleSignIn prop to the config plugin, symmetric with appleSignIn, e.g.:

[
  "@clerk/expo",
  { "appleSignIn": false, "googleSignIn": false }
]

When googleSignIn: false, exclude ClerkGoogleSignIn (and therefore the GoogleSignIn pod chain) from autolinking on iOS, so apps not using Google sign-in don't compile or ship it.

Environment

• @clerk/expo 3.2.14
• Expo SDK 55 / React Native 0.83 (New Architecture, static linking)

Current workaround

[
  "expo-build-properties",
  { "ios": { "extraPods": [
    { "name": "GoogleUtilities", "modular_headers": true },
    { "name": "RecaptchaInterop", "modular_headers": true }
  ] } }
]

This makes the build pass but still compiles and ships the unused Google Sign-In SDK.

[ygravrand]

Another data point: @clerk/expo Core 3 doesn't build at all on Expo SDK 55 — by either linking path, not just the GoogleSignIn modular-headers issue

We hit this on the same stack as the OP (Expo SDK 55 / RN 0.83.6, New Architecture, static linking) while migrating to Core 3. Worth noting the problem is broader than the AppCheckCore → GoogleUtilities/RecaptchaInterop modular-headers failure — both of Core 3's iOS linking mechanisms fail on SDK 55:

• @clerk/expo 3.5.x (the spm_dependency approach from fix(expo): link iOS SDK through podspec SPM dependencies #8927): RN's spm.rb post-install hook crashes in add_spm_to_target:

  undefined method 'package_product_dependencies' for nil
  

  project.targets.find { |t| t.name == 'ClerkExpo' } returns nil for the registered SPM dependency, so the target passed to add_spm_to_target is nil.

• @clerk/expo 3.4.x (pre-fix(expo): link iOS SDK through podspec SPM dependencies #8927, copied app-target bridge): pod install succeeds but the bridge fails to compile:

  ClerkNativeBridge.swift: no such module 'ClerkExpo'
  

#8927 says it was verified on Expo SDK 54 and 56 — so 55 is an untested gap, broken by both the old and new mechanisms.

Workarounds tried (none fully resolve it on 55):

• expo-build-properties modular_headers for GoogleUtilities + RecaptchaInterop → clears the AppCheckCore modular-headers error (this issue) ✅, but then the bridge/SPM failures above remain.
• useFrameworks: "dynamic" → gets past the modular-headers chain but breaks other RN libs (@amplitude/analytics-react-native → _RCTRegisterModule undefined; SwiftUICore linking) — not viable for an app with many native deps.

So we're stuck deferring to an Expo SDK 56 upgrade to get Core 3 building. The googleSignIn: false opt-out requested here would be a much cheaper fix for us: we don't need native Google urgently (the browser OAuth flow works fine), and being able to exclude the ClerkGoogleSignIn pod entirely would likely let Core 3 build on SDK 55 — keeping Core 3 + native Apple without forcing an app-wide SDK bump.

Env: @clerk/expo 3.4.7 & 3.5.3 · Expo SDK 55 (RN 0.83.6) · CocoaPods 1.16.2 · New Architecture, static linking.

+1 on the opt-out flag — and it'd help to know whether an SDK 55 build of Core 3 is intended to be supported at all.

[wobsoriano]

Thanks for the detailed report. We want to do this right rather than add a config flag that only partially solves the problem.

Our plan is to move native Google Sign-In into a separate package, likely @clerk/expo-google-signin, while keeping @clerk/expo/google as the import path. Apps using native Google Sign-In would install that package and add its Expo config plugin; apps that do not use it would no longer get the Google native module/pod chain from @clerk/expo.

We've added native build coverage so we can catch this earlier going forward.

[wobsoriano]

Hi @MrJune15 @ygravrand , you can try the snapshots from the PR that moves Google Sign-In to a separate package.

Install the @clerk/expo snapshot:

npm i https://pkg.pr.new/@clerk/expo@9015

This version excludes the Google Sign-In module by default. If you want to use Google Sign-In, install the new @clerk/expo-google-signin package as well:

npm i https://pkg.pr.new/@clerk/expo-google-signin@9015

Then add its config plugin to your Expo config:

  {
    "expo": {
      "plugins": [
        "@clerk/expo",
        "@clerk/expo-google-signin"
      ]
    }
  }

[wobsoriano]

The fix is now live in @clerk/expo 4.0.0 🥳 Please see the updated instructions here https://clerk.com/docs/reference/expo/native-hooks/use-sign-in-with-google#installation#installation