App Store Richtlinie 2.1: Ablehnung wegen unvollständiger App und Demoaccount beheben

Laden Sie also nicht hektisch einen neuen Build hoch. Halten Sie stattdessen diese Reihenfolge ein, damit Sie nicht zweimal mit demselben Grund abgelehnt werden.

1. Öffnen Sie in App Store Connect den Bereich App Review Ihrer App und lesen Sie die Nachricht vollständig.
2. Notieren Sie Screenshot, Gerätemodell und Betriebssystemversion, falls angegeben.
3. Ordnen Sie das Problem ein: Anmeldung, Absturz, fehlender Inhalt oder Käufe innerhalb der App?
4. Testen Sie den Demoaccount selbst auf einer frischen Installation.
5. Prüfen Sie, ob Ihr Produktivbackend läuft und während der Prüfung erreichbar bleibt.
6. Laden Sie bei Bedarf einen neuen Build hoch, aktualisieren Sie die App Review Information und antworten Sie kurz auf die Nachricht.

Was verlangt Richtlinie 2.1 genau?

Die Regel steht im Abschnitt App Completeness der App Review Guidelines von Apple. Sie verlangt, dass jede Einreichung eine finale Version ist. Das heißt: Metadaten sind vollständig, URLs funktionieren und temporäre Inhalte sind entfernt. Zudem sollen Sie die App vor dem Einreichen auf einem echten Gerät auf Fehler und Stabilität testen.

Kurz gesagt läuft die Richtlinie auf diese Punkte hinaus:

• Entfernen Sie Platzhaltertexte, leere Websites und temporäre Inhalte vor dem Einreichen.
• Hat Ihre App eine Anmeldung, geben Sie Zugangsdaten für einen Demoaccount an und lassen Sie Ihr Backend eingeschaltet.
• Können Sie aus rechtlichen oder Sicherheitsgründen keinen Demoaccount liefern, ist ein eingebauter Demomodus möglich, allerdings nur mit vorheriger Zustimmung von Apple.
• Ein Demomodus muss alle Funktionen der App zeigen.
• Unvollständige Pakete sowie Builds mit Abstürzen oder offensichtlichen technischen Problemen lehnt Apple ab.
• Käufe innerhalb der App müssen vollständig, aktuell, für die Prüfung sichtbar und funktionsfähig sein.

Somit ist App Store Richtlinie 2.1 kein einzelner Fehlertyp. Unter dieser Nummer landen sowohl fehlende Informationen als auch echte technische Mängel. Deshalb sollten Sie klären, auf welches Teilproblem Ihre Nachricht zielt, bevor Sie Code ändern.

Wie lesen Sie die Hinweise in der Ablehnungsnachricht?

Die Nachricht von Apple nennt meist die Richtliniennummer, eine kurze Erklärung und oft das Gerät, auf dem geprüft wurde. Manche Nachrichten enthalten zudem einen Screenshot. Diese Details sind Ihre wertvollsten Daten, denn mit ihnen stellen Sie das Problem nach.

In der Praxis sehen Sie zwei große Gruppen. Bei der ersten braucht die Prüfung nur Informationen: Der Demoaccount funktioniert nicht, oder der Weg zu einer Funktion ist unklar. Bei der zweiten stürzt die App ab, ein Bildschirm bleibt leer oder ein Button reagiert nicht. Die erste Gruppe kommt oft ohne neuen Build aus. Die zweite braucht ihn dagegen fast immer, also planen Sie dafür Zeit ein.

Steht ein Gerät und eine Systemversion in der Nachricht, wiederholen Sie Ihren Test genau unter diesen Bedingungen. Hat die Prüfung zum Beispiel auf einem iPad stattgefunden, prüfen Sie den Start dort, auch wenn Sie die App nur für das iPhone gestaltet haben. Vergleichen Sie außerdem den Zeitpunkt der Nachricht mit Ihren Serverlogs.

Warum ist der Demoaccount die häufigste Ursache nach App Store Richtlinie 2.1?

Weil die Prüfung Ihre App bei null startet, in einer Umgebung, an die Sie nie gedacht haben. Auf Ihrem eigenen Telefon bleiben Sie angemeldet, also fällt ein Anmeldeproblem wochenlang nicht auf. Auf dem Gerät der Prüfung zeigt es sich in der ersten Sekunde. Kommt dort niemand über den Anmeldebildschirm hinaus, endet die Prüfung genau an dieser Stelle.

Aus unserer Praxis kennen wir einige wiederkehrende Muster:

