Eine Codebasis, echte Store-App
Die Android-App lädt deine veröffentlichte GitHub Copilot-URL in einer nativen WebView. Es gibt kein zweites Projekt zu pflegen und keinen Code-Export.
Warum Wrappen für GitHub Copilot-Apps besser ist als Neubauen
Copilot lebt in deinem Repository: Issues, Pull Requests, Actions und der Host, der main deployt. WebViewGold passt in diesen Kreislauf, weil die native App die URL lädt, auf die dein main-Branch deployt wird; ein gemergter Copilot-Pull-Request aktualisiert die installierte App also ohne Store-Release. Ein separates Swift- und Kotlin-Projekt würde dem Agenten zwei weitere Codebasen aufbürden, die synchron bleiben müssen, während Copilot über die JavaScript-Bridge Push, Haptik, Teilen oder biometrischen Login in genau dem Code ergänzt, den er schon kennt.
Weiter aus GitHub Copilot veröffentlichen
Merge in main, das Deployment läuft und die App zeigt die Änderung beim nächsten Start. Nur Änderungen an der nativen Hülle selbst (Icon, neues natives Feature) brauchen ein Store-Update.
Native Features obendrauf
Push-Benachrichtigungen, Offline-Screen, natives Teilen, biometrischer Login, QR-Scanner, In-App-Käufe und Deep Links sind einzelne Einstellungen oder einzeilige JavaScript-Aufrufe.
Google Play-Genehmigungsgarantie
Google Play Store Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen. 96.4% aller WebViewGold-Apps werden von den Review-Teams beim ersten Versuch genehmigt.
Was du brauchst
- Eine veröffentlichte GitHub Copilot-App unter einer öffentlichen HTTPS-URL (username.github.io/repo oder yourproject.vercel.app oder, besser, deine eigene Domain)
- Zugang zum Google Play Console-Entwicklerkonto ($25 einmalig) für die Einreichung im Google Play Store
- Android Studio auf Windows, macOS oder Linux – oder der WebViewGold Cloud Builder in deinem Browser
- WebViewGold für Android ($109 einmalig, kostenlose Updates)
- Eine Seite mit Datenschutzerklärung, ein Icon mit 1024 × 1024 px und 30 bis 60 Minuten Zeit
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
GitHub Copilot → Google Play: die Schritt-für-Schritt-Anleitung
Acht Schritte, kein Code. Die meisten schaffen den nativen Teil in unter einer Stunde.
Veröffentliche deine GitHub Copilot-App unter einer Produktions-URL
Merge den Pull Request in deinen main-Branch und lass deinen Host deployen: Vercel, Netlify oder Azure Static Web Apps bauen jeden Push, oder ein GitHub-Actions-Workflow veröffentlicht einen statischen Build auf GitHub Pages. Trage die Produktions-URL oder deine Domain in WebViewGold ein. Weitergeleitete Ports aus Codespaces (app.github.dev), Preview-Deployments von Pull Requests und localhost sind nur vorübergehend da. Verwende das Produktions-Deployment deines main-Branches. Eigene Domain: Füge die Domain in den Pages-Einstellungen des Repositorys (oder in den Domain-Einstellungen deines Hosts) hinzu, setze die DNS-Einträge und aktiviere Enforce HTTPS. Siehe warum sich eine eigene Domain vor der Einreichung lohnt.
Mach sie bereit für den Store
Füge eine Seite mit Datenschutzerklärung und eine Option zur Kontolöschung hinzu (wenn sich Nutzer registrieren können) und entferne Builder-Badges oder „Lade unsere App herunter“-Banner. Lass den kostenlosen Google Play Readiness-Check über deine URL laufen: Er markiert in Sekunden Mixed Content, fehlende Viewport-Tags, Builder-Vorschaudomains und andere Blocker.
Hol dir WebViewGold für Android
Einmalzahlung, kostenlose Updates. Du erhältst das fertige Android-Studio-Projekt, oder du aktivierst den WebViewGold Cloud Builder und sparst dir die IDE komplett.
Füge deine URL ein und brande die App
Öffne Config.java (oder das Cloud-Builder-Formular), füge deine veröffentlichte URL ein, setze den App-Namen, wähle deinen Paketnamen, lade das Icon hoch und wähle den Splash Screen. Kein Code nötig.
Schalte native Features ein
Aktiviere Push-Benachrichtigungen, den Offline-Screen, Pull-to-Refresh, biometrischen Login, den QR-Scanner oder App Links mit einzelnen Einstellungen. Alles ist optional.
Baue das signierte App Bundle
In Android Studio: Build → Generate Signed Bundle. Im Cloud Builder: auf Build klicken, das signierte .aab wird für dich erstellt und hochgeladen.
Lege den Play Console-Eintrag an
Erstelle die App in der Play Console, fülle den Store-Eintrag aus, lade Icon, Feature-Grafik und Screenshots hoch und vervollständige Datensicherheit, Inhaltseinstufung und App-Zugriff.
Testen, dann einreichen
Neue persönliche Konten führen zuerst einen 14-tägigen geschlossenen Test mit 12 Testern durch. Danach das Release auf Produktion heben und zum Review einreichen. Unsere Genehmigungsgarantie sichert dich ab.
GitHub Copilot-spezifische Checks vor der Einreichung
Das sind die Punkte, die bei GitHub Copilot-Projekten (Jeder Web-Stack in deinem GitHub-Repository: Next.js, React + Vite, Astro, Vue, Rails, Django oder ASP.NET) am häufigsten auftauchen.
- 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 Store-Vorbereitung erledigen
Füge das in GitHub Copilot ein und lass es die Änderungen umsetzen, auf die Reviewer achten. Prüfe das Ergebnis, dann veröffentliche.
Issue für den Copilot-Cloud-Agenten (oder Agent Mode)
Titel: Web-App für App Store und Google Play vorbereiten (WebViewGold-Wrapper) Diese App wird als native iOS- und Android-App veröffentlicht, die die Produktions-URL im WebView-Wrapper WebViewGold lädt. Füge kein Capacitor, kein React Native und keine nativen SDKs hinzu; native Funktionen kommen über die JavaScript-Bridge von WebViewGold, dokumentiert unter https://www.webviewgold.com/llms-full.txt. Öffne einen einzigen Pull Request, der diese Akzeptanzkriterien erfüllt: - [ ] Meta-Viewport-Tag, kein horizontaler Überlauf zwischen 320px und 1024px, Tippflächen von 44px, safe-area-inset-Padding an fixierten Headern und Footern - [ ] Seiten /privacy und /terms, im Footer verlinkt - [ ] Eine Aktion "Konto löschen" in den Einstellungen, die nach einer Bestätigung die Daten und den Auth-Eintrag des Nutzers entfernt - [ ] Keine "App herunterladen"-Banner und keine externen Werbelinks in der Hauptnavigation - [ ] Fehlerzustände mit "Erneut versuchen" für fehlgeschlagene Anfragen; keine Platzhalterinhalte - [ ] Single-Page-Routen funktionieren beim Neuladen und über Deep Links (404-Fallback, falls die Site auf GitHub Pages liegt) - [ ] Ein Abschnitt "Nativer App-Wrapper" mit diesen Regeln in .github/copilot-instructions.md Wenn du die App ausführen kannst, füge der Beschreibung des Pull Requests Screenshots der wichtigsten Screens in Smartphone-Breite hinzu.
Google Play-Review: die Regeln, die für GitHub Copilot-Apps zählen
Google prüft Verhalten, nicht Werkzeuge. Niemand wird abgelehnt, weil er GitHub Copilot benutzt; Apps werden wegen der Punkte unten abgelehnt.
- 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.
Native Features, die deine GitHub Copilot-App in der Android-App bekommt
Jedes Feature ist optional und Schritt für Schritt in der Dokumentation zu WebViewGold für Android dokumentiert.
Push-Benachrichtigungen
Remote-Push über OneSignal oder Pushwoosh, lokal geplante Pushes über einen JavaScript-Aufruf.
DokumentationApp Links und Deep Links
https-Links zu deiner Domain und eigene Schemes öffnen sich direkt in der App.
DokumentationIn-App-Käufe
Google Play-Abos und Einmalkäufe über RevenueCat, ausgelöst aus deiner Web-App.
DokumentationOffline-Screen und Fallback
Ein nativer „Erneut versuchen“-Screen, wenn der Nutzer offline ist, oder ein lokaler HTML-Fallback.
DokumentationSplash Screen und Ladeanzeige
Minimale und maximale Splash-Dauer mit Ausblenden, oder ein nativer Spinner während des Ladens.
DokumentationBiometrischer Login
Fingerabdruck- / Gesichtsentsperrung über einen JavaScript-Aufruf.
DokumentationQR- und Barcode-Scanner
Nativer Scanner, der das Ergebnis an deine Web-App zurückgibt.
DokumentationNatives Teilen und Haptik
Share Intent und haptisches Feedback aus deiner Web-App.
DokumentationEigenes CSS und JavaScript
Website-only-Elemente ausblenden und Code injizieren, wenn die Seite in der App geladen wird.
DokumentationDatei- und Kamera-Uploads
Nativer Dateiauswahl-Dialog und Kamera für deine Upload-Formulare.
DokumentationCheckliste vor der Google Play-Einreichung
Hak diese Punkte ab, dann ist das Review nur noch Formsache. Die technische Hälfte prüfst du automatisch mit dem kostenlosen Readiness-Check.
- Überall HTTPS: Android blockiert unverschlüsselten http://-Traffic auf aktuellen Versionen standardmäßig.
- Responsives Layout von 320 px bis zu Tablet-Breiten, mit vorhersehbarem Verhalten der Zurück-Taste (WebViewGold bildet die Zurück-Taste auf den Web-Verlauf ab).
- URL zur Datenschutzerklärung bereit und das Formular zur Datensicherheit wahrheitsgemäß ausgefüllt.
- Kontolöschung in der App plus ein Web-Link zur Löschung, wenn sich Nutzer registrieren können.
- Zugangsdaten für den Reviewer, wenn Inhalte hinter einem Login liegen.
- Ein eindeutiger Paketname (zum Beispiel com.yourcompany.yourapp), festgelegt vor dem ersten Upload: Er lässt sich danach nie mehr ändern.
- Ein Icon mit 512 × 512 px und eine Feature-Grafik mit 1024 × 500 px.
- Mindestens zwei Smartphone-Screenshots aus der echten App (Tablet-Screenshots empfohlen).
- Für neue persönliche Konten: 12 Tester für den 14-tägigen geschlossenen Test organisiert.
- Signiertes Android App Bundle (.aab), gebaut mit der neuesten WebViewGold-Version.
Beispiel: vom GitHub Copilot-Projekt zur freigegebenen App
Angenommen, du hast mit Copilot in einem Next.js-Repository einen Schichtplaner für die örtliche Tafel gebaut: Ehrenamtliche sehen offene Schichten, tragen sich mit einem Tippen ein und bekommen am Vortag eine Erinnerung. Du schreibst die Store-Readiness-Checkliste als Issue, weist es dem Copilot-Cloud-Agenten zu, prüfst seinen Pull Request in Smartphone-Breite und mergst. Vercel deployt main auf shifts.yourfoodbank.org, das du mit WebViewGold verpackst, und ein OneSignal-Push sagt den Ehrenamtlichen Bescheid, wenn eine dringende Schicht frei wird. Weil der Login Google anbietet, ergänzt der Agent in einem zweiten Pull Request Sign in with Apple. Das Demo-Konto in den Review-Notizen hat schon zwei Schichten gebucht, beide Stores geben die App frei, und jeder gemergte Pull Request erreicht sie beim nächsten Start.
Deine erste Woche nach dem Launch
- Versieh Store-bezogene Issues mit einem Label (zum Beispiel app-store) und weise sie dem Copilot-Cloud-Agenten zu; prüfe jeden Pull Request in Smartphone-Breite, bevor du mergst.
- Schütze main mit einem verpflichtenden Status-Check, der die App baut, denn ein kaputter Merge landet direkt in jeder installierten Kopie.
- Halte .github/copilot-instructions.md mit den Bridge-Aufrufen von WebViewGold synchron, die du nutzt, damit der Agent sie beim Refactoring nicht entfernt.
- Lies nach dem Login mit getonesignalplayerid:// die OneSignal-Player-ID aus und speichere sie beim Nutzer, damit ein Push an eine einzelne Person gehen kann statt an alle.
- Bitte mit rateapp:// um eine Bewertung, nachdem jemand seine erste Schicht absolviert hat.
Das bekommst du mit WebViewGold
Ein komplettes natives App-Projekt statt eines Abos. Alles hier ist in der Lizenz enthalten und wird per Einstellung aktiviert.
- Komplettes Android-Studio-Projekt
- Push-Benachrichtigungen
- Offline-Bildschirm
- App-Icon & Splashscreen
- Teilen-Dialog & Haptik
- Deep Links & Universal Links
- In-App-Käufe
- Kostenlose Updates, White-Label
Häufig gestellte Fragen
Wie veröffentliche ich eine mit GitHub Copilot gebaute Web-App im App Store?
Deploye den main-Branch auf eine öffentliche HTTPS-URL (Vercel, Netlify, Azure Static Web Apps oder GitHub Pages), trage diese URL in WebViewGold für iOS ein, baue mit Xcode oder dem Cloud Builder und reiche über App Store Connect ein. Dieselbe URL treibt die Android-App an.
Kann der Copilot-Cloud-Agent meine App fürs Review vorbereiten?
Ja. Weise ihm ein Issue mit der Store-Readiness-Checkliste zu, prüfe den Pull Request, den er öffnet, in Smartphone-Breite und merge ihn. Weil die Store-App dein Deployment lädt, erreichen die gemergten Änderungen die installierten Apps ohne neue Store-Version.
Reicht GitHub Pages für eine Store-App?
Für eine statische oder clientseitig gerenderte App ja, mit eigener Domain, erzwungenem HTTPS und einem Fallback für Single-Page-Routen. Braucht die App Server-Code, API-Routen oder Geheimnisse, deploye sie stattdessen auf Vercel, Netlify oder Azure.
Brauche ich Android Studio?
Entweder Android Studio (kostenlos, läuft auf Windows, macOS und Linux) oder den WebViewGold Cloud Builder, der das signierte App Bundle aus deinem Browser heraus baut und hochlädt.
Was ist die 12-Tester-Regel?
Google verlangt von persönlichen Entwicklerkonten, die nach November 2023 erstellt wurden, einen geschlossenen Test mit mindestens 12 angemeldeten Testern über 14 zusammenhängende Tage vor dem ersten Produktions-Release. Freunde, Kollegen oder eine Discord-Community reichen; Organisationskonten sind ausgenommen.
Was, wenn Google die App ablehnt?
Google nennt die betroffene Richtlinie, und du kannst nachbessern und neu einreichen. WebViewGold kommt mit einer Google Play Genehmigungsgarantie: Lehnt Google die App aus einem nicht inhaltlichen Grund ab, bekommst du innerhalb von 14 Tagen nach dem Kauf dein Geld zurück.
Kann meine App Sign in with GitHub als einzigen Login verwenden?
Nur wenn die App ein Client für GitHub selbst ist, zum Beispiel ein Dashboard für die eigenen Repositories des Nutzers, denn Richtlinie 4.8 nimmt Apps aus, in denen sich Nutzer bei einem bestimmten Drittanbieterdienst anmelden müssen, um dort an ihre Inhalte zu kommen. Ergänze bei jedem anderen Produkt neben dem GitHub-Button Sign in with Apple oder einen anderen Login, der die Datenschutzbedingungen der Richtlinie erfüllt. Google Play hat keine solche Regel, der Abschnitt „App-Zugriff“ braucht aber trotzdem Zugangsdaten, mit denen der Reviewer hineinkommt.
Brauche ich eine eigene Domain, wenn die App auf GitHub Pages läuft?
Sehr zu empfehlen. Eine Projektseite liegt unter username.github.io/repo-name/, Dateien, die im Stammverzeichnis der Domain liegen müssen, etwa apple-app-site-association und assetlinks.json für Universal Links und App Links, lassen sich dafür also nicht ausliefern, und ein späterer Umzug der Site würde die URL in deiner App ändern. Mit deiner eigenen Domain, erzwungenem HTTPS und einer 404.html als Fallback für die Routen einer Single-Page-App ist GitHub Pages ein guter Host für eine statische Store-App.
Muss ich die App jedes Mal neu einreichen, wenn ich etwas in GitHub Copilot ändere?
Nein. Die App lädt deine veröffentlichte URL, also sind Inhalts- und Feature-Änderungen, die du in GitHub Copilot veröffentlichst, sofort in der App live. Eine neue Store-Version ist nur nötig, wenn sich die native Hülle ändert, zum Beispiel bei einem neuen App-Icon oder einem hinzugefügten nativen Feature.
Was kostet das insgesamt?
$109 einmalig für WebViewGold für Android (kostenlose Updates) plus das Google Play Console-Entwicklerkonto ($25 einmalig). Optional: das Cloud-Builder-Add-on ($349 pro Lizenz, einmalig), wenn du ohne Mac im Browser bauen willst, oder das Full-Service-Paket (ab $698 pro Plattform), bei dem unser Team die App für dich konfiguriert, baut und einreicht.
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 ansehenCloud Builder
$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobierenFull 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
Winter-Sale-Preise gültig bis 31. Dezember 2026.