Was kostet die Veröffentlichung einer App im App Store und bei Google Play?

Was die offiziellen Gebühren abdecken

Die offiziellen Gebühren der Plattformen sind nur der Zugang. Apple erhebt eine jährliche Mitgliedschaft im Developer Program, Google Play eine einmalige Registrierung für die Console. Damit erhältst du die Möglichkeit, Apps zu verteilen. Die Gebühren erstellen aber keine Screenshots, prüfen keine Datenschutzformulare, testen keine Zahlung und beheben keine Ablehnung.

Deshalb sollte ein Angebot genau sagen, was gemeint ist. Ein einfacher Upload vorhandener Dateien ist etwas anderes als ein Launch-Service, der Build, Store-Seite, Privacy, Testzugänge, Review-Kommunikation und mögliche erneute Einreichung abdeckt.

Was ein Submission-Service leisten sollte

Bei einer einfachen MVP-App umfasst die Arbeit meist Entwicklerkonto, App-ID oder Package Name, Icon, Screenshots, Name, Beschreibung, Kategorie, Altersfreigabe, Support-Link, Datenschutz-Link, Release Notes und Hinweise für die Reviewer. Ohne diese Punkte kann eine ansonsten brauchbare App unvollständig wirken.

Bei einem Geschäftsprodukt kommen TestFlight oder Google-Play-Testtracks, Crash-Checks, Analytics-Events, Push-Benachrichtigungen, Abos, Zahlungen, Demo-Daten und Produktionsserver hinzu. Wenn Nutzerrollen, Buchungen, Kurse, Lieferungen, private Inhalte oder ein Admin-Bereich beteiligt sind, braucht der Reviewer einen klaren Weg durch den Kernprozess.

Warum der Preis schwankt

Der größte Kostentreiber ist die tatsächliche Reife der App. Eine stabile Build mit einem klaren Hauptfluss lässt sich leichter einreichen. Eine App mit Staging-Backend, altem Screenshot-Set, unvollständigem Login oder unklarer Datennutzung erzeugt zusätzliche Arbeit und erhöht das Risiko einer Ablehnung.

Wann du selbst veröffentlichen kannst

Du kannst die Veröffentlichung intern übernehmen, wenn die App überschaubar ist, die Konten deiner Firma gehören, die Build getestet wurde, keine sensiblen Szenarien enthalten sind und jemand aus dem Team schnell auf Rückfragen reagieren kann. Dann reicht manchmal eine abschließende Checkliste durch eine erfahrene Person.

Riskant wird es, wenn die Person beim Upload den Produktkontext nicht kennt. Ein Reviewer braucht vielleicht eine Beispielbestellung, einen Kurierstatus, eine Premium-Rolle, eine Testbuchung, einen Kurs mit Inhalt oder Zugang zum Admin-Bereich. Ohne solche Daten kann die App leer oder kaputt wirken.

Wann bezahlte Launch-Unterstützung sinnvoll ist

Launch-Unterstützung lohnt sich, wenn der Release mit Umsatz, Investoren, Kampagnen, Partnern, Filialen oder festen Kundenterminen verbunden ist. Sie ist auch sinnvoll bei Abos, Zahlungen, Marktplätzen, Standortfunktionen, privaten Daten, medizinischen Abläufen, Moderation oder CRM- und ERP-Integrationen.

Bei Appfyl sehen wir Veröffentlichung normalerweise als Teil der Produktübergabe. Wenn wir die App entwickeln, soll die erste öffentliche Version zum Scope, zum Testplan und zur Store-Seite passen. Wenn wir eine fremde App prüfen, schauen wir zuerst auf Build, Konten, Datenschutz, Analytics und Store-Materialien, bevor wir einen Termin zusagen.

Was du für ein Angebot vorbereiten solltest

Hilfreich sind Build-Status, Plattformen, Eigentümer der Entwicklerkonten, Datenschutzseite, Support-Link, Screenshots, Store-Texte, Demo-Zugang und eine kurze Beschreibung des wichtigsten Nutzerflusses. Bei Zahlungen sollte klar sein, ob digitale Inhalte, physische Produkte, Dienstleistungen, Buchungen oder Transaktionen zwischen Nutzern verkauft werden.

Entscheide außerdem, welche Länder und Sprachen beim ersten Release zählen. Lokalisierung kann eine kleine Textanpassung sein oder ein eigenes Conversion-Thema mit lokalen Screenshots, Währung, Zahlungsarten, Vertrauenssignalen, Support und rechtlichen Texten.

Sehr hilfreich ist auch eine kurze Liste mit Dingen, die noch nicht fertig sind. Viele Teams versuchen, Unsicherheit zu verstecken, weil sie ein niedrigeres Angebot erwarten. In der Praxis passiert das Gegenteil: Wenn ein Anbieter erst beim Upload merkt, dass Push-Berechtigungen, Abo-Produkte, Demo-Daten oder rechtliche Links fehlen, wird die Arbeit unruhiger und teurer. Ein ehrlicher Status spart Zeit, weil der Launch-Plan dann zwischen Muss, Risiko und späterer Verbesserung unterscheiden kann.

Wenn es bereits eine abgelehnte Einreichung gab, schicke nicht nur den letzten Screenshot aus App Store Connect oder Google Play Console. Besser ist die vollständige Review-Nachricht, die betroffene Build-Nummer, die getesteten Zugangsdaten und eine Beschreibung, was seitdem geändert wurde. Damit lässt sich prüfen, ob eine neue Store-Notiz reicht oder ob wirklich eine technische Korrektur nötig ist.

Versteckte Arbeit

Viele Verzögerungen entstehen durch Widersprüche. Die Store-Seite verspricht Funktionen, die in der Build fehlen. Screenshots zeigen alte Oberflächen. Datenschutzangaben verschweigen ein SDK. Der Login sperrt Reviewer aus. Ein Abo funktioniert im Test, aber nicht in Produktion. Der Support-Link führt auf eine leere Seite.

Auch die Zeit nach der Freigabe gehört zum Launch. Das Team sollte Crash-Reports, Analytics, Zahlungen, Bewertungen und Support-Nachrichten beobachten. Eine Veröffentlichung ist erst dann wirklich abgeschlossen, wenn echte Nutzer den Hauptfluss ohne manuelle Hilfe schaffen.

Für Geschäfts-Apps ist außerdem wichtig, wer nach dem Release Änderungen veröffentlichen darf. Braucht jede neue Version Freigabe durch den Kunden? Wer pflegt Screenshots, Beschreibung und Release Notes? Wer antwortet auf Bewertungen? Wer prüft, ob eine neue Betriebssystemversion Login, Push oder Zahlungen verändert? Diese Verantwortung wirkt klein, entscheidet aber darüber, ob die App nach dem ersten Launch gepflegt bleibt.

Häufige Fragen