• Das Passwort hat sich in der Entwicklung geändert, in App Store Connect steht noch das alte.
• Das Konto existiert nur in der Testumgebung, nicht in der Produktivdatenbank.
• Die Anmeldung wartet auf eine E-Mail Bestätigung oder einen Einmalcode per SMS.
• Testphase oder Abo des Kontos sind abgelaufen.
• Es gibt keine Beispieldaten, die die Prüfung erkunden kann.
• Dem Konto fehlt eine Rolle, die eine Freigabe durch einen Admin braucht.

Können Sie eines dieser Muster nicht selbst lösen oder verteilt sich Ihr Backend auf mehrere Dienstleister, spart es Zeit, die Einreichung mit einem Partner für Mobile App Entwicklung zu planen. Mit eigenem Team reichen die folgenden Schritte meist aus.

Wie füllen Sie den Bereich App Review Information aus?

Konkret ist dieser Bereich in App Store Connect Ihre einzige offizielle Brücke zur Prüfung. Die Hilfeseite zu App Review Information beschreibt drei Hauptfelder: Kontakt, Notizen und Anmeldedaten. Kundinnen und Kunden sehen diese Angaben nie, und Sie können sie jederzeit bearbeiten, selbst bei einer freigegebenen Version.

• Kontakt: Name, E-Mail und Telefonnummer einer Person, die das Prüfteam erreichen kann. Die Nummer gehört ins internationale Format, beginnend mit Pluszeichen und Ländervorwahl.
• Notizen: appspezifische Einstellungen, Testregistrierung oder Kontodetails. Das Feld hat eine Bytegrenze; den aktuellen Wert finden Sie auf der Hilfeseite. Sie dürfen die Notizen in jeder Sprache schreiben.
• Anmeldung erforderlich: Benutzername und Passwort des Demoaccounts. Das Konto darf nicht ablaufen, weitere Konten gehören in die Notizen.

Nutzt Ihre App zudem einen zentralen Anmeldedienst wie Facebook, verlangt die Hilfeseite auch dafür Demozugangsdaten. Lesen Sie diese Felder daher bei jeder Version neu, denn alte Angaben veralten oft unbemerkt.

Was gehört in die Notizen für die Prüfung?

Das Notizfeld ist eine kurze Wegbeschreibung, damit sich die Prüfung nicht verirrt. Verzichten Sie daher auf Werbetexte. Beschreiben Sie stattdessen Schritt für Schritt, was zu tun ist. Dieses Gerüst passt zum Beispiel für die meisten Apps:

1. Der Zweck der App in einem Satz.
2. Die Anmeldung mit dem Demoaccount und der erste Bildschirm danach.
3. Die Schritte bis zur Kernfunktion, in der richtigen Reihenfolge.
4. Funktionen, die eine bestimmte Rolle, einen Ort oder ein Gerät brauchen, und wie man sie testet.
5. Wo Käufe innerhalb der App erscheinen und warum einzelne eventuell fehlen.
6. Weitere Demoaccounts, etwa für Admin und normale Nutzer.

Richtlinie 2.3.1 verlangt außerdem, neue Funktionen und Produktänderungen in den Notizen konkret zu beschreiben und für die Prüfung zugänglich zu machen. Allgemeine Beschreibungen lehnt Apple laut dieser Regel ab. Schreiben Sie daher nicht einfach "alle Funktionen laufen". Nennen Sie stattdessen, was auf welchem Bildschirm zu sehen ist.

Was tun, wenn der Demoaccount einen SMS Code oder eine Zweifaktoranmeldung verlangt?

Die Prüfung sieht keine Codes, die an Ihr Telefon gehen. Nutzt Ihre Anmeldung also SMS, eine E-Mail Bestätigung oder eine Authenticator App, brauchen Sie einen regelkonformen Weg, wie der Demoaccount diesen Schritt besteht. Sonst ist das Konto technisch korrekt und trotzdem unbrauchbar.

Bewährte Optionen sind:

• Die Verifizierung des Demoaccounts im Backend vorab abschließen.
• Einen festen Testcode nur für dieses Konto hinterlegen und in den Notizen nennen.
• In den Notizen eine Kontaktperson angeben, die während der Prüfung einen Einmalcode weitergibt.

Öffnen Sie diese Ausnahme allerdings nie für echte Nutzer. Binden Sie den festen Code ausschließlich an den Demoaccount und sorgen Sie dafür, dass Sie ihn nach der Prüfung abschalten können. Zudem darf das Konto nicht ablaufen; die Hilfeseite sagt das deutlich. Bei Abo Apps lassen Sie das Abo des Demoaccounts während der gesamten Prüfung aktiv.

