Web App vs Native App: welche Bauform deine Anforderungen trägt

Seit dem 31. August 2026 nimmt Google Play neue Apps und Updates nur noch an, wenn sie Android 16 ansteuern. Apple verlangt seit dem 28. April 2026, dass jede Einreichung mit Xcode 26 und einem SDK für iOS 26 gebaut ist. Keiner dieser beiden Stichtage hat damit zu tun, ob deine App fachlich noch passt. Es sind Termine, an denen Entwicklungsbudget fällig wird, ohne dass ein einziger Nutzer eine neue Funktion zu sehen bekommt. Die Frage Web App vs Native App entscheidet sich deshalb nicht an der Technik, sondern an deinen Anforderungen und daran, wer die Anwendung in fünf Jahren noch pflegt.

Damit wir über dasselbe reden: Hier geht es um die Bauform der mobilen Anwendung. Wie du eine Webanwendung intern aufziehst, als Single Page Application, als PWA oder klassisch mehrseitig, ist eine andere Ebene mit eigenen Folgen für SEO und Ladezeit. Die steht im Beitrag Webanwendung entwickeln lassen.

Web App vs Native App: woran es sich wirklich entscheidet

Fünf Achsen reichen. Alle fünf lassen sich mit Ja oder Nein beantworten.

Gerätefunktionen. Push-Nachrichten kann eine Web-App seit iOS 16.4 auch auf dem iPhone schicken. Das WebKit-Team hat das bei der Ankündigung klar eingegrenzt: Es gilt nur für Web-Apps, die der Nutzer vorher von Hand zum Home-Bildschirm hinzugefügt hat. Web Bluetooth läuft in Chrome und Edge, laut den Kompatibilitätsdaten von MDN unterstützen Safari und Firefox es gar nicht, auf dem iPhone fällt die Funktion damit aus. Barcodes lesen kann ein Browser über die Kamera, im Dauerbetrieb an der Rampe mit hunderten Scans pro Schicht liegt nativ bei Autofokus, Fehlerrate und Akku deutlich vorn. Und echter Offline-Betrieb mit späterer Synchronisation ist im Browser heikel, weil das Betriebssystem den lokalen Speicher einer Website räumen darf, wenn es eng wird. Genau das trifft dann den Monteur, dessen Daten seit gestern auf Übertragung warten.

Auffindbarkeit im Store. Soll die App über die Store-Suche gefunden werden, brauchst du nativ. Wird sie ohnehin nur an bekannte Nutzer verteilt, an eigene Mitarbeiter, an Stammkunden mit Login, ist der Store kein Vorteil, sondern eine zusätzliche Instanz zwischen dir und deinem Nutzer.

Zahl der Plattformen. In Deutschland liefen im Juli 2026 laut Statcounter rund 67 Prozent der mobilen Zugriffe über Android und rund 33 Prozent über iOS. Keine der beiden Seiten kannst du weglassen. Für nativ heißt das immer beide Plattformen, egal wie klein die Nutzergruppe ist.

Auslieferungsfrequenz. Eine Web-App ist beim nächsten Aufruf aktuell. Bei nativ liegen zwischen deinem Fertig und dem Gerät des Nutzers zwei Instanzen: die Prüfung durch Apple und Google und der Nutzer selbst, der das Update installieren muss. Wer alle zwei Wochen eine Korrektur ausliefern will, spürt das sofort.

Pflege in fünf Jahren. Die teuerste Achse, und die einzige, die in Angeboten fast nie auftaucht.

Die erzwungene Wartung, die kein Angebot ausweist

Eine native App kostet nicht einmal, sondern jedes Jahr. Ein Teil davon ist deine Entscheidung. Ein Teil nicht, und genau der taucht in Angeboten praktisch nie auf.

Google Play verlangt seit dem 31. August 2026, dass neue Apps und Updates Android 16 ansteuern. Bestands-Apps müssen mindestens Android 15 ansteuern, sonst werden sie neuen Nutzern auf neueren Geräten schlicht nicht mehr angezeigt. Wer den Termin reißt, kann eine Verlängerung bis zum 1. November 2026 beantragen. Das Muster wiederholt sich jedes Jahr mit der nächsten Android-Version. Bei Apple läuft es über die Entwicklungsumgebung: Seit dem 28. April 2026 wird jede Einreichung abgelehnt, die nicht mit Xcode 26 und einem SDK für iOS 26 gebaut wurde. Auch das kommt jährlich wieder.

