# Google Sign-In for iOS: what the keychain access group really decides

> Google Sign-In for iOS and macOS wraps Google's hosted account system into a native OAuth2 and OpenID Connect flow, with a branded button, browser based sign-in and Keychain token storage. It is a good fit for consumer apps on Apple platforms, and a poor fit for teams that need their own account directory, because the README documents neither server side verification nor token refresh.

**google/GoogleSignIn-iOS** — Enables iOS and macOS apps to sign in with Google.

- Repository: https://github.com/google/GoogleSignIn-iOS
- Website: https://developers.google.com/identity/sign-in/ios
- Stars: 759 · Forks: 285
- Language: Objective-C
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-googlesignin-ios

## What the SDK removes from your login stack

Google Sign-In for iOS and macOS packages one specific job: letting a user of your native app authenticate with the Google account they already have, so you never write a password form. The repository ships two Swift packages, GoogleSignIn and GoogleSignInSwift, alongside podspecs, an Objective-C sample and a Swift sample. The audience is engineers on Apple platforms who want a hosted account system, an OAuth2 and OpenID Connect flow and a signed-in identity token without maintaining their own user table, mail delivery and password reset pipeline.

The trade is straightforward. You give up control of the credential and of the login screen, and you get a sign-in path users recognise from other apps. The repository topics, authentication, ios-sdk, oauth2 and openid-connect, match that narrow scope, and the SDK makes no attempt to be a general account, analytics or push notification system. Its primary language is Objective-C, with the Swift package layered on top for SwiftUI and Swift callers.

## Where the sign-in flow runs on each platform

The mechanism is a browser based OAuth2 exchange that the SDK drives for you, with a native credential cache underneath. On iOS the flow presents a view controller. On macOS the README states that a user signs in to your native app with their Google account and default browser, and the API surface changes to match the platform: the signInWithConfiguration: and addScopes: methods take a presentingWindow: parameter in place of presentingViewController:. That single substitution is the clearest sign that this is a native SDK with two platform bindings rather than a web view glued onto both targets.

Underneath the flow, tokens live in the Keychain. The SDK uses the first keychain access group in your app's entitlement list, which by default is the group Xcode generates as $(AppIdentifierPrefix)$(CFBundleIdentifier). The group is not a detail you can skip past, because it decides which credentials the SDK can see and which ones it removes.

## Running the Objective-C sample in a few commands

The README offers the Objective-C sample and points to a Swift sample for the SwiftUI version. For the Objective-C demo the first route uses the CocoaPods install method:

```bash
git clone https://github.com/google/GoogleSignIn-iOS
cd GoogleSignIn-iOS/Samples/ObjC/SignInSample/
pod install
open SignInSampleForPod.xcworkspace
```

After pod install resolves, you should open SignInSampleForPod.xcworkspace rather than the .xcodeproj, because the workspace is what carries the pod dependency into Xcode. The second route skips CocoaPods and uses Swift Package Manager, and it needs only a clone and an open:

```bash
git clone https://github.com/google/GoogleSignIn-iOS
open GoogleSignIn-iOS/Samples/ObjC/SignInSample/SignInSample.xcodeproj
```

Here the project file is opened directly, since the sample project resolves the package itself. If you want the Swift flavour, the README points to Samples/Swift/DaysUntilBirthday. For wiring the SDK into your own app, the README links out to getting started guides and an API reference instead of pasting a configuration snippet, so the two sample apps are the closest thing to a reference implementation the repository offers.

## The SwiftUI button hides a view model behind defaults

GoogleSignInButton exists so you do not have to draw Google's branded button yourself. The README shows the whole usage as a closure:

```swift
GoogleSignInButton {
  GIDSignIn.sharedInstance.signIn(withPresenting: yourViewController) { signInResult, error in
      // check `error`; do something with `signInResult`
  }
}
```

What that snippet hides is that the button takes a view model, and this initializer supplies default arguments for it. The README spells out what those defaults are: the light colour scheme, the standard button style and the normal button state. If your app has a dark mode, a different style, or a loading state to show while the sign-in sheet is open, you construct your own GoogleSignInButtonViewModel with different values and hand it to the convenience initializer that exposes those parameters. The sample's inline comment reminds you that the error argument has to be checked, which matters because a cancelled sheet is a normal outcome rather than an exception.

## AppKit has no GIDSignInButton, so SwiftUI comes back

On macOS the UIKit button is simply absent. The README states that GIDSignInButton is implemented as a subclass of UIControl, so it will not be available on macOS, and AppKit apps are told to use the SwiftUI button instead. The catch is that a SwiftUI button needs a host inside an AppKit hierarchy:

```swift
let signInButton = GoogleSignInButton {
  GIDSignIn.sharedInstance.signIn(withPresenting: yourViewController) { signInResult, error in
      // check `error`; do something with `signInResult`
  }
}
let hostedButton = NSHostingView(rootView: signInButton)
```

