Nativ, Hybrid oder Cross-Platform: Welcher Tech-Stack sich 2026 für Mobile Apps lohnt

Cross-Platform App-Entwicklung gilt 2026 als der pragmatische Standard für die meisten Business-Apps. Trotzdem zahlen manche Unternehmen für den falschen Ansatz doppelt, andere sparen am falschen Ende. Welcher Tech-Stack unter dem Strich trägt, hängt an drei Fragen, die viele Auftraggeber viel zu spät stellen.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Die Wahl des Tech-Stacks entscheidet über Budget, Zeitplan und die Wartungslast der nächsten fünf Jahre. Viele Gründerinnen und Geschäftsführer behandeln diese Frage als reines Technikdetail und delegieren sie an die erstbeste Agentur. Genau an dieser Stelle beginnt der teuerste Fehler eines App-Projekts, lange bevor die erste Zeile Code entsteht.

Das Wichtigste in Kürze

• Drei Grundmodelle stehen zur Wahl: native Entwicklung, hybride Apps im WebView-Mantel und Cross-Platform-Frameworks wie React Native oder Flutter.
• Cross-Platform App-Entwicklung senkt die Kosten für Entwicklung und Wartung um rund 30 bis 40 Prozent, weil eine gemeinsame Codebasis iOS und Android bedient.
• Native lohnt sich bei tiefer Hardware-Nähe, hoher Grafiklast oder plattformspezifischen Sonderfunktionen.
• Das Backend entscheidet über die Wartbarkeit oft stärker als das Frontend-Framework auf dem Bildschirm.

Was unterscheidet nativ, hybrid und cross-platform überhaupt?

Die drei Begriffe kursieren oft synonym, meinen aber grundverschiedene Bauweisen. Native Entwicklung schreibt für jede Plattform einen eigenen Code: Swift für iOS, Kotlin für Android. Zwei Teams, zwei Codebasen, volle Nähe zur Hardware. Hybride Apps verpacken eine Webseite aus HTML, CSS und JavaScript in eine native Hülle, meist mit Ionic und Capacitor. Cross-Platform-Frameworks gehen einen dritten Weg und übersetzen einen gemeinsamen Code in echte native Bausteine.

Der Unterschied klingt akademisch, schlägt aber direkt aufs Budget durch. Ein Blick auf die aktuellen Trends der mobilen App-Entwicklung zeigt den Markt seit Jahren in Richtung geteilter Codebasis kippen. Die Trennschärfe zwischen den Modellen bleibt trotzdem wichtig, weil jeder Ansatz eigene Stärken und eigene Fallgruben mitbringt.

Ein häufiges Missverständnis betrifft das Wort „hybrid“. Manche Anbieter nennen React Native und Flutter hybrid, obwohl diese Frameworks native Komponenten erzeugen und nicht bloß eine Webseite einbetten. Diese saubere Dreiteilung, native Sprache gegen WebView gegen kompilierte Cross-Platform-Bausteine, verhindert teure Verwechslungen im Angebot. Der Sprachgebrauch im Erstgespräch verrät oft schon, wie genau eine Agentur arbeitet.

Warum ist der Tech-Stack eine Geschäftsentscheidung und keine reine Technikfrage?

Ein App-Projekt altert wie ein Firmenwagen: Der Kaufpreis steht im Angebot, die Werkstattrechnungen der nächsten fünf Jahre stehen nirgends. Genau diese Folgekosten machen den Tech-Stack zur Chefsache. Jede neue iOS- und Android-Version bringt Änderungen, die gepflegt werden wollen. Bei zwei nativen Codebasen fällt diese Pflege doppelt an.

Die Rechnung geht weit über den Launch hinaus. Für Wartung und Weiterentwicklung fallen im DACH-Raum jährlich 15 bis 25 Prozent des ursprünglichen Budgets an. Bei einer nativen Doppelentwicklung verdoppelt sich dieser Posten faktisch, weil jedes Update in zwei Sprachen erfolgt. Time-to-Market kommt als zweiter Hebel hinzu: Ein Team, das eine Codebasis pflegt, liefert Funktionen für beide Plattformen im selben Release aus, statt zwei getrennte Fahrpläne zu koordinieren.

