Guideline 4.8 Login Services: krävs Sign in with Apple?

Guideline 4.8 gäller så fort din app använder Google, Facebook eller någon annan tredjepartsinloggning för att skapa huvudkontot. Då kräver den ett annat, likvärdigt inloggningsalternativ som begränsar datan till namn och e-post, låter användaren dölja sin e-post och inte spårar användaren för reklam utan samtycke. Sedan januari 2024 måste det alternativet inte längre vara "Sign in with Apple", men det är just det Apple själv nämner i sina avslagsmeddelanden.

Bland mina appar erbjuder Solys och Nolera Apple, Google och e-post. Den här guiden utgår från Apples nuvarande text och visar sedan hur jag lägger till Apple-inloggning i en Expo-app kopplad till Supabase, och vad det ändrar för kontoradering. Vill du ha helhetsbilden av avslagsorsakerna, läs hellre varför Apple avvisar en app.

Vad säger guideline 4.8 Login Services?

4.8 finns i avsnitt 4, "Design", i App Review Guidelines. Den gäller appar som använder "a third-party or social login service" för att skapa eller autentisera huvudkontot: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon eller WeChat. De apparna måste också erbjuda, "as an equivalent option", en annan inloggningstjänst som uppfyller tre villkor.

Apples villkor	Enkelt uttryckt
Begränsad data	Namn och e-post, inget mer
Privat e-post möjlig	Användaren kan dölja den
Ingen reklam utan samtycke	Ingen reklamspårning utan samtycke

Texten definierar också huvudkontot: det konto personen skapar i din app för att identifiera sig, logga in och komma åt dina funktioner. Enligt den definitionen skapar en Google-knapp som bara används för att importera en fil inget huvudkonto. 4.8 gäller skärmen där man går in i din app.

Vad som ändrades i januari 2024

Före 2024 krävde regeln "Sign in with Apple" i appar som använde tredjepartsinloggning för huvudkontot. Den 25 januari 2024 mjukade Apple upp det: du kan erbjuda Apple-inloggning, eller en likvärdig tjänst som skyddar integriteten. Många sidor säger fortfarande motsatsen. Expos dokumentation skriver fortfarande att en app med tredjepartsinloggning måste erbjuda Apple.

I praktiken slutar avslagsmeddelandet för 4.8 som publicerats på Apples utvecklarforum så här: "Note that Sign in with Apple meets the requirements specified in guideline 4.8". Apple nämner ingen annan tjänst som uppfyller kraven. För att slippa gissningslekar med granskaren lägger jag till Apple-inloggning.

De fem undantag som texten anger

Apple listar fem fall där ingen annan inloggning krävs:

1. Din app använder bara ditt eget kontosystem, till exempel e-post med lösenord eller en kod som skickas via e-post.
2. Din app är en alternativ appbutik, eller distribueras via en sådan, med en inloggning som hör till den butiken.
3. Din app är en utbildnings-, företags- eller yrkesapp och kräver ett befintligt skol- eller företagskonto.
4. Din app använder ett system för elektronisk identifiering som stöds av en stat eller en bransch.
5. Din app är klient för en specifik tredjepartstjänst: personen loggar in på sin e-post eller sitt sociala nätverk för att komma åt sitt eget innehåll.

Innan du ens tittar på undantagen, ställ dig en fråga: behöver din app ett konto? Om inte kräver guideline 5.1.1(v) att den går att använda utan inloggning, som jag förklarar i guiden om guideline 5.1.1.

Din inloggningsskärm	Gäller 4.8?
Inget konto	Nej
Bara e-post eller kod	Nej
Bara Google	Ja
Google och e-post	Ja, i princip
Google och Apple	Ja, och godkänt
Befintligt skolkonto	Nej
Google för en import	Nej, inget konto

Lägga till "Sign in with Apple" i en Expo-app

1. Installera modulen och deklarera capabilityn

npx expo install expo-apple-authentication

Expos dokumentation säger sedan att du ska aktivera capabilityn i appens konfiguration:

{
  "expo": {
    "ios": {
      "usesAppleSignIn": true,
      "infoPlist": { "CFBundleAllowMixedLocalizations": true }
    }
  }
}

Den andra raden visar knappen på iPhonens språk. Med EAS Build aktiveras capabilityn på ditt app-ID när bygget körs. Det är en native-inställning: den följer med ett nytt bygge, aldrig med en fjärruppdatering.

