Checklista för inskickning till App Store (2026): från Xcode 26-build till Submit for Review

En checklista för inskickning till App Store är en lista över det som måste vara klart samtidigt innan du skickar in: en fungerande build, en korrekt butikssida, sanningsenliga integritetssvar och tillräckligt med sammanhang för att en granskare ska kunna använda din app. En grön build räcker inte ensam. De sex avsnitten nedan följer den ordning som App Store Connect frågar efter dem, och varje avsnitt inleds med ett kort svar som du kan agera på.

Vad behöver en inskickning till App Store innan du trycker på Submit?

En inskickning till App Store behöver en bearbetad build kopplad till versionen, versionens obligatoriska metadata, skärmdumpar, en integritetspolicy, kontaktuppgifter för App Review och, om appen har inloggning, fungerande inloggningsuppgifter till ett demokonto. Apples egen lista ”Before You Submit” i App Review Guidelines lägger till två punkter till: ”Aktivera backend-tjänster så att de är igång och tillgängliga under granskningen” och förklara funktioner som inte är självklara i granskningsanteckningarna.

Vilka konto- och appinställningar måste vara klara?

Du behöver ett aktivt Apple Developer-medlemskap, en apppost vars bundle ID matchar din signerade build och någon i teamet med rollen Account Holder, Admin eller App Manager. Det är de roller som Apples sida Submit an app kräver för att skicka in.

När du skapar posten väljer du namn, primärt språk och SKU. SKU:n är intern och syns aldrig för kunderna. Om du säljer en betalapp eller köp i appen ska du först slutföra avtalen för betalappar samt skatte- och bankuppgifter. Ett osignerat avtal kan stoppa en kommersiell lansering även när builden är i ordning.

Vilka buildkrav gäller för uppladdningar till App Store 2026?

Från och med oktober 2026 anger Apples sida upcoming requirements att ”appar som laddas upp till App Store Connect måste byggas med Xcode 26 eller senare med ett SDK för iOS 26, iPadOS 26, tvOS 26, visionOS 26 eller watchOS 26” (sedan den 28 april 2026). Där står också att iOS- och iPadOS-appar ”måste rikta sig mot iOS 13 eller senare” (sedan den 9 september 2026).

• Höj buildnumret vid varje uppladdning och se till att versionsnumret matchar den release du tänker släppa.
• Uppdatera Xcode-imagen i CI (Codemagic, Expo EAS, GitHub Actions och så vidare) och inte bara på din egen dator.
• Efter bearbetningen svarar du på eventuella frågor om exportregler och kopplar den bearbetade builden till versionen.
• Installera TestFlight-builden på en fysisk enhet. Testa onboarding, inloggning, offlinelägen, köp och återställning av köp. Att appen fungerar i simulatorn bevisar inte att den distribuerade builden fungerar.
• Läs mejlet som App Store Connect skickar efter uppladdningen. ITMS-varningar om integritetsmanifest eller SDK-versioner blir hinder om du ignorerar dem.

Riktlinje 2.1(a) är rak om vad som annars händer: ”Vi avvisar ofullständiga apppaket och binärer som kraschar eller uppvisar uppenbara tekniska problem.” Ta bort platshållarskärmar, felsökningsmenyer och döda länkar innan du arkiverar. Vår testplan för release-builds enligt 2.1 går igenom dessa kontroller i detalj.

Vilka skärmdumpar och vilken metadata kräver App Store Connect?

Från och med oktober 2026 kräver Apples specifikationer för skärmdumpar minst en skärmdump för ”iPhone with Dynamic Island (medium display)”, till exempel 1206 × 2622 eller 1179 × 2556 i stående läge. Appar som körs på iPad behöver också minst en skärmdump för iPad 13 tum, till exempel 2064 × 2752 eller 2048 × 2732.

Du ”kan ladda upp upp till 10 skärmdumpar per enhetsstorlek i formaten .jpeg, .jpg eller .png”, och ”bilder får inte innehålla alfakanaler eller transparens.” Om gränssnittet är detsamma i alla storlekar laddar du bara upp den högsta obligatoriska upplösningen, så skalar App Store Connect ned den. Riktlinje 2.3.3 säger att skärmdumpar ”ska visa appen när den används, och inte bara titelgrafik, inloggningssida eller startskärm.”

• Skriv en beskrivning som säger vem appen är till för och vad man kan göra under sin första session.
• Håll namn, undertitel och nyckelord relevanta. Upprepa inte nyckelord och använd inte konkurrenters namn.
• Se till att support-URL:en och URL:en till integritetspolicyn laddas utan inloggning.
• Besvara frågeformuläret för åldersgräns utifrån vad appen faktiskt innehåller och kan göra.
• Visa den aktuella builden i skärmdumparna, inklusive eventuell betalvägg som användaren stöter på.

Hur får du integritetssvaren att stämma med appen?

