Avvisad i App Store: så åtgärdar du det, riktlinje för riktlinje (2026)

Ett avslag i App Store är ett meddelande från App Review som hänvisar till en riktlinje, beskriver vad granskaren såg och stoppar releasen tills du åtgärdar, förklarar eller överklagar. Börja med att göra om meddelandet till ett problem du kan testa. Nästa steg beror på om granskaren inte kunde använda appen, hittade en avvikelse från policyn eller behöver mer information. I oktober 2026 uppdaterades App Review Guidelines senast den 16 oktober 2026, så kontrollera den aktuella numreringen innan du citerar ett avsnitt.

Vad säger ett avslagsmeddelande från App Store egentligen?

Ett avslagsmeddelande från App Store anger vilken riktlinje granskaren tillämpade, beskriver det konkreta beteende de såg och listar nästa steg. Ofta ingår enhet, iOS-version och skärmbilder.

Spara hela meddelandet, alla skärmbilder, byggnumret och enhetsuppgifterna. Läs det angivna avsnittet på den aktuella riktlinjesidan. Skriv sedan en mening: ”Granskaren kunde inte slutföra X på grund av Y.” Om meddelandet efterfrågar saknad information snarare än rapporterar ett fel, skriv ner exakt vad som saknas. Apples standardtext för 2.1 berättar också hur du återskapar problemet: ”För nya appar, avinstallera alla tidigare versioner av din app från en enhet, installera sedan och följ stegen för att återskapa problemet.”

• Nämner meddelandet en krasch, en skärm som inte går att nå eller en ofullständig funktion? Återskapa flödet i det inskickade release-bygget, på den enhetstyp Apple angav.
• Nämner det skärmbilder, beskrivningen eller granskningsanteckningarna? Kontrollera om du kan åtgärda det enbart i metadatan.
• Nämner det betalningar, inloggning, integritet eller minimifunktionalitet? Jämför produktens beteende med den angivna riktlinjen.

Vilka riktlinjer hänvisar avslag i App Store till, och vad kräver de?

Varje riktlinje ställer ett konkret krav, så matcha det angivna numret mot dess formulering och testa mot den formuleringen. Tabellen citerar den aktuella texten i de riktlinjer som avslagsmeddelanden ofta hänvisar till.

Uppdateringen den 16 oktober 2026 lade till 2.5.19 för dolda, vilande eller odokumenterade funktioner, som tidigare täcktes av 2.3.1. Den lade också till 2.3.14 om kreativa tillgångar och slog ihop entitlementen Music Streaming Services med StoreKit External Purchase Link-entitlementen under 3.1.1(a). Se tabellen som en utgångspunkt, inte som en garanterad lösning. En riktlinje kan täcka olika problem, och granskarens exempel är det konkreta fall du måste lösa.

Hur åtgärdar du ett avslag enligt 4.2 Minimum Functionality?

Åtgärda ett avslag enligt 4.2 genom att tillföra verkligt appvärde, inte genom att formulera om beskrivningen. Riktlinje 4.2 säger: ”Om din app inte är särskilt användbar, unik eller ’app-lik’ hör den inte hemma i App Store.”

Fråga dig vad någon kan göra i din app som gör den användbar just som app. De kanske slutför ett arbetsflöde, sparar meningsfullt tillstånd, använder enhetens funktioner på ett sätt som passar appen eller får en mobilupplevelse byggd för enheten. Ingen publicerad funktionslista garanterar godkännande. Om sådana arbetsflöden redan finns, lista dem i granskningsanteckningarna med exakta steg och skärmbilder. Om appen mest visar en webbsida behöver den produktarbete. Att lägga till notiser eller en tom inställningsskärm bara för att se inbyggd ut ersätter inte verkligt värde för användarna.

Hur svarar du App Review i App Store Connect?

Svara i App Store Connect: öppna inskickningen via appens länk om olösta problem, klicka på Resolve och klicka sedan på Reply to App Review. Enligt Apples hjälpsida kräver detta rollen Account Holder, Admin eller App Manager.

1. Välj appen under Apps.
2. Klicka högst upp på sidan på länken som visar att det finns olösta problem.
3. Klicka på Resolve bredvid inskickningen i avsnittet In Progress.
4. Klicka på Reply to App Review och skriv din text.
5. Om du vill bifoga skärmbilder eller dokument klickar du på Attach File och sedan på Reply.