Wann ist ein Demomodus ohne Anmeldung erlaubt?

Richtlinie 2.1 bietet Entwicklern, die aus rechtlichen oder Sicherheitsgründen keinen Demoaccount liefern können, eine Alternative: einen eingebauten Demomodus. Dafür brauchen Sie allerdings die vorherige Zustimmung von Apple. Es reicht also nicht, einen Demomodus einzubauen und ihn in den Notizen zu erwähnen.

Apps mit echten personenbezogenen Daten, etwa Bankdaten oder Unternehmensidentitäten, tun sich zum Beispiel schwer mit einem Demoaccount. Dann sollte der Demomodus den echten Ablauf abbilden und jede Funktion zeigen. Ein halbfertiger Schaubildschirm führt dagegen direkt zur nächsten Ablehnung nach 2.1.

Fragen Sie sich zunächst ehrlich, ob Sie wirklich kein Konto bereitstellen können. Oft erzeugt ein separater Testmandant im Backend oder ein Konto mit Beispieldaten viel weniger Reibung als ein Demomodus. Brauchen Sie ihn trotzdem, begründen Sie das klar in Ihrer Antwort auf die Ablehnung und klären Sie die Zustimmung dort.

Warum führt ein abgeschaltetes Backend zur Ablehnung?

Die Prüfung läuft nach dem Zeitplan von Apple, nicht nach Ihren Bürozeiten. Die Checkliste vor dem Einreichen verlangt, dass Backenddienste während der Prüfung live und erreichbar sind. Ein nächtliches Wartungsfenster, ein abgeschalteter Testserver oder ein abgelaufenes Zertifikat erscheinen bei der Prüfung als leere Liste oder endloser Ladekreis.

Konkret sehen wir im Backend diese typischen Fallen:

• Der Build zeigt noch auf die Testumgebung, und die ist offline.
• Der Server blockiert Zugriffe aus bestimmten Ländern.
• Eine Ratenbegrenzung hält den Prüfverkehr aus einem Netz für einen Angriff.
• Der API Endpunkt für die neue Version ist noch nicht live.

Testen Sie die Produktivumgebung deshalb durchgängig mit Ihrem finalen Build. Ist das Thema Backend neu für Sie, erklärt unser Beitrag Was ist ein Backend die Verbindung zwischen App und Server in einfachen Worten.

Funktioniert Ihre App in einem reinen IPv6 Netzwerk?

Laut der IPv6 Supportseite von Apple müssen alle Apps, die Sie im App Store einreichen, reine IPv6 Netzwerke unterstützen. Nutzt Ihre App IPv4 spezifische Schnittstellen oder fest eingetragene IP Adressen, scheitert die Verbindung in so einem Netz womöglich. Die Prüfung sieht dann einen Verbindungsfehler oder einen leeren Bildschirm.

Dieses Problem ist tückisch, denn im Büronetz läuft alles. Erwähnt Ihre Ablehnung also Netzwerkfehler oder Daten, die nie laden, gehört IPv6 auf Ihre Checkliste. Oft genügt es schon, Server über den Hostnamen statt über eine nackte IP Adresse anzusprechen.

Für einen schnellen Vorabcheck zeigt unser IPv6 Test, ob Ihre Domain über IPv6 antwortet. Den eigentlichen Test machen Sie trotzdem mit der App selbst in einer IPv6 Umgebung, denn das Tool sagt nur etwas über die Serverseite.

Wie führen Platzhalter und defekte Links zur Ablehnung?

Die Richtlinie schließt Platzhaltertexte, leere Websites und temporäre Inhalte ausdrücklich aus. Ein vergessener "Lorem ipsum" Absatz, ein Button mit "Demnächst" oder ein Beispielbild aus einer Designvorlage signalisieren der Prüfung, dass die App nicht fertig ist.

Für Links gilt außerdem dasselbe. Support URL, Datenschutzerklärung und eingebettete Webansichten müssen funktionieren. Führt Ihr Link zur Datenschutzerklärung zum Beispiel auf eine leere Domain, droht eine Ablehnung, selbst wenn die App fehlerfrei ist. Weitere Anforderungen zum Datenschutz finden Sie in unserem Leitfaden App Store Datenschutzangaben vorbereiten.