För att integritetssvaren ska stämma med appen listar du varje SDK du levererar och vilka data den samlar in, och använder sedan den listan för att fylla i App Privacy, skriva integritetspolicyn och utforma beteendet i appen. Riktlinje 2.3 säger att din metadata, ”inklusive integritetsinformation”, måste återspegla appen korrekt.

Riktlinje 5.1.1(i) slår fast: ”Alla appar måste ha en länk till sin integritetspolicy i metadatafältet i App Store Connect och i appen på ett lättillgängligt sätt.” Riktlinje 5.1.1(v) lägger till: ”Om din app stöder att konton skapas måste du också erbjuda kontoradering i appen.” SDK:er för analys, kraschrapportering, annonser och inloggning ändrar oftast dina svar, så granska dem med vår SDK-granskning för integritetsetiketter. Kontrollera också att din app och varje inkluderad SDK levereras med ett integritetsmanifest, PrivacyInfo.xcprivacy, som täcker alla required-reason-API:er de använder.

Vad ska App Review Information innehålla?

App Review Information ska innehålla en kontaktperson som svarar, inloggningsuppgifter till ett demokonto som fungerar och inte går ut, samt anteckningar som tar granskaren direkt till dina kärnfunktioner. Riktlinje 2.1(a) ber dig att ”inkludera uppgifter om ett demokonto (och slå på din backend-tjänst!) om din app har en inloggning”; ett inbyggt demoläge i stället för ett konto kräver Apples godkännande i förväg.

Här är ett konkret exempel på granskningsanteckningar: ”Logga in med det bifogade granskningskontot. Öppna Library, välj exempelprojektet och tryck på Export. Kontot har alla premiumfunktioner upplåsta. Platsfunktionerna använder en simulerad stad, så ingen resa behövs.” Skicka inte granskare till ett tomt konto, en engångskod som går ut eller ett flöde som bara fungerar medan du själv är online och godkänner det. Vår guide för att sätta upp ett demokonto visar hur du bygger en inloggning för granskare som håller.

Hur skickar du in en app för granskning i App Store Connect?

För att skicka in en app för granskning kopplar du builden till versionen, klickar på Add for Review och sedan på Submit for Review. Enbart Add for Review skickar ingenting till Apple. Stegen nedan följer Apples sida Submit an app från och med oktober 2026.

1. Under Apps väljer du appen och klickar sedan på appversionen i sidofältet.
2. Skrolla till avsnittet Build och bekräfta att rätt build är kopplad.
3. I avsnittet App Store Version Release väljer du manuell release om du vill bestämma lanseringsdagen själv, och klickar sedan på Save.
4. Klicka på Add for Review och välj ett befintligt utkast till inskickning eller skapa ett nytt. Statusen ändras till Ready for Review.
5. Klicka på Submit for Review. När granskningen börjar ändras statusen till In Review.
6. Spara en kopia av den inskickade metadatan och anteckningarna, och håll koll på granskningskontaktens e-post efter frågor.

Om inskickningen kommer tillbaka med avslag ska du läsa riktlinjenumret och granskarens förklaring innan du ändrar något. Vissa åtgärder gäller bara metadata. Andra kräver en ny build. Vår guide till avslag i App Store visar hur du avgör vilket slag du har.

Vad gick fel för andra utvecklare vid inskickningen?

I båda de offentliga fallen nedan fungerade appen för utvecklaren, och problemet visade sig först i den uppladdade builden eller under granskarens första session.

En utvecklare på Adalo-forumet fick ett avslag enligt riktlinje 2.1: ”vi kunde inte logga in med de inloggningsuppgifter för demokontot som du angav.” Uppgifterna var giltiga, men det första trycket på inloggningsknappen gjorde ingenting och först det andra fungerade, eftersom villkorsstyrd navigering kördes på inloggningsknappen innan användarsessionen hade registrerats. Utvecklaren löste det genom att låta inloggningsknappen leda till en tom övergångsskärm som innehöll de villkorsstyrda åtgärderna, och skickade sedan in igen.

En utvecklare på JUCE-forumet fick ”ITMS-91053: Missing API declaration” efter en uppladdning, med beskedet att nya uppladdningar ”måste innehålla en NSPrivacyAccessedAPITypes-array i appens integritetsmanifest.” De flaggade kategorierna var SystemBootTime och FileTimestamp, och en annan användare rapporterade UserDefaults. Lösningen var en PrivacyInfo.xcprivacy-fil med godkända orsakskoder, tillagd som en resurs i Xcode. En användares första version saknade en typnyckel, vilket utlöste ITMS-91056 för ett ogiltigt manifest tills hen rättade det.

Båda utvecklarna hade bara testat i sin egen miljö. Testa den build som Apple faktiskt tar emot med en ny inloggning, och läs varje mejl efter uppladdningen, innan du trycker på Submit for Review. Om du vill att någon annan går igenom paketet en extra gång kan du se våra tjänster för inskickning.