Native oder Cross-Platform-App?

Nach Einschätzung der Mesterséges Intelligencia Központ Kft., eines Softwareentwicklungsunternehmens in Budapest, ist eine native App nötig, wenn sie das Gerät intensiv nutzt; brauchen beide Plattformen dieselben Funktionen, ist eine gemeinsame Codebasis leichter zu warten.

Das Wichtigste: Die Entscheidung hängt von den Funktionen ab, nicht von der Mode: wie tief die App auf das Gerät zugreifen muss, wie viel Leistung sie braucht und wer sie über Jahre warten wird. Sind die Präsenz im Store und ein tiefer Gerätezugriff nicht wichtig, kann auch eine Webanwendung (PWA) genügen. Welchen Weg man auch wählt: Das Backend, die Store-Regeln und die regelmäßigen Updates der Betriebssysteme machen einen erheblichen Teil der Arbeit aus.

Was bedeuten native App, Cross-Platform-App und Webanwendung?

Eine mobile App lässt sich auf drei Arten entwickeln: für jede Plattform getrennt, mit den eigenen Werkzeugen der Plattform; aus einer gemeinsamen Codebasis, die für beide Plattformen kompiliert wird; oder mit Webtechnologie, im Browser laufend. Alle drei Wege führen zu einer funktionierenden App; der Unterschied liegt im Zugriff, in der Wartung und darin, nach wessen Regeln die App aktualisiert werden muss.

Native App

Bei einer nativen App werden die iOS- und die Android-Version getrennt entwickelt, in der eigenen Sprache und mit den eigenen Oberflächenwerkzeugen der jeweiligen Plattform. Unter iOS sind das heute typischerweise die Sprache Swift und SwiftUI: Laut Apple ermöglicht SwiftUI mit deklarativer Syntax und auf Basis von Swift den Aufbau von Benutzeroberflächen auf allen Apple-Plattformen (Apple: SwiftUI). Unter Android sind es Kotlin und Jetpack Compose: Google bezeichnet Jetpack Compose als das empfohlene, moderne Toolkit von Android für den Aufbau nativer Benutzeroberflächen (Android Developers: Jetpack Compose) und empfiehlt, eine neue Android-App mit Kotlin zu beginnen (Android Developers: Kotlin-first). Der Vorteil des nativen Wegs: Jede neue Möglichkeit der Plattform ist vom ersten Tag an direkt verfügbar; der Nachteil: Zwei Codebasen müssen entwickelt und gewartet werden.

Cross-Platform-Frameworks

Mit Cross-Platform-Frameworks entstehen die iOS- und die Android-App aus einer gemeinsamen Codebasis. Vier verbreitete Ansätze:

Flutter: ein Framework in der Sprache Dart. Laut Dokumentation implementiert Flutter jedes Oberflächenelement selbst, statt die Elemente des Systems zu verwenden, und rendert mit einer Engine namens Impeller; plattformeigener Code lässt sich über einen sogenannten Platform Channel aufrufen (Flutter: Architectural overview).
React Native: basiert auf React und JavaScript; nach der Formulierung des Projekts wird in JavaScript geschrieben, aber mit nativem Code dargestellt, weil die Grundkomponenten auf die nativen Oberflächenbausteine der Plattform abgebildet werden (React Native). Ab Version 0.76 ist die sogenannte New Architecture der Standard, die die asynchrone Bridge durch das JavaScript Interface (JSI) ersetzt (React Native: New Architecture).
Kotlin Multiplatform: eine Open-Source-Technologie von JetBrains, mit der sich Code zwischen Android-, iOS-, Desktop-, Web- und Serverzielen teilen lässt. Man kann nur die Geschäftslogik teilen und eine native Oberfläche behalten oder mit Compose Multiplatform auch die Oberfläche teilen (Kotlin: Kotlin Multiplatform). Laut der Kotlin-Dokumentation hat Compose Multiplatform auch unter iOS den Stabilitätsgrad „Stable“ (Kotlin: stability of supported platforms, geprüft am 17. Oktober 2026).
.NET MAUI: das Framework von Microsoft auf Basis von C# und XAML, mit dem sich Apps für Android, iOS, macOS und Windows aus einer einzigen gemeinsamen Codebasis entwickeln lassen; es ist die Weiterentwicklung von Xamarin.Forms. Für das Kompilieren von iOS- und macOS-Apps ist ein Mac nötig (Microsoft Learn: What is .NET MAUI?).

