Does Google Sign-In count as tracking under Apple's App Tracking Transparency?

What ATT actually covers

Apple's App Tracking Transparency requires a permission prompt specifically for tracking as Apple defines it: linking user or device data collected in your app with data from other companies' apps or websites for targeted advertising or advertising measurement purposes, or sharing that data with a data broker. The scope is narrow and purpose-specific — it is not a general prompt for "does your app use any identifiers."

This is why the Service Profile for Google Sign-In marks its tracking potential as none rather than configuration-dependent, unlike advertising or analytics SDKs where the answer genuinely varies by setup. Authentication and cross-app advertising tracking are different categories of activity, and a sign-in button does not perform the second one.

What Google Sign-In returns, and why it isn't tracking

When a user signs in with Google, your app typically receives a stable account identifier, and depending on the OAuth scopes you requested, possibly an email address or display name. This data identifies the user to your own app and backend. It does not, on its own, get linked with data from other companies' apps for advertising purposes — that would require additional code and additional purpose beyond authentication.

The identifier Google Sign-In returns is scoped to authenticating that person to your service. Apple's own guidance distinguishes this kind of first-party account identification from tracking, which requires the specific combination of cross-context linkage and an advertising or measurement purpose.

Where confusion comes from

The confusion usually comes from two directions. First, developers see that Google Sign-In is a Google product, and Google also runs a large advertising business, and assume some connection. The SDK you integrate for sign-in does not automatically feed your other Google products' advertising systems — that would require separate integration work you would recognize in your own codebase.

Second, developers conflate "collects a persistent identifier" with "tracking." Apple's App Privacy form does ask you to declare data collection, including the user ID Google Sign-In returns, under Identifiers or Contact Info as applicable. Declaring collection is correct and required. Declaring tracking, and therefore requesting ATT authorization, is a separate and narrower question that authentication alone does not answer yes to.

When a sign-in integration could still involve tracking

None of this means an app with Google Sign-In can never need ATT — it means Google Sign-In itself is not the reason. If the same app also integrates an advertising SDK, an attribution platform, or a Meta or app-events SDK that links identifiers across apps for advertising measurement, that separate integration is what would require the ATT prompt, evaluated on its own facts. Google Sign-In sitting alongside those other SDKs does not change their answer, and their presence does not change Google Sign-In's answer either. Each integration in your app gets evaluated against Apple's tracking definition independently.

Common mistake

The most common mistake is presenting the ATT prompt "to be safe" because the app uses a Google product, without an actual tracking purpose behind it. This creates its own inconsistency: requesting tracking authorization while your App Privacy label declares no tracking, or while your app performs no observable cross-app advertising linkage, looks contradictory to a reviewer just as much as the opposite mismatch does.

The second common mistake is skipping the App Privacy declaration for the account identifier Google Sign-In returns, on the theory that "it's not tracking so it's not collection." Collection and tracking are two separate questions on Apple's form. The account identifier is still collected data and still needs to be declared under the relevant Identifiers or Contact Info category, even though it correctly does not trigger the tracking question.

Why apps get rejected

Guideline 5.1.1 issues in this area rarely come from Google Sign-In in isolation. They tend to show up as:

• An ATT prompt with no corresponding tracking purpose anywhere in the app, which reviewers can find confusing or treat as a legitimacy signal worth investigating further.
• App Privacy answers that omit the account identifier or email that Google Sign-In actually returns based on the requested scopes.
• A privacy policy that describes tracking or advertising use inconsistent with what a sign-in-only integration actually does.

Where Declora fits

Declora's Google Sign-In Service Profile suggests App Facts for the account identifier and, where relevant, email and display name, based on the OAuth scopes you confirm — and marks tracking potential as none so it does not push you toward an unnecessary ATT prompt. Passport Readiness combines this with whatever other SDKs your app declares, so if you also integrate an advertising or attribution SDK elsewhere, that integration's own tracking answer is evaluated separately and consistently across your Apple and Google Play declarations and Public Pages. Declora does not scan your code and does not guarantee approval by Apple or any other reviewer — it keeps your confirmed answers aligned with what you told it your app actually does.

FAQ

Do I need to show the ATT prompt just because I added Google Sign-In?

No. Google Sign-In returns an account identifier for authentication, which is not the same as linking data across apps for advertising, which is what triggers the ATT requirement. Authentication alone does not require the prompt.

Do I still need to declare the data Google Sign-In collects in App Privacy?

Yes. The account identifier, and email or name if your requested scopes include them, are collected data and belong in your App Privacy declaration under the relevant category, even though they do not require an ATT prompt.

If my app has Google Sign-In and also uses an advertising SDK, does the sign-in trigger tracking?

No. Each SDK is evaluated against Apple's tracking definition independently. The advertising SDK's own configuration determines whether ATT applies, not the presence of Google Sign-In elsewhere in the app.

Can showing the ATT prompt anyway ever cause a problem, even if it isn't required?

It can create an inconsistency if your App Privacy label and observable app behavior show no tracking purpose, since a reviewer may find an unexplained tracking prompt harder to reconcile with the rest of your declaration.

Can Declora tell me for certain whether my whole app needs the ATT prompt?

No. Declora evaluates each Service Profile against Apple's tracking definition and marks Google Sign-In as not requiring it, but the overall answer for your app depends on every SDK you integrate. You confirm the facts for each one; Declora keeps the resulting declarations consistent. It is not legal advice and cannot guarantee approval.