Ein Rechenbeispiel verdeutlicht den Effekt. Eine Business-App für 60.000 Euro erzeugt bei 20 Prozent Wartung pro Jahr über fünf Jahre weitere 60.000 Euro an Folgekosten. Bei nativer Doppelentwicklung derselben App steigt sowohl der Einstieg als auch die jährliche Pflege, sodass die Fünf-Jahres-Summe leicht in den sechsstelligen Bereich klettert. Diese Zahlen sind gerundete Szenarien und keine Festpreise, illustrieren aber, warum der Angebotspreis nur die halbe Wahrheit erzählt.

Damit rückt die Frage weg von der Technik und hin zur Strategie. Der günstigste Stack im Angebot kann über drei Jahre zum teuersten im Betrieb werden. Ein sauber gewähltes Fundament trägt umgekehrt auch dann noch, wenn das Produkt wächst und neue Funktionen dazukommen. Aus dieser Perspektive bewerten Auftraggeber Frameworks nicht nach Mode, sondern nach der Summe aus Aufbau, Betrieb und Ausbau.

Wann lohnt sich native Entwicklung?

Native Entwicklung bleibt der Goldstandard für alles, was tief in die Hardware greift. Kameraverarbeitung in Echtzeit, Bluetooth-Low-Energy-Steuerung in der Industrie, aufwendige 3D-Grafik oder Augmented Reality holen aus dem Gerät heraus, was das jeweilige Betriebssystem hergibt. In diesen Fällen zahlt sich der getrennte Code aus, weil jede API-Neuerung von Apple oder Google sofort verfügbar ist, ohne den Umweg über ein Framework.

Auch Plattform-Erweiterungen sprechen für den nativen Weg. CarPlay, die Apple Watch, WearOS oder Live-Aktivitäten auf dem Sperrbildschirm setzen native Bausteine voraus. Langlebige Flaggschiff-Apps, die über Jahre viele plattformspezifische Neuerungen mitnehmen, fahren mit getrenntem Code oft ruhiger. Der native Vollzugriff rechnet sich dort, wo diese Sonderfunktionen den Kern des Produkts bilden.

Der Preis dafür bleibt hoch. Zwei Codebasen bedeuten rund 30 bis 50 Prozent höhere Kosten gegenüber einer geteilten Basis, weil zwei Entwicklungszyklen laufen. Der Personalbedarf steigt zusätzlich: Swift- und Kotlin-Fachleute sind teurer und seltener als Entwickler mit JavaScript-Hintergrund. Stundensätze deutscher App-Entwickler liegen ohnehin zwischen 100 und 180 Euro, jede weitere Spezialisierung treibt diesen Satz nach oben.

Ein Beispiel aus der Industrie zeigt die Grenze. Eine App, die einen Bluetooth-Sensor in Echtzeit ausliest und dabei dauerhaft im Hintergrund läuft, verlangt tiefe Systemzugriffe, die ein Framework nur mit nativen Zusatzmodulen nachbildet. Sobald solche Module den halben Code ausmachen, schmilzt der Vorteil der geteilten Basis dahin. In diesem Fall greift die native Entwicklung von Anfang an sauberer.

Für einen Großteil klassischer Business-Apps rechtfertigt der Nutzen diesen Aufwand nicht. Eine Anwendung, die Daten anzeigt, Formulare verarbeitet und mit einem Server spricht, braucht keine native Doppelentwicklung. Der native Sonderweg trägt dort, wo Performance und Hardware das Produkt definieren, nicht dort, wo eine App vor allem Prozesse abbildet. Als Faustregel gilt: Je näher am Metall, desto eher nativ.

Was leisten hybride Apps, und wo stoßen sie an Grenzen?

Hybride Apps im klassischen Sinn packen eine Webanwendung in eine native Hülle. Frameworks wie Ionic mit Capacitor oder das ältere Cordova rendern die Oberfläche in einem eingebetteten Browser, dem WebView. Der Vorteil liegt in der maximalen Wiederverwendung: Ein bestehendes Web-Team baut die App mit vertrauten Werkzeugen, oft direkt aus vorhandenem Code.

Die Grenze zeigt sich beim Gefühl. Ein WebView reicht native Gesten, Animationen und Scroll-Verhalten nur nach, statt diese selbst zu erzeugen. Eine konsumentennahe Marken-App verrät diesen Unterschied spätestens beim Scrollen. Für interne Werkzeuge, Kataloge oder inhaltslastige Anwendungen genügt der Ansatz problemlos. Bei einer Marken-App, die im Store gegen polierte Konkurrenz antritt, spart der WebView-Mantel am falschen Ende, nämlich am Eindruck, den die App beim ersten Öffnen hinterlässt.

