In 11 Schritten eine Web-App in den App Store bringen

Um eine Web-App in den App Store und bei Google Play zu bringen, verpackst du deine Web-App mit Capacitor in ein Native-Projekt, fügst native Features hinzu, erstellst Apple- und Google-Developer-Accounts, signierst und buildest die iOS- und Android-Binaries, testest sie mit echten Nutzern, bereitest die Store-Listings vor und reichst sie zur Review ein. Dein bestehender HTML-, CSS- und JavaScript-Code läuft weiterhin in einer nativen WebView, sodass du die App nicht neu schreiben musst.

Hier sind die 11 Schritte in einer Reihenfolge, die Wartezeiten minimiert – inklusive Capacitor Befehlen und den Store-Regeln, die im Oktober 2026 gelten.

Was du brauchst

• Eine Web-App, die statische Dateien generiert (React, Vue, Angular, Svelte, Next.js static export, Nuxt generate, reines HTML oder eine App von AI-Buildern wie Lovable oder Bolt).
• Node.js 22 oder neuer (Capacitor 8 Anforderung) und Bun oder einen anderen Package Manager.
• Android Studio für Android-Builds.
• Xcode 26 auf macOS für iOS-Builds oder ein Cloud-Build-Service, falls du keinen Mac hast.
• 99 USD pro Jahr für Apple und einmalig 25 USD für Google.

Realistischer Zeitplan

Schritt 1: Heute Developer-Account beantragen

Die Account-Verifizierung lässt sich nicht beschleunigen, erledige sie also vor dem Coding.

• Apple Developer Program: 99 USD pro Jahr. Einzelpersonen benötigen einen Apple Account mit Zwei-Faktor-Authentifizierung und ihrem echten Namen. Organisationen benötigen zudem eine D-U-N-S Nummer, eine Website und eine geschäftliche E-Mail-Adresse dieser Domain.
• Google Play Console: Einmalig 25 USD. Organisationen benötigen eine D-U-N-S Nummer. Rechnet mit einer ID-Verifizierung.

Wenn ihr euch bei Google Play als Einzelperson registriert, gilt die Regel für geschlossene Tests (Schritt 9). Komplette Anleitung: so erstellt ihr Apple und Google Play Developer Accounts.

Schritt 2: Web-App für das Smartphone vorbereiten

Capacitor führt deine App in einer WebView aus. Dinge, die in einem Browser-Tab völlig okay sind, fühlen sich in einer App falsch an:

• Statischer Build-Output. Capacitor lädt Dateien aus dem App-Bundle. Server-Side Rendering läuft nicht auf dem Smartphone. Nutze den statischen Output deines Frameworks (next build mit output: 'export', nuxt generate, Vite build). API API-Aufrufe gehen wie gewohnt über HTTPS an dein Backend.
• Client-seitiges Routing, das auf File-Origin basiert. Nutze History-Routing (Capacitor liefert die App aus https://localhost auf Android und capacitor://localhost auf iOS aus, damit es funktioniert) und stelle sicher, dass Deep URLs auf index.html.
• CORS. Füge die Capacitor Origins zu den erlaubten Origins deines API hinzu: capacitor://localhost (iOS) und https://localhost (Android).
• Touch statt Hover. Entferne Hover-Menüs. Nutze Tap-Targets von mindestens 44 x 44 Points.
• Safe Areas. Füge viewport-fit=cover dem Viewport-Meta-Tag hinzu und polstere Header und Bottom Bars mit env(safe-area-inset-top) und env(safe-area-inset-bottom).
• Offline- und langsame Netzwerke. Zeige einen ordentlichen State statt eines leeren Screens. Reviewer testen mit instabilem WLAN.
• Keine „App herunterladen“-Banner und keine Links, die Nutzer für Kernaufgaben auf deine Website schicken.

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />

Schritt 3: Capacitor hinzufügen

Aus deinem Webprojekt-Root:

bun add @capacitor/core
bun add -d @capacitor/cli
bunx cap init "My App" com.example.myapp --web-dir dist
bun add @capacitor/ios @capacitor/android
bun run build
bunx cap add ios
bunx cap add android

Nutze den echten Output-Ordner für --web-dir: dist für Vite, out für Next.js Static Export, .output/public für Nuxt generate, build für Create React App, dist/<project>/browser für Angular.

Die Bundle ID (com.example.myapp) ist permanent, sobald die App in den Stores ist. Nutze eine Reverse-Domain, die du kontrollierst.

Dein capacitor.config.ts sieht jetzt so aus:

import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.myapp',
  appName: 'My App',
  webDir: 'dist',
};

