Guideline 4.0 Design: App wegen Interface abgelehnt

„Guideline 4.0 - Design“ ist keine nummerierte Regel wie die anderen: Es ist die Einleitung zum Design-Abschnitt von Apples Regeln, und sie wird zitiert, wenn dein Interface unter dem erwarteten Niveau wirkt. Die veröffentlichten Ablehnungen ähneln sich: gequetschte Screens auf dem iPad, schwer lesbarer Text, Login, der nach Safari umleitet, schlecht eingebundenes Sign in with Apple. Die Korrektur beginnt fast immer auf dem Gerät, das in der Nachricht genannt wird, Screen für Screen.

Ich veröffentliche meine eigenen iOS-Apps mit Expo: Solys, TradaZen und Nolera sind nur fürs iPhone eingestellt, und trotzdem hat der Reviewer Solys und Nolera auf dem iPad getestet. Dieser Guide stützt sich auf Apples Text, auf veröffentlichte 4.0-Ablehnungen anderer Entwickler und auf das visuelle Raster, das ich vor jeder Einreichung durchgehe. Für den Überblick über die Ablehnungsgründe lies warum Apple eine App ablehnt.

Was deckt Guideline 4.0 Design ab?

Abschnitt 4 der App Review Guidelines beginnt mit einem Absatz ohne 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.“ Weiter heißt es, das Design liege bei dir, aber das Folgende lege „minimum standards for approval“ fest. Außerdem wird gewarnt, dass eine App, die nach der Freigabe nachlässt, entfernt werden kann.

Klartext: Apple erwartet eine einfache, sorgfältige und leicht bedienbare App, und 4.0 greift, wenn das Problem unter keine genauere Unterregel fällt. Der Text nennt keine konkreten Zahlen. Die praktische Referenz sind die Human Interface Guidelines, Apples Designregeln.

Die häufigsten 4.0-Ablehnungen

Hier die vier Fälle, die ich in veröffentlichten Nachrichten in Apples Foren gefunden habe, mit der zitierten Formulierung.

Fall	Apples Formulierung	Lösung
Gequetschte Screens auf iPad	„crowded“	Flexibles Layout
Unlesbarer Text	„hard to read type“	HIG-Größen
Login in Safari	„taken to Safari“	Login in der App
Sign in with Apple	Name erneut abgefragt	Name bereits geliefert

Gequetschte oder abgeschnittene Screens auf dem iPad

Die typische Nachricht, veröffentlicht im 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.“ Weiter hieß es, die App nutze nur einen Teil des Bildschirms (Forenthread).

Die Ursache liegt in Regel 2.4.1: „iPhone apps should run on iPad whenever possible.“ Bei Expo steht die Option ios.supportsTablet laut Expo-App-Konfiguration standardmäßig auf false. Deine iPhone-App läuft auf dem iPad dann im Kompatibilitätsmodus, in einem Fenster im iPhone-Format. Eine App nur fürs iPhone einzustellen, schützt sie nicht vor einem Test auf dem iPad. Auf einem iPad Air wurde die Demo von Solys unschaffbar, ein Fall, den ich im Guide zur Guideline 2.1 beschreibe.

Zwei Auswege. Entweder du unterstützt das iPad wirklich, mit einem Layout, das sich dem verfügbaren Platz anpasst. Apples Designregeln verlangen, das Layout nach Size Classes zu bestimmen, nicht nach Gerätemodell. Oder du bleibst beim iPhone, und jeder Screen muss in das Kompatibilitätsfenster passen.

Schwer lesbarer Text

Die Nachricht, veröffentlicht im Januar 2025: „Your app included hard to read type or typography.“ Apple erinnert darin, dass Nutzer Apps erwarten, die „simple, refined, and easy to use“ sind (Forenthread).

Apples Typografie-Regeln geben für iOS Richtwerte: standardmäßig 17 Punkt, mindestens 11 Punkt. Die Barrierefreiheitsregeln verlangen einen Kontrast von mindestens 4,5 zu 1 für Text bis 17 Punkt und standardmäßig Touch-Flächen von 44 mal 44 Punkt.

