VeröffentlichenIn App Stores veröffentlichen
Natives Projekt
Das vollständige Handy-Projekt, für Werbung, Käufe und jemanden aus der Entwicklung, der sich darum kümmert.
Native gibt Ihnen die ganze App als Handy-Projekt, in einer ZIP-Datei oder in ein GitHub-Repository übertragen. Geben Sie zuerst den Namen der App und eine App-ID wie com.yourcompany.yourapp an: Die ID ist es, woran die Stores Ihre App erkennen, und sie lässt sich nach der Veröffentlichung nicht mehr ändern.
Das Fenster zeigt dann die genauen Befehle zum Erstellen, für Android und für das iPhone:
npm install && npm run build
npx cap add android
npm run icons
npx cap sync && npx cap open androidBeim iPhone tritt ios an die Stelle von android, und der letzte Befehl öffnet Xcode.
Ab hier ist es der eigene Weg der Stores: Signieren Sie die App in Android Studio oder Xcode, laden Sie sie hoch, testen Sie sie, füllen Sie die Store-Seite aus und veröffentlichen Sie. Bewahren Sie den Android-Signaturschlüssel und seine Passwörter sicher auf. Jedes Update muss mit demselben Schlüssel signiert werden. Ohne Android Studio oder Mac kann GitHub die App für Sie bauen: In der Cloud bauen.
Das Projekt erhalten: Download oder GitHub
In Schritt 1 hat Download the project zwei Felder, App name und App ID. Die ID beginnt mit com.setherion. und dem Namen der App und muss in der umgekehrten Domain-Schreibweise geschrieben sein. Download project (.zip) erstellt eine ZIP-Datei, die nach der App benannt ist. Sie enthält das Web-Projekt, die Handy-Dateien, eine schema.sql, wenn die App Tabellen hat, eventuelle Spielgrafiken sowie die Bilder für Symbol und Startbildschirm. Dafür braucht es einen kostenpflichtigen Tarif.
Stattdessen gibt es or push to GitHub: Verbinden Sie sich mit Connect with GitHub oder fügen Sie ein Token ein, wählen Sie einen Repo name und klicken Sie auf Export to GitHub. Das Repository wird privat angelegt, und Open repo führt Sie dorthin. Auch dafür braucht es einen kostenpflichtigen Tarif.
Native auf Android, Schritt für Schritt
- Download the project, wie oben.
- Erstellen Sie es. Dafür braucht es Node 22 und Android Studio. Führen Sie die Befehle aus, die das Fenster zeigt. Wenn die App Werbung oder Käufe nutzt, wird
npm run native:setupnachnpx cap add androidergänzt. - Signieren Sie es. Wählen Sie in Android Studio Build, dann Generate Signed App Bundle. Erstellen Sie einen Schlüssel und bewahren Sie ihn samt Passwörtern auf: Jedes Update braucht denselben Schlüssel.
- Laden Sie es hoch und testen Sie es. Legen Sie die App in der Play Console an, laden Sie die .aab-Datei in Internal testing hoch und füllen Sie dann die Store-Seite, die Inhaltseinstufung und Data safety aus. Bei Werbung geben Sie zusätzlich die Werbe-ID an.
- Veröffentlichen Sie es. Die Prüfung dauert einige Stunden bis zwei Tage. Ein persönliches Google-Play-Konto, das nach November 2023 eröffnet wurde, braucht zuerst den geschlossenen Test.
Native auf dem iPhone, Schritt für Schritt
- Download the project: dieselbe ZIP-Datei wie für Android.
- Erstellen Sie es. Dafür braucht es einen Mac mit Xcode und das Apple-Entwicklerkonto für 99 $ im Jahr. Führen Sie dieselben Befehle aus, mit
iosstattandroid. - Signieren Sie es und laden Sie es hoch. Öffnen Sie in Xcode Signing & Capabilities und wählen Sie Ihr Team. Bei Werbung oder Käufen fügen Sie In-App Purchase hinzu. Dann Product, Archive, Distribute, zu App Store Connect.
- Probieren Sie es auf Ihrem iPhone aus, mit TestFlight.
- Füllen Sie die Store-Seite aus und reichen Sie die App zur Prüfung ein. Bei Werbung zählt Apple sie als Tracking.
In der Cloud bauen
Kein Android Studio und kein Mac: GitHub kann die App auf eigenen Computern bauen. Übertragen Sie das Projekt in Schritt 1 an GitHub, dann bekommt das Repository zwei Build-Workflows, einen für Android und einen für das iPhone. Der Schritt Build it zeigt danach Build it in the cloud, mit einer Schaltfläche zur Seite des Workflows auf GitHub.
Öffnen Sie auf GitHub Actions, wählen Sie Android build oder iPhone build, klicken Sie auf Run workflow und wählen Sie, was gebaut werden soll:
| Workflow | Auswahl | Was Sie bekommen |
|---|---|---|
| Android build | Test APK | Eine App zum Installieren auf Ihrem eigenen Handy, unter den Artifacts des Laufs. Nichts einzurichten. |
| Android build | Make a new key | Der Signaturschlüssel, einmal vor Ihrem ersten Upload zu Google Play erstellt. Nur in einem privaten Repository. |
| Android build | Google Play bundle (.aab) | Die signierte Datei für die Play Console, mit einer höheren Versionsnummer bei jedem Lauf. |
| iPhone build | Check that it builds | Der Nachweis, dass sich die App für das iPhone kompilieren lässt. Kein Apple-Konto nötig. |
| iPhone build | TestFlight | Die App, signiert und an App Store Connect gesendet, zum Installieren mit TestFlight. |
Ein privates Repository hat 2.000 kostenlose Minuten auf den Computern von GitHub pro Monat. Ein Android-Build braucht davon nur wenige, und GitHub zählt eine Mac-Minute wie zehn. Die README des Repositorys erklärt jeden Schritt.
Vor dem ersten Google Play bundle
- Starten Sie Make a new key und laden Sie upload-key aus dem Lauf herunter.
- Bewahren Sie
upload.jksund das Passwort sicher auf, außerhalb des Repositorys. Jedes Update muss mit demselben Schlüssel signiert werden. - Öffnen Sie im Repository Settings, Secrets and variables, Actions und fügen Sie drei Secrets hinzu, jedes mit dem Text seiner Datei:
ANDROID_KEYSTORE_BASE64,ANDROID_KEYSTORE_PASSWORDundANDROID_KEY_ALIAS. - Starten Sie Google Play bundle (.aab) und laden Sie die Datei in der Play Console unter Internal testing hoch.
Vor dem ersten TestFlight-Build
- Legen Sie die App in App Store Connect an, mit derselben App-ID wie in Schritt 1.
- Erstellen Sie unter Users and Access, Integrations, App Store Connect API einen Schlüssel mit der Rolle Admin und laden Sie seine .p8-Datei herunter. Apple lässt Sie sie nur einmal herunterladen.
- Fügen Sie im Repository vier Secrets hinzu:
APPLE_TEAM_ID(Membership details auf developer.apple.com),ASC_KEY_ID,ASC_ISSUER_IDundASC_KEY_P8, den Text der .p8-Datei. - Starten Sie TestFlight. Einige Minuten später ist der Build in App Store Connect unter TestFlight. Der Workflow teilt Apple mit, dass die App nur Standardverschlüsselung nutzt, daher fragt TestFlight nicht danach.
Eine GitHub-Verbindung, die vor dem Build in der Cloud entstanden ist, kann die Workflows nicht hinzufügen: Der Schritt sagt es, und Reconnect in Schritt 1 behebt das.
Konten in der Handy-App
In der Handy-App melden sich Personen mit E-Mail und Passwort an. Der Google-Button und der per E-Mail gesendete Anmeldelink blenden sich dort aus. Deshalb ist die Prüfung Delete account button wichtig: Apple lehnt eine App ab, bei der man ein Konto erstellen kann, ohne dass es eine solche Funktion gibt.
Werbung und Käufe
Ein Spiel, das Werbung zeigt oder etwas verkauft, funktioniert nur im Native-Projekt wirklich: Werbung von Google AdMob, Käufe über die Stores mit RevenueCat. In der Vorschau des Editors sind sie nur gespielt („Test ad“, „Test purchase“, es wird kein Geld abgebucht), sodass Sie sie ausprobieren können, und auf der veröffentlichten Website sind sie ausgeblendet. Beim einfachen Weg läuft das Spiel ohne sie.
Das Projekt startet mit den Testanzeigen von Google, die nichts einbringen. Tragen Sie Ihre eigenen Werbe-IDs und Store-Schlüssel in src/monetize.keys.json ein und führen Sie npm run native:setup aus: Die README des Projekts sagt, woher jeder einzelne stammt.
Was in die Schlüsseldatei gehört
Die Datei enthält die AdMob-App-ID und die IDs der Rewarded- und Interstitial-Anzeigenblöcke für Android und das iPhone sowie die RevenueCat-Schlüssel für jeden Store (beginnend mit goog_ für Android und appl_ für das iPhone). Ohne RevenueCat-Schlüssel oder ohne Produkte wird nichts verkauft.
Für echte Werbung legen Sie das AdMob-Konto, die Apps und die Anzeigenblöcke an, tragen die IDs in die Datei ein, führen npm run native:setup auf frischen nativen Ordnern aus und veröffentlichen eine Datei app-ads.txt auf der Website. Für Käufe legen Sie in der Play Console und in App Store Connect Produkte mit denselben IDs an wie in src/monetize.json und verbinden beide Stores in einem RevenueCat-Projekt. Auf dem iPhone fügen Sie die Fähigkeit In-App Purchase hinzu.
Beide Stores verlangen einen Link zur Datenschutzerklärung, und eine Schaltfläche Restore purchases ist Pflicht: Das Projekt bringt eine mit. Zwischen Werbeeinblendungen überspringt die App eine Interstitial-Anzeige in den ersten 30 Sekunden, innerhalb von 60 Sekunden nach der letzten und für Spielende, die das Produkt zum Entfernen der Werbung gekauft haben.
War diese Seite hilfreich?