Did Apple update TestFlight or App Store rules for Sign in with Apple email addresses?

Did Apple update TestFlight or App Store rules for Sign in with Apple email addresses

Apple did update Sign in with Apple email handling, but the change is about relay domains, not a new TestFlight rule or a new App Store submission rule. The practical issue is whether your app accepts Apple’s private relay addresses and whether your test workflow treats them as valid account emails.

The recent Apple notice says developers should accept addresses on the new private.icloud.com domain in addition to privaterelay.appleid.com. That is a Sign in with Apple account-system change, not a change to the TestFlight beta program or to App Store review criteria for email addresses.

TestFlight still works as a beta distribution tool. Apple’s TestFlight pages describe invitations, tester emails, and feedback collection, and they also note that the email address used for a TestFlight invitation may or may not match the tester’s Apple Account. That separation is the part people often miss.

App Review Guidelines still point beta builds to TestFlight, and they still focus on whether the app is a beta, demo, or trial, not on whether a user’s sign-in email is a real mailbox or a private relay address. If your account system rejects Apple relay mail, the failure usually shows up inside the app, not at App Store review intake.

The inconvenient part is that teams often test only with personal inboxes and then discover that Sign in with Apple users chose Hide My Email. Apple documents that users can share a private relay address instead of their personal email, and developers should support that flow. If your backend assumes every account email ends in a common consumer domain, you will break real signups.

A correct implementation treats Sign in with Apple email addresses as account identifiers, not as proof that the person is reachable through that address. Apple says the relay address exists to facilitate communication while preserving privacy, so the inbox is not the same thing as the account. That matters for password resets, receipts, support messages, and duplicate-account matching.

If you are debugging a failed sign-in or test invitation, check the exact email path first. A TestFlight invitation email can go to one address, the Apple Account on the device can be another, and the app account can be yet another relay address. The rule change Apple announced is about accepting the new relay domain in your own validation logic, not about changing those three concepts into one.

For teams publishing through DevConnect, the useful habit is simple: test Sign in with Apple with both a personal email and a relay address before release, then verify that invite emails, account creation, and password recovery all still work. The platform itself is at https://devconnectplatform.com, but the Apple-side requirement is the same either way, your app must accept the relay address you are given.

The bottom line is yes, Apple updated Sign in with Apple email behavior, but no, that is not a new TestFlight rule and not a new App Store rule for beta testers. The update is a relay-domain compatibility change, and the failure mode is usually app-side validation, not Apple distribution policy.

Common follow-up questions

What exactly changed in Apple’s email handling Apple says developers should accept the new private.icloud.com relay domain in account systems, email validation, and allowlists, while still supporting the existing privaterelay.appleid.com domain.

Does TestFlight require the tester’s email to match their Apple Account email No. Apple’s TestFlight help says the invitation email may or may not be the same as the Apple Account associated with the tester’s device.

Will App Store review reject an app just because it uses Sign in with Apple relay emails Apple’s published guidance does not say that. The relevant issue is whether your app follows Sign in with Apple requirements and correctly handles user email choices, including private relay addresses.

What should I test before shipping Test account creation, login, password reset, duplicate-account linking, and support email delivery with both a normal inbox and a Hide My Email relay address. That catches the common failure where the UI works but the backend rejects the address.

Is this related to Google Play closed testing No. Google Play’s tester-count rules are separate from Apple’s Sign in with Apple email behavior. Apple’s change here is about relay domain acceptance, not app-store access requirements.