Retningslinjer for skjermbilder i App Review: Apples regler oppsummert

Hvorfor bryr Apple seg spesifikt om skjermbilder?

App Store er kuratert. Apples standpunkt, gjengitt i innledningen til App Review Guidelines, er at en butikk av høy kvalitet er til fordel for både brukere og utviklere. Skjermbilder er brukerens førsteinntrykk; villedende skjermbilder svekker tilliten til hele butikken. Det er derfor håndhevingen av skjermbilder er blant de strengeste delene av App Review, og hvorfor det å rette opp problemer raskt er viktigere enn å diskutere.

Hva betyr «nøyaktig fremstilling» (2.3.3)?

Retningslinje 2.3.3 krever at skjermbilder viser appen mens den faktisk kjører. Gråsonen er hva som teller som «kjører». Apple er strenge når det gjelder:

• Konseptkunst for funksjoner som ikke leveres i binærfilen du sendte inn
• Forhåndsrenderte markedsføringsillustrasjoner som viser appen i et hypotetisk scenario
• Konkurrenters skjermbilder utgitt for å være dine egne

Apple er mer tillatende når det gjelder:

• Enhetsmockups — den ekte appskjermen din satt sammen i en iPhone-ramme er greit
• Bildetekster og overskrifter — tekstoverlegg som forklarer hva skjermen gjør
• Bakgrunner — gradient- eller fotografiske bakgrunner bak enhetsrammen
• Genererte eksempeldata som plausibelt representerer det en ekte bruker ville sett

Hvorfor er plassholderinnhold et problem?

Lorem ipsum, «User Name» og åpenbare testkontoer (f.eks. «test@test.com») signaliserer et uferdig produkt. App Review behandler disse som tegn på at appen er uferdig — en rask vei til avslag. Fyll ut hvert felt med plausible data: realistisk utseende navn, realistiske transaksjonsbeløp, gjeldende datoer. Genererte data er greit; åpenbare plassholderdata er det ikke.

Hva med feil enhetsstørrelser (2.3.10)?

Retningslinje 2.3.10 dekker nøyaktigheten av metadata. Å sende inn et 6,1-tommers skjermbilde i 6,7-tommers-sporet — selv om det er oppskalert — blir avvist fordi det resulterende bildet ikke representerer appen i den større enhetens faktiske sideforhold. Bruk de enhetsspesifikke renderne vi lister opp i guiden om skjermbildestørrelser i App Store, og la Screenshots.live API-et generere hver enhet nativt i stedet for å skalere.

Kan du nevne Android i iOS-skjermbilder?

Nei. Retningslinje 2.3.10 forbyr referanser til andre mobile plattformer i iOS-metadata, inkludert skjermbilder. Vanlige overtredelser:

• «Now on Android»-bannere
• Google Play-nedlastningsmerker
• Skjermbilder som viser appen din inne i en Android-enhetsramme (Pixel, Galaxy) i stedet for en iPhone-ramme

Løsningen er plattformspesifikke varianter: samme mal, ulik konfigurasjon av enhetsramme. Render iOS-varianten med iPhone-rammer, Android-varianten med Pixel-rammer, og last opp til den aktuelle butikken. Se funksjonen for støtte til flere plattformer for konfigurasjonen.

Hva med markedsføringspåstander (2.3.7)?

Apple har avvist oppføringer for udokumenterte superlativer: «#1 productivity app», «Best note-taker on iOS», «Used by 10M+ teams». Løsningen er enten:

• Oppgi en kilde i skjermbildet eller bildeteksten («Top 10 in Productivity, App Store, US, mars 2026»)
• Vær spesifikk i stedet for å bruke superlativer («Trusted by 8,432 teams» hvis det tallet er korrekt)
• Fjern påstanden helt og len deg på selve produktet

Hvordan samspiller aldersgrenser med skjermbilder?

