Guideline 4.2 Minimum Functionality: App abgelehnt

Die Guideline 4.2, „Minimum Functionality“, lehnt eine App ab, die nicht mehr bietet als eine Website oder zu wenig, um sie zu behalten. Die Lösung ist nicht, native Funktionen zu stapeln: Setz eine davon ins Zentrum der Nutzung und sag dem Reviewer, wo er sie findet. Die Korrektur braucht fast immer einen neuen Build.

Ich veröffentliche meine eigenen iOS-Apps: Solys, TradaZen und Nolera sind im App Store. Dieser Guide stützt sich auf den offiziellen Text von Apple, gelesen am 15. Oktober 2026, und auf 4.2-Ablehnungen, die Entwickler in den Apple-Foren veröffentlicht haben. Die abgelehnten Apps weiter unten sind Beispiele. Für den Überblick über alle Ablehnungsgründe lies lieber warum Apple eine App ablehnt.

Was sagt die Guideline 4.2?

Die 4.2 steht in Abschnitt 4, „Design“, der App Review Guidelines. Ihr erster Satz legt das Kriterium fest: „Your app should include features, content, and UI that elevate it beyond a repackaged website.“ Anders gesagt: Deine App muss Funktionen, Inhalte und eine Oberfläche bieten, die sie über eine neu verpackte Website hinausheben.

Der Text ergänzt zwei Gedanken. Eine App, die nicht wirklich nützlich, einzigartig oder „app-like“ ist, gehört nicht in den App Store. Und eine App, die weder dauerhafte Unterhaltung noch ausreichenden Nutzen bietet, kann abgelehnt werden. Die 4.2 bewertet also zwei Dinge: den Unterschied zum Web und die Menge an Wert.

Die Unterregeln, die die Nachricht nennen kann

Unterregel	Was Apple verlangt	Die typische Ablehnung
4.2	Über eine Website hinausgehen	Website in einer WebView angezeigt
4.2.1	Ein echtes Augmented-Reality-Erlebnis	Ein 3D-Modell in die AR-Ansicht gestellt
4.2.2	Nicht nur Marketing oder Links	Schaufenster-App, Aggregator, Links
4.2.3	Eine eigenständige App, klare Downloads	App, die eine andere App voraussetzt
4.2.6	Keine App aus einer kommerziellen Vorlage	Template, eingereicht von einem Dienstleister

Drei Hinweise. Die 4.2.2 macht eine Ausnahme für Kataloge: „Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.“ Ein Produktkatalog kann also durchgehen. Ein Werbeprospekt nicht.

Die 4.2.3 hat zwei Absätze. Absatz (i) verlangt, dass die App allein funktioniert, ohne dass eine andere App installiert werden muss. Absatz (ii) verlangt: Wenn die App beim ersten Start Ressourcen herunterladen muss, gibst du die Downloadgröße an und holst vorher die Zustimmung ein.

Die 4.2.6 zu kommerziellen Vorlagen und App-Generatoren erkläre ich ausführlich im Guide zur Guideline 4.3, weil sie mit der Anti-Spam-Regel zusammenhängt.

Die zwei häufigsten 4.2-Nachrichten

Apples Nachricht beginnt mit dem Titel „Guideline 4.2 - Design - Minimum Functionality“. Der Rest sagt, welches der beiden Probleme der Reviewer gesehen hat. Hier zwei Formulierungen, die Entwickler in den Apple-Foren veröffentlicht haben. Sie sind ein paar Jahre alt: Der genaue Text kann sich geändert haben, die zwei Familien nicht.

Die App sieht aus wie eine Website. „Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.“ Diese Nachricht, in den Apple-Foren veröffentlicht, enthält einen entscheidenden Satz: „Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store.“

Die App ist zu dünn. „We found that the usefulness of your app is limited by the minimal amount of content or features it includes.“ Diese zweite Nachricht fordert, das Konzept zu überarbeiten, und räumt ein, dass keine bezifferte Regel festlegt, was nützlich oder unterhaltsam ist.

Einer verpackten Website Benachrichtigungen, Standort und einen Teilen-Button hinzuzufügen, reicht nicht: Apple hat das in seinen eigenen Ablehnungen geschrieben.

Vier typische 4.2-Ablehnungen

Die vier Fälle unten sind konstruierte Beispiele zur Veranschaulichung der Regel, keine echten Apps.

Die verpackte Website

Beispiel: Ein Sportverein zeigt seine mobile Website in einer WebView an, mit einer nativen Tab-Leiste darüber. Kursplan, Buchung und Konto sind Webseiten. Der Reviewer sieht dort, was Safari ihm auch zeigen würde. Apple sagt es auf seiner App-Review-Seite: Eine Website in einer iOS-App, nicht an iOS angepasste Webinhalte oder eingeschränkte Web-Interaktionen machen keine hochwertige App.

Was ich tun würde: die Screens der Hauptaktion nativ neu bauen, hier Kursplan und Buchung. Dann hinzufügen, was die Website nicht kann: eine Erinnerung vor dem Training, den Kursplan offline abrufbar, das nächste Training in einem Widget.

