11 Schritte, um eine Web-App auf dem App Store zu platzieren

Um eine Web-App auf dem App Store und Google Play zu veröffentlichen, müssen Sie Ihre Web-App in eine native Projektumgebung einbetten, Capacitor hinzufügen, einige native Funktionen hinzufügen, Apple- und Google-Entwicklerkonten erstellen, die iOS- und Android-Binärdateien signieren und bauen, sie mit echten Benutzern testen, die Store-Listen vorbereiten und zur Überprüfung einreichen. Ihre bestehende HTML, CSS und JavaScript-Code bleibt innerhalb einer native WebView laufen, sodass Sie den App-Code nicht neu schreiben müssen.

Die folgenden 11 Schritte in der Reihenfolge, die Wartezeiten minimiert, mit Befehlen für Capacitor 8 und den Store-Regeln, die im Oktober 2026 gelten.

Was Sie benötigen

• Eine Web-App, die sich als statische Dateien baut (React, Vue, Angular, Svelte, Next.js statische Export, Nuxt generieren, einfaches HTML oder eine App, die mit einem AI-Bauwerkzeug wie Lovable oder Bolt erstellt wurde).
• Node.js 22 oder später (Capacitor 8-Anforderung) und Bun oder ein anderes Paketmanager.
• Android Studio für Android-Builds.
• Xcode 26 auf macOS für iOS-Builds oder ein Cloud-Build-Service, wenn Sie keinen Mac haben.
• 99 USD pro Jahr für Apple und 25 USD einmal für Google.

Realistischer Zeitplan

Schritt 1: Erstelle heute dein Entwicklerkonto

Kontoüberprüfung ist der Schritt, den du nicht beschleunigen kannst, also mach ihn vor dem Coding.

• Apple-Entwickler-Programm: 99 USD pro Jahr. Einzelne Personen benötigen einen Apple-Konto mit Zwei-Faktor-Authentifizierung und ihrem bürgerlichen Namen. Organisationen benötigen auch eine D-U-N-S-Nummer, eine Unternehmenswebsite und eine E-Mail-Adresse auf dieser Domain.
• Google Play Console: 25 USD einmal. Organisationen benötigen eine D-U-N-S-Nummer. Warten Sie auf die ID-Verifizierung.

Wenn Sie sich bei Google Play als Einzelperson anmelden, ist Ihr Konto dem geschlossenen Testregelwerk (Schritt 9) unterworfen. Vollständiger Leitfaden: Erstellen Sie Apple- und Google Play-Entwicklerkonten.

Schritt 2: Bereiten Sie die Web-App auf ein Smartphone vor

Capacitor läuft Ihre App in einem WebView. Dinge, die in einem Browserfenster in Ordnung sind, fühlen sich in einer App falsch an:

• Static build output. Capacitor lädt Dateien aus der App-Bundle. Die Serverseitige Rendernung läuft nicht auf dem Telefon. Verwenden Sie stattdessen die statische Ausgabe Ihres Frameworks ("next build with output: 'export', nuxt generate, Vite build. API Anfragen gehen wie zuvor über HTTPS.
• Client-seitige Routierung, die aus einem Datei-Origin funktioniert. Verwenden Sie die Geschichte-Routierung (Capacitor dient dem App von) https://localhost auf Android und capacitor://localhost auf iOS, so dass sie funktioniert) und stellen sicher, dass tiefe URLs auf index.html.
• CORS. Fügen Sie die Capacitor-Origins zu den zulässigen Ursprüngen Ihrer API hinzu: capacitor://localhost (iOS) und https://localhost (Android).
• Berühren, nicht überfahren. Remove hover-only menus. Make tap targets at least 44 x 44 points.
• Sichere Bereiche. Fügen Sie viewport-fit=cover zum Viewport-Meta-Tags und füllen Sie Kopf- und Fußleisten auf env(safe-area-inset-top) und env(safe-area-inset-bottom).
• Offline und langsamem Netzwerk Zeigen Sie einen richtigen Zustand an, anstatt eine leere Seite. Rezensenten testen auf fluktuierenden Wi-Fi.
• Keine "Herunterladen unsere App"-Bannern und keine Links, die Benutzer zu Ihrer Website leiten, um Kernaufgaben durchzuführen.

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

Schritt 3: Fügen Sie Capacitor

Von Ihrem Web-Projekt-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

Verwenden Sie das echte Ausgabeverzeichnis für --web-dir: dist Für Vite out Für Next.js statische 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. Verwenden Sie eine umgekehrte Domäne, die Sie kontrollieren.

Ihr capacitor.config.ts soll nun wie folgt aussehen:

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

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

export default config;

Capacitor 8 erstellt das iOS-Projekt mit Swift Package Manager standardmäßig, sodass Sie CocoaPods nicht benötigen. Jedes Mal, wenn Sie die Web code ändern:

bun run build
bunx cap sync

Lauf es an:

bunx cap run ios
bunx cap run android

Commit die ios/ und android/ Ordner. Sie sind die Quell code , die Sie bearbeiten (Eigenschaften, Icons, Signierung). Weitere Hintergrundinformationen finden Sie unter Wie einfach es ist, eine Web-App in eine mobile App umzuwandeln mit Capacitor, und wenn Sie mit einem AI-Tool gebaut haben, unsere Lieblingsleitfaden zur mobilen App.

Step 4: Add native features that justify an app

Die Richtlinie 4.2 von Apple (Mindestfunktion) lehnt Apps ab, die nur eine Website in einem Shell sind. Sie benötigen nicht Dutzende von native Funktionen, aber die App sollte wie eine App funktionieren. Gemeinsame, nützliche Hinzufügungen:

Beispiel: Zeige das native Share Sheet anstatt 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);
  }
}

