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

Um eine Web-App auf dem App Store und Google Play zu erstellen, verpacken Sie Ihre Web-App in einem native Projekt mit Capacitor, fügen Sie ein paar native Funktionen hinzu, erstellen Sie Apple- und Google-Entwicklerkonten, signieren und bauen Sie die iOS- und Android-Binärdateien, testen Sie sie mit echten Benutzern, bereiten Sie die Store-Listen und senden Sie sie zur Überprüfung.

Hier sind die 11 Schritte in der Reihenfolge, die Warten vermeidet, mit Befehlen für Capacitor 8 und den Store-Regeln, die im Oktober 2026 gelten.

Was Sie benötigen

• Eine Web-App, die sich auf statische Dateien aufbaut (React, Vue, Angular, Svelte, Next.js statische Export, Nuxt generieren, einfaches HTML oder eine mit einem KI-Baukasten wie Lovable oder Bolt erstellte App).
• 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 kein Mac haben.
• 99 USD pro Jahr für Apple und 25 USD einmal für Google.

Realistischer Zeitplan

Schritt 1: Registrieren Sie sich heute für ein Entwicklerkonto

Kontoüberprüfung ist der Schritt, den Sie nicht beschleunigen können, also tun Sie ihn vor der Programmierung.

• Apple Developer-Programm: 99 USD pro Jahr. Einzelne Personen benötigen einen Apple-Konto mit Zwei-Faktor-Authentifizierung und ihrem rechtlichen 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. Erwartete ID-Überprüfung.

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

Schritt 2: Bereiten Sie die Webanwendung auf ein Handy 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 Server-Seitenerstellung läuft nicht auf dem Telefon. Verwenden Sie die statische Ausgabe Ihres Frameworks (next build mit output: 'export', nuxt generate, Vite build). API-Aufrufe gehen wie zuvor über HTTPS an Ihren Backend.
• Client-seitige Routen, die von einem Datei-Origin funktionieren. Verwenden Sie die History-Routen (Capacitor dient die App von https://localhost auf Android und capacitor://localhost auf iOS, so funktioniert es) und stellen sicher, dass tiefe URLs auf index.html.
• fallen. Fügen Sie die Capacitor-Origins zu den erlaubten Ursprüngen Ihrer API hinzu: capacitor://localhost (iOS) und https://localhost (Android).
• (Berührung, nicht Mauszeiger). Remove hover-only menus. Make tap targets at least 44 x 44 points.
• Sichere Bereiche. Hinzufügen viewport-fit=cover zum Viewport-Meta-Tag und füllen Sie Kopf- und Fußleisten mit env(safe-area-inset-top) und env(safe-area-inset-bottom).
• Offline- und langsamem Netzwerk. Zeigen Sie einen korrekten Zustand an, anstatt eine leere Seite. Testen Sie auf fluktuierenden Wi-Fi-Netzwerken.
• Keine ‘Herunterladen unsere App’-Bannern and no links that send users to your website to do core tasks.

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

Schritt 3: Hinzufügen 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 Exporte, .output/public Für Nuxt generieren, 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 jetzt sieht aus wie:

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

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

export default config;

Capacitor 8 erstellt den iOS-Projekt mit Swift Package Manager standardmäßig, sodass Sie CocoaPods nicht benötigen. Jede Änderung an Ihrem Web code:

bun run build
bunx cap sync

Laufen Sie es:

bunx cap run ios
bunx cap run android

Kommt das ios/ und android/ Ordner. Sie sind die Quellen code Sie bearbeiten werden (Erlaubnisse, 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 Lieblingsanleitung zum Mobilisieren.

Step 4: Add native features that justify an app

Apple's Richtlinie 4.2 (Mindestfunktion) lehnt Apps ab, die nur eine Website in einem Gehäuse sind. Sie benötigen nicht Dutzende von native Funktionen, aber das App-Verhalten muss wie ein App-Verhalten sein. Gemeinsame, nützliche Hinzufügungen:

Beispiel: Zeigen Sie die native Teilen-Schaltfläche anstelle eines "Link kopieren"-Knopfes.

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);
  }
}