Eine Sonderform verdient die Progressive Web App. Diese Variante verzichtet komplett auf den App-Store und läuft im mobilen Browser, lässt sich aber über einen Service Worker auf dem Homescreen ablegen und teilweise offline nutzen. Als günstigste Option startet die PWA bereits ab 5.000 bis 20.000 Euro. Der Verzicht auf verlässliche Push-Benachrichtigungen, Store-Präsenz und tiefen Hardware-Zugriff bleibt der Preis für diese Ersparnis. Für ein inhaltsgetriebenes Angebot ohne Store-Zwang reicht dieser Weg häufig aus.

Warum ist Cross-Platform App-Entwicklung 2026 für Business-Apps der Standard?

Cross-Platform-Frameworks haben den alten Ruf des Kompromisses abgelegt. React Native und Flutter teilen heute 70 bis 90 Prozent des Codes zwischen iOS und Android und übersetzen ihn in echte native Komponenten. Der frühere Ruck in Animationen, verursacht durch die alte JavaScript-Brücke, gehört mit der neuen Architektur von React Native der Vergangenheit an. Für Standard-Geschäftsanwendungen hat sich der Performance-Abstand zur nativen Variante praktisch geschlossen.

Die Verbreitung untermauert diesen Kurs. Laut einer Statista-Entwicklerbefragung nutzten 2023 rund 46 Prozent der Befragten Flutter und etwa 35 Prozent React Native. Auch der Stack Overflow Developer Survey führt beide Frameworks unter den meistgenutzten Werkzeugen professioneller Entwickler. Discord, Shopify und Microsoft Office setzen React Native produktiv ein und teilen dabei einen Großteil ihres Codes zwischen den Plattformen, was den Reifegrad der Technik belegt.

Der große Hebel bleibt die Wirtschaftlichkeit. Eine gemeinsame Codebasis senkt Entwicklungs- und Wartungskosten um 30 bis 40 Prozent, weil ein Team beide Plattformen bedient. Genau in dieser Nische arbeiten spezialisierte Softwareunternehmen wie Laramate, die React Native mit einem sauberen Backend auf PHP-Basis koppeln. Der JavaScript-Hintergrund vieler Fachkräfte vergrößert zudem den Bewerberpool, was die Suche nach Personal spürbar entspannt. Für B2B-Apps, Mitarbeiter-Werkzeuge und Kundenbindungs-Apps führt die Cross-Platform App-Entwicklung damit die Liste der ersten Wahl an.

Wie unterscheiden sich React Native und Flutter?

Innerhalb der Cross-Platform App-Entwicklung stehen zwei Frameworks im Zentrum, die unterschiedliche Philosophien verfolgen. React Native von Meta baut auf JavaScript und TypeScript und rendert native Plattform-Komponenten. Der größte praktische Vorteil liegt im Personal: JavaScript-Entwickler übertreffen die Zahl der Dart-Fachleute deutlich, und ein bestehendes React-Web-Team findet ohne Sprachwechsel in das mobile Projekt. Ein Team, das bereits mit React und einem Node-Backend arbeitet, teilt Logik und Denkweise über Web und App hinweg.

Flutter von Google verfolgt den umgekehrten Weg. Das Framework nutzt die Sprache Dart und malt jede Oberfläche über eine eigene Rendering-Engine selbst, statt native Bausteine zu bemühen. Das Ergebnis ist ein plattformübergreifend pixelgenau gleiches Bild, ideal für markenstarke Designs mit vielen Animationen. Google Pay, BMW und Alibaba setzen auf diesen Ansatz. Der Preis dafür ist ein etwas kleinerer, aber wachsender Personalmarkt.

Die Wahl folgt selten dem Bauchgefühl, sondern dem Team und dem Produkt. Ein React-lastiges Softwareunternehmen liefert mit React Native schneller, weil kein Umlernen nötig ist. Steht dagegen ein gestalterisch anspruchsvolles Interface mit eigenem Look im Vordergrund, spielt Flutter seine Stärke bei der Konsistenz aus. Beide Wege produzieren heute Apps, die Endnutzer kaum von nativer Software unterscheiden.