En fälla jag hittade när jag gick igenom startkoden i mina kit: den här capabilityn kräver signering, även för att köra appen i simulatorn. På en Mac utan "Apple Development"-certifikat misslyckades den lokala kompileringen med "No code signing certificates are available to use". Lösningen: aktivera Apple-inloggning först när autentiseringsservern är konfigurerad.

2. Visa den officiella knappen, lika synlig som Google

Apples designregler är tydliga: Apple-knappen får inte vara mindre än de andra inloggningsknapparna, och man ska inte behöva scrolla för att se den. Expos komponent ritar den officiella knappen, med en titel som Apple godkänner.

import * as AppleAuthentication from "expo-apple-authentication";
import { useEffect, useState } from "react";

export function BoutonApple({ onPress }: { onPress: () => void }) {
  const [disponible, setDisponible] = useState(false);

  useEffect(() => {
    AppleAuthentication.isAvailableAsync().then(setDisponible);
  }, []);

  // Android och webb: ingen Apple-inloggning, ingen knapp.
  if (!disponible) return null;

  return (
    <AppleAuthentication.AppleAuthenticationButton
      buttonType={AppleAuthentication.AppleAuthenticationButtonType.CONTINUE}
      buttonStyle={AppleAuthentication.AppleAuthenticationButtonStyle.BLACK}
      cornerRadius={12}
      style={{ width: "100%", height: 50 }}
      onPress={onPress}
    />
  );
}

Expo påpekar att knappen inte syns utan bredd och höjd. Färg och hörnradie sätts med buttonStyle och cornerRadius, inte via style.

3. Öppna sessionen i Supabase

import * as AppleAuthentication from "expo-apple-authentication";
import { supabase } from "./supabase";

export async function connexionApple(): Promise<"ok" | "annule"> {
  try {
    const credential = await AppleAuthentication.signInAsync({
      requestedScopes: [
        AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
        AppleAuthentication.AppleAuthenticationScope.EMAIL,
      ],
    });
    if (!credential.identityToken) throw new Error("Apple-token saknas");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // Förnamnet kommer bara vid första godkännandet: spara det direkt.
    const prenom = credential.fullName?.givenName;
    if (prenom) await supabase.auth.updateUser({ data: { prenom } });
    return "ok";
  } catch (e) {
    if ((e as { code?: string }).code === "ERR_REQUEST_CANCELED")
      return "annule";
    throw e;
  }
}

Fyra detaljer spelar roll, hämtade från Supabases dokumentation, Expos dokumentation och Apples designregler:

• I Supabase anger du ditt bundle-ID under Client IDs för Apple-providern. En app som bara är native behöver ingen hemlig nyckel för att logga in. Lägg till host.exp.Exponent om du testar i Expo Go.
• Förnamn och e-post kommer bara en gång. Apple skickar dem inte vid senare inloggningar: spara dem direkt vid första svaret.
• E-postadressen kan vara en relayadress. Apple rekommenderar att du inte ber om en personlig adress efteråt.
• En avbrytning är inget fel. I Nolera visas inget rött meddelande när man stänger Apple-arket: det är ett medvetet val.

Ett verkligt fall i Solys, augusti 2026: Apple- och Google-knapparna fanns i appen, men ingen av de två providers var aktiverad i Supabase. Koden var rätt, rättningen gjordes på serversidan, utan nytt bygge. En Apple-knapp som misslyckas framför granskaren ger ett avslag enligt 2.1 i stället för 4.8. Detaljerna finns i guiden om guideline 2.1.

4. Testa på en riktig iPhone

Expo varnar för att simulatorn bara ger ett begränsat test, och att de identifierare du får i Expo Go skiljer sig från den publicerade appens. Testa inloggning, utloggning och ny inloggning på en riktig iPhone, med ett TestFlight-bygge.

Apple-inloggning och kontoradering

Guideline 5.1.1(v) kräver att ett konto som skapats i appen kan raderas från appen. Med Apple-inloggning lägger Apples sida om kontoradering till ett steg: använda Sign in with Apples REST-API för att återkalla personens tokens.

Återkallelsen kräver två saker: en token för personen, som du får genom att validera en auktoriseringskod, och en hemlighet signerad med din privata Sign in with Apple-nyckel. Även om den native inloggningen klarar sig utan hemlig nyckel kräver återkallelsen en, och den stannar på din server. Varför förklarar jag i hemlig API-nyckel i en Expo-app.