Beides bedeutet: SDK anheben, gegen die neue Betriebssystem-Version testen, geänderte Berechtigungen und Hintergrundregeln nachziehen, neu einreichen. Erfahrungswert aus unseren Projekten, keine Erhebung: Das sind pro Codebasis und Jahr grob zwei bis fünf Entwicklertage, sofern man nicht drei Versionen im Rückstand ist. Bei zwei nativen Codebasen für iOS und Android landest du bei vier bis zehn Tagen. Mit dem in Deutschland üblichen Tagessatz von rund 1.000 Euro für Softwareentwicklung sind das 4.000 bis 10.000 Euro pro Jahr, für null neue Funktionen. Über fünf Jahre 20.000 bis 50.000 Euro.

Das ist nicht die gesamte Wartung, sondern der erzwungene Teil davon. Für die volle Pflege einer App rechnen wir mit 15 bis 20 Prozent der ursprünglichen Entwicklungskosten pro Jahr, aufgeschlüsselt im Beitrag App entwickeln lassen: Kosten. Bei einer nativen App für 140.000 bis 200.000 Euro sind das 21.000 bis 40.000 Euro jährlich. Der Unterschied zwischen beiden Zahlen ist der entscheidende: Über den großen Rest kannst du verhandeln, priorisieren, auch mal ein Jahr aussetzen. Über die vier bis zehn Tage Store-Pflicht nicht. Die fallen an, selbst wenn du zwölf Monate lang keine einzige fachliche Änderung beauftragst.

Cross-Platform mit Flutter oder React Native drückt das auf eine Codebasis, aber nicht auf null: Beide Stores wollen weiterhin bedient werden, nach unserer Erfahrung rund drei bis sechs Tage im Jahr. Eine Web-App hat diesen Posten gar nicht. Browser bleiben abwärtskompatibel, es gibt keinen Stichtag, an dem deine Anwendung aus dem Regal fliegt.

Die Entscheidungsregel in fünf Fragen

Geh alle fünf Fragen durch, keine überspringen. Die ersten beiden entscheiden die Bauform, die letzten drei beziffern, was diese Entscheidung dich kostet.

1. Braucht die Anwendung eine Gerätefunktion, die im Browser nicht zuverlässig läuft? Bluetooth-Kopplung, dauerhafter Hintergrundbetrieb, hochfrequentes Scannen, garantierter Offline-Betrieb mit Synchronisation.
2. Soll die App über die Store-Suche neue Nutzer gewinnen, die dich heute noch nicht kennen?

Zweimal Nein heißt Web. Mindestens einmal Ja heißt nativ oder Cross-Platform. Weiter mit den drei Preisschildern:

3. Musst du häufiger als monatlich ausliefern? Ja heißt: Jede Auslieferung läuft durch die Store-Prüfung und muss vom Nutzer installiert werden. Dann gehören Inhalte und Konfiguration in einen Teil, den die App zur Laufzeit aus dem Web nachlädt.
4. Verteilst du ausschließlich an bekannte Nutzer, eigene Leute oder Kunden mit Vertrag? Ja heißt: Der Store bringt dir nichts, und du musst den Verteilweg vor dem Bau klären, nicht danach.
5. Trägst du vier bis zehn Entwicklertage Pflichtwartung pro Jahr dauerhaft im Budget? Nein heißt: Dein Ja aus Frage 1 oder 2 trägt die Bauform nicht. Zurück auf Web.

Daraus folgt die Regel: Nativ lohnt sich ab genau einer Anforderung aus Frage 1 oder 2. Eine reicht. Darunter nicht, weil du dir mit der Bauform allein 4.000 bis 10.000 Euro erzwungene Wartung pro Jahr einkaufst, für die dein Nutzer nichts bekommt. Fällt Frage 1 auf Ja, ist es aber kein Grafik- oder Rechen-Grenzfall, nimm Cross-Platform statt zwei nativer Apps.

Wann du gar keine App brauchst

Der häufigste Fall im Mittelstand ist der, in dem gar keine App gebraucht wird. Eine mobil sauber bedienbare Website löst das Problem vollständig, und die App wäre ein Symbol. Das sagen wir auch dann, wenn wir sie bauen könnten.

