Was kostet eine App? Native, Cross-Platform oder Web-App

Entscheidend ist, was hinter den Bildschirmen passiert. Eine App mit zehn Ansichten kann günstiger sein als eine mit fünf, wenn diese fünf Daten aus drei Systemen abgleichen. In der Praxis bestimmen diese Punkte den Aufwand:

• Funktionsumfang: Login, Push-Benachrichtigungen, Kamera, Standort, Offline-Modus oder Zahlungen kommen jeweils als eigener Arbeitsblock dazu.
• Backend und Schnittstellen: Fast jede App braucht einen Server für Daten und Nutzerkonten. Anbindungen an ERP, CRM oder Warenwirtschaft sind oft der größte Einzelposten.
• Plattformen: Nur iOS, nur Android, beide oder zusätzlich Browser – jede Plattform will getestet und gepflegt werden.
• Design: Ein individuelles Interface mit Animationen kostet mehr als eines, das sich an den Standards von iOS und Android orientiert.
• Tests: Apps laufen auf sehr vielen Geräten und Bildschirmgrößen. Tests auf echten Geräten und eine Beta-Phase gehören in jedes Budget.
• Store-Freigabe: Store-Texte, Screenshots, Datenschutzangaben und der Review-Prozess bei Apple und Google brauchen Zeit, gelegentlich auch eine zweite Runde.

Am günstigsten ist meist die Web-App, am teuersten die native Entwicklung für beide Plattformen. Native Apps werden für jedes System eigens geschrieben, in Swift für iOS und in Kotlin für Android. Cross-Platform-Frameworks wie React Native oder Flutter erzeugen beide Apps aus einer gemeinsamen Codebasis. Eine Web-App oder Progressive Web App (PWA) läuft im Browser und lässt sich auf dem Homescreen installieren.

Native Entwicklung lohnt sich vor allem bei sehr rechenintensiven Anwendungen oder wenn Sie neueste Systemfunktionen sofort nutzen müssen. Für die meisten Kunden- und Mitarbeiter-Apps entwickle ich plattformübergreifend, weil iOS und Android so dauerhaft auf demselben Stand bleiben. Und wo eine PWA reicht, ist sie die ehrlichste Lösung: Seit iOS und iPadOS 16.4 kann auch eine auf dem Homescreen installierte Web-App Push-Benachrichtigungen empfangen.

Nach dem Launch fallen Gebühren für die Stores, Kosten für Server und vor allem regelmäßige Wartung an. Die Store-Gebühren selbst sind überschaubar:

• Apple Developer Program: 99 US-Dollar pro Mitgliedsjahr; der Betrag in Euro wird je nach Region bei der Anmeldung angezeigt.
• Google Play Console: einmalige Registrierungsgebühr von 25 US-Dollar.
• Apple-Provision: Im App Store Small Business Program sinkt die Provision auf bezahlte Apps und In-App-Käufe auf 15 %, solange die Erlöse unter 1 Million US-Dollar pro Jahr bleiben.
• Google-Provision: Für Nutzer im EWR gilt seit dem 30. Juni 2026 eine neue Gebührenstruktur; je nach Transaktion und Programm liegen die Sätze zwischen 10 % (Abos) und 25 %, bei Abrechnung über Google Play zuzüglich 5 % Abrechnungsgebühr.

Die Provisionen betreffen nur Verkäufe digitaler Inhalte über die App. Laut Google vertreiben 97 % der Entwickler ihre Apps ohne Servicegebühr – eine kostenlose Service- oder Mitarbeiter-App zahlt also in der Regel nichts. Prüfen Sie die aktuellen Sätze vor dem Start, denn beide Anbieter passen ihre Bedingungen regelmäßig an.

Der größere Posten ist die Wartung. Seit dem 28. April 2026 müssen neue Uploads im App Store mit Xcode 26 und dem SDK für iOS 26 gebaut sein. Bei Google müssen neue Apps und Updates seit dem 31. August 2026 auf Android 16 (API-Level 36) ausgerichtet sein. Wer seine App ein Jahr nicht anfasst, kann also keine Fehlerkorrektur mehr ausliefern, ohne erst nachzurüsten. Als Richtwert sollten Sie pro Jahr etwa 15–20 % der ursprünglichen Entwicklungskosten für Pflege, Updates und Server einplanen.

Weil Sie mit einem Minimum Viable Product (MVP) früh lernen, was Nutzer wirklich brauchen, bevor das große Budget fließt. Ein MVP enthält nur die Kernfunktionen, die das wichtigste Problem lösen – sauber gebaut, aber ohne Extras. So gehen Sie dabei vor:

1. Kernnutzen festlegen: Welches eine Problem löst die App besser als jede Alternative?
2. Klickbaren Prototyp testen: Schon wenige echte Nutzer am Gerät decken viele Verständnisprobleme auf, bevor programmiert wird.
3. Erste Version veröffentlichen: lieber mit drei Funktionen live als mit zwölf Funktionen in der Warteschleife.
4. Nutzung messen und ausbauen: Neue Funktionen entstehen auf Basis echter Daten, nicht nach Bauchgefühl.

Ein MVP ist keine Wegwerf-App. Die Architektur sollte von Anfang an so angelegt sein, dass weitere Funktionen ohne Neubau hinzukommen können.

Über ein kurzes Konzept mit Prototyp, bevor die eigentliche Entwicklung beginnt. Darin werden Zielgruppe, Funktionen, Plattformen und Schnittstellen festgelegt und mit Stunden hinterlegt. Achten Sie im Angebot darauf, dass Store-Einreichung, Tests, Backend und Wartung ausdrücklich enthalten oder getrennt beziffert sind – und dass Quellcode und Store-Konten Ihnen gehören.

Wenn die App vor allem interne Abläufe abbilden soll, kann auch eine Browser-Anwendung genügen – wann sich eigene Software lohnt, beschreibe ich im Artikel Standardsoftware oder Individualsoftware. Wie ich von der Idee bis zur Veröffentlichung im Store vorgehe, finden Sie auf der Seite zu Apps für iOS und Android. Einen ersten Überblick über Ihre Möglichkeiten bekommen Sie im kostenlosen Bedarfscheck.