Gehen Sie vor dem Einreichen jeden Bildschirm durch, lesen Sie jeden Text, tippen Sie jeden Button einmal an und öffnen Sie jeden Link. Verstecken Sie eine unfertige Funktion nicht, sondern nehmen Sie sie ganz aus diesem Release. So bekommen Prüfung und Nutzer ein stimmiges Produkt.

Wie finden Sie abstürzende Bildschirme vor dem Einreichen?

Die App Review Seite von Apple bittet darum, nur fertige und veröffentlichungsreife Inhalte einzureichen und gründlich auf Geräten mit der neuesten Software zu testen. Eine App, die im Simulator problemlos läuft, kann auf einem echten Gerät trotzdem abstürzen, etwa wegen Speicher, Berechtigungen oder Netzbedingungen.

Testen Sie den finalen Build daher auf echten Geräten mit frischer Installation. Der praktischste Weg dafür ist TestFlight für iOS Tests vor dem Release, denn so erhalten externe Tester den Build in derselben Form wie die Prüfung. Probieren Sie außerdem diese Szenarien aus:

• Erster Start ohne Berechtigungen und ohne Daten.
• Alle Berechtigungen verweigert: Kamera, Standort, Mitteilungen.
• Schwache oder abbrechende Internetverbindung.
• Verschiedene Bildschirmgrößen, vor allem iPad.
• Abmelden und erneut anmelden.

Liegt ein Absturzbericht vor, nutzen Sie die Dokumentation von Apple zum Abrufen und Analysieren von Crash Reports; auch die App Review Seite verweist nach einer Ablehnung darauf.

Wie fallen Käufe innerhalb der App unter Richtlinie 2.1?

Der zweite Teil der Richtlinie verlangt, dass Käufe innerhalb der App vollständig, aktuell, für die Prüfung sichtbar und funktionsfähig sind. Findet die Prüfung ein in App Store Connect angelegtes Produkt nicht in der App, müssen Sie den Grund in den Notizen erklären.

Ein typisches Szenario: Zunächst legen Sie eine neue Abostufe in App Store Connect an, doch die Bezahlseite erscheint nur für ein bestimmtes Nutzersegment. Die Prüfung gehört nicht dazu und findet das Produkt also nie. Die Lösung: Nennen Sie in den Notizen Bildschirm und Bedingung, oder richten Sie den Demoaccount so ein, dass er die Bedingung erfüllt.

Ist das Bezahlmodell selbst noch offen, vergleicht unser Beitrag Kauf in der App oder Webzahlung beide Wege. Prüft Ihr Kaufablauf außerdem Belege über den Server, muss das Backend während der Prüfung laufen.

Was tun, wenn die App Hardware, einen Ort oder einen QR Code braucht?

Manche Apps hängen von etwas ab, das die Prüfung nicht hat: einem smarten Gerät, einem Ladengeschäft, einer bestimmten Stadt oder einem QR Code auf dem Tisch. Die Checkliste vor dem Einreichen bittet darum, nötige Hardware oder Ressourcen bereitzustellen, etwa Zugangsdaten oder einen Beispiel QR Code.

Die App Review Seite empfiehlt zudem, für schwer nachstellbare Umgebungen ein Demovideo oder die Hardware selbst bereitzuhalten. In der Praxis helfen diese Ansätze:

1. Hängen Sie den Beispiel QR Code als Bild an und erklären Sie in den Notizen, wo man ihn scannt.
2. Binden Sie standortbasierte Funktionen für den Demoaccount an eine feste Testregion.
3. Nehmen Sie eine kurze Bildschirmaufnahme der Kopplung mit dem Gerät auf.
4. Listen Sie die Bildschirme auf, die auch ohne Hardware erreichbar sind.

Somit kann die Prüfung die Logik Ihrer App beurteilen, ohne an einer physischen Abhängigkeit hängen zu bleiben.

Wie bereiten Sie den Demoaccount für die Prüfung vor?

Aus Sicht der App Store Richtlinie 2.1 kann ein guter Demoaccount mehr als sich anmelden. Nach dem Login sollte die Prüfung den Nutzen Ihrer App innerhalb weniger Minuten erkennen. Eine leere Startseite, ein Hinweis "noch keine Inhalte" oder ein endloser Einrichtungsassistent wirken dagegen unfertig.

Befüllen Sie den Demoaccount also so, als hätte ihn eine echte Person einige Wochen genutzt. Eine Termin App zeigt dann vergangene und kommende Termine, ein Shop einen Warenkorb samt Bestellhistorie und eine Team App Beispielnachrichten. Verwenden Sie dabei ausschließlich erfundene Inhalte statt personenbezogener Daten.