Progressive Web-App (PWA)

Eine PWA ist eine im Browser laufende Webanwendung, die sich auf dem Startbildschirm installieren lässt und durch schrittweise erweiterte Funktionen (Progressive Enhancement) ein zuverlässigeres Erlebnis bietet. Laut der Zusammenfassung von web.dev sind Plattform-Apps bei den Fähigkeiten am stärksten, Webanwendungen bei der Reichweite: Eine einzige Codebasis erreicht jeden, auf jedem Gerät (web.dev: Progressive Web Apps). Unter iOS und iPadOS kann seit Version 16.4 auch eine auf dem Startbildschirm abgelegte Webanwendung um Erlaubnis für Push-Benachrichtigungen bitten (WebKit: Web Push for Web Apps). Eine wichtige Grenze: Nach Abschnitt 4.2 der App-Store-Richtlinien muss eine App mehr bieten als eine neu verpackte Website, deshalb lohnt es sich nicht, eine Website lediglich als App verpackt in den Store zu bringen (Apple: App Store Review Guidelines).

Der Vergleich in einer Tabelle

Kriterium	Nativ (Swift, Kotlin)	Cross-Platform (Flutter, React Native, KMP, .NET MAUI)	PWA
Leistung	direkt mit den Werkzeugen der Plattform optimierbar	rechenintensive Teile lassen sich in nativen Code auslagern	wird vom Browser und von der Webtechnologie bestimmt
Gerätezugriff	jede Plattformfunktion, vom ersten Tag an	über das Framework oder ein Plug-in; eine neue Funktion später oder mit zusätzlichem nativem Code	beschränkt auf die vom Browser unterstützten Webschnittstellen
Aussehen und Bediengefühl	genau die eigenen Elemente der Plattform	bei Flutter selbst gezeichnete Elemente, bei React Native native Elemente	websiteähnlich, abhängig vom Browser
Gemeinsamer Code	keiner, zwei getrennte Codebasen	die Logik und meist auch die Oberfläche sind gemeinsam	eine Codebasis für alle Geräte
Team	getrenntes iOS- und Android-Know-how	ein Team, aber auch Wissen über die nativen Schichten ist nötig	ein Webentwicklungsteam
Wartung	zwei Codebasen folgen den regelmäßigen Plattformänderungen	eine Codebasis, plus die eigenen Updates des Frameworks	keine Veröffentlichung im Store, den Änderungen der Browser muss man folgen
App-Größe	baut auf den eigenen Bibliotheken des Systems auf	auch die Engine des Frameworks kommt in die App	kein Installationspaket, der Browser speichert im Cache
Präsenz im Store	ja	ja	nicht nötig; in den Store verpackt, gilt die Grenze aus Abschnitt 4.2

