Zum Inhalt springen
WebViewGold Vibe Coding in den App Store
Deutsch
WebViewGold holen

Hilfe bei Ablehnung

GitHub Copilot-App abgelehnt? So behebst du es und bekommst die Genehmigung

Eine Ablehnung ist kein Urteil über GitHub Copilot oder über dich. Reviewer lehnen aus einer kleinen Zahl konkreter Gründe ab, und fast alle lassen sich an einem Nachmittag beheben. Diese Seite führt dich durch die Triage, die Lösungen für GitHub Copilot-Apps und die Antwort, die das Review wieder in Gang bringt.

Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.

  • Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
  • Kein Programmieren nötig
  • Einmalzahlung, kostenlose Updates
  • 24/7 Support von echten Menschen
  • Made in Germany seit 2014 · ISO 27001

Zuerst: Lies die Ablehnung wie ein Reviewer

Zehn Minuten Triage sparen Tage des Ratens.

  1. Finde die Nummer der Guideline

    Apple nennt die Guideline (zum Beispiel 4.2, 2.1, 5.1.1) im Resolution Center; Google nennt die Richtlinie (zum Beispiel Mindestfunktionalität, Nutzerdaten) auf der Seite zum Richtlinienstatus. Die Nummer sagt dir, ob die Lösung in deiner Web-App, in den WebViewGold-Einstellungen oder im Store-Eintrag liegt.

  2. Ordne sie deinem GitHub Copilot-Projekt zu

    Die meisten Ablehnungen von GitHub Copilot-Apps fallen in fünf Kategorien: nicht App-artig genug (4.2 / Mindestfunktionalität), etwas hat nicht geladen (2.1 / defekte Funktionalität), Datenschutz-Formalitäten (5.1.1 / Datensicherheit, Kontolöschung), Login-Regeln (4.8 Sign in with Apple, blockierter Google-Login) und Zahlungen (3.1.1 / Play Billing).

  3. Reproduziere, was der Reviewer gesehen hat

    Öffne die GitHub Copilot-App im Flugmodus, auf einem iPad, mit einem frischen Konto, mit dem Demo-Login, den du ihnen gegeben hast. Lass den kostenlosen Readiness-Check über deine URL laufen. Häng Screenshots von dem an, was sie angehängt haben.

  4. Beheben, dann antworten, dann neu einreichen

    Ändere die Web-App (sofort wirksam) oder die native Einstellung (neuer Build), schreib eine kurze sachliche Antwort, die benennt, was sich geändert hat, und reiche den neuen Build ein. Zweite Reviews sind meist schneller als das erste.

App Store-Guidelines, die GitHub Copilot-Apps treffen

Apple prüft das Verhalten der App, nicht das Tool, mit dem sie gebaut wurde. Das sind die Guidelines hinter den meisten Ablehnungen von GitHub Copilot-Apps, jeweils mit der Lösung.

  • 4.2

    Mindestfunktionalität

    Die App muss mehr bieten als eine neu verpackte Website. Responsives Layout, native Navigation und mindestens eine native Fähigkeit (Push-Benachrichtigungen, Offline-Screen, natives Teilen, biometrischer Login) machen den Unterschied. WebViewGold schaltet diese mit je einer Einstellung ein.

  • 2.1

    Vollständigkeit der App

    Keine Platzhalterinhalte, keine toten Links, keine Abstürze. Liegen Inhalte hinter einem Login, hinterlege ein Demo-Konto in den App-Review-Notizen.

  • 5.1.1

    Datenschutz

    Eine öffentliche URL zur Datenschutzerklärung ist Pflicht. Apps, in denen Nutzer Konten anlegen können, müssen auch das Löschen des Kontos in der App ermöglichen.

  • 4.8

    Anmeldedienste

    Wenn die App für das Nutzerkonto einen Login über Google, Facebook oder einen anderen Drittanbieter- oder Social-Login-Dienst nutzt, muss sie auch einen gleichwertigen Login anbieten, der nur Name und E-Mail-Adresse erhebt, Nutzern erlaubt, ihre E-Mail-Adresse zu verbergen, und sie nicht für Werbung trackt. Sign in with Apple ist der sichere Weg, das zu erfüllen. Eine App, die nur ihren eigenen Login mit E-Mail und Passwort nutzt, ist nicht betroffen.

  • 3.1.1

    In-App-Kauf

    Digitale Güter und Abos, die in der App verkauft werden, müssen Apples In-App-Kauf nutzen. Physische Güter und Dienstleistungen in der realen Welt dürfen bei Stripe oder PayPal bleiben.

  • 2.3

    Korrekte Metadaten

    Screenshots, Beschreibung und App-Name müssen zu dem passen, was die App tut. Erwähne im Eintrag keine anderen Plattformen und kein „Beta“.

