Use-Case

Die App ist kein Anhang an die Website

Viele Teams haben WordPress oder ein PaaS fürs Web und daneben Xcode, Play Console und ein Backend auf einem anderen Hoster. Die Application Platform nimmt Frontend, Backend und Store-Release in ein Projekt. Dieselbe Pipeline kennt Test, Build und Upload.

  • Flutter, Expo oder native iOS/Android im selben Projekt wie das Backend
  • CI baut, signiert und lädt hoch, sobald die Stores angebunden sind
  • Pipeline-Macs für iOS-Builds, die lokal niemandem mehr gelingen
Kostenlos registrieren App-Store-Automatisierung

Kostenlos starten. Keine Kreditkarte nötig.

Ein Projekt App-Repo, Backend-Repo und Homepage gehören zusammen, nicht in drei Tools.
Stores inklusive Metadaten, Screenshots, Signing, Upload – nicht als Nachmittag in Fastlane.
Backend daneben API, Datenbank und Secrets auf dem Server, den das Projekt schon kennt.
  • App StoreApple-Releases mit vorbereiteten Metadaten und Assets.
  • Google PlayPlay-Store-Einträge automatisiert bespielt.
Powered by Fastlane
Metadaten und Versionen pro Store, nicht als Folie in einem Drive-Ordner.

Kurz gesagt

Eine App ohne Backend ist selten. Die Plattform behandelt beides als ein Liefergegenstand.

  • Website allein bleibt WordPress oder ein Homepage-Stack.
  • App plus API gehört in ein Plattform-Projekt, sonst driftet Signing, Secret und Release.
  • Store-Uploads sind Teil der Pipeline, nicht ein manueller Account in der Console.
  • macOS-Workspaces für iOS-Builds folgen – Ubuntu-Workspaces für den Rest sind da.

App und Backend zusammen oder auf getrennten Diensten

Getrennte Dienste funktionieren, bis Credentials, Versionen und Rollbacks nicht mehr zusammenpassen.

Gemeinsames Projekt

Mit der Application Platform: Frontend, Backend und Homepage als Repos eines Projekts

Website-CMS + separates App-Setup: CMS, API-Hoster und Xcode-Projekt ohne gemeinsame Quelle

API und Secrets

Mit der Application Platform: Credentials in der Plattform, Umgebungen Dev/Prod

Website-CMS + separates App-Setup: wp-config, .env auf dem Hoster, weitere in Xcode

iOS- und Android-Build

Mit der Application Platform: Pipeline und Signing in der Plattform

Website-CMS + separates App-Setup: Lokale Maschinen oder ein dritter CI-Dienst

Store-Metadaten

Mit der Application Platform: Texte, Screenshots, Changelogs in der Plattform bzw. im Repo

Website-CMS + separates App-Setup: Von Hand in App Store Connect und Play Console

Release koppeln

Mit der Application Platform: Backend-Deploy und Store-Version als nachvollziehbare Releases

Website-CMS + separates App-Setup: Website live, App zwei Wochen später, API dazwischen

Team ohne lokale Toolchain

Mit der Application Platform: Cloud-Workspaces (Ubuntu jetzt, macOS später)

Website-CMS + separates App-Setup: Jeder Laptop mit Android Studio und Zertifikaten

macOS-Workspaces sind noch nicht für Nutzer anlegbar. iOS-Signing und Store-Uploads laufen über die Projekt-Pipeline, nicht über einen User-Workspace.

Stand: 4. September 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.

Was neben dem Store-Formular abfällt

Die Console bleibt der Store. Die Vorbereitung soll nicht dort stattfinden.

Eine CI für App und API

Test und Build für Backend und Clients, ohne zwei Runner-Welten zu pflegen.

Signing liegt im Projekt

Keystore und Apple-Credentials gehören zum Projekt, nicht zum Laptop einer Person.

Whitelabel möglich

Mehrere Store-Einträge aus einer Codebasis, wenn Marken sich die App teilen.

Server für die API

Dieselbe Organisation betreibt den Server, gegen den die App spricht.

Das Backend liegt auf dem Server des Projekts, nicht auf einem dritten PaaS. Das Backend liegt auf dem Server des Projekts, nicht auf einem dritten PaaS.
Das Backend liegt auf dem Server des Projekts, nicht auf einem dritten PaaS.

So kommt die App ins Projekt

Wenn schon eine Website existiert, bleibt sie. Die App zieht nicht ins CMS.

  1. Projekt mit App-Stack

    Flutter, Expo oder native Clients anlegen, Backend dazu. Bestehenden Code importieren, statt in WordPress eine WebView zu bauen.

  2. Stores anbinden

    Accounts, Signierung, Metadaten. Die Pipeline übernimmt die Store-Uploads, die du nicht in jedem Repo neu schreiben musst.

  3. API auf dem Server

    Managed oder eigener Server. Secrets nicht in der App hardcoden.

  4. Release koppeln

    Backend zuerst oder bewusst gemeinsam. Store-Review dauert – die Pipeline macht den Upload, nicht die Wartezeit weg.

Häufige Fragen

Kann ich die Website in WordPress lassen und nur die App hier bauen?

Technisch ja, organisatorisch ungeschickt: zwei Welten für Secrets und Releases. Sinnvoll ist die Website als Homepage-Stack im selben Projekt oder ein bewusstes Zwischenstadium auf dem Weg dorthin.

Gibt es native iOS-Builds ohne Mac vor Ort?

Store-Pipelines und Signierung sind Teil der Plattform. Cloud-Workspaces unter macOS kannst du noch nicht selbst anlegen – die folgen. Ubuntu-Workspaces sind verfügbar. iOS-Builds in der Pipeline laufen auf macOS-Geräten der Plattform.

Was ist mit Expo und Flutter?

Beides ist als Frontend-Stack vorgesehen, inklusive der üblichen Store-Wege. Der genaue Umfang steht in der Doku und in den Projekt-Templates.

Ersetzt das App Store Connect?

Nein. Review, Verträge und Steuer leben weiter bei Apple und Google. Die Plattform füllt und lädt, sie entscheidet das Review nicht.

App-Store-Automatisierung Metadaten, Screenshots, Upload. Mobile CI/CD Builds für iOS und Android. Warum nicht WordPress Warum die App nicht als Plugin an der Website hängt. Für Mobile-Teams Einstieg, wenn die App das Produkt ist.

App und API in dasselbe Projekt

Lege das Projekt mit Frontend und Backend an. Die Stores kommen dazu, sobald Signing und Metadaten da sind – nicht als zweites Produkt.

Kostenlos registrieren Mit uns sprechen

Kostenlos starten. Keine Kreditkarte nötig.