Hat Ihre App mehrere Rollen, legen Sie außerdem pro Rolle ein Konto an. Das Hauptkonto gehört in die Anmeldefelder, die übrigen in die Notizen. Stellen Sie schließlich sicher, dass niemand den Demoaccount während der Prüfung ändert; setzt jemand aus dem Team das Passwort zurück, war die ganze Vorbereitung umsonst.

Wie verteilen Sie die Einreichung im Team?

Viele Ablehnungen nach Richtlinie 2.1 entstehen durch Kommunikationslücken, nicht durch Code. Die Mobilentwicklung lädt den Build hoch, das Backendteam zieht in derselben Nacht den Server um, und das Produktmanagement kopiert die Notizen aus dem letzten Release. Jeder hat seinen Teil richtig gemacht, trotzdem sieht die Prüfung eine kaputte App.

Behandeln Sie den Einreichungstag deshalb wie einen kleinen Releaseprozess:

1. Bestimmen Sie eine Person, die für die Einreichung verantwortlich ist.
2. Bitten Sie das Backendteam, während der Prüfung keine Änderungen auszurollen.
3. Legen Sie das Passwort des Demoaccounts in einem gemeinsamen Passwortsafe ab.
4. Schreiben Sie die Notizen bei jedem Release neu, statt alten Text zu kopieren.
5. Prüfen Sie das Kontaktpostfach regelmäßig, bis die Freigabe da ist.

So beantworten Sie Rückfragen der Prüfung innerhalb von Stunden und ziehen den Prozess nicht unnötig in die Länge.

App Store Richtlinie 2.1: Ablehnungsarten und Lösungen im Überblick

Die Tabelle verknüpft das Symptom in Ihrer Nachricht mit einer wahrscheinlichen Ursache und einem ersten Schritt. Sie ist ein Startpunkt; bestätigen Sie die Diagnose mit Ihren eigenen Logs.

Zusammengefasst: Wer Informationsproblem und Codeproblem trennt, lädt keine unnötigen Builds hoch und verliert keine Zeit in der Warteschlange.

Wie antworten Sie nach einer Ablehnung an App Review?

Laut der Apple Hilfeseite zum Antworten auf App Review Nachrichten können Sie mit Apple korrespondieren und Anhänge wie Screenshots und Belege beifügen, bis Sie erneut einreichen. Betraf die Ablehnung nur Metadaten, dürfen Sie nach der Korrektur denselben Build erneut einreichen.

Die Schritte sehen also so aus:

1. Wählen Sie in App Store Connect unter Apps Ihre App aus.
2. Klicken Sie oben auf der Seite auf den Link zu den offenen Problemen.
3. Neben der laufenden Einreichung klicken Sie auf Resolve.
4. Öffnen Sie mit Reply to App Review das Antwortfeld und schreiben Sie Ihren Text.
5. Fügen Sie bei Bedarf über Attach File einen Screenshot oder ein Dokument hinzu und senden Sie die Antwort.

Halten Sie die Antwort kurz und konkret: was Sie behoben haben, welche Bildschirme Sie mit dem Demoaccount getestet haben und welche Schritte die Prüfung gehen soll. Ein hilfsbereiter Ton statt eines defensiven beschleunigt den Austausch.

Wann lohnt sich ein Einspruch beim App Review Board?

Die App Review Seite von Apple sagt: Wenn Sie glauben, dass die Prüfung Konzept oder Funktion Ihrer App missverstanden hat, können Sie beim App Review Board Einspruch einlegen. Dieselbe Seite bittet allerdings darum, vorher alle Rückfragen zu beantworten und pro abgelehnter Einreichung nur einen Einspruch zu senden.

Bei App Store Richtlinie 2.1 ist ein Einspruch selten der erste Schritt. Diese Ablehnungen zeigen meist ein echtes Zugangs oder Stabilitätsproblem. Können Sie das Problem nachstellen, beheben Sie es, statt Einspruch einzulegen. Haben Sie dagegen alles geprüft und kommt dieselbe Ablehnung trotzdem wieder, antworten Sie zunächst ausführlich auf die Nachricht; erst danach kommt ein Einspruch in Frage.

Außerdem erwähnt die App Review Seite Videotermine mit App Review, um die Richtlinien zu besprechen. Bei einem komplexen Anmeldeablauf ist so ein Gespräch oft ergiebiger als ein Einspruch.

Was sollten Sie nach einer Ablehnung nach Richtlinie 2.1 vermeiden?