Planen Sie Zahlungen, wenn Sie digitale Inhalte oder Abonnements verkaufen. Apple und Google erfordern in den meisten Fällen ihre In-App-Kaufsysteme für digitale Güter. Im US-App-Store dürfen Apps nach dem Gerichtsurteil von 2025 auch auf externe Web-Checkout-Links verweisen; andere Regionen haben ihre eigenen Regeln. Für physische Güter und Dienstleistungen (Lieferungen, Fahrten) können Stripe oder jeder Zahlungsanbieter verwendet werden. Siehe In-App-Käufe mit Capacitor.

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

Schritt 5: Icons, Splash-Screen und Berechtigungszeichenfolgen

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

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

Auf iOS benötigen alle von Ihnen verwendeten Berechtigungen eine Verwendungsbegründung in ios/App/App/Info.plist, oder das App-Programm stürzt ab, wenn es fragt und Apple lehnt es 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>

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

Auf Android fügen Plugins die meisten Berechtigungen selbst in das Manifest ein. Entfernen Sie Berechtigungen, die Sie nicht verwenden; Google fragt Sie nach, warum Sie sensitive Berechtigungen verwenden.

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

Schritt 6: Zertifizierung einrichten

iOS. Sie benötigen ein Apple-Distributionszertifikat (mit seinem privaten Schlüssel, der normalerweise als) .p12) und ein App Store Connect-Provisioningprofil für Ihren Bundle-Id. Xcode kann sie automatisch erstellen oder Sie können sie selbst erstellen, auch ohne Mac. Lesen Sie iOS-Zertifikate und Provisioning-Profile erklärt; der iOS-Zertifikatsgenerator die CSR-Schritt im Browser abhandelt.

Android. Erstellen Sie einen Upload-Keystore und sichern Sie ihn. 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

die Android-Keystore-Generator.

Schritt 7: Erstelle die Release-Dateien

Ortlich

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

1. bunx cap open ios
2. Wähle das App Ziel, setze die Version und Buildnummer, wähle dein Team unter Signierung & Fähigkeiten.
3. Wähle Jedwedes iOS-Gerät (arm64), dann Produkt > Archivieren.
4. In der Organizer, Distribute App > App Store Connect > Hochladen.

Android:

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

Der AAB ist in android/app/build/outputs/bundle/release/. Konfigurieren signingConfigs in android/app/build.gradle mit Ihrem Keystore, Passwörter aus Umgebungsvariablen laden.

Make sure targetSdkVersion is 36. Since August 31, 2026 Google Play requires new apps and updates to target Android 16 (API 36), which is the Capacitor 8 default.

Im Cloudspeicher

Wenn Sie kein Mac haben oder wenn Sie 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 .

Benutzereinstellungen werden nur für die Erstellung verwendet und werden nicht auf Capgo-Server gespeichert. Siehe die Capgo-Build-Dokumentation.

Schritt 8: Verteilen an Tester

Stellen Sie das Build auf echten Smartphones, bevor es von jemandem bei Apple oder Google gesehen wird.

• iOS: Hochladen in TestFlight. Internen Testern (bis zu 100 Teammitglieder) wird es sofort 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 Eingabefelder bedeckende und die Zurück-Taste auf Android. Details für jede Option: wie Sie iOS- und Android-Apps an Tester 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 Play Console-Dashboard, der von Google in der Regel innerhalb einer Woche überprüft wird.

Starten Sie dies so schnell wie möglich, sobald Sie einen verwendbaren Android-Build haben. Verwenden Sie eine Google-Gruppe als Testerteam, damit sich die Personen selbst anmelden können. Verschicken Sie Updates während der 14 Tage und sammeln Sie Feedback, da Google wissen möchte, was Sie gelernt haben. Organisationen sind von dieser Regelung ausgenommen.

Schritt 10: Vorbereiten der Ladenlisten und Einreichen

Für beide Stores benötigen Sie: App-Name, Beschreibungen, Screenshot in den akzeptierten Größen, Icon, URL der Datenschutzrichtlinie, Datenschutzmitteilungen (Apple App-Privacy und Google Data-Sicherheit), Fragebogen für die Altersbewertung, Kontakt für die Support-Abteilung und eine Demo-Konto, wenn die App eine Anmeldung hat. Google benötigt auch eine 1024 x 500 Pixel große Feature-Graphic. Spezifikationen und Grenzen: Wie Sie Ihre App-Store- und Google Play-Listung vorbereiten.