Sollten Sie digitale Inhalte oder Abonnements verkaufen, planen Sie die Zahlungen jetzt. Apple und Google erfordern ihre In-App-Kaufsysteme für digitale Güter in der Regel. Im US-App-Store können Apps außerdem nach dem Gerichtsurteil von 2025 auf externe Web-Checkout-Links verlinken; andere Regionen haben ihre eigenen Regeln. Für physische Güter und Dienstleistungen (Lieferungen, Fahrten) können Sie Stripe oder einen anderen Zahlungsanbieter verwenden. Siehe In-App-Käufe mit Capacitor.

Das vollständige Katalog der Capgo-Plugins finden Sie auf der Plugins-Seite.

Schritt 5: Icons, Splashbild und Berechtigungszeichenfolgen

Erstellen Sie alle Icon- und Splashbildgrößen aus zwei Quellbildern:

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

On iOS benötigen Sie für jede verwendete Berechtigung eine Beschreibung. ios/App/App/Info.plist, oder das App-Programm stürzt ab, wenn es fragt und Apple es ablehnt:

<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>

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

Auf Android hinzufügen Plugins die meisten Berechtigungen zum Manifest selbst. Entfernen Sie Berechtigungen, die Sie nicht verwenden; Google fragt Sie nach, warum Sie sensitive Berechtigungen verwenden.

Auch fügen Sie ein Datenschutz-Manifest (PrivacyInfo.xcprivacyWenn Ihr code die erforderlichen-Gründe-APIs verwendet. Datenschutz-Manifest-Anleitung für Capacitor.

Schritt 6: Konfigurieren Sie die Signierung

iOS. Sie benötigen ein Apple-Distributionssertifikat (mit seinem privaten Schlüssel, der normalerweise als .p12) exportiert wird) und ein App-Store-Connect-Provisioning-Profil für Ihre Bundle-ID. Xcode kann sie automatisch erstellen, oder Sie können sie selbst erstellen, auch ohne einen Mac. Lesen Sie iOS-Zertifikate und -Profilierungserklärungen erklärt; die iOS-Zertifikatsgenerator fertigt den CSR-Schritt im Browser ab.

Android. Erstellen Sie einen Upload-Keystore und sichern Sie ihn ab. Google Play verwendet Play App Signing, daher hält Google die endgültige App-Zertifizierungsschlüssel und Sie signieren Uploads mit Ihrem Schlüssel.

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

Verwenden Sie Android-Keystore-Generator.

Schritt 7: Erstellen Sie die Release-Dateien

Lokal

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

1. bunx cap open ios
2. Wählen Sie das App ziel, legen Sie die Version und die Buildnummer fest, wählen Sie Ihr Team unter Signing & Fähigkeiten.
3. Wählen Sie Jedwedes iOS-Gerät (arm64), dann Produkt > Archivieren.
4. In der Organizer, Verteilen Sie das App > App Store Connect > Hochladen.