export default config;

Capacitor erstellt das iOS-Projekt standardmäßig mit dem Swift Package Manager, sodass du CocoaPods nicht benötigst. Jedes Mal, wenn du den Web-code änderst:

bun run build
bunx cap sync

Führe es aus:

bunx cap run ios
bunx cap run android

Commit den ios/ und android/ Ordner. Das sind die code, die du bearbeiten wirst (Berechtigungen, Icons, Signing). Weitere Infos findest du unter wie einfach es ist, eine Web-App mit Capacitor in eine Mobile App zu verwandeln,und falls du ein KI-Tool genutzt hast, ist unser Lovable-zu-Mobile-Guide.

Schritt 4: Native Features hinzufügen, die eine App rechtfertigen

Apples Guideline 4.2 (Minimum Functionality) lehnt Apps ab, die nur eine Website in einem Shell sind. Du brauchst keine dutzenden nativen Features, aber die App muss sich wie eine App verhalten. Gängige, nützliche Ergänzungen:

Beispiel: Zeige das native Share Sheet statt eines „Link kopieren“-Buttons.

import { Share } from '@capacitor/share';
import { Capacitor } from '@capacitor/core';

export async function shareLink(url: string, title: string) {
  if (Capacitor.isNativePlatform()) {
    await Share.share({ title, url });
  } else {
    await navigator.clipboard.writeText(url);
  }
}

Wenn du digitale Inhalte oder Abos verkaufst, plane die Zahlungen jetzt. Apple und Google verlangen für digitale Güter meist ihre eigenen In-App-Kauf-Systeme. Im US App Store dürfen Apps nach dem Gerichtsurteil 2025 eventuell auf externe Web-Checkouts verlinken; andere Regionen haben eigene Regeln. Physische Güter und Dienstleistungen (Lieferungen, Fahrten) können Stripe oder andere Zahlungsanbieter nutzen. Siehe In-App-Käufe mit Capacitor.

Der vollständige Katalog der Capgo Plugins findest du auf der Plugins-Seite.

Schritt 5: Icons, Splash Screen und Permission Strings

Generiere alle Icon- und Splash-Größen aus zwei Quelldateien:

bun add -d @capacitor/assets
# assets/icon.png 1024x1024, assets/splash.png 2732x2732
bunx capacitor-assets generate

Unter iOS benötigt jede genutzte Permission eine Beschreibung in ios/App/App/Info.plist, sonst stürzt die App beim Abfragen ab und Apple lehnt sie ab:

<key>NSCameraUsageDescription</key>
<string>Take a photo of your receipt to attach it to an expense.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Choose receipt photos from your library.</string>

Schreibe spezifische Gründe. „Diese App benötigt die Kamera“ wird abgelehnt.

Unter Android fügen Plugins die meisten Permissions selbst zum Manifest hinzu. Entferne ungenutzte Permissions; Google verlangt für sensible Berechtigungen eine Begründung.

Füge außerdem ein Privacy Manifest (PrivacyInfo.xcprivacy) hinzu, falls dein code required-reason APIs nutzt. Siehe den Privacy Manifest Guide für iOS-Apps.

Schritt 6: Signing einrichten

iOS. Du benötigst ein Apple Distribution Certificate (inklusive Private Key, meist exportiert als .p12) und ein App Store Connect Provisioning Profile für deine Bundle ID. Xcode kann diese automatisch erstellen, oder du machst es selbst, sogar ohne Mac. Lies iOS-Zertifikate und Provisioning Profiles erklärt; der iOS Certificate Generator übernimmt den CSR-Schritt im Browser.

Android. Erstelle einen Upload Keystore und sichere ihn regelmäßig. Google Play nutzt Play App Signing, sodass Google den finalen App Signing Key hält und du Uploads mit deinem Key signierst.

keytool -genkeypair -v -keystore upload-keystore.jks -alias upload \
  -keyalg RSA -keysize 2048 -validity 10000

Oder nutze den Android Keystore Generator.

Schritt 7: Release-Binaries erstellen

Lokal

iOS (auf einem Mac mit Xcode 26, erforderlich für App Store Uploads seit April 2026):

