# Guideline 4.0 Design: app avvist på grunn av grensesnittet

> Guideline 4.0 Design: Apple avviser grensesnitt som er vanskelige å bruke, ofte på iPad. Test hver skjerm på iPhone SE og iPad, rett feilene og svar.

Opprinnelig side: [Guideline 4.0 Design: app avvist på grunn av grensesnittet](https://devoria.fr/no/blog/guideline-4-0-design-app-avvist-grensesnitt)
Forfatter: [Mehdi Azizi](https://devoria.fr/no/mehdi-azizi)
Publisert: 2026-11-04
Innhold sist revidert: 2026-11-04


«Guideline 4.0 - Design» er ikke en nummerert regel som de andre: det er innledningen til Design-delen av Apples regler, og den siteres når grensesnittet ditt virker under forventet nivå. De publiserte avvisningene ligner på hverandre: trange skjermer på iPad, tekst som er vanskelig å lese, innlogging sendt til Safari, Sign in with Apple som er dårlig integrert. **Rettingen starter nesten alltid på enheten som nevnes i meldingen, skjerm for skjerm.**

Jeg publiserer mine egne iOS-apper med Expo: Solys, TradaZen og Nolera er satt opp kun for iPhone, og likevel testet revieweren Solys og Nolera på iPad. Denne guiden bygger på Apples tekst, på 4.0-avvisninger publisert av andre utviklere og på den visuelle sjekklisten jeg bruker før hver innsending. For en oversikt over avvisningsgrunnene, les [hvorfor Apple avviser en app](https://devoria.fr/no/blog/avvist-av-apple-hvorfor-appen-blir-avvist).

## Hva dekker guideline 4.0 Design?

Del 4 av [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#design) åpner med et avsnitt uten nummer: «Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store.» Det legger til at designet er ditt, men at resten fastsetter «minimum standards for approval». Det advarer også om at en app som blir dårligere etter godkjenning, kan bli fjernet.

Kort sagt: **Apple forventer en enkel, gjennomarbeidet og brukervennlig app, og 4.0 brukes når problemet ikke hører inn under noen mer presis underregel.** Teksten gir ingen tallfestede kriterier. Den praktiske referansen er [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/layout), Apples designregler.

## De vanligste 4.0-avvisningene

Her er de fire tilfellene jeg har funnet i meldinger publisert på Apples forum, med formuleringen som ble sitert.

| Tilfelle                | Apples formulering  | Løsning              |
| ----------------------- | ------------------- | -------------------- |
| Trange skjermer på iPad | «crowded»           | Fleksibel layout     |
| Uleselig tekst          | «hard to read type» | HIG-størrelser       |
| Innlogging i Safari     | «taken to Safari»   | Innlogging i appen   |
| Sign in with Apple      | Navn spurt om igjen | Navn allerede levert |

### Trange eller avkuttede skjermer på iPad

Typisk melding, publisert i september 2025: «Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0.» Resten presiserte at appen bare brukte en del av skjermen ([forumtråd](https://developer.apple.com/forums/thread/800657)).

Årsaken ligger i regel 2.4.1: «iPhone apps should run on iPad whenever possible.» Med Expo er `ios.supportsTablet` satt til `false` som standard, ifølge [Expos app-konfigurasjon](https://docs.expo.dev/versions/latest/config/app/). iPhone-appen din kjører da på iPad i kompatibilitetsmodus, i et vindu i iPhone-format. **Å sette appen til kun iPhone beskytter den ikke mot en test på iPad.** Det var på en iPad Air at demoen av Solys ble umulig å vinne, et tilfelle jeg går gjennom i guiden om [guideline 2.1](https://devoria.fr/no/blog/guideline-2-1-app-store-avvisning).

To utveier. Enten støtter du iPad på ordentlig, med en layout som tilpasser seg tilgjengelig plass. Apples designregler sier at layouten skal bestemmes ut fra størrelsesklasser, ikke enhetsmodell. Eller så holder du deg til iPhone, og da må hver skjerm passe i kompatibilitetsvinduet.

### Tekst som er vanskelig å lese

Meldingen, publisert i januar 2025: «Your app included hard to read type or typography.» Apple minner der om at brukerne forventer apper som er «simple, refined, and easy to use» ([forumtråd](https://developer.apple.com/forums/thread/772671)).

[Apples typografiregler](https://developer.apple.com/design/human-interface-guidelines/typography) gir holdepunkter for iOS: 17 punkter som standard, 11 punkter som minimum. [Tilgjengelighetsreglene](https://developer.apple.com/design/human-interface-guidelines/accessibility) krever en kontrast på minst 4,5 til 1 for tekst opptil 17 punkter, og trykkflater på 44 x 44 punkter som standard.

En felle hvis du skalerer ned skrifttypene på små skjermer, slik jeg gjør for å beholde de samme linjeskiftene overalt: **sjekk at den minste teksten din, nedskalert på iPhone SE, fortsatt er minst 11 punkter.**

### Innlogging sendt til Safari

Meldingen, publisert på [Apples forum](https://developer.apple.com/forums/thread/126333): «We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience.» Apple ber om at registrering og innlogging skjer i appen, og anbefaler en innebygd Safari-visning.

Med Expo dekker [expo-web-browser](https://docs.expo.dev/versions/latest/sdk/webbrowser/) begge behovene uten å forlate appen: `openAuthSessionAsync` åpner en autentiseringsøkt i et modalt vindu, og `openBrowserAsync` viser en side i en innebygd Safari-visning. Å åpne innloggingen med `Linking.openURL` sender derimot brukeren til Safari-appen. Hvilke innloggingsmetoder du skal tilby, hører under en annen regel, 4.8.

### Sign in with Apple dårlig integrert

Meldingen, publisert i mai 2024: «Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework.» ([forumtråd](https://developer.apple.com/forums/thread/751115)).

Dokumentasjonen til [expo-apple-authentication](https://docs.expo.dev/versions/latest/sdk/apple-authentication/) forklarer fellen: navn og e-post leveres bare ved første innlogging. **Lagre dem med en gang**, ellers blir du fristet til å spørre om dem igjen. Bruk også knappen som biblioteket tilbyr: fargen velges med `buttonStyle` og hjørnene med `cornerRadius`, aldri via `style`.

## 4.0, 4.2, 4.3: tre designavvisninger du ikke må blande sammen

| Regel | Hva som vurderes  | Løsning                  |
| ----- | ----------------- | ------------------------ |
| 4.0   | Grensesnittet     | Rette skjermene          |
| 4.2   | Appens nytteverdi | Legge til native innhold |
| 4.3   | Likheten          | Bytte konsept            |

[4.2, Minimum Functionality](https://devoria.fr/no/blog/guideline-4-2-minimum-functionality-app-avvist), krever funksjoner, innhold og et grensesnitt som løfter appen «beyond a repackaged website». Grensen mot 4.0 er hårfin: en nettside pakket inn i en app kan få begge. **Hvis appen din mangler innhold, holder det ikke å pusse på skjermene.**

4.3 retter seg mot kopier og mettede kategorier: jeg har gått gjennom de to leddene i guiden om [guideline 4.3 Design Spam](https://devoria.fr/no/blog/guideline-4-3-design-spam-app-avvist). Et gjennomarbeidet grensesnitt redder ikke en app som ligner tusen andre.

## Den visuelle sjekklisten før innsending

Dette er det jeg legger til ved hver innsending. I appene mine tegnes hver skjerm for den største iPhonen, og skaleres så ned med én enkelt faktor på de mindre: samme proporsjoner, samme linjeskift. Deretter sammenligner jeg resultatene side om side: iPhone SE, standard iPhone, største iPhone og en iPad for kompatibilitetsmodus.

| Kontroll          | Enhet           | Hva som må holde               |
| ----------------- | --------------- | ------------------------------ |
| Første oppstart   | iPhone SE       | Ingenting avkuttet             |
| Hele onboardingen | iPad            | Hver knapp tilgjengelig        |
| Tastatur åpent    | iPhone SE       | Felt og knapp synlige          |
| Forstørret tekst  | Standard iPhone | Ingen avkortet tekst           |
| Mørk modus        | Alle            | Lesbar tekst overalt           |
| Trygge soner      | Største         | Ingenting under Dynamic Island |
| Paywall           | iPhone SE       | Priser og lenker synlige       |
| Innlogging        | iPad            | Den blir værende i appen       |

Tre presiseringer:

- **Forstørret tekst.** Apples typografiregler foreslår en enkel test: slå på de største tekststørrelsene under Settings, Accessibility, Display & Text Size, og sjekk at alt fortsatt er lesbart.
- **Mørk modus.** [Apples regler for mørk modus](https://developer.apple.com/design/human-interface-guidelines/dark-mode) krever at appen er lesbar i begge utseender. Expo bruker `light` som standard hvis du ikke setter `userInterfaceStyle`. Solys følger telefonens innstilling, TradaZen er alltid mørk, Nolera lys: i alle tre tilfellene tester jeg utseendet som vises.
- **Trygge soner.** Innholdet skal verken gå under Dynamic Island eller under hjem-indikatoren. Expo forklarer metoden i sin guide om [trygge soner](https://docs.expo.dev/develop/user-interface/safe-areas/).

På Mac kan simulatoren styres fra kommandolinjen, så sjekklisten er rask å kjøre på nytt:

```bash
xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png
```

På en ekte telefon tar jeg samme runde med en [TestFlight](https://devoria.fr/no/blog/testflight-teste-iphone-app-for-innsending)-build. Metodikk: denne sjekklisten er min egen, bygget på avvisningene appene mine har fått, ikke en liste fra Apple. Den gir færre overraskelser, men garanterer ikke godkjenning.

## Hvordan svarer du på en 4.0-avvisning?

1. **Finn enheten og versjonen** som nevnes i meldingen, og åpne samme modell i simulatoren.
2. **Rett alle forekomstene.** Den typiske meldingen ber deg «address all instances» av problemet, ikke bare skjermen på skjermbildet.
3. **Send en ny build**: revieweren tester koden som ligger i appen.
4. **Svar med skjermbilder** tatt på samme enhet, ved å [svare på meldingen fra App Review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/).
5. **Anke bare hvis du er sikker**: Apple lar deg [klage til App Review Board](https://developer.apple.com/distribute/app-review/), med én anke per avvist innsending.

Malen jeg ville brukt, tilpass den:

```text
Hello,

Thank you for your feedback regarding Guideline 4.0.

We reproduced the issue on [device] running [OS version].

Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].

We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.

Attached: screenshots of the updated screens on [device].

Best regards,
```

## Forbered innsendingen uten designavvisning

[Review Kit](https://devoria.fr/no/kits/app-review) samler sjekklisten min før innsending, som blant annet dekker regel 2.4.1 om iPad, og Claude Code-skills som går gjennom prosjektet ditt. Vil du ha et menneskelig blikk, [bestill en time med meg](https://devoria.fr/no/coaching): vi åpner skjermene dine i flere størrelser, over video. Hele fremgangsmåten etter en avvisning finner du på siden [app avvist av Apple](https://devoria.fr/no/expertise/app-avvist-av-apple).

Forbereder du din første lansering? [Ta den gratis diagnosen](https://devoria.fr/no/diagnostic): den setter stegene i riktig rekkefølge og sender deg sjekklisten min mot Apple-avvisninger.

## Ofte stilte spørsmål

### Hva betyr «Guideline 4.0 - Design» i en avvisningsmelding?

Apple mener grensesnittet ditt er under forventet nivå, uten å peke på en bestemt underregel: trange skjermer, tekst som er vanskelig å lese, en innloggingsflyt som vurderes som dårlig. Meldingen nevner vanligvis enheten som ble brukt, og har ofte et skjermbilde vedlagt.

### Appen min er satt opp kun for iPhone: hvorfor tester Apple den på iPad?

Fordi regel 2.4.1 sier at iPhone-apper skal kjøre på iPad når det er mulig. Appen din åpnes der i kompatibilitetsmodus, i et vindu i iPhone-format, og hver skjerm må fortsatt være brukbar.

### Trenger jeg en ny build etter en 4.0-avvisning?

Ja, i de fleste tilfeller. Revieweren tester koden som ligger i appen ved første oppstart, og en rettelse levert eksternt kan gå under radaren. Det forklarer jeg i guiden om guideline 2.1.

### Er mørk modus påkrevd for å bli godkjent?

Teksten i review-reglene krever det ikke. Designreglene minner om at brukerne forventer at apper følger innstillingen deres. Hvis du tvinger lys eller mørk modus, slik Expo tillater, test det utseendet. Hvis du følger telefonens innstilling, test begge.

### Kan man anke en 4.0-avvisning?

Ja, til App Review Board, hvis du mener appen din følger reglene. Apple krever konkrete begrunnelser, én anke per avvist innsending, og at du først svarer på eventuelle forespørsler om informasjon.


## Prosjektet ditt

[Review Kit](https://devoria.fr/no/kits/app-review): Sjekklisten min for App Store-gjennomgang, Apples avslag på appene mine med rettelser, sjekklisten for Google Play og tre Claude Code-skills. 499 kr.

[iOS & Android Kit](https://devoria.fr/no/kits/ios): Lag din iPhone- og Android-app med Claude Code: startkoden fra appene mine, veien helt til butikkene og alle kitene. 999 kr.

[Diagnose: dette står mellom deg og iPhone-appen din](https://devoria.fr/no/diagnostic): 7 spørsmål, 60 sekunder: du får vite hva som egentlig hindrer deg i å publisere iPhone-appen din, veien din i 4 steg og kitet som passer deg.