Short answer: your app lets people sign in with Google (or Facebook, GitHub, X) but doesn't offer a login option that keeps their data private. Apple's Guideline 4.8 says that if you offer a third-party login, you must also offer one that limits what you collect. Sign in with Apple is the quickest way to meet it, and for apps built with Lovable, Bolt, Base44 or v0 it usually takes an afternoon.
AI app builders make it easy to add "Continue with Google". It works on the web, so nobody thinks about it again until the App Store review note arrives:
Guideline 4.8 - Design - Login Services
Nothing in your app is broken. Apple just wants iPhone users to have a login option that doesn't hand their data to another company.
What does Guideline 4.8 ask for?
If your app uses a third-party or social login service to set up or sign in to the main account, you must also offer another login option with all three of these features:
- It only collects the person's name and email address.
- It lets people keep their email address private from everyone, including you.
- It doesn't track people for advertising without their consent.
Sign in with Apple has all three built in. Since early 2024, Apple accepts any login service that meets them, but Sign in with Apple is still the one reviewers expect, and the only one that comes ready-made on every iPhone.
Do I have to use Sign in with Apple?
Not strictly. Apple's wording asks for "another login service" with the three features above, so another provider that meets them counts. In practice, Sign in with Apple is the safest choice:
- Reviewers recognize it immediately, so there's nothing to argue about.
- It uses Face ID or Touch ID, so it's the fastest login on an iPhone.
- Supabase, which most AI-built apps use for login, supports it out of the box.
Does email and password login count?
Usually not as the fix. Your own email and password sign-up is your account system, not a login service with private email built in. The exemption for your own accounts only applies when your app only uses them. Once you add Google login, Apple expects a private third-party option next to it. If you want to avoid Guideline 4.8 entirely, the other route is removing social login and keeping email and password only.
Which apps don't need it?
Guideline 4.8 doesn't apply if your app:
- Only uses your own email and password accounts, with no social login.
- Is an education or enterprise app where people sign in with an existing school or work account.
- Uses a government or industry-backed identity system, such as a national e-ID.
- Is a client for a specific third-party service, where people sign in to that service directly (for example, an app that reads their Google Drive files).
If none of those fit and you have Google login, plan on adding Sign in with Apple.
How to add Sign in with Apple to a Supabase app
Most apps built with Lovable, Bolt, Base44 or v0 store their users in Supabase, so here's the path for a native React Native and Expo app with Supabase.
- Turn on the capability. In your Apple Developer account, open Identifiers, select your app's App ID and enable Sign in with Apple.
-
Turn on the Apple provider in Supabase. In Authentication, then Providers, enable Apple and add your app's bundle ID (for example
it.letsdeploy.myapp) to the Client IDs. If you also want Apple login on your website, create a Services ID and a signing key in Apple Developer and add those too. -
Add the Expo package. Install
expo-apple-authenticationand set"usesAppleSignIn": trueunderiosin yourapp.json. - Add the button and sign in. Show Apple's own button, then pass the token Apple gives you to Supabase:
import * as AppleAuthentication from 'expo-apple-authentication';
import { supabase } from './supabase';
export async function signInWithApple() {
const credential = await AppleAuthentication.signInAsync({
requestedScopes: [
AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
AppleAuthentication.AppleAuthenticationScope.EMAIL,
],
});
if (!credential.identityToken) throw new Error('No identity token from Apple');
const { error } = await supabase.auth.signInWithIdToken({
provider: 'apple',
token: credential.identityToken,
});
if (error) throw error;
// Apple only sends the name the first time, so save it now
if (credential.fullName?.givenName) {
await supabase.auth.updateUser({
data: { full_name: `${credential.fullName.givenName} ${credential.fullName.familyName ?? ''}`.trim() },
});
}
}
- Test on a real iPhone with a fresh Apple ID: sign in, choose "Hide My Email", and check the new user appears in Supabase.
On the web, Supabase handles Apple login with a redirect, the same way it does Google, so your Lovable or Bolt web version can keep working as it does.
The mistakes that get apps rejected again
- The Apple button is hidden or smaller. Put Sign in with Apple at least as high and as large as Google on the login screen. Use Apple's official button style, not a custom one.
- The name is lost. Apple sends the person's name only on the first sign-in. If you don't save it then, you'll never get it again, and your profile screens show blanks.
-
Emails to "Hide My Email" users bounce. People who hide their email get an address ending in
privaterelay.appleid.com. To send them emails (password resets, receipts), register your sending domain in Apple Developer under the private email relay settings. - Account deletion doesn't revoke Apple tokens. If you offer Sign in with Apple, Apple expects you to revoke the person's tokens when they delete their account. Our account deletion guide covers the full deletion flow.
What to write back to App Review
When you resubmit, add a short note in App Store Connect so the reviewer doesn't have to hunt:
- Where it is: "Sign in with Apple is now on the login screen, above Continue with Google."
- What it offers: "It collects only name and email and supports Hide My Email."
- A demo account in the App Review information, if parts of the app need a login to review.
Apps rejected under 4.8 are often rejected for something else in the same review. The Guideline 4.2 guide covers the most common one for AI-built apps, and the launch checklist lists everything else Apple and Google ask for.
Can you fix it yourself?
Yes. If you can edit your app's login screen and your Apple Developer settings, most people fix this in an afternoon.
It gets harder when login touches several places: the native app, the web version, Supabase, the private email relay and account deletion. That's part of the store work we do when we convert an app to native, with steps for Lovable, Bolt.new, Base44 and v0. See how it works or our plans.
FAQ
Is Sign in with Apple required if I only have email and password login?
No. Guideline 4.8 only applies when you offer a third-party or social login, such as Google, Facebook or GitHub.
Do I need Sign in with Apple on Android too?
No. Guideline 4.8 is an App Store rule. You can show the Apple button only on iOS and keep Google login on Android.
Can I use Google login and nothing else?
Not on the App Store, unless your app fits one of the exemptions. You need at least one login option with the three privacy features next to it.
Will Apple reject a custom-styled Apple button?
It can. Apple's design guidelines ask you to use their official button styles, and expo-apple-authentication gives you those buttons ready-made.
Does Lovable add Sign in with Apple automatically?
No. Lovable, Bolt, Base44 and v0 build web apps and usually add email and Google login. Sign in with Apple needs Apple Developer setup and, in a native app, the native sign-in sheet.
Can I fix this without a new build?
No. Adding a login option changes the app, so you need a new build and a new submission. Expo's EAS Build makes that a single command once the code is in.
Top comments (0)