Apple skriver att du kan korrespondera och bifoga filer ”tills du skickar in till App Review igen”, så skicka dina belägg innan du skickar in på nytt. Håll svaret kort och sakligt: berätta vad som ändrats, var det finns och hur det kan verifieras. Argumentera inte om andra appar som verkar göra samma sak.

Ska du rätta metadatan, ladda upp ett nytt bygge eller överklaga?

Rätta metadatan och skicka in samma bygge igen när det bara var listningsinformationen som var fel. Ladda upp ett nytt bygge när appens beteende måste ändras. Överklaga bara när du anser att appen redan följer riktlinjen.

Apples vägledning för överklaganden ber dig att ”förklara punkt för punkt hur din app uppfyller” riktlinjen. Där står också att du inte ska överklaga efter att du redan har åtgärdat problemen och skickat in igen. Ett fullständigt överklagande ”garanterar inte” att beslutet ändras. För appar som redan finns i butiken säger riktlinjernas policy för Bug Fix Submissions att buggfixar inte fördröjs på grund av riktlinjeöverträdelser ”utom sådana som rör juridiska frågor eller säkerhetsfrågor”.

Hur löste andra utvecklare verkliga avslag i App Store?

I offentliga forumtrådar berodde många avslag enligt 2.1 på skillnader mellan granskarens och utvecklarens miljö: ett annat nätverk, en annan enhet eller ett annat behörighetsläge. Ett avslag enligt 4.2 är ett produktproblem, så små justeringar räcker sällan.

Inloggningsfel enligt 2.1. En utvecklare på Apple Developer Forums citerade meddelandet ”Specifikt kunde vi inte logga in på grund av ett fel”, trots att live- och TestFlight-versionerna loggade in med samma inloggningsuppgifter. Andra utvecklare i tråden rapporterade olika lösningar. En löste det genom att ”byta http till https på webbservern”. En annan lade efter tre avslag till ett läge med ”Kontrollera din anslutning” i stället för en oändlig laddningsindikator. En tredje tog efter fem avslag bort iPad från deployment target, vilket kringgår problemet genom att slopa stödet för iPad.

Krasch vid start. På Solar2D-forumet fick en utvecklare beskedet ”Vi kunde inte granska appen eftersom den kraschade vid start” på en iPhone 13 mini med iOS 18.3.2. Den bifogade kraschloggen visade att nyckeln NSUserTrackingUsageDescription saknades. Utvecklaren bekräftade: ”Den gick igenom efter att jag lade till: NSUserTrackingUsageDescription.”

WebView-app enligt 4.2. En utvecklare på Apple Developer Forums rapporterade ett tionde avslag för en WebView-baserad app. Granskaren hade skickat en skärmbild av vänstermenyn och skrivit att den saknade innehåll. Huvudskärmarna var nu inbyggda, men två eller tre öppnade fortfarande en WebView. Svaret som markerats som lösning kom från App Review och rekommenderade en personlig App Review-konsultation. Tråden bekräftar inget godkännande.

Jämförelsen: fallen enligt 2.1 löstes genom att återskapa granskarens förhållanden och läsa kraschloggen. Fallet enligt 4.2 körde fast eftersom varje ny inskickning bara ändrade en del av en app som fortfarande mest var en webbplats.

Hur förhindrar du att samma avslag händer igen?

Gör varje löst problem till en punkt på din release-checklista och testa om den i release-bygget före varje inskickning. Apples riktlinjer varnar för att granskningen ”tar längre tid” om en app upprepade gånger avvisas för samma riktlinjeöverträdelse.

• Radera appen och installera sedan release-bygget från början på en fysisk iPhone och iPad.
• Logga in med granskningskontot på ett nätverk utan utvecklingsservrar eller HTTP-undantag.
• Öppna varje behörighetsdialog och kontrollera att varje användningsbeskrivning i Info.plist finns.
• Se till att varje köp i appen är inskickat, synligt och förklarat i granskningsanteckningarna.
• Uppdatera granskningsanteckningarna när ett flöde ändras. Klistra inte in anteckningar från sex releaser sedan.

För problem enligt 2.1, följ testplanen för release-bygget vid avslag enligt 2.1 och sätt upp ett demokonto för granskare. Gå sedan igenom checklistan för inskickning inför nästa bygge. Om granskningsbeskedet fortfarande lämnar dig fast, skicka oss detaljerna så hjälper vi dig att reda ut om det som saknas är åtkomst, metadata eller kod.