Android:

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

Die AAB befindet sich in android/app/build/outputs/bundle/release/. Konfigurieren Sie signingConfigs auf android/app/build.gradle mit Ihrem Keystore, Passwörter aus Umgebungsvariablen laden.

Make sure targetSdkVersion ist 36. Da Google Play ab dem 31. August 2026 neue Apps und Updates erfordert, die sich auf Android 16 ( API 36) richten, das Capacitor 8 Standard ist.

Im Cloud-Service

Wenn Sie keinen Mac haben oder Builds aus CI wiederholbar machen möchten, Capgo Build baut beide Plattformen auf gehosteten Maschinen auf und kann direkt auf 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 .

Die Anmeldedaten werden nur für die Erstellung verwendet und werden nicht auf Capgo Servern gespeichert. Siehe die Capgo Build-Dokumentation.

Schritt 8: Verteilen Sie an Tester

Legen Sie das Build auf echte Smartphones, bevor es von Apple oder Google jemand sieht.

• iOS: Hochladen in TestFlight. Internen Testern (bis zu 100 Teammitglieder) wird es nach Bearbeitung zugestellt; externen Testern (bis zu 10.000) nach einer kurzen Beta-App-Überprüfung.
• Android: Erstellen Sie ein internes Testversion in Play Console und teilen Sie den Opt-in-Link.

Testen Sie Registrierung und Anmeldung, Zahlungen im Sandbox, Push-Benachrichtigungen, Offline-Verhalten, die Tastatur, die Eingaben und das Zurück-Button-Verhalten auf Android. Details für jede Option: wie Sie iOS- und Android-Apps an Testern verteilen.

Schritt 9: Durchführen von Googles geschlossener Test (neue persönliche Konten)

Wenn Ihr Play-Konto nach dem 13. November 2023 erstellt wurde, können Sie die Veröffentlichung in die Produktion nicht vornehmen, bis Sie eine closed test with at least 12 testers opted in for 14 consecutive daysDann beantragen Sie Zugriff auf die Produktion im Google Play Console-Dashboard, wobei Google diesen normalerweise innerhalb einer Woche überprüft.

Start this as soon as you have a usable Android build. Use a Google Group as the tester list so people can join themselves. Ship updates during the 14 days and collect feedback, since Google asks what you learned. Organization accounts are exempt.

Schritt 10: Vorbereiten der Ladenlisten und Einreichen

Sie benötigen für beide Stores: App-Name, Beschreibungen, Screenshot in den akzeptierten Größen, Icon, URL der Datenschutzrichtlinie, Datenschutzmitteilungen (Apple App Privacy und Google Data Safety), Fragebogen zur Altersstufeneinstufung, Kontakt zur Unterstützung und ein Demo-Konto, wenn die App eine Anmeldung hat. Google benötigt auch eine 1024 x 500 Features-Bildmarke. Spezifikationen und Grenzen: Vorbereitung Ihres App Store- und Google Play-Listings.

iOS-Submission: erstellen Sie in App Store Connect die Version, wählen Sie die TestFlight-Build, füllen Sie die App Review Information (Demo-Konto, Notizen) aus und klicken Sie Zur Überprüfung hinzufügen, dann Submit.

Android-Submission: Erstellen Sie eine Produktionsversion mit der AAB (oder bewerben Sie die getestete Version aus einem Test-Track), füllen Sie alle App-Inhalts Erklärungen aus, setzen Sie Länder und senden Sie zur Überprüfung.

Die Ablehnungen, die Web-Apps am häufigsten treffen:

1. 4.2 MindestfunktionenDie App ist einfach deine Website. Füge native Werte hinzu und entferne Browser-UI.
2. Anmeldung erforderlich, aber kein Demo-Konto, oder das Konto funktioniert nicht.
3. Keine Datenschutz-fokussierte Anmeldeoption bei iOS, wenn Sie Google- oder Facebook-Anmeldung anbieten. Richtlinie 4.8 erfordert eine äquivalente Option, die die Datenerfassung einschränkt; Sign in with Apple ist die übliche Wahl.
4. Keine Konto-Löschung innerhalb der App, wenn Benutzer Konten erstellen können.
5. Digitale Kauf durch Stripe wo in-App-Käufe erforderlich sind.
6. Verbrochener iPad-Ansichtsbereich weil das Projekt iPad standardmäßig unterstützt.
7. Fehlende oder vage Berechtigungszeichen.

