Guideline 4.0 Design: appen avvisad för sitt gränssnitt

"Guideline 4.0 - Design" är inte en numrerad regel som de andra. Det är inledningen till Design-avsnittet i Apples regler, och den citeras när ditt gränssnitt verkar ligga under förväntad nivå. De publicerade avvisningarna liknar varandra: trånga skärmar på iPad, svårläst text, inloggning som skickas till Safari, Sign in with Apple som är felintegrerat. Rättningen börjar nästan alltid på enheten som nämns i meddelandet, skärm för skärm.

Jag publicerar mina egna iOS-appar med Expo. Solys, TradaZen och Nolera är inställda för enbart iPhone, och ändå testade granskaren Solys och Nolera på iPad. Den här guiden bygger på Apples text, på 4.0-avvisningar som andra utvecklare har publicerat och på den visuella checklista jag går igenom före varje inskickning. För en översikt över skälen, läs varför Apple avvisar en app.

Vad täcker guideline 4.0 Design?

Avsnitt 4 i App Review Guidelines inleds med ett onumrerat stycke: "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." Där står också att designen är din, men att det som följer fastställer "minimum standards for approval". Stycket varnar dessutom för att en app som försämras efter godkännandet kan tas bort.

Kort sagt: Apple förväntar sig en app som är enkel, genomarbetad och lätt att använda, och 4.0 används när problemet inte faller under någon specifik underregel. Texten anger inga mätbara kriterier. Den praktiska referensen är Human Interface Guidelines, Apples designregler.

De vanligaste 4.0-avvisningarna

Här är de fyra fall jag har hittat i meddelanden publicerade på Apples forum, med formuleringen som citerades.

Fall	Apples formulering	Åtgärd
Trånga skärmar på iPad	"crowded"	Flexibel layout
Oläslig text	"hard to read type"	Storlekar enligt HIG
Inloggning i Safari	"taken to Safari"	Inloggning i appen
Sign in with Apple	Namnet efterfrågas igen	Namnet finns redan

Trånga eller avklippta skärmar på iPad

Typmeddelandet, publicerat 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." Därefter preciserades att appen bara använde en del av skärmen (forumtråd).

Orsaken är regel 2.4.1: "iPhone apps should run on iPad whenever possible." I Expo är ios.supportsTablet som standard false, enligt Expos appkonfiguration. Din iPhone-app körs då på iPad i kompatibilitetsläge, i ett fönster i iPhone-format. Att ställa in appen för enbart iPhone skyddar den inte från att testas på iPad. Det var på en iPad Air som Solys-demon blev omöjlig att vinna, ett fall jag beskriver i detalj i guiden om guideline 2.1.

Två vägar ut. Antingen stöder du iPad på riktigt, med en layout som anpassar sig efter tillgängligt utrymme. Apples designregler säger att layouten ska bestämmas utifrån storleksklasser, inte enhetsmodell. Eller så stannar du på iPhone, och då måste varje skärm rymmas i kompatibilitetsfönstret.

Svårläst text

Meddelandet, publicerat i januari 2025: "Your app included hard to read type or typography." Apple påminner där om att användare förväntar sig appar som är "simple, refined, and easy to use" (forumtråd).

Apples typografiregler ger riktmärken för iOS: 17 punkter som standard, minst 11 punkter. Tillgänglighetsreglerna kräver en kontrast på minst 4,5 till 1 för text upp till 17 punkter, och tryckytor på 44 gånger 44 punkter som standard.

En fälla om du krymper typsnitten på små skärmar, som jag gör för att behålla samma radbrytningar överallt: kontrollera att din minsta text, nedskalad på iPhone SE, fortfarande är minst 11 punkter.

Inloggning som skickas till Safari

Meddelandet, publicerat på Apples forum: "We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience." Apple kräver att registrering och inloggning går att göra i appen, och rekommenderar en inbäddad Safari-vy.

Med Expo täcker expo-web-browser båda behoven utan att lämna appen: openAuthSessionAsync öppnar en autentiseringssession i ett modalt fönster, och openBrowserAsync visar en sida i en inbäddad Safari-vy. Att öppna inloggningen med Linking.openURL skickar däremot användaren till Safari-appen. Vilka inloggningsmetoder du ska erbjuda styrs av en annan regel, 4.8.

Felintegrerat Sign in with Apple

Meddelandet, publicerat i maj 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).

Dokumentationen för expo-apple-authentication förklarar fällan: namn och e-post skickas bara vid första inloggningen. Spara dem direkt, annars frestas du att fråga efter dem igen. Använd också knappen som biblioteket tillhandahåller: färgen väljs med buttonStyle och hörnen med cornerRadius, aldrig via style.

4.0, 4.2, 4.3: tre designavvisningar som inte ska blandas ihop

Regel	Vad som bedöms	Åtgärd
4.0	Gränssnittet	Rätta skärmarna
4.2	Appens nytta	Lägg till nativt innehåll
4.3	Likheten	Byt koncept