Ein weiterer Faktor gewinnt 2026 an Gewicht: die Anbindung von KI-Funktionen. Der JavaScript-nahe Werkzeugkasten rund um Sprachmodelle und Agenten lässt sich in React-Native-Projekte oft direkter einbinden als in andere Stacks. Für Apps, die auf Empfehlungslogik, Chat-Assistenten oder eingebettete Sprachmodelle setzen, verkürzt dieser Umstand die Wege spürbar.

Am Ende zählt die Verfügbarkeit von Fachkräften oft mehr als jedes technische Detail. Ein Framework, für das sich am Markt kaum jemand findet, wird Monate nach dem Launch zur Bremse. Der ehrliche Blick auf das eigene Team schlägt daher die Suche nach dem theoretisch besten Werkzeug.

Welche Rolle spielt das Backend bei der Stack-Wahl?

Die Framework-Debatte übersieht regelmäßig die Hälfte des Systems. Jede App, die Nutzer verwaltet, Daten speichert oder Zahlungen abwickelt, braucht eine solide Server-Schicht. Welche Rolle das Backend im Projekt spielt, zeigt sich am Kostenanteil: Der Aufbau der Server-Logik verschlingt oft 25 bis 50 Prozent des Gesamtbudgets.

Die Wahl des Frontends ändert an dieser Schicht wenig. Ob React Native, Flutter oder native Entwicklung, alle drei Wege sprechen am Ende über eine Schnittstelle mit demselben Server. Eine durchdachte API entscheidet daher stärker über die Wartbarkeit als das Framework auf dem Bildschirm. Ein aufgeräumtes Backend übersteht sogar einen späteren Wechsel des Frontends, ohne dass die gesamte Geschäftslogik neu entsteht.

Für kleine Projekte verkürzen fertige Dienste den Weg. Backend-as-a-Service-Plattformen wie Firebase oder Supabase liefern Authentifizierung, Datenbank und Push-Benachrichtigungen aus einem Baukasten und drücken die Anfangskosten. Ab einer gewissen Komplexität lohnt sich das eigene Backend, etwa mit Laravel, weil individuelle Geschäftsregeln, Schnittstellen zu ERP- und CRM-Systemen und volle Datenhoheit dann besser aufgehoben sind. Die Faustregel lautet: Standardbedarf deckt ein Baukasten, individuelle Logik verlangt ein eigenes Fundament.

Gerade im DSGVO-Raum wiegt die Datenhoheit schwer. Ein eigenes Backend erlaubt die Ablage sensibler Daten auf europäischen Servern und eine feine Kontrolle über Rollen und Rechte. Diese Kontrolle wird bei Apps mit Kunden-, Gesundheits- oder Finanzdaten schnell zum Ausschlusskriterium für schlüsselfertige Fremddienste. Auch die spätere Skalierung profitiert von einem eigenen Fundament, weil Lastspitzen und zusätzliche Schnittstellen sich gezielt abfangen lassen. Ein von Beginn an sauber geschnittenes Backend spart daher genau die Umbaukosten, die eine überstürzte Baukastenlösung nach dem ersten Wachstumsschub verursacht.

Was kostet welcher Ansatz im DACH-Raum?

Eine seriöse Zahl braucht ein Briefing, keine Pauschale. Trotzdem lassen sich belastbare Rahmen benennen. Eine einfache App mit wenigen Screens und schlankem Backend startet im DACH-Raum bei rund 15.000 bis 40.000 Euro. Komplexe Business-Apps mit Nutzerrollen, Schnittstellen und individuellem Design liegen zwischen 35.000 und 105.000 Euro, Enterprise-Lösungen darüber.

Die Verteilung des Budgets über die Projektphasen zeigt, wo das Geld hinfließt. Das Backend und das Frontend verschlingen zusammen den Löwenanteil, während Konzept und Veröffentlichung schlanker ausfallen.

Neben der Erstentwicklung verdient die Total Cost of Ownership Beachtung. Store-Gebühren, Server, Wartung und Sicherheits-Updates summieren sich über die Jahre. Apple verlangt für das Developer-Programm 99 Euro pro Jahr, Google Play einmalig 25 Euro, dazu kommen Umsatzbeteiligungen bei In-App-Käufen. Der Server-Betrieb schlägt je nach Last mit rund 50 bis mehreren Tausend Euro pro Monat zu Buche, und jedes neue Betriebssystem bringt Anpassungsbedarf. Die laufenden Kosten von 15 bis 25 Prozent pro Jahr entscheiden am Ende über die Wirtschaftlichkeit stärker als der Angebotspreis.