I Nolera ber appen om en ny Apple-inloggning när kontot ska raderas, för att få en färsk auktoriseringskod. Den skickas till en serverfunktion som byter in den hos Apple och sedan återkallar token. Om personen avbryter visas ett tydligt meddelande och ingenting raderas. Resten av flödet, med data, prenumeration och tester, finns i kontoradering i iOS.

Vad du svarar Apple efter ett avslag enligt 4.8

Apples meddelande ger två vägar ut. Antingen lägger du till ett likvärdigt alternativ. Eller så har din app redan ett: då svarar du i App Store Connect, säger vilket och varför det uppfyller de tre villkoren. Apple föreslår också att du uppdaterar skärmbilderna som visar inloggningsskärmen. Hur du svarar App Review fungerar likadant som för andra regler.

Här är en mall på engelska att anpassa (byt ut byggnumret):

Hello,

Thank you for your review.

Build X adds Sign in with Apple as an equivalent login option.
It appears on the same screen as Google Sign-In, with the same
size, and is visible without scrolling.

How to verify: launch the app, open the sign-in screen and
tap "Continue with Apple".

We also updated the screenshots that show the sign-in screen.

Best regards,

Checklistan för 4.8 före inskick

• Du vet om din app behöver ett konto. Om inte går den att använda utan inloggning.
• Om Google, Facebook eller X skapar kontot finns Apple-inloggning på samma skärm.
• Apple-knappen är den officiella, lika stor som de andra, synlig utan att scrolla.
• Apple-providern är aktiverad på serversidan, med ditt bundle-ID.
• En avbrytning leder tillbaka till inloggningsskärmen, utan felmeddelande.
• Förnamn och e-post sparas redan vid första inloggningen.
• Kontoraderingen återkallar Apple-token, från din server.
• Allt är testat på en riktig iPhone, med ett Apple-konto som aldrig loggat in i appen.
• Dina skärmbilder visar inloggningsskärmen som den ser ut i bygget du skickar in.

Rätta till avslaget innan du skickar in appen igen

Om din app just fått avslag enligt 4.8 samlar Apple Review Kit allt jag kontrollerar före varje inskick, med två skills som går igenom ditt projekt i Claude Code och förbereder ditt svar om Apple avvisar appen. Vill du ha ett mänskligt öga, boka en timme med mig: vi läser meddelandet tillsammans och tittar på din inloggningsskärm. Hela tillvägagångssättet efter ett avslag finns på sidan app avvisad av Apple.

Förbereder du din första release, gör din gratis diagnos: den säger vilket steg du ska ta itu med först och skickar dig min checklista mot avslag från Apple.

Ingen kan garantera att Apple godkänner din app. Att lägga till Apple-inloggning på rätt ställe stryker åtminstone den här orsaken från listan.

Vanliga frågor

Är inloggning med Apple obligatorisk på iOS?

Nej, inte i alla fall. Den krävs bara om din app erbjuder en tredjepartsinloggning, som Google eller Facebook, för att skapa huvudkontot. Sedan januari 2024 kan en annan likvärdig tjänst ersätta den, men Apple nämner bara Apple-inloggning som godkänd.

Vad betyder "Guideline 4.8 - Design - Login Services"?

Det är rubriken på avslaget i Apples meddelande. Det betyder att din app erbjuder en tredjepartsinloggning utan ett likvärdigt alternativ som begränsar datan till namn och e-post, låter användaren dölja e-posten och inte används för reklam utan samtycke.

Räcker min registrering med e-post vid sidan av Google?

Det är inte säkert. Texten kräver en tjänst som låter användaren hålla sin e-post privat, medan ett vanligt formulär ber om den. Apple har inte publicerat någon ståndpunkt i just det fallet, och avslagsmeddelandet nämner bara Apple-inloggning. Jag skulle inte ta den risken.

Måste jag erbjuda Apple-inloggning på Android?

Nej. 4.8 är en App Store-regel, och Expos modul fungerar bara på iOS. På Android returnerar isAvailableAsync() false: Apple-knappen visas inte, och Google kan stå ensam.

Behövs ett nytt bygge efter ett avslag enligt 4.8?

Ja, i de flesta fall. Apple-inloggning kräver en native capability som aktiveras när bygget körs. En fjärruppdatering kan inte lägga till den. Enda undantaget: din app hade redan ett godkänt alternativ, och då räcker det att förklara det för Apple i ditt svar.