Die zu einfache App

Beispiel: eine App, die ein Zitat pro Tag anzeigt, sonst nichts. In zehn Sekunden hast du alles gesehen. Die 4.2 spricht von „lasting entertainment value or adequate utility“: einem Wert, der bleibt, oder ausreichendem Nutzen. Zum Korrigieren gib der Hauptaktion mehr Tiefe, statt Screens drumherum zu bauen. Hier: ein Verlauf, Favoriten, eine Erinnerung zur gewählten Uhrzeit, ein Widget auf dem Home-Bildschirm.

Die KI-generierte App ohne native Elemente

Beispiel: ein Textfeld, ein Button, eine KI-Antwort als reiner Text. Apple bewertet nicht das Tool, sondern das, was auf dem Bildschirm des Reviewers ankommt. Wenn das Erlebnis in eine Webseite passt, stehen die Chancen gut, dass die 4.2 greift.

Was KI gut macht und was sie verfehlt, erkläre ich in eine App mit KI erstellen. Welches Format jeder Generator liefert, Web-App oder Mobile-Projekt, vergleiche ich in Lovable, Rork oder FlutterFlow.

Die Hülle, die auf Inhalte wartet

Beispiel: ein Marktplatz ohne Anzeigen, ein leeres Verzeichnis, ein Feed mit „Demnächst verfügbar“. Der Reviewer öffnet eine App, die nichts zu zeigen hat. Dieser Fall betrifft auch die 2.1, die Platzhalterinhalte ablehnt: siehe den Guide zur Guideline 2.1. Reich die App ein, wenn sie echte Inhalte hat, oder stell einen bereits gefüllten Demo-Account bereit.

Mein Test: „Und in Safari?“

Vor dem Einreichen frage ich mich, ob eine Website dieselbe Hauptfunktion bieten könnte. Wenn ja, ist die App der 4.2 ausgesetzt. Hier mein Raster, um eine native Funktion zu bewerten. Eine Funktion zählt, wenn sie der Hauptaktion dient, nicht wenn sie nur dekoriert.

Funktion	Sie zählt, wenn...	Sie reicht nicht, wenn...
Benachrichtigungen	Sie eine erwartete Information liefern	Sie deine Artikel weiterleiten
Offline	Der Hauptinhalt nutzbar bleibt	Nur ein Fehlerscreen erscheint
Widget	Es Daten der jeweiligen Person zeigt	Es dein Logo anzeigt
Teilen	Man Inhalte an deine App sendet	Es nur einen Link teilt
Kamera, Sensoren	Sie Teil der Hauptaktion sind	Sie deine Website öffnen
Lokale Daten	Die App rechnet, ordnet und sich erinnert	Alles auf einer Webseite lebt

Apples Empfehlungen gehen in dieselbe Richtung. Ein Widget zeigt aktuelle Inhalte, auf einen Blick lesbar. Eine Benachrichtigung liefert eine nützliche Information in wenigen Worten und dient nicht dazu, zu einer Aufgabe in der App zu drängen.

Was meine Apps können, was eine Website nicht kann

Ich baue jede App um eine Hauptfunktion herum, die es im Browser nicht gibt, oder um einen Wert, der die Leute zurückkommen lässt.

• Solys ist ein Wecker. Der Alarm läuft über AlarmKit, den Alarmdienst von iOS 26: Er geht durch den Stummmodus, wie Apples Wecker. Um ihn auszuschalten, musst du ein Minispiel gewinnen, und die gewählten Apps bleiben nach dem Aufwachen pausiert. Keine Webseite lässt ein stummgeschaltetes iPhone klingeln.
• TradaZen ist ein Trading-Simulator: ein echter Chart an einem echten Datum, eine Entscheidung, Kerzen, die sich aufdecken, gerankte Duelle und ein Rang, der steigt. Hier trägt keine native Funktion die App. Es ist der dauerhafte Unterhaltungswert, von dem die 4.2 spricht.
• Nolera ist ein Kleiderschrank: Du fotografierst deine Kleidung, die App stellt sie frei und sortiert sie und schlägt dir jeden Morgen ein Outfit vor. Die Kamera ist Teil der Hauptaktion. Sie ist kein Bonus.

Die 4.2 verlangt keine Liste nativer Funktionen: Sie verlangt einen Grund, die App zu installieren, statt eine Website zu öffnen.

Eine 4.2-Ablehnung beheben, Schritt für Schritt

