Der Launch ist erst der Anfang

Viele Unternehmen planen sorgfältig Budget und Zeitplan für die Entwicklung ihrer App – und vergessen dabei einen wesentlichen Faktor: die laufenden Kosten nach dem Go-live. Eine App ist kein einmaliges Produkt, sondern ein lebendiges System, das gepflegt, aktualisiert und weiterentwickelt werden muss. Wer das unterschätzt, riskiert sicherheitskritische Lücken, schlechte Store-Bewertungen und letztlich eine App, die kaum noch genutzt wird.

Warum braucht eine App regelmäßige Wartung?

Die Antwort liegt in der Natur mobiler Plattformen:

Betriebssystem-Updates: Apple und Google veröffentlichen jährlich neue iOS- und Android-Versionen – häufig mit Änderungen, die bestehende Apps beeinflussen. Eine App, die unter der vorletzten OS-Generation einwandfrei lief, kann nach dem nächsten großen Sprung optisch oder funktional brechen.

Sicherheitslücken: Abhängigkeiten (Libraries, SDKs) werden regelmäßig mit Sicherheits-Patches versorgt. Wer nicht aktualisiert, häuft technische Schulden an – und riskiert Angriffsflächen.

Store-Anforderungen: Apple und Google verschärfen regelmäßig ihre Richtlinien. Apps, die nicht angepasst werden, können aus dem Store entfernt werden.

Nutzerfeedback: Bugs, die erst im Betrieb auftauchen, müssen schnell behoben werden – eine langsame Reaktion kostet Bewertungen und Vertrauen.

Was App-Wartung kostet – und was den Preis treibt

Die ehrliche Antwort: Es gibt keine feste Jahreszahl. Wartungsaufwand ist keine Konstante, sondern folgt aus wenigen Treibern – und die schwanken von Jahr zu Jahr erheblich.

Treiber 1 – die Bibliotheks-Oberfläche. Jedes eingebundene SDK ist eine Quelle für Breaking Changes und Sicherheits-Patches. Eine App, die mit wenig Fremdcode auskommt, kann ein Jahr lang praktisch wartungsfrei laufen. Eine App mit einem Dutzend Libraries hat fast immer irgendwo ein Update, das nachgezogen werden muss.

Treiber 2 – die Plattformen ticken unterschiedlich und unregelmäßig. Aus mehreren Jahren Betrieb: Es gab Jahre, in denen von Apples Seite fast nichts kam und eine schlanke iOS-App einfach weiterlief. Und es gab Phasen, in denen Google Play alle paar Monate etwas verlangte. Ein frisches Beispiel aus unserer eigenen Play Console: Für eine der von uns betreuten Apps meldete Google, dass die genutzte Google Play Billing Library ausläuft – bis Ende August 2026 musste die App auf mindestens Version 8.0.0 aktualisiert sein, sonst hätte Google weitere Updates abgelehnt. Solche Fristen werden von außen gesetzt, sind nicht verhandelbar und tauchen ohne Vorlauf im Dashboard auf – und genau deshalb muss Wartung manchmal recht zügig erfolgen: nicht weil die App fachlich versagt, sondern weil eine Plattform-Uhr abläuft, auf die niemand Einfluss hat. Wer mit einer glatten Prozentzahl pro Jahr plant, plant an dieser Realität vorbei.

Treiber 3 – die geforderte Reaktionszeit. Eine 24-Stunden-Zusage für kritische Fehler kostet mehr Bereitschaft als „wir schauen es uns diese Woche an".

Für die grobe Budgetplanung über den gesamten Lebenszyklus taugt trotzdem eine Faustregel – ergänzend zu unseren ausführlichen Entwicklungskosten: im Mittel 15–25 % der ursprünglichen Entwicklungskosten pro Jahr, bei einer App für 60.000 € also grob 9.000–15.000 €. Entscheidend ist „im Mittel": In einem ruhigen Jahr liegen Sie darunter, in einem Jahr mit großem OS-Sprung oder verschärften Store-Regeln darüber. Ein guter Wartungspartner glättet diese Schwankung über ein festes Kontingent, statt Ihnen jedes Quartal eine Überraschung zu schicken.

Was gehört in einen guten Wartungsvertrag?

Ein strukturierter Wartungsvertrag schafft Planbarkeit für beide Seiten. Achten Sie auf:

Native vs. Cross-Plattform: Unterschiede bei der Wartung

Ob Ihre App nativ (Swift/Kotlin) oder mit einem Cross-Plattform-Framework (Flutter, .NET MAUI, React Native) entwickelt wurde, verändert nicht nur den Wartungsaufwand, sondern auch, wie schnell Sie im Ernstfall handeln können.

Der Vorteil von Cross-Plattform liegt im Alltag: iOS und Android teilen sich eine Codebasis, ein Update deckt oft beide Plattformen ab – das spart bei laufender Pflege und kleineren Anpassungen Aufwand.

Der Nachteil zeigt sich, wenn eine Plattform etwas erzwingt. Bei einer nativen App übernehmen Sie ein neues Xcode oder Android-SDK am Tag der Veröffentlichung. Bei Cross-Plattform hängt ein zusätzlicher Hersteller in der Kette: Sie können erst handeln, wenn Microsoft, Google oder Meta ihr Framework auf die neue Umgebung nachgezogen haben. Das ist keine Kleinigkeit, weil Apple es zur harten Bedingung macht – neue App-Uploads müssen mit einem aktuellen iOS-SDK gebaut sein (seit April 2025 etwa mit dem iOS-18-SDK), und dieses SDK steckt nur in einer bestimmten Xcode-Version. Unterstützt Ihr Framework dieses Xcode noch nicht, ist die Einreichung schlicht blockiert, bis der Hersteller nachliefert. Dieses Muster kennen wir noch aus Xamarin-Zeiten – etwa das Warten auf aktualisierte Google-Maps-Bindings; es existiert weiterhin, nur ist die Wartezeit heute meist Tage bis Wochen statt Monate.

Die drei Frameworks stehen dabei unterschiedlich da:

Kurz: Nativ gibt Ihnen die schnellste Reaktionsfähigkeit bei erzwungenen Änderungen, Cross-Plattform den geringeren Alltagsaufwand. Welche Seite schwerer wiegt, hängt davon ab, wie kritisch schnelle Update-Fähigkeit für Ihre App ist. Mehr zu den Unterschieden lesen Sie in unserem Vergleich der Frameworks.

Lauth IT: Wartung aus einer Hand

Lauth IT GmbH betreut Apps, die wir selbst entwickelt haben – aber auch Apps, die von anderen Dienstleistern stammen. Wir übernehmen Code-Überprüfung, Refactoring und laufende Pflege und bieten flexible Wartungsverträge mit klaren Reaktionszeiten.

Ihre App braucht einen verlässlichen Wartungspartner? Sprechen Sie uns an – wir schauen uns Ihren Code an und machen Ihnen ein transparentes Angebot.

Quellen: Apple Developer – Upcoming requirements (iOS-18-SDK-Pflicht) · Flutter – How Flutter stays ahead of iOS releases (Day-0-Zusage)