Eine Falle, wenn du Schriften auf kleinen Bildschirmen verkleinerst, wie ich es tue, um überall dieselben Zeilenumbrüche zu behalten: Prüfe, dass dein kleinster Text, verkleinert auf dem iPhone SE, mindestens 11 Punkt behält.

Login, der nach Safari umleitet

Die Nachricht, veröffentlicht im Apple-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 verlangt, Registrierung und Login in der App zu ermöglichen, und empfiehlt eine eingebettete Safari-Ansicht.

Mit Expo deckt expo-web-browser beide Fälle ab, ohne die App zu verlassen: openAuthSessionAsync öffnet eine Authentifizierungssitzung in einem modalen Fenster, und openBrowserAsync zeigt eine Seite in einer eingebetteten Safari-Ansicht. Den Login mit Linking.openURL zu öffnen, schickt dagegen in die Safari-App. Welche Login-Methoden du anbieten musst, regelt dagegen eine andere Regel, die 4.8.

Schlecht eingebundenes Sign in with Apple

Die Nachricht, veröffentlicht im 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.“ (Forenthread).

Die Dokumentation von expo-apple-authentication erklärt die Falle: Name und E-Mail werden nur beim ersten Login geliefert. Speichere sie sofort, sonst bist du versucht, sie erneut abzufragen. Nutze außerdem den Button der Bibliothek: Seine Farbe wählst du mit buttonStyle, seine Ecken mit cornerRadius, niemals über style.

4.0, 4.2, 4.3: drei Design-Ablehnungen, die du nicht verwechseln solltest

Regel	Was bewertet wird	Lösung
4.0	Das Interface	Screens korrigieren
4.2	Der Nutzen der App	Native Substanz hinzufügen
4.3	Die Ähnlichkeit	Konzept ändern

Die 4.2, Minimum Functionality, verlangt Funktionen, Inhalte und ein Interface, die die App „beyond a repackaged website“ heben. Die Grenze zu 4.0 ist schmal: Eine in eine App verpackte Website kann beides kassieren. Wenn deiner App die Substanz fehlt, reicht es nicht, die Screens nachzubessern.

Die 4.3 zielt auf Kopien und übersättigte Kategorien: Ihre zwei Absätze habe ich im Guide zur Guideline 4.3 Design Spam erklärt. Ein sorgfältiges Interface rettet keine App, die tausend anderen gleicht.

Das visuelle Raster vor der Einreichung

Das ist der Schritt, den ich bei jeder Einreichung ergänze. In meinen Apps wird jeder Screen für das größte iPhone gestaltet und dann auf den kleineren mit einem einzigen Faktor verkleinert: gleiche Proportionen, gleiche Zeilenumbrüche. Danach vergleiche ich die Darstellungen nebeneinander: iPhone SE, Standard-iPhone, größtes iPhone und ein iPad für den Kompatibilitätsmodus.

Prüfung	Gerät	Was passen muss
Erster Start	iPhone SE	Nichts abgeschnitten
Komplettes Onboarding	iPad	Jeder Button erreichbar
Tastatur offen	iPhone SE	Feld und Button sichtbar
Vergrößerter Text	Standard-iPhone	Kein Text abgeschnitten
Dark Mode	Alle	Text überall lesbar
Safe Areas	Größtes	Nichts unter der Dynamic Island
Paywall	iPhone SE	Preise und Links sichtbar
Login	iPad	Bleibt in der App

Drei Hinweise:

• Vergrößerter Text. Apples Typografie-Regeln schlagen einen einfachen Test vor: die größten Textgrößen unter Settings, Accessibility, Display & Text Size aktivieren und prüfen, ob alles lesbar bleibt.
• Dark Mode. Apples Regeln zum Dark Mode verlangen, dass die App in beiden Darstellungen lesbar bleibt. Expo nutzt standardmäßig light, wenn du userInterfaceStyle nicht setzt. Solys folgt der Einstellung des Telefons, TradaZen bleibt dunkel, Nolera hell: In allen drei Fällen teste ich die angezeigte Darstellung.
• Safe Areas. Inhalte liegen weder unter der Dynamic Island noch unter dem Home-Indikator. Expo erklärt die Methode in seinem Guide zu Safe Areas.

