Apple kann eine Website-basierte App ablehnen, wobei „minimale Funktionalität“ der häufigste Grund ist. Leitlinie 4.2 ist die Regel dahinter. Eine Website-App wird nicht automatisch abgelehnt, aber eine App, die über eine Website in einem Frame hinaus nichts hinzufügt, ist einem echten Risiko ausgesetzt.
In diesem Leitfaden wird erklärt, was in der Richtlinie steht, worauf Gutachter achten und wie man eine Einreichung vorbereitet. Niemand außerhalb von Apple kann eine Genehmigung versprechen, und dieser Artikel tut dies auch nicht. Sie können die vermeidbaren Ablehnungsgründe beseitigen.
Was Leitlinie 4.2 eigentlich sagt
In den Richtlinien zur App-Überprüfung heißt es unter 4.2, Mindestfunktionalität:
Ihre App sollte über Funktionen, Inhalte und Benutzeroberfläche verfügen, die sie von einer neu gepackten Website abheben. Wenn Ihre App nicht besonders nützlich, einzigartig oder „App-ähnlich“ ist, gehört sie nicht in den App Store.
Die Worte, auf die es ankommt, sind „neu verpackte Website“. Die Regel verbietet keine Apps, die auf Webinhalten basieren. Es verbietet Apps, die nichts bieten, was eine Website nicht bereits bietet.
Verwandte Richtlinien tauchen auch in Website-App-Rezensionen auf:
- 4.2.2: Abgesehen von Katalogen sollten Apps nicht in erster Linie aus Marketingmaterialien, Anzeigen, Webausschnitten, Inhaltsaggregatoren oder einer Sammlung von Links bestehen.
- 4.2.3: Die App sollte eigenständig funktionieren, ohne dass die Installation einer anderen App erforderlich ist, und sie sollte alle erforderlichen großen Downloads beim ersten Start offenlegen und dazu auffordern.
- 2.1 (App-Vollständigkeit): Bei den Einsendungen sollte es sich um endgültige Versionen mit funktionierenden URLs, ohne Platzhalterinhalt und Demokontodetails handeln, wenn die App über ein Login verfügt.
- 4.2.6: Apps, die aus einer kommerzialisierten Vorlage oder einem App-Generierungsdienst erstellt wurden, werden abgelehnt, es sei denn, sie werden direkt vom Anbieter des App-Inhalts eingereicht.
Lesen Sie immer den aktuellen Text selbst, da Apple die Richtlinien aktualisiert. Die offizielle Quelle ist die Richtlinien zur App Store-Überprüfung.
Wird Apple eine Website-App ablehnen?
Es kommt darauf an, was die eingereichte App macht. In der Praxis reagieren Gutachter auf einige Muster:
- Die App öffnet eine einzelne URL und sieht genauso aus wie die mobile Website, einschließlich der Navigation im Webstil.
- Es wird nur eine Anmeldewand ohne durchsuchbaren Inhalt angezeigt, sodass der Prüfer nicht sehen kann, was die App tut.
- Ohne Verbindung bricht es ab oder zeigt Fehler an.
- Seine Links springen ständig zum Browser.
- Es sieht aus wie eine Marketingbroschüre für ein Unternehmen ohne eigene Funktion.
Eine App, die einen realen Dienst, etwa einen Shop, ein Buchungssystem, einen Mitgliederbereich oder eine Inhaltsbibliothek, umschließt und mit einer App-ähnlichen Navigation präsentiert, ist an einer anderen Stelle. Sie können immer noch abgelehnt werden, da die Überprüfung ein Urteil ist, aber Sie haben etwas, auf das Sie hinweisen können.
Warum eine servicegenerierte App ein eigenes Konto benötigt
Richtlinie 4.2.6 besagt, dass Apps, die mit einem App-Generierungsdienst erstellt wurden, abgelehnt werden, es sei denn, sie werden direkt vom Anbieter des App-Inhalts eingereicht. Für einen Websitebesitzer lautet die praktische Lektüre: Veröffentlichen Sie unter Ihrem eigenen Apple Developer-Konto, in Ihrem eigenen Namen oder dem Ihres Unternehmens und stellen Sie sicher, dass die App Ihren eigenen Inhalt repräsentiert.
So funktioniert auch SiteTo.App. Builds werden mit dem Apple Developer-Konto signiert, das Sie verbinden, und der Build wird an TestFlight in Ihrem App Store Connect-Konto übermittelt. Sie sind Eigentümer des Eintrags und reichen ihn ein. Siehe die Leitfaden für Apple-Entwicklerkonten für die Einrichtung. Geben Sie Ihre Inhalte nicht an einen Anbieter weiter, der die gleiche Shell für viele Kunden unter seinem eigenen Konto bereitstellt.
Wie fühlt sich eine Website-App wie eine App an?
Das Ziel besteht nicht darin, Funktionen um ihrer selbst willen hinzuzufügen. Es soll die mobile Nutzung verbessern. Zu den starken, ehrlichen Ergänzungen gehören:
- Native Navigation. Eine Tab-Leiste oder ein Menü, das der Art und Weise entspricht, wie sich Nutzer auf einem Telefon auf Ihrer Website bewegen, und nicht eine Desktop-Kopfzeile, die in einen kleinen Bildschirm gequetscht wird.
- Push-Benachrichtigungen. Nachrichten, für die sich Benutzer entscheiden, beispielsweise Bestellaktualisierungen, Buchungserinnerungen oder neue Inhalte. In SiteTo.App werden diese über Firebase eingerichtet; siehe die Firebase-Anleitung.
- Deep-Links. Links aus Benachrichtigungen oder E-Mails, die den rechten Bildschirm in der App öffnen.
- Ein gestaltetes Starterlebnis. Ein Symbol, ein Begrüßungsbildschirm und ein klarer Lade- und Fehlerstatus.
- Native Übergaben. Freigabe, Datei-Uploads, Kamerazugriff oder Downloads, die auf dem Gerät ordnungsgemäß funktionieren.
Fügen Sie keine Gimmicks wie einen Taschenlampenschalter hinzu. Richtlinie 4.2 wird nicht behandelt und die Gutachter durchschauen sie.
Eine Checkliste vor der Einreichung
Gehen Sie Folgendes durch, bevor Sie hochladen:
- Testen Sie die gesamte Reise auf einem echten iPhone. Installieren Sie über TestFlight, nicht nur über einen Simulator. Öffnen Sie die App, melden Sie sich an, navigieren Sie mehrere Ebenen tief und verwenden Sie die Zurück-Geste.
- Test ohne Verbindung. Schalten Sie den Flugmodus ein und öffnen Sie die App. Sie sollten eine klare Nachricht sehen, keine leere Seite.
- Überprüfen Sie jeden externen Link. Entscheiden Sie gezielt, welche Links in der App bleiben und welche den Browser öffnen.
- Beheben Sie Probleme mit dem Website-Layout. Reaktionsprobleme, winzige Tippziele und Popups nur für den Desktop sind in einer App offensichtlich.
- Platzhalterinhalt entfernen. Richtlinie 2.1 erwartet ein fertiges Produkt mit funktionierenden Support- und Datenschutz-URLs.
- Geben Sie Demo-Zugangsdaten an. Wenn eine Anmeldung erforderlich ist, geben Sie ein Konto an, das während der gesamten Überprüfung weiterhin funktioniert.
- Sorgen Sie für präzise Antworten zum Datenschutz. Sie sollten das gesamte Erlebnis beschreiben, einschließlich der in der App geladenen Webanalyse- und Zahlungstools.
- Schreiben Sie ehrliche Screenshots und eine Beschreibung. Zeigen Sie die echte App und behaupten Sie nicht, dass ihr Funktionen fehlen.
- Verwenden Sie Rezensionsnotizen. Erklären Sie, was die App macht, wo sich die nativen Funktionen befinden und welche Regions- oder Kontoanforderungen es gibt.
Sie können Ihre Website mit vielen davon vergleichen Checkliste für die Bereitschaft, und unsere Verlagsführer deckt die umliegenden Ladenstufen ab.
So schreiben Sie hilfreiche Rezensionsnotizen
Gutachter sehen viele Einsendungen. Eine kurze, konkrete Notiz hilft ihnen, den Wert schnell zu finden. Abdeckung:
- Wozu die App dient, in ein oder zwei Sätzen.
- So melden Sie sich mit funktionierenden Demo-Anmeldeinformationen an.
- Wo finde ich die nativen Funktionen, zum Beispiel „Benachrichtigungen können über die Registerkarte „Konto“ aktiviert werden.“
- Alles Ungewöhnliche, etwa eine Funktion, die eine bestimmte Region oder Hardware erfordert.
Bleiben Sie sachlich. Vermeiden Sie Streitigkeiten über die Richtlinien in der ersten Einreichung. Bewahren Sie dies für eine Antwort auf, falls Sie abgelehnt werden.
Wenn Apple die App ablehnt
Eine Ablehnung ist ein Gespräch, kein endgültiges Urteil. Apple erläutert die angewendete Richtlinie im Resolution Center.
- Lesen Sie die Nachricht sorgfältig durch. Beachten Sie die Richtliniennummer und alle erwähnten spezifischen Bildschirme oder Verhaltensweisen.
- Beheben Sie das eigentliche Problem. Wenn der Grund eine minimale Funktionalität ist, verbessern Sie die Funktionsweise der App, anstatt die Beschreibung umzuformulieren.
- Antworten Sie präzise. Beschreiben Sie, was sich geändert hat und wo der Prüfer es sehen kann.
- Senden Sie bei Bedarf erneut einen neuen Build. Eine Änderung an der Binärdatei erfordert einen erneuten Upload.
- Berufung nur mit einem Fall. Wenn Sie der Meinung sind, dass es sich bei der Ablehnung um einen Fehler handelt, nutzen Sie das App Review-Einspruchsverfahren und geben Sie die Fakten an.
Da eine Website-basierte App Ihre Website lädt, werden viele Korrekturen auf der Website selbst vorgenommen und in der App angezeigt, ohne dass eine neue Store-Version veröffentlicht wird. Native Konfigurationsänderungen erfordern weiterhin einen neuen Build.
Häufige Fragen
Muss eine Website-App offline funktionieren?
Nicht in der Regel, aber es sollte problemlos scheitern. Ein leerer Bildschirm ohne Verbindung sieht unvollendet aus, und das wirkt sich darauf aus, wie Prüfer die App sehen.
Wird eine PWA anders behandelt als jede andere Website?
Bei einer PWA in einer iOS-App handelt es sich immer noch um Webinhalte innerhalb einer nativen Shell, daher gelten dieselben Richtlinien. Sehen So veröffentlichen Sie eine PWA im App Store und bei Google Play.
Kann ich dieselbe App für mehrere Marken einreichen?
Richtlinie 4.2.6 schränkt Apps ein, die aus einer Vorlage oder einem Generierungsdienst erstellt und im Namen von Kunden eingereicht werden. Jedes Unternehmen sollte unter seinem eigenen Konto veröffentlichen.
Muss ich für einen Konverter bezahlen, um genehmigt zu werden?
Kein Werkzeug entscheidet über das Ergebnis. Apple bewertet die eingereichte App. Daran ändert auch die Bezahlung eines Baus nichts, daher ist die Preisgestaltung von der Genehmigung getrennt. Sehen Preisgestaltung.
Nächste Schritte
Testen Sie zunächst Ihre Website als App. Zeigen Sie eine Vorschau Ihrer Website in SiteTo.App anProbieren Sie es auf Ihrem Telefon aus und achten Sie darauf, dass es sich wie eine Website und nicht wie eine App anfühlt. Beheben Sie diese Punkte und befolgen Sie dann die Anweisungen Leitfaden erstellen und veröffentlichen.
Sehen Sie Ihre Website als App
Passen Sie das Erlebnis individuell an und zeigen Sie es in der Vorschau an, bevor Sie eine Plattform auswählen.
Erstellen Sie Ihre Vorschau