Ein Kostenfaktor bleibt oft unsichtbar: die Barrierefreiheit. Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz viele B2C-Apps zur barrierefreien Gestaltung nach dem Standard WCAG 2.1 AA. Die zuständige Bundesfachstelle Barrierefreiheit informiert über Umfang und Ausnahmen. Bei Verstößen drohen Bußgelder bis zu 100.000 Euro, weshalb die Konformität kein Nachgedanke sein sollte. Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz bleiben bei Dienstleistungen ausgenommen.

Welche Fehler kosten App-Projekte am meisten Geld?

Die teuersten Fehler entstehen selten im Code, sondern in der Planung. Der häufigste Griff daneben ist eine native Vollentwicklung für eine unbestätigte Idee. Ein aufwendiges Doppelprodukt, gebaut bevor überhaupt Nutzer den Bedarf bestätigt haben, bindet Budget in einem Ansatz, den der Markt später vielleicht gar nicht verlangt. Ein schlankes MVP liefert nach sechs bis acht Wochen echtes Feedback, günstiger und schneller.

Ein zweiter Irrtum betrifft die Qualitätssicherung. Eine gemeinsame Codebasis bedeutet nicht automatisch weniger Fehler. Android läuft auf tausenden Geräten mit verschiedenen Bildschirmen und Systemversionen, was den Testaufwand für jeden Ansatz hochhält. Die Geräte-Matrix verlangt reale Tests, keine Annahmen, sonst schlagen Regressionsfehler nach dem Launch teuer zurück.

Der dritte Fehler steckt im Preisvergleich selbst. Der niedrigste Stundensatz führt nicht zwangsläufig zu den niedrigsten Gesamtkosten. Offshore-Projekte mit günstigem Satz kosten häufig mehr an Kommunikation, Koordination und Nacharbeit, als die Ersparnis je einbringt. Auch das Design gerät unter Druck: Mit 15 bis 30 Prozent des Budgets bleibt der Design-Anteil der am häufigsten unterschätzte Posten, obwohl schwaches Design später jede Supportabteilung belastet.

Ein vierter Fehler betrifft den Funktionsumfang. Ohne klaren Release-Schnitt wächst der Wunschkatalog schneller als das Budget, und jede zusätzliche Funktion addiert Stunden. Ein sauber definiertes erstes Release hält die Kosten planbar und verschiebt Zusatzwünsche in spätere Ausbaustufen, statt das Startbudget zu sprengen.

Wie treffen Sie die Entscheidung für Ihr Projekt?

Die Entscheidung fällt entlang weniger Fragen. Steht die Hardware im Mittelpunkt, etwa Kamera, Sensorik oder Grafik, spricht viel für native Entwicklung. Zählt Time-to-Market bei überschaubarem Hardware-Bedarf, führt der Weg zu Cross-Platform. Genügt eine reine Inhaltsanwendung ohne Store-Zwang, reicht oft eine PWA.

Die zweite Frage betrifft das Team, nicht die Technik. Ein Stack, für den sich am Markt kaum Fachkräfte finden, wird 18 Monate nach dem Launch zum Problem, nicht am Starttag. Der größte Fehler steckt daher selten im Framework selbst, sondern in der Begründung dahinter. Eine Agentur, die schon vor dem ersten Gespräch weiß, dass die App in einem bestimmten Framework entstehen soll, verkauft ihr Lieblingswerkzeug, nicht Ihre Lösung.

Als schnelle Orientierung dienen vier Leitfragen, die das Feld sortieren:

• Hardware-Nähe: Braucht die App Kamera-Processing, Sensorik oder AR, führt der Weg eher zu nativer Entwicklung.
• Zeitdruck: Sollen iOS und Android gleichzeitig starten, spielt die Cross-Platform App-Entwicklung ihre Stärke aus.
• Personal: Arbeitet Ihr Team bereits mit React und JavaScript, liegt React Native nahe.
• Design: Steht ein markenstarkes, animationsreiches Interface im Zentrum, überzeugt Flutter.