Zusenden auf iOS: Im App-Store-Connect erstellen Sie die Version, wählen Sie die TestFlight-Build, füllen Sie die App-Review-Informationen (Demo-Konto, Notizen) aus und klicken Sie auf Zur Überprüfung hinzufügenund dann Zusenden.

Zusenden auf Android: Erstelle eine Produktionsversion mit der AAB (oder bewirke die getestete von einem Testtrack), fülle alle Anwendungsdaten Erklärungen aus, setze Länder und sende zur Überprüfung.

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

1. 4.2 Mindestfunktionalität: Die App ist nur Ihre Website. Füge native Werte hinzu und entferne browserartige Benutzeroberflächen.
2. Anmeldung erforderlich, aber keine Demo-Konto, oder das Konto funktioniert nicht.
3. Keine Datenschutz-fokussierte Anmeldeoption bei der Nutzung von Google- oder Facebook-Anmeldung auf iOS. 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 Kaufabwickungen über Stripe wo eine In-App-Kaufanforderung erforderlich ist.
6. Verstörter iPad-Ansichtsbereich weil das Projekt iPad standardmäßig unterstützt.
7. Fehlende oder unklare Berechtigungszeichenfolgen.

Unsere erste App-Bewertungsanleitung und iOS-App-Submission-Leitfaden gehen Sie jeden einzelnen aufschlüsselt durch.

Schritt 11: Schicken 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 auf der nächsten Startanforderung 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 Sie an notifyAppReady() wenn Ihr App gestartet ist, damit der Updater weiß, dass das 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 Stores erlauben dies für interpretierte code solange die Aktualisierung nicht den Hauptzweck der App ändert oder ihre Zahlungsvorschriften umgeht. Native Änderungen (neue Plugins, neue Berechtigungen, Capacitor Upgrades) gehen jedoch immer noch durch die Stores. Lesen Sie mehr auf Capgo Live-Updates und Updater-Dokumentation.

Fügen Sie das Plugin vor Ihrer ersten Store-Submission hinzu. Es muss im Binärdatei enthalten sein, die Benutzer installieren, ansonsten kann Ihre erste live update nur nach einer zweiten Store-Veröffentlichung erreichen.

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

Vorstart-Checkliste

• Apple- und Google-Konten genehmigt, Vereinbarungen akzeptiert
• Die App funktioniert offline oder zeigt einen klaren Offline-Zustand.
• Safe Areas, Tastatur und Android-Rücktaste werden behandelt.
• Mindestens ein paar native Funktionen, die eine Website nicht anbieten kann.
• Icons, Splash, Berechtigungszeichenfolgen, Datenschutzmanifest
• Verteilungszertifikat, App Store-Profil, hochladen von Backup des Keystores
• Ziel SDK 36 auf Android, mit Xcode 26 auf iOS erstellt
• TestFlight und Play-Internetesting wurden auf echten Geräten durchgeführt
• Google Play geschlossene Testphase abgeschlossen (persönliche Konten)
• Listings sind auf beiden Stores abgeschlossen, Demo-Konto hinzugefügt
• Konto löschen, wenn Benutzer sich anmelden können
• Live-Updates-Plugin ist im ersten Binär enthalten

Problemlösung

Weißer Bildschirm beim Start. webDir zeigt auf den falschen Ordner oder Sie haben vergessen bunx cap sync nach dem Bauen. Überprüfen Sie ios/App/App/public und android/app/src/main/assets/public enthält index.html.

API-Aufrufe funktionieren nur im App. CORS: erlauben capacitor://localhost und https://localhost. Überprüfen Sie auch, ob Sie nicht auf http:// URLs aufrufen, die iOS standardmäßig blockiert.

Routen 404 nach Neuladen oder tiefem Link. Verwenden Sie einen Router, der auf eine andere Route fällt. index.htmloder Routing über Hashes für ältere Konfigurationen.

Xcode-Signierungsfehler. Siehe die Fehlerliste in iOS-Zertifikate und Provisioning-Profile erklärt.

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-Leitfadenerforderlich. Für andere Gradle-Fehler siehe wie Android-Buildfehler in Capacitor gelöst werden..

Google Play-Upload abgelehnt für Ziel SDK. Setz targetSdkVersion = 36 context android/variables.gradle.