4.2, Minimum Functionality, kräver funktioner, innehåll och ett gränssnitt som lyfter appen "beyond a repackaged website". Gränsen mot 4.0 är hårfin: en webbplats inpackad i en app kan få båda. Om din app saknar substans räcker det inte att putsa på skärmarna.

4.3 riktar sig mot kopior och mättade kategorier. Jag har gått igenom dess två stycken i guiden om guideline 4.3 Design Spam. Ett snyggt gränssnitt räddar inte en app som liknar tusen andra.

Den visuella checklistan före inskickning

Det här är steget jag lägger till vid varje inskickning. I mina appar ritas varje skärm för den största iPhonen och skalas sedan ned med en enda faktor på de mindre: samma proportioner, samma radbrytningar. Sedan jämför jag resultaten sida vid sida: iPhone SE, en vanlig iPhone, den största iPhonen och en iPad för kompatibilitetsläget.

Kontroll	Enhet	Vad som ska hålla
Första start	iPhone SE	Inget avklippt
Hela onboardingen	iPad	Varje knapp nåbar
Tangentbord öppet	iPhone SE	Fält och knapp synliga
Förstorad text	Vanlig iPhone	Ingen text avkortad
Mörkt läge	Alla	Läsbar text överallt
Säkra zoner	Största	Inget under Dynamic Island
Paywall	iPhone SE	Priser och länkar synliga
Inloggning	iPad	Den stannar i appen

Tre förtydliganden:

• Förstorad text. Apples typografiregler föreslår ett enkelt test: aktivera de största textstorlekarna under Settings, Accessibility, Display & Text Size och kontrollera att allt förblir läsbart.
• Mörkt läge. Apples regler för mörkt läge kräver att appen förblir läsbar i båda utseendena. Expo använder light som standard om du inte ställer in userInterfaceStyle. Solys följer telefonens inställning, TradaZen är alltid mörk och Nolera ljus: i alla tre fallen testar jag det utseende som visas.
• Säkra zoner. Innehållet får varken hamna under Dynamic Island eller under hemindikatorn. Expo beskriver metoden i sin guide om säkra zoner.

På Mac styrs simulatorn från kommandoraden, så checklistan går snabbt att köra igen:

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 riktig telefon gör jag samma runda med ett TestFlight-build. Metod: den här checklistan är min egen, byggd på avvisningar mina appar har fått, inte en lista från Apple. Den minskar överraskningarna men garanterar inget godkännande.

Hur svarar man på en 4.0-avvisning?

1. Notera enheten och versionen som nämns i meddelandet och öppna sedan samma modell i simulatorn.
2. Rätta alla förekomster. Typmeddelandet ber dig "address all instances" av problemet, inte bara skärmen på skärmdumpen.
3. Skicka ett nytt build: granskaren testar den inbyggda koden.
4. Svara med skärmdumpar tagna på samma enhet, genom att svara på meddelandet från App Review.
5. Överklaga bara om du är säker: Apple låter dig vända dig till App Review Board, med en enda överklagan per avvisad inskickning.

Mallen jag skulle använda, att anpassa:

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,

Förbered din inskickning utan designavvisning

Review Kit samlar min checklista inför inskickning, som bland annat täcker regel 2.4.1 om iPad, och Claude Code-skills som går igenom ditt projekt. Vill du ha ett mänskligt öga, boka en timme med mig: vi öppnar dina skärmar i flera storlekar, via videosamtal. Hela tillvägagångssättet efter en avvisning finns på sidan app avvisad av Apple.

Förbereder du din första lansering? Gör din gratis diagnostik: den sätter stegen i rätt ordning och skickar dig min checklista mot avvisningar från Apple.

Vanliga frågor

Vad betyder "Guideline 4.0 - Design" i ett avvisningsmeddelande?

Apple bedömer att ditt gränssnitt ligger under förväntad nivå, utan att peka på en specifik underregel: trånga skärmar, svårläst text, ett inloggningsflöde som anses dåligt. Meddelandet nämner oftast vilken enhet som användes och bifogar ofta en skärmdump.

Min app är inställd för enbart iPhone: varför testar Apple den på iPad?

För att regel 2.4.1 säger att iPhone-appar ska köras på iPad när det är möjligt. Din app öppnas där i kompatibilitetsläge, i ett fönster i iPhone-format, och varje skärm måste förbli användbar där.

Behövs ett nytt build efter en 4.0-avvisning?

Ja, i de flesta fall. Granskaren testar koden som är inbyggd vid första start, och en rättning som levereras på distans kan missas. Det förklarar jag i guiden om guideline 2.1.

Är mörkt läge obligatoriskt för att bli godkänd?

Granskningsreglerna kräver det inte. Designreglerna påminner om att användare förväntar sig att appar följer deras inställning. Om du tvingar fram ljust eller mörkt, vilket Expo tillåter, testa det utseendet. Om du följer telefonens inställning, testa båda.

Kan man överklaga en 4.0-avvisning?

Ja, hos App Review Board, om du anser att din app följer reglerna. Apple kräver konkreta skäl, en enda överklagan per avvisad inskickning, och att du först svarar på eventuella förfrågningar om information.