Deshalb lohnt der Blick auf den Partner mehr als der Blick auf das Framework. Ein seriöses Softwareunternehmen fragt zuerst nach Nutzern, Backend, Budget und Wartungsplan, bevor irgendeine Technologie auf den Tisch kommt. Wie Sie den passenden App-Entwickler finden, entscheidet über den Projekterfolg oft stärker als die Wahl zwischen React Native und Flutter. Die richtige Reihenfolge heißt: erst das Produkt verstehen, dann den Stack wählen.

Am Ende bleibt die Wahl des Tech-Stacks eine Rechnung über Jahre, keine Momentaufnahme. Wer nativ, hybrid und cross-platform an den eigenen Anforderungen misst, statt an einer Modewelle, trifft eine Entscheidung, die auch nach dem dritten Betriebsjahr noch trägt. Der beste Stack ist der, den Ihr Produkt und Ihr Team gemeinsam tragen können.

Glossar

• Native App: Anwendung, die für eine einzelne Plattform in deren eigener Sprache entsteht, Swift für iOS und Kotlin für Android. Native Apps bieten die höchste Performance und den vollsten Hardware-Zugriff.
• Cross-Platform: Entwicklungsansatz, bei dem eine geteilte Codebasis über Frameworks wie React Native oder Flutter in native Komponenten für iOS und Android übersetzt wird. Der Kernvorteil liegt in geringeren Kosten bei nahezu nativer Performance.
• Hybrid-App (WebView): App, die eine Webanwendung in eine native Hülle verpackt, meist über Ionic oder Capacitor. Der WebView rendert die Oberfläche im eingebetteten Browser statt in nativen Bausteinen.
• React Native: Von Meta entwickeltes Cross-Platform-Framework auf Basis von JavaScript und TypeScript. Das Framework übersetzt den geteilten Code in native Plattform-Komponenten.
• Flutter: Von Google entwickeltes Cross-Platform-Framework mit der Sprache Dart und einer eigenen Rendering-Engine. Flutter malt jede Oberfläche selbst und erreicht so ein plattformübergreifend gleiches Bild.
• Progressive Web App (PWA): Webanwendung, die im Browser läuft und sich auf dem Homescreen installieren lässt, ohne den App-Store. Die PWA verzichtet auf tiefen Hardware-Zugriff zugunsten geringer Kosten.
• Total Cost of Ownership: Summe aus Erstentwicklung, Betrieb, Wartung und Weiterentwicklung über die gesamte Nutzungsdauer. Diese Gesamtrechnung übersteigt den Angebotspreis oft deutlich.

FAQ

Was ist der Unterschied zwischen Cross-Platform App-Entwicklung und nativer Entwicklung?

Native Entwicklung schreibt für iOS und Android je einen eigenen Code und erreicht maximale Performance. Cross-Platform App-Entwicklung nutzt eine geteilte Codebasis über React Native oder Flutter und senkt Kosten sowie Wartungsaufwand um rund 30 bis 40 Prozent.

Ist Cross-Platform langsamer als nativ?

Für Standard-Geschäftsanwendungen hat sich der Abstand praktisch geschlossen. Spürbar wird der Unterschied erst bei hoher Grafiklast, Echtzeit-Verarbeitung oder tiefer Hardware-Nähe.

Wann lohnt sich eine native App trotzdem?

Native Entwicklung trägt bei Spielen, Augmented Reality, aufwendiger Kameraverarbeitung oder industrieller Bluetooth-Steuerung. Der Mehrpreis von 30 bis 50 Prozent rechnet sich nur, sofern Hardware und Performance das Produkt definieren.

Was kostet eine App in Deutschland?

Eine einfache App startet bei rund 15.000 bis 40.000 Euro, komplexe Business-Apps liegen zwischen 35.000 und 105.000 Euro. Die laufenden Kosten betragen jährlich 15 bis 25 Prozent des Erstbudgets.

Müssen Apps barrierefrei sein?

Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz viele B2C-Apps zur Barrierefreiheit nach WCAG 2.1 AA. Bußgelder reichen bis 100.000 Euro, Kleinstunternehmen bleiben bei Dienstleistungen ausgenommen.

Quellen

• Statista: Cross-Platform-Framework-Nutzung unter Entwicklern (Befragung 2023)
• Stack Overflow Developer Survey 2024
• Bundesfachstelle Barrierefreiheit: Barrierefreiheitsstärkungsgesetz (BFSG)
• DACH-Kostenerhebungen App-Entwicklung 2026 (induux, mvst, kigazon, campus-itconsulting)