1. bunx cap open ios
2. Wähle das App- Target, setze die Version und Build-Nummer und wähle dein Team unter Signing & Capabilities.
3. Wähle Jedes iOS-Gerät (arm64), dann Product > Archive.
4. Im Organizer: Distribute App > App Store Connect > Upload.

Android:

bun run build
bunx cap sync android
cd android
./gradlew bundleRelease

Die AAB liegt in android/app/build/outputs/bundle/release/. Konfiguriere signingConfigs in android/app/build.gradle mit deinem Keystore und lade Passwörter aus Umgebungsvariablen.

Stelle sicher, targetSdkVersion ist 36. Seit dem 31. August 2026 verlangt Google Play, dass neue Apps und Updates Android 16 (API 36) anvisieren, was der Capacitor 8 Standard ist.

In der Cloud

Wenn du keinen Mac hast oder Builds über CI reproduzierbar machen willst, Capgo Build erstellt Builds für beide Plattformen auf gehosteten Maschinen und kann direkt zu TestFlight und Google Play hochladen:

bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform ios
bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform android
bunx @capgo/cli@latest build request com.example.myapp --platform ios --path .
bunx @capgo/cli@latest build request com.example.myapp --platform android --path .

Credentials werden nur für den Build verwendet und nicht auf den Servern von Capgo gespeichert. Siehe Capgo Build Docs.

Schritt 8: An Tester verteilen

Installiere den Build auf echten Geräten, bevor ihn jemand bei Apple oder Google sieht.

• iOS: zu TestFlight hochladen. Interne Tester (bis zu 100 Teammitglieder) bekommen ihn direkt nach der Verarbeitung; externe Tester (bis zu 10.000) nach einem kurzen Beta App Review.
• Android: erstelle ein internes Testing-Release in der Play Console und teile den Opt-in-Link.

Teste Sign-up und Login, Zahlungen in der Sandbox, Push-Notifications, Offline-Verhalten, die Tastatur, die Eingabefelder verdeckt, und das Back-Button-Verhalten unter Android. Details zu den einzelnen Optionen: so verteilst du iOS- und Android-Apps an Tester.

Schritt 9: Den Closed Test von Google Play durchführen (neue persönliche Accounts)

Wenn dein Play-Konto ein persönliches Konto ist, das nach dem 13. November 2023 erstellt wurde, kannst du nicht in Production veröffentlichen, bevor du einen geschlossenen Test mit mindestens 12 Testern durchgeführt hast, die 14 Tage in Folge angemeldet waren. Danach beantragst du den Production-Zugriff im Play Console Dashboard, was Google meist innerhalb einer Woche prüft.

Starte dies, sobald du einen nutzbaren Android-Build hast. Nutze eine Google Group als Testerliste, damit Leute sich selbst anmelden können. Veröffentliche während der 14 Tage Updates und sammle Feedback, da Google fragt, was du gelernt hast. Organisations-Accounts sind ausgenommen.

Schritt 10: Store-Einträge vorbereiten und einreichen

Für beide Stores brauchst du: App-Name, Beschreibungen, Screenshots in den zulässigen Größen, Icon, URL zur Datenschutzerklärung, Datenschutzangaben (Apple App Privacy und Google Data Safety), Altersfreigabe-Fragebogen, Support-Kontakt und einen Demo-Account, falls die App einen Login hat. Google braucht zusätzlich ein 1024 x 500 Feature Graphic. Specs und Limits: So bereitest du dein App Store- und Google Play-Listing vor.

Einreichen unter iOS: Erstelle in App Store Connect die Version, wähle den TestFlight-Build aus, fülle die App Review Information (Demo-Account, Notizen) aus und klicke auf Zur Prüfung hinzufügen, dann Absenden.

Einreichung auf Android: erstelle ein Production-Release mit der AAB (oder befördere ein getestetes Release aus einem Testing-Track) und fülle alle App-Inhalts- Deklaration abgeben, Länder auswählen und zur Prüfung einreichen.

Die häufigsten Ablehnungsgründe für Web-Apps:

1. 4.2 Mindestfunktionalität: Die App ist nur deine Website. Füge nativen Mehrwert hinzu und entferne Browser-typische UI-Elemente.
2. Login erforderlich, aber kein Demo-Accountvorhanden, oder der Account funktioniert nicht.
3. Keine datenschutzfreundliche Login-Option bei Google- oder Facebook-Login auf iOS. Guideline 4.8 verlangt eine gleichwertige Option zur Datensparsamkeit; Sign in with Apple ist hier der Standard.
4. Keine Account-Löschfunktion innerhalb der App, wenn Nutzer Konten erstellen.
5. Digitale Käufe über Stripe wo In-App-Käufe erforderlich sind.
6. Fehlerhaftes iPad-Layout da das Projekt standardmäßig iPad unterstützt.
7. Fehlende oder unklare Permission-Strings.

Unser Guide für die erste App-Review und iOS App Submission Guide gehen wir im Detail durch.

Schritt 11: Updates ohne Review-Wartezeit ausrollen

Nach dem Launch liegen die meisten Änderungen weiterhin in der Web-code. Statt für jeden Fix einen neuen Store-Build zu erstellen, nutze Live Updates. Der Capgo Updater lädt neue Web-Bundles von Capgo herunter und wendet sie beim nächsten Start an – inklusive automatischem Rollback, falls das neue Bundle nicht startet.

bun add @capgo/capacitor-updater
bunx cap sync
bunx @capgo/cli@latest init

Rufe notifyAppReady() auf, sobald deine App gestartet ist, damit der Updater weiß, dass das Bundle stabil läuft:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

CapacitorUpdater.notifyAppReady();

Jedes Release der Web-code erfolgt dann mit nur einem Befehl:

bun run build
bunx @capgo/cli@latest bundle upload --channel production

Beide Stores erlauben dies für interpretierte code, solange das Update den Hauptzweck der App nicht ändert oder deren Zahlungsregeln umgeht. Native Änderungen (neue Plugins, neue Berechtigungen, Capacitor Upgrades) müssen weiterhin über die Stores laufen. Mehr dazu unter Capgo Live Updates und den Updater-Docs.

Füge das Plugin vor deinem ersten Store-Submission hinzu. Es muss Teil der Binärdatei sein, die die Nutzer installieren, sonst erreicht dein erstes live update die User erst nach einem zweiten Store-Release.

Automatisiere zum Schluss: Build und Upload bei jedem Tag via GitHub Actions oder GitLab CI, und pushe Live Updates bei jedem Merge zu main, und nutze Native Releases nur für native Änderungen.

Pre-Launch-Checkliste

• Apple- und Google-Accounts bereit, Vereinbarungen akzeptiert
• App funktioniert offline oder zeigt klaren Offline-Status
• Safe Areas, Tastatur und Android Back-Button berücksichtigt
• Mindestens einige native Features, die Webseiten nicht bieten
• Icons, Splash, Permission Strings, Privacy Manifest
• Distribution Certificate, App Store Profil, Keystore gesichert
• Target SDK 36 auf Android, Xcode 26 auf iOS
• TestFlight und Play Internal Testing auf echten Geräten
• Google Play Closed Test abgeschlossen (Privatkonten)
• Listings in beiden Stores abgeschlossen, Demo-Account hinzugefügt
• Account-Löschung in der App bei Registrierung möglich
• Live Update Plugin im ersten Binary enthalten

Fehlerbehebung

Weißer Bildschirm beim Start. webDir zeigt auf den falschen Ordner oder du hast vergessen, bunx cap sync nach dem Build. Prüfe, ios/App/App/public und android/app/src/main/assets/public enthalten index.html.

API Aufrufe schlagen nur in der App fehl. CORS: Erlaube capacitor://localhost und https://localhostStelle außerdem sicher, dass du nicht aufrufst http:// URLs aufrufst, die iOS standardmäßig blockiert.

404-Fehler bei Refresh oder Deep Links. Verwende einen Router mit Fallback auf index.html, oder Hash-Routing für ältere Setups.

Xcode-Signing-Fehler. Die Fehlerliste findest du in iOS-Zertifikate und Provisioning Profiles erklärt.

Gradle-Build schlägt nach Upgrade fehl. Capacitor 8 benötigt Android Studio Otter (2025.2.1) oder neuer sowie JDK 21, wie in der Capacitor 8 Upgrade-Guideangegeben. Bei anderen Gradle-Fehlern siehe wie man Android-Build-Fehler in Capacitor behebt.

Google Play Upload für Ziel SDK abgelehnt. Setze targetSdkVersion = 36 von android/variables.gradle.