Der größte Fehler ist daher, die Prüfung umgehen zu wollen, statt das Problem zu lösen. Folgende Schritte verschlimmern die Lage:

• Dieselbe App über ein anderes Entwicklerkonto oder eine neue Bundle ID erneut hochladen.
• Eine fehlerhafte Funktion während der Prüfung verstecken und nach der Freigabe aus der Ferne einschalten.
• Notizen schreiben, die nicht der Wahrheit entsprechen.
• Denselben Build ohne Änderungen immer wieder einreichen.

Versteckte Funktionen und irreführende Angaben können weitere Richtlinien auslösen und bis zu Maßnahmen gegen das ganze Konto reichen. Wie Umgehungsversuche mit verknüpften Konten auf Android Seite ausgehen, zeigt unser Beitrag zum gekündigten Google Play Entwicklerkonto. Haben Sie zusätzlich eine Ablehnung wegen Datenerhebung erhalten, lesen Sie unseren Leitfaden zur Ablehnung nach Richtlinie 5.1.1; beide kommen oft zusammen.

Mit welchen anderen Ablehnungen wird Richtlinie 2.1 verwechselt?

Richtlinie 2.1 erscheint manchmal in derselben Nachricht wie andere Regeln. Bietet Ihre App zum Beispiel eine Kontoerstellung, aber keine Löschung, greift eine eigene Regel; mehr dazu in unserem Beitrag Apples Pflicht zur Kontolöschung. Nutzen Sie Anmeldungen über Drittanbieter, prüfen Sie auch, ob Sign in with Apple Pflicht ist.

Einen breiten Überblick über alle Gründe gibt unser Leitfaden Warum wurde Ihre App abgelehnt. Auf Android laufen geschlossene Tests und Entfernungen anders; dazu passen unsere Beiträge zu 12 Testern und 14 Tagen bei Google Play und zum Einspruch nach einem Richtlinienverstoß bei Google Play.

Diese Unterscheidung ist wichtig, denn jede Regel braucht eine andere Korrektur. Listen Sie also alle Nummern aus der Nachricht auf und behandeln Sie jede einzeln. Das senkt das Risiko, wegen einer halben Korrektur erneut abgelehnt zu werden.

Die letzte Checkliste vor dem Einreichen

Gehen Sie diese Liste bei jedem Release durch, direkt bevor Sie einreichen:

• Der Demoaccount existiert in der Produktion, das Passwort stimmt und läuft nicht ab.
• Im Demoaccount liegen Beispieldaten für die Prüfung.
• Codeabfragen lassen sich mit dem Demoaccount bestehen.
• Ihr Build nutzt die Produktiv URL, und das Backend bleibt während der Prüfung online.
• Auch in einem reinen IPv6 Netzwerk baut die App eine Verbindung auf.
• Kein Bildschirm zeigt Platzhaltertext oder tote Buttons.
• Links zu Datenschutzerklärung und Support funktionieren.
• Jeder Kauf innerhalb der App ist auffindbar, oder die Notizen erklären, warum nicht.
• Ihre Notizen enthalten einen Testpfad Schritt für Schritt und aktuelle Kontaktdaten.

Diese Liste kostet also fünf Minuten, kann Ihnen aber mehrere Tage Prüfschleifen ersparen. Reichen bei Ihnen wechselnde Personen ein, legen Sie die Liste zudem in ein gemeinsames Dokument, damit der Ablauf einheitlich bleibt.

Wann sollten Sie sich professionelle Hilfe holen?

Die meisten Ablehnungen nach App Store Richtlinie 2.1 löst Ihr eigenes Team mit den Schritten oben. Ein Blick von außen hilft allerdings, wenn dieselbe Ablehnung wiederkehrt, wenn der Absturz nur in der Prüfung auftritt oder wenn Backend und App bei verschiedenen Dienstleistern liegen und niemand weiß, wo der Fehler sitzt.

Wir bei Talha Aslan und Team prüfen in solchen Fällen zuerst Ablehnungsnachricht, Demoaccount und Produktivumgebung gemeinsam. Dann beheben wir, was fehlt, und schreiben die Notizen neu. Die Entscheidung über die Freigabe liegt immer bei Apple; deshalb sollte Ihnen niemand eine sichere Freigabe versprechen.

Möchten Sie eine neue App von Anfang an prüfungsreif aufbauen oder Ihren Einreichungsprozess ordnen, sehen Sie sich an, wie wir bei der iOS und Android App Entwicklung vorgehen, und nehmen Sie Kontakt auf.