Sign in with Apple and Public Pages: privacy policy, relay email, support

Make the pages easy to find and keep them aligned

Apple requires an iOS app to provide a privacy-policy URL in App Store Connect, and the policy must also be accessible from within the app. The policy should explain the data the app or service collects, how it is collected, the purposes for its use, third parties that receive it, and the applicable retention and deletion practices. An optional user privacy choices URL can help users find information about managing their data. Keep each URL functional and relevant to the app version under review.

Treat these pages as the public explanation of the path users experience, not as a generic SDK inventory. Your privacy policy, in-app privacy link, App Store Connect privacy answers, support page, and account-deletion instructions should tell a consistent story. They need not all contain identical text: the policy gives fuller detail, the store answers summarize data categories and purposes, and support or deletion pages tell users what action to take.

Before drafting, test the links from both the store listing and the installed app. Check that pages load without a special internal account, render on a phone, identify the product and a responsible contact, and do not redirect to an unrelated landing page. A reviewer or user should be able to understand the policy without needing to complete a Sign in with Apple flow first.

Describe only the Sign in with Apple data your app uses

Map each step of the authentication exchange. Your app may receive a stable identifier for the user, and may request name and email scopes. A user can choose to share a real email or an Apple private-relay address. The name may only be sent on the first authorization, so determine whether your app persists it at that point and whether the user can edit it later.

The Service Profile can suggest likely account-identifier data and configuration-dependent email or name facts. Treat those as prompts for your review, not automatic answers. Inspect the production scopes, the values your app stores, and the payloads sent to your backend. If your app never requests a name, do not write as if it does. If the email is passed through a server or saved in a customer-support system, account for that flow even though Apple supplied the address.

Use language readers can recognize. Explain that the app uses an Apple-provided identifier to associate sign-ins with an app account, if that matches your implementation. If you keep an email address, state whether it is used for account notices, support, receipts, or another specific purpose. If you ask for a display name, explain why. Avoid a broad claim such as “Apple does not share personal information” when your app receives and processes an identifier or optional profile fields.

Do not conflate login with advertising tracking. Authentication data can identify a person within your service without automatically being used to track them across other companies' apps or websites. If your app combines the sign-in identifier with advertising or attribution systems, describe those separate practices accurately and review the relevant App Privacy answers and consent experience. The Sign in with Apple button alone does not tell you how every other SDK in the app behaves.

Explain private relay email operationally

When a user selects Hide My Email, the address your app receives may be a private relay address that forwards email to the user's personal inbox. Respect that choice; do not make the user provide a personal email just because the relay address is unfamiliar. Your policy should explain the role of the address in account communication and how your app handles it, not imply that your business sees the underlying personal inbox.

If your service sends account notices, password or security messages, or support replies to a relay address, test that email path in production-like conditions. Apple requires developers to register sending domains or email addresses with the Private Email Relay service and authenticate the sending domain as documented. An email that is accepted by your own provider but blocked by the relay is still a broken support or account-notice path.

Account for changes in forwarding settings. Users can disable forwarding, so do not make email delivery the only way to access an in-app account or complete a deletion request. Provide an in-app support route and explain what users should do if an email does not arrive. If you retain relay addresses, state the purpose and retention practice; remove them or handle them according to the same account-deletion process as other account identifiers.

Link to support, privacy choices, and deletion

Your support page should give users a working route to a person or team who can help with login, relay email, account access, and deletion questions. A contact form should not require the user to disclose more information than necessary. Explain which details help locate an account and offer a safe alternative if the person cannot sign in.

If you provide a privacy choices page, describe the controls it actually offers. It might explain how to request access, correct account details, withdraw an optional consent, or initiate deletion. Do not call an informational page a deletion portal if it only links to support, and do not imply that opening a web page itself revokes Sign in with Apple credentials.

For deletion, explain the in-app route and what users can expect after submitting a request. Your implementation should remove app-held account data and separately revoke the Sign in with Apple authorization when the required token is available. If you need a fallback when the token is unavailable, tell users how to reach support and follow Apple's documented manual-revocation process. Avoid promising immediate removal from backups or third-party systems if your actual retention procedure has a delay or exception.

Common mistake

A frequent mismatch is an App Store privacy policy that says the app collects no identifiers while the sign-in flow stores Apple's stable user ID and relay email in a backend account. Another is saying the app deletes an account when it only disconnects the login provider. Keep the page wording tied to the exact production behavior, including any data copied to analytics, support, or billing tools.

Also avoid treating “Sign in with Apple” as a complete privacy-policy sentence. Users need to know what your app does with the resulting account data. Conversely, avoid presenting the provider's entire platform as if your app uses every available feature. Describe the scopes, messages, storage, recipients, retention, and controls that apply to your implementation.

Where Declora fits

Declora's Sign in with Apple Service Profile can help organize suggested App Facts for the account identifier and any optional name or email you confirm, then keep those facts in view as you prepare App Privacy answers and Public Pages. You decide whether each fact matches the shipped app. Declora provides informational guidance, not legal advice, and cannot guarantee store approval.

FAQ

Is a privacy-policy URL required for my iOS app?

Yes. Apple requires an iOS privacy-policy URL in App Store Connect and a privacy-policy link within the app. A separate user privacy choices URL is optional.

Does Sign in with Apple always give my app a user's real email?

No. A user may choose a private relay email address instead. Describe and handle the address your app receives, and test that your registered email-sending domains can deliver through Apple's relay.

Does Sign in with Apple itself mean the app tracks users?

No. A sign-in identifier is used to authenticate or recognize an account in your service; Apple's tracking question concerns separate cross-context uses. Review your app's other SDKs and actual data flows before completing the App Privacy answers.