Unsere Nutzungsschwelle dafür liegt bei rund drei Öffnungen pro Woche, kombiniert mit mindestens einer echten Gerätefunktion. Wer darunter bleibt, baut ein Icon. Die Anwendung wird einmal installiert, zweimal geöffnet und beim nächsten Handywechsel nicht wieder eingerichtet. Du hast die Entwicklung bezahlt, zahlst die Pflichtwartung weiter und hast trotzdem null Nutzung.

Ein Warnsignal, das wir ernst nehmen: Wenn im Kickoff niemand sagen kann, wie oft ein einzelner Nutzer die App pro Woche öffnen wird, gibt es keinen Anwendungsfall. Es gibt nur den Wunsch nach einem Icon auf dem Homescreen.

Der teuerste Fehler: die interne App im öffentlichen Store

Das Muster sehen wir regelmäßig. Ein Unternehmen lässt eine native App für die eigenen Mitarbeiter bauen, für Zeiterfassung, Auftragsrückmeldung oder Lagerbewegungen. Die Verteilung soll über den App Store laufen, weil das der bekannte Weg ist. Kurz vor dem Rollout kommt die Ablehnung.

Ursache: Apple ordnet Apps, die erkennbar nur für eine bestimmte Organisation und deren Mitarbeiter gedacht sind, nicht dem öffentlichen App Store zu. Es gibt zwei vorgesehene Wege, und sie kosten sehr unterschiedlich viel.

Der eine heißt Custom App und läuft über Apple Business Manager, ausgeliefert per Mobile Device Management oder Einlösecodes. Wer den nimmt, ohne ihn geplant zu haben, verschiebt den Rollout: Das Unternehmen muss sich in Apple Business Manager anlegen, braucht dafür eine D-U-N-S-Nummer und für die Verteilung auf die Geräte in aller Regel eine Geräteverwaltung. Wer bisher private Handys nutzen ließ, steht zusätzlich vor der Frage, wie eine Firmen-App auf ein Privatgerät kommt. Aus einem Entwicklungsprojekt wird nebenbei ein IT-Projekt.

Der andere Weg geht in diesem Moment regelmäßig unter, obwohl er der billigere ist: Unlisted App Distribution. Die App liegt regulär im App Store, taucht aber in Suche, Kategorien, Charts und Empfehlungen nicht auf und wird ausschließlich über einen Direktlink verteilt. Ohne Apple Business Manager, ohne Geräteverwaltung, ohne D-U-N-S-Nummer, ausdrücklich auch auf Geräten, die dem Mitarbeiter gehören. Du beantragst das bei Apple, nachdem die App die reguläre Prüfung bestanden hat, und vermerkst die Absicht in den Review-Notizen. Der Haken ist derselbe wie bei jedem Link: Wer ihn hat, kann die App laden. Eine Zugangsprüfung in der Anwendung selbst brauchst du also trotzdem, und genau dazu rät Apple auch.

Vermeiden lässt sich der ganze Verzug mit einer einzigen Frage vor dem ersten Klick: Auf welchem Weg kommt diese Anwendung auf die Geräte? Wer darauf keine belastbare Antwort hat, sollte über die Bauform noch nicht entschieden haben. Bei reiner Mitarbeiternutzung ist eine Web-App hinter Login übrigens meistens die kürzeste Strecke, weil sie Store, Geräteverwaltung und Update-Zwang komplett umgeht.

Was du jetzt tun kannst

Schreib die fünf Fragen auf und beantworte sie mit den Leuten, die die Anwendung später bedienen sollen, nicht mit der IT. Bleibt bei Frage 1 und 2 zweimal ein Nein stehen, ist die Sache entschieden, und du sparst dir eine fünfstellige Summe über die Laufzeit.

Wenn du dir bei einer der Fragen nicht sicher bist, schau mit uns in einer Fokus-Session drauf. In 60 Minuten gehen wir die fünf Fragen an deinem Fall durch und klären mit, auf welchem Weg die Anwendung später auf die Geräte kommt. Am Ende steht eine klare Empfehlung für eine Bauform, auch wenn sie lautet, dass eine gute mobile Website reicht. Und wenn die Entscheidung steht, siehst du auf unserer Seite zur Softwareentwicklung, wie wir solche Projekte aufsetzen und danach betreuen.