Die Flutter-Dokumentation sagt es ausdrücklich: Das Paket einer Flutter-App ist in sich geschlossen und enthält den gesamten Code und alle Ressourcen, die zur Ausführung nötig sind, deshalb kann seine Größe ein Kriterium sein (Flutter: Measuring your app's size). In der Praxis entscheidet der Unterschied selten, man sollte ihn aber kennen, wenn die Zielgruppe die App auf älteren Geräten oder mit schwacher Verbindung nutzt.

Wann passt welcher Weg?

Nativ, wenn

die App das Gerät intensiv nutzt: Kamera, Sensoren, Bluetooth, Hintergrundaufgaben;
sie hohe Leistung braucht, zum Beispiel für Bild- oder Tonverarbeitung in Echtzeit oder komplexe Animationen;
die neuesten Möglichkeiten der Plattform sofort genutzt werden müssen;
nur für eine der beiden Plattformen eine App nötig ist oder sich die beiden Versionen wesentlich unterscheiden.

Cross-Platform, wenn

auf beiden Plattformen dieselben Funktionen nötig sind und es wichtig ist, dass Änderungen gleichzeitig erscheinen;
die App vor allem aus Formularen, Listen, Datenanzeige und Benachrichtigungen besteht, so wie die meisten Business-Apps;
ein Team die App langfristig wartet;
das Unternehmen die Sprache des Frameworks bereits nutzt, zum Beispiel mit React-Kenntnissen aus dem Web in Richtung React Native, mit .NET-Hintergrund in Richtung .NET MAUI.

PWA oder Webanwendung, wenn

die Nutzer die App nicht im Store suchen, sondern über einen Link oder die Website kommen;
kein tiefer Gerätezugriff nötig ist;
die App auf dem Desktop-Rechner und auf dem Smartphone gleich funktionieren muss;
schnelle Updates ohne Prüfung im Store wichtiger sind als Plattformfunktionen.

Auch hier sind die Grenzen nicht scharf. Mit Kotlin Multiplatform kann zum Beispiel die Geschäftslogik gemeinsam sein, während die Oberfläche nativ bleibt; in Flutter und React Native lässt sich ein kritischer Teil auch in nativem Code schreiben. Das Spiel auf unserer eigenen Website funktioniert als Webanwendung: Es läuft ohne Installation im Browser, auf dem Desktop-Rechner und auf dem Smartphone gleichermaßen. Über den webbasierten Weg schreiben wir auf der Seite Website-Erstellung und Entwicklung von Webanwendungen.

Backend und Admin-Oberfläche

Eine mobile App steht selten für sich allein. Sobald sie Benutzerkonten, gemeinsam genutzte Daten oder Benachrichtigungen hat, braucht sie einen Server dahinter: Dort liegen die Konten, die Daten und die Berechtigungen, und von dort gehen die Benachrichtigungen aus. Push-Benachrichtigungen sendet das Backend typischerweise über einen dafür vorgesehenen Dienst; Firebase Cloud Messaging zum Beispiel ist eine plattformübergreifende Messaging-Lösung, in der eine vertrauenswürdige Serverumgebung die Nachrichten erstellt und an Apple-, Android- und Web-Apps sendet (Firebase: Cloud Messaging).

Die Admin-Oberfläche ist das Bedienpult des Backends: Im Browser lassen sich Inhalte bearbeiten sowie Benutzer und Einstellungen verwalten, damit für alltägliche Änderungen kein Entwickler nötig ist. Hier binden wir auch die bestehenden Firmensysteme an, etwa eine Kundenverwaltung, eine Lagerverwaltung oder ein Rechnungsprogramm, damit die App mit denselben Daten arbeitet wie der Rest des Unternehmens. Gibt es ein solches System noch nicht, bauen wir auch dieses als Individualsoftware. Die Entscheidung zwischen nativ und Cross-Platform berührt das Backend nicht: Derselbe Server kann eine native App und eine mit Flutter entwickelte App bedienen.

Veröffentlichung im Store: Worauf ist im Oktober 2026 zu achten?

Die Regeln der Stores ändern sich häufig, deshalb sind die folgenden Angaben mit Datum versehen (geprüft am 17. Oktober 2026).

App Store (Apple)

Prüfungsrichtlinien: Die App Store Review Guidelines wurden zuletzt am 16. Oktober 2026 aktualisiert. Nach Abschnitt 2.1 ist eine prüfbereite, vollständige Version einzureichen; hat die App eine Anmeldung, muss ein Demokonto bereitgestellt werden, und das Backend muss auch während der Prüfung funktionieren. Nach Abschnitt 5.1.1 muss jede App auf ihre Datenschutzhinweise verweisen, und wenn die App das Anlegen eines Kontos ermöglicht, muss sie auch das Löschen des Kontos innerhalb der App anbieten (Apple: App Store Review Guidelines).
Datenschutzangaben: In App Store Connect müssen die Datenschutzpraktiken der App angegeben werden, auch die der eingebundenen externen Komponenten (zum Beispiel Analyse-SDKs); das ist für die Einreichung neuer Apps ebenso erforderlich wie für Updates (Apple: App privacy details).
Anforderung an die Entwicklungswerkzeuge: Seit dem 28. April 2026 müssen in App Store Connect hochgeladene Apps mit Xcode 26 oder neuer und dem iOS 26 SDK erstellt werden, und seit dem 9. September 2026 müssen iOS- und iPadOS-Apps mindestens iOS 13 als Ziel haben (Apple: Upcoming requirements).
Firmenkonto: Für die Registrierung als Organisation muss das Unternehmen eine juristische Person sein und eine D-U-N-S-Nummer haben, und die registrierende Person muss berechtigt sein, im Namen des Unternehmens rechtlich verbindliche Verpflichtungen einzugehen (Apple: Enrollment).
Händlerstatus in der EU: Apple verlangt vom Entwickler eine Erklärung, ob er nach EU-Recht als Händler gilt; die Kontaktdaten von Händlern erscheinen in der EU auf der Store-Seite der App (Apple: Digital Services Act trader requirements).

Google Play

Ziel-API-Level: Seit dem 31. August 2026 müssen neue Apps und Updates für Smartphones mindestens Android 16 (API-Level 36) als Ziel haben; bestehende Apps müssen mindestens Android 15 (API-Level 35) als Ziel haben, damit sie auf Geräten mit neueren Android-Versionen auch für neue Nutzer verfügbar bleiben. Mit einer in der Play Console beantragten Verlängerung endet die Frist am 1. November 2026 (Android Developers: Target API level).
Tests bei privaten Konten: Bei privaten Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, muss vor der Veröffentlichung in der Produktion ein geschlossener Test mit mindestens 12 Testern laufen, die seit mindestens 14 Tagen ununterbrochen daran teilnehmen (Play Console Help: testing requirements).
Organisationskonto: Ein Entwicklerkonto für eine Organisation lässt sich ohne D-U-N-S-Nummer nicht erstellen (Play Console Help: creating an account).
Formular zur Datensicherheit: Es muss für jede bei Google Play veröffentlichte App ausgefüllt werden, auch wenn die App keine Nutzerdaten erhebt (Play Console Help: Data safety).
Kontolöschung: Lässt sich in der App ein Konto anlegen, muss die Löschung des Kontos und der zugehörigen Daten sowohl innerhalb der App als auch über einen Weblink beantragt werden können (Play Console Help: account deletion requirements).

Diese Regeln gelten unabhängig von der Technologie: Eine mit Flutter oder React Native entwickelte App muss dieselben Ziel-API- und SDK-Anforderungen erfüllen wie eine native, und die Updates des Frameworks müssen mit ihnen Schritt halten. Wir empfehlen, dass das Entwicklerkonto dem Unternehmen des Auftraggebers gehört: So erscheint die App unter dem Namen Ihres Unternehmens, und auch der Store-Eintrag bleibt beim Unternehmen.

Barrierefreiheit

Beide Plattformen haben einen integrierten Screenreader (VoiceOver unter iOS, TalkBack unter Android) und bieten Schnittstellen, damit Apps mit diesen assistiven Technologien zusammenarbeiten (React Native: Accessibility). Die Flutter-Dokumentation empfiehlt zum Beispiel, dass der Screenreader jedes Bedienelement verständlich beschreibt, das Kontrastverhältnis zwischen Text und Hintergrund mindestens 4,5:1 beträgt und jedes antippbare Element mindestens 48×48 Pixel groß ist (Flutter: Accessibility). Die Android-Dokumentation empfiehlt die Material-Design-Richtlinien, das Tool Accessibility Scanner und automatisierte Prüfungen, um Probleme aufzudecken (Android Developers: Accessibility).

Das ist nicht nur gute Praxis: Nach der Richtlinie (EU) 2019/882 müssen die Mitgliedstaaten die Barrierefreiheitsanforderungen an Dienstleistungen im elektronischen Geschäftsverkehr für Verbraucher, auch an solche, die über mobile Apps erbracht werden, ab dem 28. Juni 2025 anwenden (die ungarischen Vorschriften beruhen auf der Umsetzung der Richtlinie); Kleinstunternehmen, die Dienstleistungen erbringen, sind davon auszunehmen (EUR-Lex: Richtlinie (EU) 2019/882). Die Einzelheiten für Webshops behandelt der Artikel Webshop: Mietshop oder individuelle Entwicklung?.

Künstliche Intelligenz: auf dem Gerät oder in der Cloud?

In einer mobilen App kann eine KI-Funktion an zwei Orten laufen: direkt auf dem Smartphone oder, über das Backend, bei einem großen Sprachmodell in der Cloud.

Auf dem Gerät (Apple): Das Foundation Models Framework von Apple gibt ab iOS 26 Zugriff auf die für Apple Intelligence entwickelten Modelle, die auf dem Gerät und in Private Cloud Compute laufen; es lässt sich für Textgenerierung, strukturierte Ausgaben und den Aufruf eigener Werkzeuge nutzen, aber nur auf Geräten, die Apple Intelligence unterstützen (Apple: Foundation Models).
Auf dem Gerät (Android): Gemini Nano läuft im Android-Systemdienst AICore und ist über die GenAI-Schnittstellen von ML Kit verfügbar, zum Beispiel für Zusammenfassungen, Korrekturlesen, Umformulieren und Bildbeschreibungen. Laut Google funktioniert es auch ohne Netzwerkverbindung, und sensible Daten bleiben auf dem Gerät, doch dem Modell setzen das Token-Limit und die Hardware des Geräts Grenzen (Android Developers: Gemini Nano).
In der Cloud: die großen Sprachmodelle von OpenAI (ChatGPT), Anthropic (Claude) und Google (Gemini) für komplexere Aufgaben, etwa für einen Assistenten auf Basis der eigenen Materialien des Unternehmens, für Dokumenten- und Bildverarbeitung oder Zusammenfassungen. Der Zugangsschlüssel für den KI-Dienst bleibt im Backend, nicht auf dem Smartphone: So lässt er sich nicht aus der App auslesen, und die Nutzung lässt sich auf dem Server steuern.

Ein Modell auf dem Gerät ist wegen des Datenschutzes und des Offline-Betriebs attraktiv, steht aber nicht auf jedem Gerät der Nutzer zur Verfügung, deshalb lohnt es sich typischerweise, es zusammen mit einer Ausweichlösung in der Cloud zu planen. Über die Anbindung der Modelle schreibt die Seite KI-Integration.

Wovon hängt der Aufwand für die Wartung ab?

Eine mobile App ist auch nach der Übergabe nicht fertig: Ihr Umfeld ändert sich ständig. Den Wartungsaufwand bestimmen vor allem diese Faktoren:

Die Anforderungen der Betriebssysteme und Stores: Apple schreibt für Uploads neuere Xcode- und SDK-Versionen vor, Google Play ein neueres Ziel-API-Level. Die Termine oben zeigen, dass diese Anforderungen regelmäßig steigen.
Änderungen der Store-Richtlinien: neue Datenschutzangaben, Regeln zur Kontolöschung oder zu Tests.
Updates des Frameworks: Bei einer Cross-Platform-App kann ein größerer Versionswechsel von Flutter, React Native oder .NET MAUI Arbeit im eigenen Code und in den verwendeten Plug-ins bedeuten.
Externe Komponenten: Zahlungs-, Karten- und Analyse-SDKs, die ebenfalls eigene Update-Anforderungen haben.
Das Backend und die Integrationen: Änderungen an den Schnittstellen der angebundenen Firmensysteme und KI-Dienste.
Die Zahl der Codebasen: Zwei native Apps erfordern Änderungen an zwei Stellen.

Häufige Fehler

Über die Technologie entscheiden die Gewohnheiten des Teams, nicht die Funktionen der App.
Mit dem Backend und der Admin-Oberfläche wird nicht gerechnet, nur mit den Bildschirmen.
Eine Website wird lediglich als App verpackt, und der Store lehnt sie ab.
Das Entwicklerkonto läuft auf den Namen des Entwicklungsunternehmens, und der Store-Eintrag lässt sich später nicht übertragen.
Kontolöschung, Datenschutzangaben oder Demokonto werden erst am Tag der Einreichung nachgeholt.
Für die Updates nach der Übergabe ist niemand zuständig, und nach einer Regeländerung ist die App für neue Nutzer nicht mehr erreichbar.

Häufige Fragen

Nativ oder Flutter/React Native?

Wenn die App das Gerät intensiv nutzt (Kamera, Sensoren, Hintergrundprozesse) oder hohe Leistung braucht, ist die native Entwicklung der sicherere Weg. Brauchen beide Plattformen dieselben Funktionen, ist eine mit Flutter oder React Native entwickelte App mit gemeinsamer Codebasis leichter zu warten. Mit Kotlin Multiplatform ist auch ein Mittelweg möglich: gemeinsame Geschäftslogik, native Oberfläche. Im Erstgespräch geben wir auf Grundlage der konkreten Funktionen eine Empfehlung.

Wann genügt eine Webanwendung (PWA)?

Wenn die Nutzer über einen Link oder die Website kommen, kein tiefer Gerätezugriff nötig ist und es wichtig ist, dass die App auf dem Desktop-Rechner und auf dem Smartphone gleich funktioniert. Sie lässt sich auf dem Startbildschirm installieren und kann auch unter iOS Push-Benachrichtigungen senden, bietet aber keine Präsenz im Store, und der Umfang der Gerätefunktionen hängt vom Browser ab.

Braucht die App ein Backend?

Fast immer: Sobald die App Benutzerkonten, gemeinsam genutzte Daten oder Benachrichtigungen hat, braucht sie einen Server dahinter. Die Ausnahme ist eine App, die Daten nur auf dem Gerät speichert. Wir bauen auch das Backend und die Admin-Oberfläche und binden sie an die bestehenden Firmensysteme an.

Wer stellt die App in die Stores?

Die Veröffentlichung übernehmen wir: Wir bereiten die Materialien für den Store-Eintrag und die Datenschutzangaben vor, reichen die App ein und begleiten die Prüfung bis zum Ende. Wir empfehlen, dass das Entwicklerkonto Ihrem Unternehmen gehört; für ein Organisationskonto verlangen beide Stores eine D-U-N-S-Nummer, deshalb lohnt es sich, sie rechtzeitig zu beschaffen.

Wovon hängen die Kosten der Wartung ab?

Davon, wie viele Codebasen gewartet werden müssen, wie oft sich die Betriebssysteme und die Anforderungen der Stores ändern, wie viele externe Komponenten und Integrationen die App nutzt und wie viel Weiterentwicklung zu erwarten ist. Den Preis der Entwicklung ermitteln wir aus der funktionalen Größe; die Methode beschreibt die Seite Preisgestaltung.

Wie können wir helfen?

Wir entwickeln iOS- und Android-Apps: Wir bauen das Backend und die Admin-Oberfläche dahinter, binden künstliche Intelligenz ein und begleiten die App bis zur Veröffentlichung im Store. Die Entscheidung zwischen nativ und Cross-Platform treffen wir gemeinsam, auf Grundlage der Funktionen. Die Einzelheiten des Dienstes beschreibt die Seite Mobile-App-Entwicklung.

Die funktionale Größe der Entwicklung messen wir in COSMIC-Funktionspunkten (ISO/IEC 19761), daraus entstehen das Angebot und der Zeitplan. Das Erstgespräch ist kostenlos, auf Wunsch schließen wir eine Geheimhaltungsvereinbarung (NDA), und nach der Übergabe übernehmen wir auch Betrieb und Wartung. Quellcode und Nutzungsrechte regelt der Vertrag. Beschreiben Sie Ihre Idee in ein paar Sätzen, und nehmen Sie Kontakt mit uns auf.