App von Apple abgelehnt (Guideline 4.2)? So behebst du es

Du hast deine Website in eine App verpackt, eingereicht und dann kam die Mail: Guideline 4.2 – Design – Minimum Functionality. Das ist die häufigste Ablehnung für webbasierte Apps – und die Nachricht sagt selten, was genau du ändern sollst.

Dieser Artikel erklärt, was die Richtlinie tatsächlich sagt, was Reviewer an einer verpackten Website bemerken, welche Änderungen wirklich etwas bewirken und wie du erneut einreichst. Außerdem geht es um zwei Regeln, die die meisten Artikel weglassen – 4.2.6 und 4.3(a) –, die aber wichtig werden, sobald du einen App-Builder nutzt.

Die Zitate stammen aus Apples App Review Guidelines mit Stand 8. Juni 2026, im englischen Original (Apple bietet auch eine deutsche Fassung an). Eine Freigabe kann niemand garantieren – App Review entscheidet im Einzelfall. Was du tun kannst: die Gründe für eine Ablehnung beseitigen.

Was Guideline 4.2 wirklich sagt

Der Kern der Regel ist ein Absatz:

„Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store."

Sinngemäß: Deine App soll Funktionen, Inhalte und eine Oberfläche bieten, die über eine umverpackte Website hinausgehen. Dazu kommt eine Unterregel, die die typischen Web-App-Probleme beim Namen nennt:

4.2.2 „Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Daraus folgen zwei Dinge:

1. Web-Technik ist nicht verboten. Viele freigegebene Apps zeigen Web-Inhalte. Die Frage ist, ob das Ergebnis sich wie eine App verhält oder wie ein Browser mit Icon.
2. Die Messlatte ist subjektiv. „App-like" beurteilt ein Mensch, der deine App ein paar Minuten benutzt. Deine Aufgabe: Diese Minuten sollen sich wie eine App anfühlen.

Was Reviewer an einer verpackten Website bemerken

Diese Signale führen typischerweise zu einer 4.2-Ablehnung:

• Browser-Verhalten. Pinch-Zoom auf einem Desktop-Layout, Links, die Safari öffnen, ein „Seite nicht gefunden" vom Webserver, sichtbare Scroll-Ruckler.
• Nur Web-Navigation. Ein Hamburger-Menü und ein Footer voller Links statt einer app-typischen Navigation, die immer erreichbar ist.
• Kein Offline-Zustand. Im Flugmodus erscheint ein leerer Bildschirm oder die System-Seite „Keine Verbindung".
• Login-Wand ohne Demo-Account. Kommt der Reviewer nicht am Login vorbei, wirkt die App wie eine leere Hülle. (Das ist zusätzlich ein eigener Ablehnungsgrund nach Richtlinie 2.1, die „demo account info" verlangt, wenn deine App einen Login hat.)
• Marketing-Seiten statt Funktion. Sind die ersten Screens eine Landingpage – Hero, Testimonials, „Lade unsere App"-Banner –, ist das der 4.2.2-Fall „marketing materials".
• Nichts, was eine App ausmacht. Kein Grund, sie auf dem Home-Screen statt als Lesezeichen zu haben.

Änderungen, die das Ergebnis wirklich verändern

1. Navigation wie in einer App

Gib der App eine untere Tab-Leiste mit deinen drei bis fünf wichtigsten Bereichen (für einen Shop: Start, Kategorien, Warenkorb, Konto). Sie sollte auf jedem Screen sichtbar und mit einem Daumen bedienbar sein. Diese eine Änderung wirkt gegen den Eindruck „Sammlung von Links" besser als alles andere.

2. Ein sauberer Offline-Zustand

Schalte den Flugmodus ein und öffne deine App. Siehst du eine Fehlerseite, sieht der Reviewer sie womöglich auch. Zeig eine gebrandete Offline-Seite mit „Erneut versuchen"-Button und lade automatisch neu, sobald die Verbindung zurück ist.

3. Alles ausblenden, was „Browser" sagt

• Nutze überall ein mobiles Layout; deaktiviere Pinch-Zoom dort, wo er nur eine Desktop-Seite zeigt.
• Interne Links bleiben in der App; nur echte externe Links öffnen den Browser.
• Entferne „Lade unsere App"-Banner, für den Desktop gebaute Cookie-Wände und Footer voller Links aus der App-Ansicht.

4. Dort starten, wo der Nutzen ist

Der erste Screen nach dem Start sollte der nützliche Teil deines Produkts sein – Katalog, Dashboard, Buchungsstrecke –, nicht deine Marketing-Startseite. Hast du eine eigene App-Startseite, nutz sie.

5. Gerätefunktionen mit echtem Zweck

Push-Benachrichtigungen für Dinge, die Nutzer wirklich wollen (Bestellung versendet, Termin morgen), das Teilen-Menü, Kamera-Upload, wo dein Produkt ihn braucht. Vermeide dekorative Berechtigungen: Standort oder Kamera ohne erkennbaren Grund abzufragen, ist ein eigenes Ablehnungsrisiko, und jede Berechtigung braucht einen klaren Begründungstext.

6. Konten richtig umsetzen

Können Nutzer in deiner App ein Konto anlegen, gilt Richtlinie 5.1.1(v): „If your app supports account creation, you must also offer account deletion within the app." Bei Web-Apps ist das Löschen oft auf einer Desktop-Einstellungsseite versteckt – mach es in der App erreichbar. Und gib App Review in App Store Connect einen funktionierenden Demo-Account.

Was nicht hilft

• Ein nativer Screen, den niemand nutzt, nur um „etwas Natives" zu haben.
• Nur Splash-Screen und Icon – nötig, aber nicht ausreichend.
• Das Aussehen einer anderen App kopieren. Reviewer bewerten den Nutzen deiner App, nicht ihr Styling.

Die Regeln, die kaum jemand erwähnt: 4.2.6 und 4.3(a)

Nutzt du einen App-Builder oder einen Template-Dienst, lies diese beiden Regeln vor dem Einreichen.

4.2.6 „Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients […]"

Im Klartext: Die App muss über deinen eigenen Apple-Developer-Account eingereicht werden, nicht über den des Builders. Ein Dienst, der Apps für dich unter seinem eigenen Account veröffentlicht, setzt jede dieser Apps einem Risiko aus.

4.3(a) „Don't create multiple Bundle IDs of the same app […]"

Betreibst du mehrere ähnliche Websites – eine pro Stadt, pro Filiale oder, als Agentur, pro Kunde –, ist eine fast identische App für jede davon der Lehrbuchfall für 4.3(a) „Spam". Denk stattdessen an eine App mit Auswahl, oder mach jede App wirklich eigenständig.

Zahlungen: noch eine Falle für Web-Apps

Verkauft deine Web-App digitale Inhalte oder Abos, verlangt Richtlinie 3.1.1 In-App-Käufe in der iOS-App („If you want to unlock features or functionality within your app […] you must use in-app purchase"). Ein Web-Checkout für ein digitales Abo innerhalb der App ist eine eigene, häufige Ablehnung.

Physische Waren sind anders: Nach 3.1.3(e) musst du für „physical goods or services that will be consumed outside of the app" andere Zahlungswege als In-App-Kauf nutzen. Ein Shop mit echten Produkten behält seinen normalen Checkout.

So reichst du erneut ein

1. Erst beheben, dann antworten. Änderungen umsetzen, neuen Build hochladen, dann in App Store Connect antworten.
2. Konkrete Review-Notizen schreiben. Richtlinie 2.3.1(a) verlangt, dass neue Funktionen „described with specificity in the Notes for Review section" werden. Liste auf, was du geändert hast und wo man es findet.
3. Demo-Account hinterlegen und, falls deine App versteckte Funktionen hat, eine kurze Bildschirmaufnahme.
4. Sachlich bleiben. Reviewer reagieren auf Belege, nicht auf Frust.

Eine Antwort, die als Ausgangspunkt funktioniert (auf Englisch, weil App Review in der Regel englisch kommuniziert):

Thank you for the review. We've updated the app to address Guideline 4.2: – Added a bottom tab bar (Home, Shop, Cart, Account) available on every screen – Added an offline screen with automatic reload instead of a web error – The app now opens directly in the catalog instead of our marketing page – Account deletion is available under Account → Settings A demo account is included in App Review Information. Thank you for taking another look.

Hältst du die Ablehnung für falsch, kannst du Einspruch beim App Review Board einlegen – aber erst, wenn du sicher bist, dass die Punkte oben erfüllt sind.

Checkliste vor dem Einreichen

• Untere Navigation mit deinen Hauptbereichen, auf jedem Screen sichtbar
• Gebrandete Offline-Seite mit „Erneut versuchen", im Flugmodus getestet
• Kein Browser-Rahmen, kein Desktop-Layout, kein Pinch-Zoom auf mobilen Seiten
• Interne Links bleiben in der App
• Erster Screen = der Kern deines Produkts, nicht die Marketing-Seite
• Nur Berechtigungen, die du nutzt, jeweils mit klarem Begründungstext
• Konto-Löschung in der App erreichbar (5.1.1(v)); Demo-Account in App Store Connect (2.1)
• Digitale Güter per In-App-Kauf (3.1.1); physische Waren über deinen normalen Checkout (3.1.3(e))
• Eingereicht über deinen eigenen Apple-Developer-Account (4.2.6); eine App, nicht eine pro Standort (4.3(a))
• Konkrete Notes for Review (2.3.1(a))

Wo AppThunder hilft

AppThunder baut die iOS- und Android-App um deine bestehende Website herum in der Cloud. Es übernimmt die Punkte dieser Checkliste, die außerhalb deiner Website liegen: natives App-Icon und Splash-Screen, Begründungstexte für die Kamera- und Standort-Berechtigungen, die du aktivierst, eine gebrandete Offline-Seite mit automatischem Neuladen und eine Tab-Leiste für deine Website per Copy-Paste-Snippet. Die Builds werden mit deinen Apple-Zugangsdaten signiert und in dein App Store Connect hochgeladen – du reichst also über deinen eigenen Account ein, wie 4.2.6 es verlangt. Ein eingebauter Guideline Checker zeigt typische Probleme vor dem Einreichen, etwa eine fehlende Datenschutzseite, eine Login-Wand oder eine fehlende Konto-Löschung.

Was es dir nicht abnehmen kann: entscheiden, was dein erster Screen zeigt, App Review einen Demo-Account geben oder eine Marketing-Seite nützlich machen. Die Checkliste oben bleibt deine Aufgabe.

FAQ

Kann eine App auf Basis von WKWebView überhaupt freigegeben werden? Ja. Apples Regel bewertet das Ergebnis, nicht die Technik: Funktionen, Inhalte und eine Oberfläche, die „elevate it beyond a repackaged website".

Wie lange dauert ein erneutes Review? Apple veröffentlicht keine festen Zeiten. Die Richtlinien warnen aber, dass das Review „will take longer", wenn eine App „repeatedly rejected for the same guideline violation" wird – behebe also alles, bevor du erneut einreichst.

Hat Google Play dieselbe Regel? Google Play hat kein direktes Gegenstück zu 4.2, aber seine Richtlinien zu Mindestfunktionalität und Spam gelten auch für Apps, die nur eine Website anzeigen. Dieselben Verbesserungen helfen in beiden Stores.

Reichen Splash-Screen und Icon? Nein. Sie werden erwartet, ändern aber nicht, wie sich die App verhält – das tun Navigation, Offline-Zustand und ein nützlicher erster Screen.