Wrapping the button in NSHostingView is the entire workaround, and it carries a real cost: a SwiftUI view tree inside an AppKit app, plus the need to manage the hosting view's frame and appearance yourself. The asymmetry is worth naming. The macOS flow runs in the default browser, so a Mac user sees a web page rather than a native sheet, while the iOS flow stays inside the app.

## Keychain access groups decide which credentials survive a fresh install

Keychain access groups are where this SDK has a documented sharp edge. The SDK uses your default, first listed, keychain access group. If you do not add a custom group, that default is the one Xcode provides and it looks like $(AppIdentifierPrefix)$(CFBundleIdentifier). The README also records that the SDK removes keychain items upon fresh install, so stale credentials from a previous install of your app are not mistaken for a live session.

The consequence shows up when your app shares a keychain access group with others. If your app uses a shared group by default, a new install of one app in that group can remove keychain credentials for apps that are already installed. The README gives the fix: explicitly list the typical default access group, or another group of your choosing as long as it is not shared, as the first item in your list, and the SDK will then use that group. For macOS and for Mac Catalyst builds you need the same first entry, $(AppIdentifierPrefix)$(CFBundleIdentifier), in the keychain access group for the app to store credentials in the Keychain on macOS.

## Where this SDK is the wrong tool

There are ordinary situations where Google Sign-In does not fit, and the README is quiet on all of them. It documents no token refresh procedure, no recipe for verifying the identity token on your own backend, no logout walkthrough and no rollback path, so an engineer who needs those answers has to find them outside this repository. It also says nothing about what happens for a user who has no Google account, which in some markets is most of the people who could install your app.

The macOS story is thinner still. The button arrives wrapped in a hosting view, the sign-in runs in the default browser, and credential storage depends on a keychain access group you configure by hand.

A real alternative for many teams is to run the OAuth2 and OpenID Connect flow yourself with a general purpose HTTP client and an in-app browser, then keep your own session token in your own storage. You gain full control over the account system, the interface and the recovery flow, and you lose the trusted account users already have, the prebuilt branded button and the token handling the SDK does for you. For a consumer app aimed at Google users the SDK is the shorter path. For an enterprise app with its own directory, handling the flow directly removes the keychain group and hosting view problems entirely.

Maintenance is current. The last push was on 2026-10-19, and the releases move in order: 9.1.0 on 2026-01-08, 9.2.0 on 2026-06-15 and 10.0.0 on 2026-09-04. The repository carries a CHANGELOG.md, though the README does not summarise what the major version changed, so an upgrade across that jump needs the changelog file itself. The library is Apache-2.0 licensed, which lets you vendor and modify it provided you keep the licence notices.

## Conclusion

Adopt Google Sign-In for iOS if your audience already lives on Google accounts and you would rather not run a password, recovery and directory stack of your own, and check first that your Keychain access group is not shared with sibling apps. Do not adopt it if you need to verify tokens on your own backend, support accounts outside Google, or want a native macOS button, since the README documents none of those paths and the macOS UI is a wrapped SwiftUI view.

## FAQ

### How do I add a Sign in with Google button to an AppKit macOS app?

GIDSignInButton is implemented as a subclass of UIControl, so it is not available on macOS. Use the SwiftUI GoogleSignInButton and wrap it in NSHostingView to place it in an AppKit hierarchy.

### Why does Google Sign-In delete Keychain items after a fresh install?

The SDK removes keychain items upon fresh install so that stale credentials from previous installs of your app are not mistakenly used. If your app shares a keychain access group by default, new installs can remove credentials belonging to other apps, so list a non-shared group first in your access group list.

### Which Keychain access group should I set for macOS and Mac Catalyst?

You need to add $(AppIdentifierPrefix)$(CFBundleIdentifier) as the first item in the keychain access group for the app to store credentials in the Keychain on macOS. The same entry is required for a Mac Catalyst build.

### How do I run the GoogleSignIn-iOS Objective-C sample app?

Clone the repository, enter GoogleSignIn-iOS/Samples/ObjC/SignInSample/, run pod install and open SignInSampleForPod.xcworkspace. The alternative path opens Samples/ObjC/SignInSample/SignInSample.xcodeproj directly, which resolves the package through Swift Package Manager.

### What licence does Google Sign-In for iOS use?

The project is published under Apache-2.0, which permits vendoring and modification provided the licence and notices are retained. This is a description of the licence terms, not legal advice for your specific use.

## Sources

- [google/GoogleSignIn-iOS on GitHub](https://github.com/google/GoogleSignIn-iOS)
- [License: Apache-2.0](https://github.com/google/GoogleSignIn-iOS/blob/main/LICENSE)
- [Project website](https://developers.google.com/identity/sign-in/ios)
- [README](https://github.com/google/GoogleSignIn-iOS/blob/main/README.md)
- [Releases](https://github.com/google/GoogleSignIn-iOS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-googlesignin-ios