Demokonto för App Store-granskning: så skapar du en granskarinloggning som klarar granskningen (2026)

Om någon del av din app ligger bakom en inloggning måste ditt demokonto för App Store-granskningen fungera första gången Apple provar det. Apples App Review Guidelines kräver uppgifter om ett demokonto, eller ett fullt fungerande demoläge, och att din backend är igång under granskningen. I praktiken innebär det ett dedikerat konto som aldrig löper ut, redan innehåller realistisk data, når alla betalda och rollbaserade funktioner och inte kräver en inloggningskod som bara du kan se. Den här guiden visar hur du bygger kontot, hur du skriver anteckningarna som hör till och vad andra utvecklare råkade ut för när det inte fungerade.

Vad kräver Apple av ett demokonto för App Store-granskning?

Apple kräver ett fungerande användarnamn och lösenord för ett demokonto så snart en app kräver inloggning. Uppgifterna anges under App Review Information i App Store Connect, och kontot får inte löpa ut. Riktlinje 2.1(a) kräver dessutom att din backend är igång under granskningen.

Riktlinje 2.1(a) lyder: ”include demo account info (and turn on your back-end service!) if your app includes a login” – alltså att du ska ange demokontouppgifter (och slå på din backendtjänst!) om appen har en inloggning. App Store Connects referens för plattformsversionsinformation tillägger att demokontot ”används under App Review-processen och inte får löpa ut”, att ”uppgifter om ytterligare konton ska anges i fältet Notes” och att Notes ”kan innehålla upp till 4000 byte”. Fälten för Sign-in required gäller ”om din app kräver inloggning för att användas”.

Apples hjälpsida om en komplett granskning är ännu tydligare: ”Inloggningsuppgifter som löper ut eller ändras innan granskningen börjar kan leda till att inskickningen avvisas.” Om din app har flera kontotyper, till exempel admin och vanlig användare, ska du ange inloggningsuppgifter för var och en i Notes. Om du säljer automatiskt förnyade abonnemang ska du ”tillhandahålla ett demokonto med ett utgånget abonnemang så att hela köpflödet kan granskas”.

Hur sätter du upp ett demokonto för App Review?

Sätt upp ett demokonto genom att skapa ett dedikerat produktionskonto, hålla alla utgångs- och rensningsjobb borta från det, fylla det med realistisk data och logga in på exakt det releasebygge du skickar in innan du skickar in.

1. Skapa ett dedikerat produktionskonto, till exempel appreview@yourdomain.com. Återanvänd inte ett personligt konto eller ett QA-konto som någon kan ändra.
2. Undanta det från alla rensningsjobb: lösenordsrotation, radering av inaktiva konton, utgång av provperioder och bedrägeriregler.
3. Fyll det med realistiskt innehåll så att ingen skärm är tom. Granskare bedömer fullständigheten utifrån det de ser.
4. Ställ in abonnemangsstatusen enligt Apples riktlinjer. Om du säljer abonnemang ska kontot ha ett utgånget abonnemang så att betalväggen och köpflödet visas.
5. Ställ in det på en region där alla dina funktioner fungerar, eller beskriv de regionala skillnaderna i Notes.
6. Logga in på en ren enhet med exakt det releasebygge du skickar in och gå sedan igenom varje funktion du nämner i Notes.
7. Rör inte lösenordet igen förrän granskningen är klar.

Vad gäller om appen använder inloggningskoder, SMS-engångskoder, magiska länkar eller SSO?

Om inloggningen kräver en engångskod ska du skriva en fast kod för granskningskontot i Notes innan du skickar in. Apple varnar för att det utan en sådan kod ”kan krävas ett samtal för att fortsätta granskningen”, och de samtalen ”genomförs normalt inom tre till fem arbetsdagar”.

För magiska länkar via e-post eller engångskoder via SMS ställer du in granskningskontot så att det accepterar en fast kod eller ett lösenord, och anger koden i Notes. Om du använder en tredjepartstjänst för enkel inloggning (SSO) ber App Store Connect dig att även ”ange inloggningsuppgifterna för demokontot för den tjänsten”.

Om du inte kan dela ett demokonto av juridiska eller säkerhetsmässiga skäl, vilket är vanligt i bank-, hälso- och andra reglerade appar, tillåter riktlinje 2.1(a) att du använder ”ett inbyggt demoläge i stället för ett demokonto med förhandsgodkännande från Apple”. Demoläget måste visa ”appens fullständiga funktioner och funktionalitet” med demonstrationsdata, inte en nedbantad rundtur.

Vilka konton ska du ge App Review?

Ge App Review en inloggning som inte löper ut för varje kontotyp i din app, plus det som krävs för att ta sig förbi koder, betalväggar och hårdvarukrav. Tabellen visar var varje upplägg ska anges.

Vad ska granskningsanteckningarna för ett demokonto innehålla?

Bra granskningsanteckningar beskriver appens koncept, alla inloggningar, inloggningskoden, hur man når betalväggen, var varje funktion finns, eventuella regionala skillnader och vilka enheter du har testat på. Här är ett exempel för en påhittad vanespårare för team som använder inloggningskoder via e-post och ett Pro-abonnemang.

CONCEPT: Team habit tracker. Coaches create groups; members log daily habits.
Pro subscription (monthly/annual) unlocks progress reports.