Google Play-Richtlinien, die GitHub Copilot-Apps treffen

Googles Review ist stärker automatisiert und stärker von Formularen getrieben. Die Richtlinien unten decken die meisten Ablehnungen von GitHub Copilot-Apps ab.

  • Mindestfunktionalität

    Richtlinie zu Spam und Mindestfunktionalität

    Google lehnt Apps ab, die nur eine Website ohne Erlaubnis des Website-Betreibers verpacken oder keine echte Funktionalität bieten. Dein eigenes Produkt mit zusätzlichen nativen Features zu verpacken ist in Ordnung.

  • Datensicherheit

    Richtlinie zu Nutzerdaten

    Jede App braucht eine URL zur Datenschutzerklärung und ein ausgefülltes Formular zur Datensicherheit, das auflistet, was die App und ihre SDKs erheben.

  • Kontolöschung

    Richtlinie zu Nutzerdaten

    Apps, in denen Nutzer Konten anlegen können, müssen die Kontolöschung in der App und über einen Web-Link anbieten, den du in der Play Console hinterlegst.

  • Testpflicht

    Persönliche Entwicklerkonten

    Persönliche Konten, die nach November 2023 erstellt wurden, müssen einen geschlossenen Test mit mindestens 12 Testern über 14 zusammenhängende Tage durchführen, bevor sie Produktionszugang beantragen können.

  • Ziel-API-Level

    Anforderungen an das Ziel-API-Level

    Neue Apps müssen auf eine aktuelle Android-Version abzielen. WebViewGold-Updates halten das Template aktuell; baue einfach mit der neuesten Version.

  • Zahlungen

    Google Play Billing

    Digitale Güter und Abos, die in der App verkauft werden, müssen in der Regel Google Play Billing nutzen (WebViewGold unterstützt RevenueCat). Physische Güter und Dienstleistungen dürfen andere Zahlungsmethoden nutzen.

Mit einer gut optimierten Version Ihrer Web-App können Sie innerhalb von wenigen Minuten eine beeindruckende mobile App erstellen. Zusätzlich dazu ist der Kundenservice sehr nett und hilfsbereit! Ich kann WebViewGold nur empfehlen :-)

Julian Koch · Mitbegründer von DuelDonkey · CodeCanyon

Was bei GitHub Copilot-Projekten besonders ist

Weil GitHub Copilot-Apps meist auf Jeder Web-Stack in deinem GitHub-Repository: Next.js, React + Vite, Astro, Vue, Rails, Django oder ASP.NET laufen, mit Was auch immer du gebaut hast: Auth.js, Clerk, Supabase, Firebase oder Sign in with GitHub und Stripe, sind das die Punkte, die uns im Support bei GitHub Copilot-Ablehnungen begegnen.

  • GitHub Pages liefert nur statische Dateien aus, und eine Projekt-Site liegt unter /repo-name/. Setze den Basispfad, ergänze für Single-Page-Apps einen 404.html-Fallback (oder Hash-Routing) und nimm am besten eine eigene Domain, sonst enden Deep Links und Neuladen in der App auf einer 404-Seite.
  • Schreib die WebViewGold-Regeln in .github/copilot-instructions.md (oder AGENTS.md), damit Agent Mode und der Cloud-Agent keine „App herunterladen“-Banner, keine Menüs, die nur per Hover am Desktop funktionieren, und keine reinen Browser-APIs mehr einbauen.
  • Prüfe jeden Copilot-Pull-Request in Smartphone-Breite (im Preview-Deployment oder in einem Codespace), bevor du mergst: Horizontaler Überlauf bei 320 px und winzige Tippflächen sind genau das, was eine verpackte App für Reviewer wie eine Website wirken lässt.
  • Wenn die App Sign in with GitHub, Google oder einen anderen Drittanbieter-Login anbietet, erwartet Apple nach Richtlinie 4.8 eine gleichwertige datenschutzfreundliche Option wie Sign in with Apple, die WebViewGold automatisch abwickelt; Google- und Facebook-Logins laufen über den Social Login Helper.

