Zurück zum Journal
Mobile AppsNº 00721. Juni 20267 Min.

Was eine native App in beiden Stores 2026 wirklich kostet

Die Store-Gebühren sind der billige Teil. Der echte Preis steht nicht auf der Rechnung: Wartung, abgelehnte Reviews und das zweite Betriebssystem.

Jemand hat dir gesagt, eine App zu veröffentlichen kostet 25 Dollar. Technisch stimmt das. So viel verlangt Google einmalig für ein Konto in der Play Console.

Diese Zahl ist eine Falle. Es ist, als würdest du sagen, ein Restaurant zu eröffnen kostet den Preis der Gewerbeanmeldung. Die Anmeldung ist real. Sie bezahlt nicht die Küche, das Personal oder den Kühlschrank, der im August kaputtgeht.

Schauen wir uns an, was es 2026 wirklich kostet, eine native App in beide Stores zu bringen und am Leben zu halten.

Die Store-Gebühren sind der kleinste Posten auf der Liste

Apple verlangt 99 Dollar pro Jahr für das Apple Developer Program. Zahlst du nicht, verschwindet die App. Das ist Miete, kein Kauf.

Google verlangt 25 Dollar, einmalig, für die Registrierung des Entwicklerkontos in der Play Console. Einmal im Leben gezahlt und erledigt.

Zusammengerechnet gibst du im ersten Jahr rund 124 Dollar an offiziellen Gebühren aus. Merk dir diese Zahl. Sie ist der einzige Kostenpunkt, den alle kennen, und der unwichtigste von allen.

Es sind zwei Apps, nicht eine

Hier ist der Teil, der Budgets zerstört. Wenn du "native App für beide Stores" sagst, verlangst du zwei Produkte mit zwei Betriebssystemen, zwei Grundsprachen und zwei Review-Teams mit unterschiedlichen Regeln.

iOS ist Swift und Xcode. Android ist Kotlin und Android Studio. Das sind verschiedene Werkzeuge, verschiedene Build-Zyklen, verschiedene Bugs. Was du auf der einen Seite kaputtmachst, machst du auf der anderen nicht kaputt.

Frameworks wie React Native oder Flutter versprechen geteilten Code. Sie helfen, und wir nutzen sie. Aber sie lösen das Problem nicht. Du brauchst weiterhin einen Mac, um für iOS zu kompilieren, Konten auf beiden Seiten und echte Geräte aus beiden Welten zum Testen. Der Bezahlbildschirm, der auf dem Pixel läuft, scheitert auf dem iPhone mit Notch. Er scheitert jedes Mal.

Das typische Szenario sieht so aus: Du kalkulierst eine App und bekommst in der Praxis anderthalb. Die zweite Hälfte taucht auf, wenn der Kunde die Android-Version öffnet und merkt, dass die Tastatur das Login-Feld verdeckt.

Die Kosten, die auf keiner Rechnung stehen

Es gibt Ausgaben, die dir am Anfang niemand zeigt, weil sie nicht in ein sauberes Angebot passen. Genau diese trennen ein Projekt, das lebt, von einem, das nach drei Monaten stirbt.

  • Abgelehntes Review. Apple setzt die App Store Review Guidelines hart durch. Eine schlecht begründete Berechtigung, ein fehlender Button zum Löschen des Kontos, und die App geht zurück. Jede Runde sind verlorene Tage.
  • Ein Mac. Ohne Apple-Hardware kein iOS-Build. Hast du keinen, ist es ein Kauf oder ein CI-Dienst in der Cloud mit monatlicher Rechnung.
  • Push-Benachrichtigungen. Du brauchst Firebase auf Android und APNs-Zertifikate bei Apple. Jedes bricht auf seine eigene Weise und erneuert sich seltener von allein, als dir lieb ist.
  • Jährliche Wartung. Jede neue Version von iOS und Android kann etwas kaputtmachen. Aktualisierst du nicht, verkommt die App, bis sie sich auf neuen Geräten nicht mehr installieren lässt.
  • Datenschutz-Konformität. App Privacy bei Apple, Data Safety bei Google. Du erklärst, was du erhebst, und musst es auch einhalten, unter der DSGVO.

Also, ehrliche Zahlen

Ich werde dir keinen Rechnungsbetrag einer Firma erfinden, die nicht existiert. Aber ich kann dir die Kostenstruktur geben, die wir in echten Projekten sehen.

Offizielle Gebühren: rund 124 Dollar im ersten Jahr. Entwicklung: hängt vom Umfang ab, und hier stecken neunzig Prozent des Geldes. Wartung: rechne mit einem wiederkehrenden Bruchteil der Build-Kosten, jedes Jahr, auf unbestimmte Zeit.

Die Faustregel, die ich Kunden gebe, ist einfach. Der Launch ist eine Ehe, kein Abendessen. Der Eintrittspreis ist der leichte Teil. Die Verpflichtung ist das, was wiegt.

Es gibt einen günstigeren Weg, und manchmal ist er der richtige

Nicht alles muss nativ sein. Eine Progressive Web App installiert sich aus dem Browser, läuft auf beiden Systemen mit einer einzigen Codebasis und entgeht den Gebühren und Reviews der Stores. Für viele Unternehmen reicht das mehr als aus.

Was du verlierst, ist das Siegel, im Store zu sein, einige tiefe Hardware-Zugriffe und das Vertrauen, das ein Icon im App Store immer noch vermittelt. Wenn deine App Vertrauen verkauft oder zuverlässige Push-Benachrichtigungen auf iOS braucht, willst du nativ.

Die richtige Frage lautet nicht "was kostet der Launch in beiden Stores". Sie lautet "brauche ich überhaupt beide Stores". Beantworte das zuerst. Das spart mehr als jede Preisverhandlung.


Wenn dir jemand ein App-Angebot ohne eine Zeile für Wartung vorlegt, versteckt er die Kosten nicht. Er schiebt sie auf in sechs Monate, wenn du längst unterschrieben hast.

Quellen
  1. 01Apple Developer Program
  2. 02App Store Review Guidelines
  3. 03Google Play Console — Registrierungsgebühr
  4. 04web.dev — Progressive Web Apps
  5. 05Google Play — Data safety
Auch:
Performance & SEONº 006

Was ein LCP von vier Sekunden mit deiner Checkout-Conversion macht

Vier Sekunden klingen nach wenig. Im Checkout sind sie der Unterschied zwischen Verkauf und abgebrochenem Warenkorb.

Web für KMUNº 005

Warum Ihre WordPress-Website von 2019 Sie 2026 Kunden kostet

Sieben Jahre sind eine Ewigkeit im Web. Was 2019 modern wirkte, vertreibt heute Kunden vor dem ersten Kontakt. Hier ist der Grund.

Zurück zum Journal