Wie Apps im App Store und bei Google Play genehmigt werden
Die Pruefung lehnt taeglich duenne Webview-Huellen, tote Links und Datenschutzluecken ab. Hier erfaehrst du, warum Apps abgelehnt werden, was Pruefer kontrollieren und wie du in beiden Stores bestehst.
Warum es die App-Pruefung gibt (und was sie wirklich testet)
Bevor deine App auch nur einen einzigen Nutzer erreicht, durchlaeuft sie die Pruefung bei Apple und Google. Die Pruefung ist nicht dazu da, dir das Leben schwer zu machen — sie schuetzt Menschen vor Apps, die unsicher, kaputt, irrefuehrend oder schlicht leer sind. Um deine App im App Store und bei Google Play genehmigt zu bekommen, musst du zwei getrennte Regelwerke erfuellen: Apples App Review Guidelines und die Developer Program Policies von Google Play.
Beide Stores decken sich im Wesentlichen — Sicherheit, Datenschutz, ehrliche Metadaten und echte Funktionalitaet — unterscheiden sich aber in Ton und Ablauf. Apples Pruefung ist strenger und weitgehend manuell: Ein Mensch oeffnet deine App und benutzt sie. Google setzt staerker auf automatische Analyse, mit menschlichen Pruefern fuer Grenzfaelle. Beide stellen letztlich dieselbe Frage: 'Ist das ein echtes, sicheres, nuetzliches Produkt?' Wer das verinnerlicht, hoert auf zu raten und baut gezielt auf Freigabe hin.
Die haeufigsten Ablehnungsgruende
Der mit Abstand groesste Ablehnungsgrund ist die duenne Webview-Huelle. Apples Richtlinie 4.2 (Minimum Functionality) sagt ausdruecklich, dass eine App Funktionen, Inhalte und eine Oberflaeche bieten muss, die ueber eine neu verpackte Website hinausgehen, und Google Play sanktioniert Apps, die nur eine Huelle um eine mobile Website ohne Mehrwert sind. Wenn deine App ein Browser ist, der auf deine URL zeigt, rechne mit Ablehnung.
Die weiteren Gruende sind praktischer Natur: tote Links oder Sackgassen-Bildschirme, Abstuerze und Fehler waehrend der Pruefung, eine fehlende oder nicht erreichbare Datenschutzerklaerung, unvollstaendige Datenschutzangaben (Apples 'Nutrition Labels', Googles Formular zur Datensicherheit), das Tracken von Nutzern ohne Apples App-Tracking-Transparency-Abfrage, irrefuehrende Screenshots oder Metadaten und Login-Huerden ohne Testzugang fuer den Pruefer. Jeder dieser Punkte ist vermeidbar und dokumentiert — es sind wiederkehrende Gruende, aus denen eine Einreichung zurueckkommt.
Worauf Pruefer im App Store und bei Google Play wirklich achten
Pruefer arbeiten eine kurze gedankliche Liste ab. Erstens: Tut die App etwas Natives und Nuetzliches, oder ist es eine Seite, die du auch in Safari oder Chrome oeffnen koenntest? Zweitens: Ist sie stabil — keine Abstuerze, keine leeren Bildschirme, keine offensichtlich kaputten Ablaeufe? Drittens: Ist sie ehrlich — passen Screenshots, Beschreibung und Kategorie zu dem, was die App wirklich tut?
Dann folgen Datenschutz und Berechtigungen. Fordert deine App Kamera, Standort oder Benachrichtigungen an, erwartet der Pruefer einen klaren, kontextbezogenen Grund und eine passende Datenschutzangabe. Verwaltet sie Konten, muss er hineinkommen — ein funktionierender Testzugang (oder ein Gastmodus) ist deshalb Pflicht. Zuletzt pruefen sie Alterseinstufung, Anmeldeoptionen und plattformspezifische Regeln. Nichts davon ist geheim — es steht alles in den Richtlinien — aber du musst es wirklich erfuellen, nicht nur behaupten.
Warum eine echte native App die Pruefung besteht (und eine duenne Huelle oft nicht)
Der zuverlaessigste Weg durch die Minimum Functionality ist, dem Store echtes natives Verhalten zu bieten. Eine echte native App — eine Swift-Huelle auf iOS, eine Kotlin-Huelle auf Android — die deine Live-Website in einem leistungsstarken nativen Container laedt und Geraetefunktionen ueber eine JavaScript-Bruecke ergaenzt, ist eine ganz andere Produktklasse als eine blosse Huelle. Push-Benachrichtigungen, Offline-Betrieb, biometrischer Login, Deep Links, Kamera, Homescreen-Widgets und App-Shortcuts sind genau der 'native Mehrwert', nach dem Pruefer suchen sollen.
Genau diesen Ansatz verfolgt Transform To APP. Die auf deiner Website veroeffentlichten Inhalte erscheinen weiterhin sofort in der App — ohne erneute Einreichung fuer einen Blogbeitrag oder eine Preisaenderung — waehrend die native Huelle die Funktionalitaet liefert, die beide Stores zufriedenstellt. Du bekommst die schnellen Web-Updates und die native Tiefe, die die Pruefung besteht, ohne dich entscheiden zu muessen.
Deine Checkliste vor der Einreichung in beiden Stores
Geh sie durch, bevor du auf 'Senden' klickst. Sie faengt die meisten vermeidbaren Ablehnungen ab:
- Nativer Mehrwert: mindestens ein bis zwei echte Geraetefunktionen (Push, Offline, Biometrie, Kamera, Widgets), nicht nur eine geladene URL. - Stabilitaet: auf einem echten Geraet testen; keine Abstuerze, keine leeren Bildschirme, jeder Link und Button funktioniert. - Datenschutzerklaerung: aktive, erreichbare URL, verlinkt in der App und im Store-Eintrag. - Angaben: Apples Datenschutz-Labels und Googles Formular zur Datensicherheit korrekt ausgefuellt; ATT-Abfrage, falls du trackst. - Berechtigungen: nur anfordern, was du nutzt, jeweils mit klarer, kontextbezogener Erklaerung. - Zugang: funktionierender Testaccount oder Gastmodus fuer den Pruefer, falls es einen Login gibt. - Metadaten: Screenshots und Beschreibung passen zur echten App; korrekte Kategorie und Alterseinstufung.
Hak jeden Punkt ab, und du nimmst dem Pruefer fast jeden Grund fuer eine Ablehnung.
Veroeffentlichung unter deinen eigenen Entwicklerkonten
Die Freigabe haengt auch davon ab, wo die App lebt. Beide Stores verlangen Entwicklerkonten: Das Apple Developer Program kostet 99 USD pro Jahr, ein Google-Play-Entwicklerkonto ist eine einmalige Gebuehr von 25 USD. Wenn du unter deinen eigenen Konten veroeffentlichst, traegt die App deine Marke, dein Icon und deinen Firmennamen — ohne Spuren Dritter im Eintrag.
Transform To APP baut und reicht unter den eigenen Apple- und Google-Konten des Kunden ein, nicht unter einer geteilten Publisher-Identitaet. So gehoert dir der Eintrag vollstaendig und du kontrollierst kuenftige Updates. Da Inhalte ueber deine Live-Website fliessen, erfordern nur native Aenderungen einen neuen Build und eine erneute Einreichung — und die uebernehmen wir. Das Ergebnis ist eine echte native App, die die Pruefung besteht, die dir vollstaendig gehoert und die aktuell bleibt, ohne bei jeder Wortaenderung auf deiner Website erneut in die Pruefschlange zu muessen.
FAQ
Wie lange dauert die App-Pruefung?+
Das variiert. Apple prueft oft innerhalb von ein bis zwei Tagen, waehrend Google von wenigen Stunden bis zu mehreren Tagen reichen kann; beide koennen bei einer Erstelnreichung, einem markierten Problem oder in ausgelasteten Phasen laenger dauern. Reiche mit Puffer vor jedem Starttermin ein und versprich nie einen oeffentlichen Launch, der von einer Freigabe am selben Tag abhaengt.
Wird eine App aus meiner Website abgelehnt?+
Eine duenne Huelle, die nur deine Website ohne Zusatzfunktionen laedt, ist ein haeufiger Ablehnungsgrund nach Apples Minimum-Functionality-Regel und Googles Aequivalent. Eine echte native App, die deine Live-Website in einer nativen Huelle laedt und echte Geraetefunktionen ergaenzt (Push, Offline, Biometrie, Widgets), ist genau das, wonach Pruefer suchen, und besteht deshalb.
Brauche ich eigene Entwicklerkonten bei Apple und Google?+
Ja. Das Apple Developer Program kostet 99 USD pro Jahr, ein Google-Play-Konto ist eine einmalige Gebuehr von 25 USD. Die Veroeffentlichung unter deinen eigenen Konten haelt die App unter deiner Marke und gibt dir die volle Eigentuemerschaft an Eintrag und kuenftigen Updates.
Was passiert, wenn meine App abgelehnt wird?+
Du erhaeltst den konkreten Grund und die betroffene Richtlinie. Meist behebst du das Problem und reichst erneut ein; viele Ablehnungen sind schnell geloest, sobald die Ursache klar ist. Haelst du eine Ablehnung fuer falsch, bieten beide Stores ein Einspruchs- oder Klaerungsverfahren.
Muss ich bei einer Website-Aktualisierung die App neu einreichen?+
Nein. Bei einer nativen App, die deine Live-Website laedt, erscheinen Inhaltsaenderungen — neue Beitraege, Produkte oder Preise — sofort in der App, ohne erneute Einreichung. Nur native Aenderungen, etwa eine neue Geraetefunktion, erfordern einen neuen Build und eine erneute Pruefung.