Auf dem Mac lässt sich der Simulator per Kommandozeile einstellen, so ist das Raster schnell wiederholt:

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

Auf einem echten Telefon mache ich dieselbe Runde mit einem TestFlight-Build. Methodik: Dieses Raster ist meins, entstanden aus den Ablehnungen meiner Apps, keine Liste von Apple. Es verringert Überraschungen, garantiert aber keine Freigabe.

Wie antwortest du auf eine 4.0-Ablehnung?

1. Finde Gerät und Version, die in der Nachricht genannt werden, und öffne dasselbe Modell im Simulator.
2. Korrigiere alle Vorkommen. Die typische Nachricht verlangt, „address all instances“ des Problems, nicht nur den Screen auf dem Screenshot.
3. Schick einen neuen Build: Der Reviewer testet den mitgelieferten Code.
4. Antworte mit Screenshots vom selben Gerät, indem du auf die Nachricht von App Review antwortest.
5. Leg nur Einspruch ein, wenn du sicher bist: Apple erlaubt, das App Review Board anzurufen, mit nur einem Einspruch pro abgelehnter Einreichung.

Die Vorlage, die ich verwenden würde, zum Anpassen:

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,

Deine Einreichung ohne Design-Ablehnung vorbereiten

Das Review Kit enthält meine Checkliste vor der Einreichung, die unter anderem Regel 2.4.1 zum iPad abdeckt, und Claude-Code-Skills, die dein Projekt prüfen. Für einen menschlichen Blick buch eine Stunde mit mir: Wir öffnen deine Screens in mehreren Größen, per Videocall. Das komplette Vorgehen nach einer Ablehnung findest du auf der Seite App von Apple abgelehnt.

Du bereitest deinen ersten Release vor? Mach deine kostenlose Diagnose: Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Checkliste gegen Apple-Ablehnungen.

Häufige Fragen

Was bedeutet „Guideline 4.0 - Design“ in einer Ablehnungsnachricht?

Apple findet dein Interface unter dem erwarteten Niveau, ohne eine genauere Unterregel zu nennen: gequetschte Screens, schwer lesbarer Text, ein als schlecht bewerteter Login-Ablauf. Die Nachricht nennt meist das verwendete Gerät und enthält oft einen Screenshot.

Meine App ist nur fürs iPhone eingestellt: Warum testet Apple sie auf dem iPad?

Weil Regel 2.4.1 vorsieht, dass iPhone-Apps wann immer möglich auf dem iPad laufen. Deine App öffnet sich dort im Kompatibilitätsmodus, in einem Fenster im iPhone-Format, und jeder Screen muss dort bedienbar bleiben.

Brauche ich nach einer 4.0-Ablehnung einen neuen Build?

Ja, in den meisten Fällen. Der Reviewer testet den beim ersten Start mitgelieferten Code, und eine aus der Ferne ausgelieferte Korrektur kann ihm entgehen. Das erkläre ich im Guide zur Guideline 2.1.

Ist der Dark Mode Pflicht für die Freigabe?

Der Text der Review-Regeln schreibt ihn nicht vor. Die Designregeln erinnern daran, dass Nutzer erwarten, dass Apps ihrer Einstellung folgen. Wenn du hell oder dunkel erzwingst, wie Expo es erlaubt, teste diese Darstellung. Wenn du der Einstellung des Telefons folgst, teste beide.

Kann man gegen eine 4.0-Ablehnung Einspruch einlegen?

Ja, beim App Review Board, wenn du glaubst, dass deine App die Regeln einhält. Apple verlangt konkrete Gründe, nur einen Einspruch pro abgelehnter Einreichung und dass du zuerst auf Informationsanfragen antwortest.