Die Frage nach der Technik kommt meist früh und wird oft falsch beantwortet, nämlich mit dem, was der Anbieter ohnehin einsetzt. Als Auftraggeber musst du die Werkzeuge nicht kennen. Du solltest aber erkennen, ob die Antwort aus deiner Aufgabe folgt oder aus dem Werkzeugkasten des Gegenübers.
Vier Fragen entscheiden: Wie tief greift die App in Gerätefunktionen ein? Wie wichtig ist das plattformtypische Bedienempfinden? Wie lange soll die App leben? Und wer pflegt sie danach? Aus diesen vier Antworten ergibt sich der Weg meist eindeutig.
Die drei Wege in Kurzform
| Nativ | Flutter | React Native | |
|---|---|---|---|
| Grundlage | je Plattform getrennt | gemeinsame Grundlage, eigene Darstellung | gemeinsame Grundlage, plattformeigene Elemente |
| Zugriff auf Gerätefunktionen | vollständig, sofort | über Zusatzmodule | über Zusatzmodule |
| Bedienempfinden | plattformtypisch | eigenständig, überall gleich | nah am Plattformstandard |
| Aufwand für zwei Plattformen | am höchsten | niedrig | niedrig |
| Verfügbare Entwickler | gut | gut | sehr gut, wenn Webkenntnisse vorhanden |
Frage 1: Wie tief greift die App ins Gerät ein?
Kamera, Standort und Dateien sind bei allen drei Wegen unproblematisch. Anspruchsvoll wird es bei Bluetooth-Geräten, bei Hintergrundverarbeitung, bei Nahfeldkommunikation, bei Zugriff auf Hardware wie Barcodescanner in Industriegeräten, oder bei aufwendiger Bild- und Signalverarbeitung.
Bei den plattformübergreifenden Wegen läuft solcher Zugriff über Zusatzmodule. Die gibt es meist, und dann ist alles gut. Gibt es sie nicht, muss ein Teil doch plattformspezifisch gebaut werden, und der Vorteil schmilzt.
Praktische Prüfung: Liste die besonderen Gerätefunktionen auf und lass dir zeigen, welches Zusatzmodul sie abdeckt und wie aktiv es gepflegt wird. Ein Modul mit letzter Aktualisierung vor drei Jahren ist ein Risiko.
Frage 2: Wie wichtig ist plattformtypisches Empfinden?
Für eine betriebsinterne Erfassungs-App spielt das kaum eine Rolle. Die Leute lernen die Anwendung, und ob sich ein Auswahlfeld genau wie im Betriebssystem verhält, ist zweitrangig.
Für eine App, die Endkunden freiwillig installieren, ist es wichtiger. Dort werden Abweichungen von den gewohnten Bedienmustern als unfertig empfunden, und die Bewertungen im Store sind unbarmherzig.
Frage 3: Wie lange soll die App leben?
Bei einer Lebensdauer von zwei bis drei Jahren ist die Wahl unkritisch. Bei zehn Jahren wird sie zur Wette darauf, welche Grundlage in zehn Jahren noch gepflegt wird.
Native Entwicklung ist hier am ruhigsten, weil sie direkt an den Plattformen hängt. Die plattformübergreifenden Wege hängen zusätzlich an einem Projekt, das eingestellt werden könnte. Beide betrachteten Werkzeuge werden von großen Unternehmen getragen, was das Risiko begrenzt, aber nicht beseitigt.
Frage 4: Wer pflegt die App danach?
Der unterschätzte Punkt, und oft der entscheidende. Wenn im Betrieb bereits Webentwicklung stattfindet, ist ein Weg, der auf denselben Kenntnissen aufbaut, praktisch wertvoll: Dieselben Leute können Fehler beheben, ohne eine neue Umgebung zu lernen.
Gibt es keine eigene Entwicklung und wird ohnehin extern gepflegt, fällt dieses Kriterium weg, und die technischen Fragen entscheiden.
Was gegen den plattformübergreifenden Weg spricht
Damit die Darstellung nicht einseitig wird: Es gibt Fälle, in denen native Entwicklung trotz höherem Aufwand die richtige Wahl ist.
- Wenn die App im Kern aus einer Gerätefunktion besteht, etwa Kamera mit eigener Bildverarbeitung.
- Wenn Hintergrundverarbeitung zuverlässig funktionieren muss, etwa dauerhafte Standorterfassung.
- Wenn nur eine Plattform bedient wird. Dann entfällt der Hauptvorteil, und der Umweg über eine zusätzliche Schicht bringt nichts.
- Wenn sehr strenge Anforderungen an Startzeit und Speicherverbrauch bestehen.
Woran du einen technikgetriebenen Vorschlag erkennst
Ein gutes Zeichen ist, wenn zuerst nach Gerätefunktionen, Zielgruppe und Lebensdauer gefragt wird und die Technik danach kommt. Ein schlechtes Zeichen ist, wenn die Technik im ersten Satz steht und die Begründung allgemein bleibt.
Eine hilfreiche Gegenfrage: „In welchem Fall würdet ihr davon abraten?“ Wer darauf keine Antwort hat, hat nur einen Weg im Angebot.
Wie wir das entscheiden
Wir legen uns nicht auf eine Technik fest. Bei Erfassungs-Apps für den Innenbereich eines Betriebs führt die Bewertung häufig zu einem plattformübergreifenden Weg, bei starker Gerätenähe zu nativer Entwicklung. Die Begründung schreiben wir ins Angebot, damit sie nachvollziehbar ist. Mehr dazu unter App-Entwicklung für Unternehmen.
Ist Flutter oder React Native besser?
Das hängt vom Vorhaben ab. Flutter bringt eine eigene, überall gleiche Darstellung mit, React Native nutzt plattformeigene Elemente und baut auf Webkenntnissen auf. Für betriebsinterne Anwendungen sind beide geeignet.
Wann ist native Entwicklung nötig?
Wenn die App im Kern aus einer Gerätefunktion besteht, wenn Hintergrundverarbeitung zuverlässig laufen muss, bei sehr strengen Anforderungen an Startzeit und Speicher, oder wenn ohnehin nur eine Plattform bedient wird.
Spart eine plattformübergreifende App wirklich Kosten?
Bei zwei Plattformen deutlich, weil die Grundlage gemeinsam ist. Getrennt bleiben Einreichung, Tests und plattformeigene Besonderheiten. Bei nur einer Plattform entfällt der Vorteil.
Wie erkenne ich einen technikgetriebenen Vorschlag?
Daran, dass die Technik vor der Aufgabe steht. Eine brauchbare Gegenfrage lautet, in welchem Fall der Anbieter von dieser Technik abraten würde. Wer darauf keine Antwort hat, hat nur einen Weg im Angebot.
Passend dazu