1. Bestimme die Familie. Web-Browsing: Es ist die verpackte Website. Minimale Inhalte oder Funktionen: Es ist die zu dünne App. Die 4.2.3: eine Abhängigkeit von einer anderen App oder ein nicht angekündigter Download.
2. Ändere das Produkt, nicht die Formulierung. Eine Antwort, die argumentiert, ohne etwas zu ändern, hat keinen Grund zu überzeugen. Bau die Screens der Hauptaktion nativ neu oder füg die fehlende Tiefe hinzu.
3. Plan einen neuen Build ein. Die Ursache liegt in der App: Ein Remote-Update reicht nicht. Jede Einreichung geht wieder durch die Warteschlange, siehe die Prüfdauer im App Store.
4. Schreib Review-Notizen, die führen. Apple verlangt auf seiner Seite zu den Informationen für ein vollständiges Review, Konzept, Funktionen und Zielgruppe zu beschreiben. Bei einem Update: was sich geändert hat und wo man es findet.
5. Leg nur Einspruch ein, wenn der Reviewer etwas übersehen hat. Wenn deine native Funktion schon existierte, aber nicht gesehen wurde, antworte in App Store Connect mit einem kurzen Video. Ein Einspruch beim App Review Board ist gerechtfertigt, wenn deine App missverstanden wurde, nicht wenn sie zu dünn ist.

Die Vorlage für Notizen, die ich verwenden würde, auf Englisch, zum Anpassen:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Schreib nur, was im eingereichten Build existiert. Eine angekündigte, aber nicht auffindbare Funktion bringt dir eine neue Ablehnung, diesmal nach 2.1.

Die 4.2-Checkliste vor dem Einreichen

• Du kannst in einem Satz sagen, was deine App kann, was eine Website nicht kann.
• Die Screens der Hauptaktion sind nativ, keine Webseiten.
• Jede native Funktion dient der Hauptaktion, und der Reviewer stößt in weniger als zwei Minuten darauf.
• Die App hat ab dem ersten Start echte Inhalte oder einen gefüllten Demo-Account.
• Die App funktioniert allein, ohne eine andere App installieren zu müssen.
• Ein großer Download beim ersten Start nennt seine Größe und fragt nach Zustimmung.
• Die Review-Notizen beschreiben Konzept, Zielgruppe und den Ort jeder Funktion.
• Wenn deine Idee an der Grenze kratzt, hast du sie vor dem Coden getestet, mit einem sauber abgegrenzten MVP einer iOS-App.

Die 4.2 bei deiner nächsten Einreichung bestehen

Wenn deine App gerade nach 4.2 abgelehnt wurde, hilft dir das Apple Review Kit, die genannte Regel und ihre Anforderungen zu finden, mit Notizvorlagen für den Tester. Wenn du noch baust, startet der Weg im iOS Kit bei der Hauptfunktion, noch vor der ersten Codezeile. Für einen menschlichen Blick buch eine Stunde mit mir. Das komplette Vorgehen steht auf der Seite App von Apple abgelehnt.

Wenn du deinen ersten Release vorbereitest, mach deine kostenlose Diagnose: Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Anti-Ablehnungs-Checkliste für Apple. Die Startseite zeigt, wie du eine mobile App erstellst, die von Anfang an für das Review gedacht ist.

Niemand kann garantieren, dass Apple deine App akzeptiert. Ich kann dir helfen, ihr einen Grund zu geben, im App Store zu existieren.

Häufige Fragen

Was bedeutet „Guideline 4.2 - Design - Minimum Functionality“?

Das ist der Titel der Ablehnung wegen minimaler Funktionalität. Apple findet, dass deine App zu sehr einer Website ähnelt oder zu wenig Inhalte oder Funktionen bietet. Derselbe Titel kann eine Unterregel betreffen: „Guideline 4.2.2“ für eine Schaufenster-App oder eine Linkliste, 4.2.3 für eine App, die von einer anderen App abhängt.

Wird eine WebView-App immer abgelehnt?

Nein. Die Regel zielt auf die in eine App verpackte Website, nicht auf die Technologie. Der Reviewer bewertet das Haupterlebnis: Wenn dessen Screens Webseiten sind, die dasselbe tun wie Safari, ist das Risiko hoch. Eine Hilfeseite, die im Browser geöffnet wird, ist nicht das Thema.

Reichen Push-Benachrichtigungen, um die 4.2 zu bestehen?

Nein. In einer in seinen Foren veröffentlichten Ablehnung schreibt Apple, dass Benachrichtigungen, Standort und Teilen nicht reichen, um das Erlebnis reichhaltig genug zu machen. Eine Benachrichtigung zählt, wenn sie der Hauptfunktion dient, etwa ein Alarm oder eine von der Person gewählte Erinnerung.

Was ist der Unterschied zwischen Guideline 4.2 und 4.3?

Die 4.2 bewertet deine App für sich: Bringt sie genug im Vergleich zu einer Website? Die 4.3 vergleicht sie mit anderen: Ist sie eine Kopie, eine Variante oder noch eine App in einer übersättigten Kategorie? Eine App kann beide abbekommen, aber sie werden nicht auf dieselbe Weise behoben.

Brauche ich nach einer 4.2-Ablehnung einen neuen Build?

Fast immer, denn die Ursache liegt in der App selbst. Einzige Ausnahme: Der Reviewer hat eine Funktion nicht gefunden, die schon existierte. Dann antworte in App Store Connect mit präzisen Notizen und einem kurzen Video, ohne den Build zu ändern.