Unsere Erste Anleitung für die App-Überprüfung und iOS-App-Submission-Leitfaden gehen Sie jede detailliert durch.

Schritt 11: Versenden Sie Updates ohne auf eine Überprüfung zu warten

Nach der Veröffentlichung werden die meisten Ihrer Änderungen immer noch im Web code sein. Anstatt eine neue Ladenkompilation für jeden Fix zu erstellen, fügen Sie Live-Updates hinzu. Der Capgo-Updater lädt neue Web-Bundles von Capgo herunter und fügt sie bei der nächsten Startphase hinzu, mit automatischer Rückschaltung, wenn der neue Bundle fehlschlägt.

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

Rufen notifyAppReady() wenn Ihre App gestartet ist, damit der Updater weiß, dass der Bundle gesund ist:

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

CapacitorUpdater.notifyAppReady();

Dann ist jede Veröffentlichung von Web code eine Befehlszeile:

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

Beide Läden erlauben dies für interpretierte code solange die Aktualisierung nicht den Hauptzweck der App ändert oder die Zahlungsregeln umgeht. Native Änderungen (neue Plugins, neue Berechtigungen, Capacitor-Upgrades) gehen immer noch durch die Läden. Lesen Sie mehr auf Capgo Live-Updates und die Updater-Dokumentation.

Fügen Sie das Plugin vor Ihrer ersten Store-Einreichung hinzu. Es muss im Binärdatei, die die Benutzer installieren, enthalten sein, ansonsten kann Ihre erste live update nur nach einer zweiten Store-Ausgabe an die Benutzer gelangen.

Automatisieren Sie schließlich: Erstellen und hochladen Sie auf jeden Tag von GitHub Actions oder GitLab CI, pushen Sie Live-Updates auf jeden Merge zu main, und behalten Sie native Releases für native Änderungen bei.

Vorab-Überprüfung

• Apple- und Google-Konten genehmigt, Vereinbarungen angenommen
• Die App funktioniert offline oder zeigt einen klaren Offline-Zustand an
• Sichere Bereiche, Tastatur und Android-Rück-Button behandelt
• Mindestens ein paar native Funktionen, die eine Website nicht anbieten kann
• Ikone, Splash, Berechtigungszeichenketten, Datenschutzmanifest
• Distributionsszertifikat, App Store-Profil, Upload von Backup-Keystore
• Ziel SDK 36 auf Android, mit Xcode 26 auf iOS erstellt
• TestFlight und Play-Interner-Test auf echten Geräten durchgeführt
• Google Play geschlossener Test abgeschlossen (persönliche Konten)
• Listungen abgeschlossen in beiden Stores, Demo-Konto hinzugefügt
• Konto-Löschen im App-Angebot, wenn Benutzer sich anmelden können
• Live-Updates-Plugin im ersten Binär enthalten

Schwierigkeiten

Weißes Bildschirmfenster beim Start. webDir wählt den falschen Ordner aus oder Sie haben vergessen bunx cap sync nachdem Sie gebaut haben. Überprüfen ios/App/App/public and android/app/src/main/assets/public enthalten index.html.

API-Aufrufe funktionieren nur im App. CORS: zulassen capacitor://localhost und https://localhostURLs, die iOS standardmäßig blockiert. http:// Routen 404 nach Neuladen oder tiefem Link.

Verwenden Sie einen Router, der auf oder Hash-Routing für ältere Konfigurationen. index.htmloder Routing mit Hash für ältere Konfigurationen.

Siehe die Fehlerliste in iOS-Zertifikate und Provisioningprofile erklärt iOS-Zertifikate und Provisioningprofile.

Gradle-Build fehlt nach Upgrade. Capacitor 8 benötigt Android Studio Otter (2025.2.1) oder neuer und JDK 21, wie im Capacitor 8 Upgrade-Leitfaden beschrieben.. Für andere Gradle-Fehler siehe Wie man Android-Build-Fehler löst in Capacitor.

Google Play Upload wurde wegen Ziel SDK abgelehnt. Set targetSdkVersion = 36 Setz android/variables.gradle.