ACCOUNTS (non-expiring, pre-filled with 30 days of data):
- Member: review-member@example.com (in the username/password fields)
- Coach: review-coach@example.com / password: [shared here]
- Deletion test: review-delete@example.com / password: [shared here]

LOGIN CODE: The app emails a 6-digit code. For these review
accounts, enter 246810.

SUBSCRIPTION: The member account's subscription has expired.
Tap Reports > Upgrade to see the full purchase flow.

WHERE TO LOOK: Groups tab (coach) > Create group. Today tab (member)
> Log habit. Settings > Account > Delete account.

REGIONS: All features work the same in every storefront.
TESTED ON: iPhone 15 (iOS 26), iPad Air (iPadOS 26).
SERVICES: Supabase (auth/data), RevenueCat (subscriptions).

Håll det kort och praktiskt. För uppdateringar säger Apples hjälpsida att du ska ”beskriva vad som har ändrats och var granskarna hittar betydande nytt innehåll eller nya funktioner”. Riktlinje 2.3.1(a) kräver att nya funktioner ”beskrivs specifikt” och varnar för att ”generiska beskrivningar avvisas”. Riktlinjernas formuleringar ändras flera gånger om året, så läs vår sammanfattning av ändringarna i App Review Guidelines i oktober 2026 innan du skickar in.

Varför misslyckas inloggningen med demokontot i granskningen? Verkliga fall

I offentliga rapporter misslyckas demoinloggningar oftast av ett av två skäl: en andra faktor som granskaren inte kan ta emot, eller ett konto som fungerar för utvecklaren men ger ett fel på Apples enhet. Två trådar i Apple Developer Forums visar båda.

SMS-baserad tvåfaktorsautentisering på en central funktion. En utvecklare i Apple Developer Forums berättade att deras app ”ständigt avvisades” eftersom profilredigering krävde en kod som skickades via sms till ett amerikanskt mobilnummer. De förklarade att ”eftersom vi inte har granskarens mobilnummer … får granskaren inte verifieringskoden”. Andra utvecklare i tråden beskrev lösningar: en ändrade backend ”så att testkontot alltid får samma 2FA-kod” och angav den i anteckningarna, och en annan kopplade ett produktionskonto till ett virtuellt telefonnummer och gav Apple åtkomst till det.

Inloggningsuppgifter som fungerar överallt utom i granskningen. En utvecklare som använde React Native och Expo med Supabase-autentisering via e-post och lösenord rapporterade upprepade avslag. Apples skärmbild visade rätt e-postadress och felet ”Invalid login credentials”, men inloggningen fungerade från utvecklarens enheter, Postman och Supabase-klienten, utan MFA, hastighetsbegränsning eller geoblockering. Tråden har ingen bekräftad orsak. Utvecklaren övervägde att lägga till ett demoläge, men enligt riktlinje 2.1(a) kräver den vägen Apples förhandsgodkännande.

Det fallen har gemensamt: granskarens upplevelse är det enda test som räknas. En fast kod i Notes löser problemet med den andra faktorn. För problemet ”det funkar för mig” behöver du logga in på releasebygget, på en ren enhet, mot produktion – och sedan låta kontot vara.

Vad ska du kontrollera innan du skickar in med ett demokonto?

Innan du skickar in ska du bekräfta att demoinloggningen fungerar på releasebygget, att varje roll och kod finns i Notes och att inget kommer att låta kontot löpa ut, rotera lösenordet eller radera kontot under granskningen.

• Inloggad på releasebygget på en ren enhet under den senaste timmen
• Backend, autentiseringsleverantör och e-post- eller SMS-tjänst är alla igång och hastighetsbegränsar inte kontot
• Kontot är undantaget från jobb för utgång, rensning och lösenordsrotation
• Varje roll har en egen inloggning i Notes
• Abonnemangsstatusen visar köpflödet
• Ett separat konto är redo för raderingstestet
• Inloggningskoden eller förbikopplingen står i Notes
• Kontakttelefonnumret är i internationellt format med plustecken (+), och någon kommer att svara

Enligt Apples App Review-sida är ”i genomsnitt över 40 % av de olösta problemen kopplade till riktlinje 2.1: App Completeness”, som omfattar ofullständig information. En trasig demoinloggning är något av det enklaste att förebygga där. För att kontrollera resten av bygget kan du använda vår testplan för releasebyggen vid 2.1-avslag.

Vad gör du om App Review ändå inte kan logga in?

Om App Review inte kan logga in: åtgärda kontot, testa det igen på releasebygget, uppdatera App Review Information och svara i App Store Connect med exakt vad du har ändrat. App Review Information ”kan redigeras när som helst”.

Läs avslagsmeddelandet noggrant. Ofta är orsaken en enkel diskrepans: ett lösenord har ändrats, en session har gått ut eller granskaren befann sig i en region som din backend blockerar. Vår guide om att göra om ett granskningsmeddelande till en åtgärd går igenom svaret. Om du hellre vill lämna över granskningsförberedelserna förbereder vår tjänst för App Store-inskickning granskningen och arbetar igenom avslagsfeedback tillsammans med dig, för $599 för båda butikerna (avgifterna för utvecklarkonton tillkommer).