Lass GitHub Copilot die Web-App-Seite reparieren

Füge den Ablehnungstext zusammen mit diesem Prompt in GitHub Copilot ein; es setzt die Änderungen um, die Reviewer typischerweise verlangen.

Issue für den Copilot-Cloud-Agenten (oder Agent Mode)
The app built from this project was rejected by the app store review. Here is the rejection text: [PASTE REJECTION TEXT]. The app runs inside the WebViewGold native WebView wrapper (iOS and Android).
1. Explain in one paragraph which guideline or policy is cited and what the reviewer saw.
2. Apply every fix that belongs in the web app: responsive layout from 320px, 44px tap targets, safe-area padding on fixed bars, /privacy and /terms pages, a Delete account action with confirmation, friendly error and retry states, no external promotional links or "download our app" banners, no placeholder content, a demo account seeded for reviewers.
3. If the fix is native (push notifications, offline screen, Sign in with Apple provider, in-app purchases via RevenueCat), tell me exactly what to enable in the WebViewGold configuration and what to change in the backend.
4. Draft a short, factual reply to the reviewer that lists what changed.

Antwortvorlage für den Reviewer

Kurz, sachlich, konkret. Reviewer lesen davon hunderte am Tag.

Antwort im Resolution Center / Richtlinienstatus
Thank you for the review. We have addressed the points raised:

1. [Guideline/policy number]: [what was wrong] → [what changed, where to find it in the app, e.g. Settings → Delete account].
2. Native functionality: the app provides push notifications for [use case], an offline mode with retry, and [Face ID login / native sharing / QR scanning], none of which are available on the website.
3. Demo account: [email] / [password]. The main features are reachable from the home screen after login.

A new build ([version]) with these changes has been uploaded. Please let us know if anything else is needed.

Häufig gestellte Fragen

Lehnen Apple oder Google Apps ab, weil sie mit GitHub Copilot gebaut wurden?

Nein. Kein Store sieht den Builder oder interessiert sich dafür. Ablehnungen drehen sich um Verhalten (App-artige UI, native Features), Vollständigkeit, Datenschutz-Formalitäten, Login-Regeln und Zahlungen. Bring das in Ordnung, und die GitHub Copilot-Herkunft spielt keine Rolle.

Wie oft kann ich neu einreichen?

So oft wie nötig. Jede Einreichung wird erneut geprüft, meist schneller als die erste. Das Einzige, was Reviewer nervt, sind wiederholte identische Einreichungen ohne Änderungen.

Soll ich antworten oder einfach neu einreichen?

Beides: Antworte mit einer kurzen Liste dessen, was sich geändert hat (oder, höflich, was der Reviewer übersehen hat), und reiche dann den neuen Build ein. Eine Antwort ohne neuen Build ändert selten etwas am Ergebnis, es sei denn, die Ablehnung war ein Missverständnis.

Drei Wege, deine App in die Stores zu bringen

Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.

Selbst machen

$109 pro Plattform, einmalig

Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.

Pakete auf der Hauptseite ansehen

Full Service

$698 pro Plattform $798

Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.

Full-Service-Details Powered by WeSetupYourWebViewApp

Winter-Sale-Preise gültig bis 31. Dezember 2026.

Bereit, deine GitHub Copilot-App zu veröffentlichen?

App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen

Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.

Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.