Aldersgrensen du velger i App Store Connect gjelder for hvert eneste element i oppføringen — også skjermbildene. En 4+-app som viser alkohol, tobakk, intens vold eller suggestivt innhold i skjermbilder, blir oppgradert til en høyere aldersgrense, eller avvist hvis aldersgrensen ikke kan rommer innholdet. Tilpass innholdet til aldersgrensen fra starten: hvis skjermbildet ditt trenger et UI med vinmeny, må appens aldersgrense allerede romme alkoholreferanser.

Hvilke enhetsrammer er tillatt?

Apple tillater å vise appen din inne i en Apple-enhetsramme for enhetsklassen du oppgir (iPhone, iPad, Apple Watch, Apple TV). Ikke:

• Endre enhetsrammen visuelt (egendefinerte farger, logoer)
• Bland Android-rammer inn i iOS-oppføringer
• Bruk generiske «telefonformede» rammer som ikke er godkjent av Apple

Bruk Apples offisielle ressurser for enhetsrammer (Sketch- / Figma-biblioteker) når du designer malen din.

Hva med tredjepartslogoer og opphavsrettsbeskyttet innhold?

Retningslinje 5.2 dekker immaterielle rettigheter. Den vanligste overtredelsen i skjermbilder er et falskt push-varsel fra et merke appen ikke har lisens til å bruke: for eksempel «Slack: New message from Eve» i et skjermbilde av en app som ikke er Slack. Bruk generiske mock-varsler, anonymisert merkelignende UI (uten ekte logoer), eller lisensiert innhold med dokumenterbare rettigheter.

Hvordan gjelder riktige priser (3.1.1)?

Hvis et skjermbilde sier «Free forever», men appen din bruker et abonnement på 4,99 USD/måned, kan du forvente avslag. Prispåstander i skjermbilder må gjenspeile den faktiske IAP-en eller abonnementet du leverer. Det samme gjelder påstander om «No ads», «One-time purchase» og varigheten av «Free trial» — alt må samsvare med det brukeren møter i appen.

Hva med uoverensstemmelser på språk-/regionnivå?

En prislapp i amerikanske dollar i den tyske oppføringen din virker uoppmerksom både for App Review og for brukerne. Det samme gjelder datoformater (MM/DD/ÅÅÅÅ i en tysk oppføring), sosiale referanser («Trending on Twitter» i en oppføring i Fastlands-Kina der Twitter er blokkert) og høytider (Thanksgiving-utrop i ikke-amerikanske oppføringer). Lokaliseringsguiden dekker overstyringer per språk/region for nettopp disse tilfellene.

Hva gjør du når du blir avvist?

De fleste avslag på skjermbilder er enkle å fikse: endre det aktuelle elementet i malen din, render på nytt via API, last opp på nytt, send inn på nytt. Hele syklusen tar vanligvis under en time. To råd:

• Les den nøyaktige retningslinjen som Apple siterer i Resolution Center. Løsningen er nesten alltid mer avgrenset enn du tror — noen ganger et enkelt element på et enkelt skjermbilde.
• Send inn på nytt før du klager. Klager via Resolution Center tar dager; ny innsending etter en rettelse behandles vanligvis i løpet av timer. Klager gir mening når du oppriktig mener at vurderingen var feil — ikke når løsningen er åpenbar.

Hvordan skiller Google Plays regler seg ut?

Google Plays Store Listing and Promotional Content Policy dekker lignende områder, men er generelt mer tillatende når det gjelder markedsføringsspråk og strengere på villedende funksjonalitet. Det grunnleggende — nøyaktig fremstilling, ingen falske varsler, samsvar med aldersgrense — gjelder på begge plattformer. De tekniske spesifikasjonene er forskjellige; se vår guide til skjermbildekrav i Google Play for disse.

Konklusjonen

Den raskeste måten å holde seg unna App Reviews avslagsbunke for skjermbilder, er å ta utgangspunkt i en mal som allerede følger reglene — nøyaktige enhetsrammer, ingen plattformovergripende referanser, plausible eksempeldata, ingen udokumenterte påstander. Generer varianter fra den malen, og avslagsraten faller mot null.