Web-App auf Google Play veröffentlichen (2026)

Warum ein Google-Play-Eintrag für ein SaaS zählt

Ein Browser-Tab konkurriert mit allen anderen offenen Tabs. Eine installierte App hat ihr eigenes Icon auf dem Homescreen, direkt vor den Augen der Nutzer, jedes Mal wenn sie ihr Handy entsperren. Für ein SaaS, das man täglich öffnet, ist das kein kosmetischer Unterschied: Er zeigt sich in der Bindung der Nutzer.

Was der Play Store tatsächlich prüft

Die automatisierte Überprüfung von Google Play für Web-App-Pakete prüft vier Dinge:

• Ziel-API-Level — muss seit dem 31. August 2026 für alle neuen Apps und Updates 36 (Android 16) sein.
• Mindestfunktionalität — nach den Regeln von Google zu Spam und Mindestfunktionalität muss die App etwas Nützliches tun. Eine statische einseitige Seite scheitert; eine mehrseitige App, ein SaaS-Dashboard oder eine Content-Plattform besteht.
• Datensicherheitsformular — Sie müssen erklären, welche Daten Ihre App sammelt. Erforderlich für jede App.
• Gültige Signatur — das .aab muss mit einem Keystore signiert sein. Derselbe Keystore muss für jedes zukünftige Update dieses Package-Namens verwendet werden.

TWA vs Capacitor: den richtigen Build für Ihre Web-App wählen

Die Build-Methode beeinflusst App-Größe, PWA-Feature-Zugang und Play Store-Kompatibilität. Beide erzeugen ein gültiges .aab — der Unterschied liegt in der Laufzeit.

Schritt für Schritt: von der Web-App-URL zum Play Store

1. 1. PWA-Check durchführen

   Fügen Sie Ihre URL in einen kostenlosen PWA-Checker ein. Das zeigt Ihren Manifest-Score, ob Sie einen Service Worker haben, und ob TWA oder Capacitor der richtige Build-Pfad ist. Dauert 10 Sekunden.

2. 2. App-Identität konfigurieren

   Einen Package-Namen im umgekehrten Domain-Format festlegen (com.ihrfirma.appname). Das ist permanent — es identifiziert Ihre App im Play Store für immer.

3. 3. Das signierte .aab erstellen

   Ein kostenpflichtiger SaasToStore-Build generiert das signierte Android App Bundle. Ihr Keystore entsteht beim ersten kostenpflichtigen Build, wird verschlüsselt verwahrt und für jedes Update wiederverwendet; sein Passwort erhalten Sie einmal per E-Mail. Der Build zielt automatisch auf API Level 36 (Android 16) ab und dauert wenige Minuten.

4. 4. Play Console-Konto erstellen

   Registrieren Sie sich auf play.google.com/console und zahlen Sie die einmalige 25$-Entwicklergebühr. Die Identitätsverifizierung dauert in der Regel 1 bis 2 Tage.

5. 5. Neue App erstellen und hochladen

   In der Play Console neue App erstellen → Production Track → .aab hochladen. Pflichtabschnitte ausfüllen: App-Inhalt, Zielgruppe, Datensicherheitserklärung, Inhaltsklassifizierungsfragebogen, Datenschutzrichtlinien-URL. Dann zur Überprüfung einreichen.

Den Store-Eintrag vorbereiten und Ablehnungen vermeiden

Vor dem Einreichen muss der Google-Play-Eintrag vollständig sein. Das wird verlangt. SaasToStore kann Icon, Feature-Grafik, Screenshots und einen ersten Entwurf der Beschreibungen für Sie erzeugen.

Die vier Fehler, die eine erste Veröffentlichung am häufigsten aufhalten:

Was die Veröffentlichung kostet

Bei Google kostet die Entwickler-Registrierung aus Schritt 4 einmalig 25$ und gilt für alle Apps, die Sie über dieses Konto veröffentlichen. Der andere Kostenpunkt ist das signierte Bundle selbst. Von Hand sind die Werkzeuge kostenlos: Googles Bubblewrap-CLI für eine TWA, die Capacitor-CLI für eine native Hülle. Sie zahlen mit Zeit: Android-SDK und Java installieren und pflegen, fehlschlagende Builds debuggen, einen Signaturschlüssel aufbewahren, den Sie nie verlieren dürfen. Ein gehosteter Builder übernimmt all das und verwahrt den Schlüssel für jedes Update.

Bei SaasToStore ist der kostenlose Test-Build eine APK mit dem SaasToStore-Logo, damit Sie die App auf Ihrem eigenen Handy sehen. Das .aab für Google Play gibt es mit einem kostenpflichtigen Build: siehe Preise.

SaaS-Besonderheiten: Anmeldung und Push-Benachrichtigungen

Anmeldung: meist nichts zu ändern

Ihre bestehende Authentifizierung (Supabase, Auth0, Clerk, eigene Sessions) funktioniert in der App weiter. E-Mail und Passwort oder Einmalcodes verhalten sich wie auf Ihrer Website; Magic Links ebenfalls, sobald Deep Links sie in die App leiten. In einer TWA teilt die App die Cookies von Chrome: Wer auf diesem Handy schon in Chrome angemeldet ist, ist es in der App oft auch. Ein nativer Capacitor-Build hat seine eigene Session: Die Nutzer melden sich einmal in der App an. Die Ausnahme ist Google: Google lässt seine Anmeldung nicht in einer eingebetteten WebView zu. Die native App öffnet „Mit Google anmelden“ deshalb im System-Browser und bringt die Nutzer danach zurück. Dafür muss bei Ihrem Authentifizierungsanbieter eine Adresse freigegeben werden.

Push-Benachrichtigungen für die Bindung

Push ist der wichtigste Hebel für die Nutzerbindung, den eine Store-App einem SaaS gibt. Diese Nachrichten wirken am besten:

• — Testphase endet in 3 Tagen, mit einem Link zum Upgrade
• — Neue Aktivität bei etwas, dem der Nutzer folgt: ein Kommentar, eine Erwähnung, ein Update
• — Eine wöchentliche Zusammenfassung oder ein erreichter Nutzungsmeilenstein
• — Eine neue Funktion, an aktive Nutzer gesendet
• — Eine Erinnerung nach 7 Tagen ohne Besuch

Im nativen Build kommen die Benachrichtigungen von der App selbst: Die Browser-Benachrichtigungen Ihrer Website gelangen nicht in die App.

Über Google Play hinaus

Dieselbe Build-Sitzung, die Ihr Google Play AAB erzeugt, kann auch ein Windows .msi, macOS .dmg und Linux .AppImage generieren — veröffentlicht auf dem Microsoft Store, dem Snap Store, Flathub und GitHub Releases. Wenn Sie Ihre Web-App einmal verpacken, gibt es keine Grenzkosten für das Erreichen aller 7 Stores im gleichen Build.

Unter Android geht dieselbe App auch in den Amazon Appstore und den Samsung Galaxy Store, und aus derselben URL wird eine iPhone-App für den App Store. Ihre Website ist mit einem No-Code-Tool gebaut? Lesen Sie die Anleitungen für Lovable, Bubble und Webflow.