Build vs. Buy in der Mobile-Entwicklung: Native, Cross-Platform, No-Code

1. Kartieren Sie das Produktrisiko vor der Technologie

Das erste Dokument sollte keine Funktionsliste sein, sondern eine Risikokarte. Hängt der Produkterfolg an Live-Kamera, Bluetooth, Standort, Gesundheitsdaten, Audio mit geringer Latenz, komplexer Grafik oder Ausführung im Hintergrund? Lebt die App nur auf Smartphones oder auch auf Tablets, Uhren und Desktops? Welche Module sind von Sicherheits-, Regulierungs-, Datenstandort- und Offline-Anforderungen betroffen? Diese Fragen zeigen, wie schwer die technische Entscheidung tatsächlich wiegt.

Erstellen Sie danach eine Veränderungskarte. Bildschirme, an denen Sie häufig experimentieren, ein langlebiger Transaktionskern und Integrationen von Drittanbietern verändern sich nicht im selben Tempo. Die veränderliche Oberfläche modular zu halten, ist wertvoller, als das gesamte Produkt an die Grenzen eines einzigen Werkzeugs zu binden. Trennen Sie den Umfang der ersten Version von der Produktvision für drei Jahre: Bauen Sie heute keine übertriebene Architektur für unwahrscheinliche Fälle, verschieben Sie bekannte hohe Risiken aber auch nicht auf die Zeit nach dem Prototyp.

Halten Sie den Erfolgsmaßstab schriftlich fest: Veröffentlichungstermin im Store, Dauer der kritischen Aufgabe, absturzfreie Sitzungen, Barrierefreiheit, Nutzbarkeit ohne Verbindung oder Release-Kapazität pro Team. „Schnelle Entwicklung“ hat nur dann eine Bedeutung, wenn klar ist, was genau schneller wird.

2. Vergleichen Sie Native, Cross-Platform und No-Code nach denselben Kriterien

Die native Entwicklung arbeitet unmittelbar mit der offiziellen Sprache und dem Oberflächen-Framework der Plattform. Sie ist ein starker Kandidat, wenn früher Zugriff auf die neuesten Betriebssystemfunktionen, plattformtypisches Verhalten und feingliedrige Leistungskontrolle wichtig sind. Der Preis dafür sind getrennte Expertise, getrennter Code und getrennte Testfläche für die Abdeckung von iOS und Android. Gemeinsame Geschäftslogik oder ein gemeinsames Designsystem verringern Doppelarbeit, dennoch verwalten Sie zwei Plattform-Lebenszyklen.

Der Cross-Platform-Ansatz zielt darauf, mit einer gemeinsamen Codebasis mehrere Ziele zu erreichen. Er kann sich auszahlen, wenn die Produktabläufe ähnlich sind, die Anpassung an die Plattform begrenzt bleibt und ein einziges Team arbeitet. Gemeinsamer Code bedeutet jedoch nicht null Plattformarbeit. Native Module, Store-Richtlinien, Geräteverhalten, Barrierefreiheit und Versionssprünge verlangen weiterhin eine eigene Prüfung. Sehen Sie sich bei der Auswahl eines Frameworks nicht nur den heutigen Komponentenkatalog an, sondern auch, wer die Pflege verantwortet.

No-Code- und Low-Code-Werkzeuge können bei Prototypen, internen Anwendungen, formularlastigen Prozessen und Standard-Datenflüssen Zeit sparen. Bei komplexer Offline-Synchronisierung, eigener Geräteanbindung, intensiver Interaktion oder Anforderungen an die Portierbarkeit sollten Sie die Grenzen früh testen. Eigentum am erzeugten Code, Export, Preisgestaltung, Qualität der Erweiterungen und die Folgen einer Plattformeinstellung gehören sichtbar in den Vertrag.

3. Lesen Sie die offizielle Support-Matrix und die Architektur gemeinsam

Die offizielle Support-Matrix von Flutter weist je Version aus, welche Kombinationen aus Betriebssystem und Hardware unterstützt werden, welche in der kontinuierlichen Integration getestet werden und welche nicht unterstützt sind. Da sich diese Liste im Lauf der Zeit ändert, gleichen Sie Ihre Zielgeräte mit der aktuellen offiziellen Matrix ab statt mit dem Satz „läuft überall“ aus einer Vertriebspräsentation. Ein unterstütztes Ziel bedeutet nicht, dass jede Erweiterung und jedes Verhalten in Ihrem Produkt gleich ausgereift ist.Flutter Documentation — Supported deployment platforms

Der offizielle Architekturleitfaden von Android empfiehlt, die Zuständigkeiten von Benutzeroberfläche und Datenschicht zu trennen, und setzt auf eine einzige verlässliche Datenquelle sowie eine datengetriebene Oberfläche; zugleich weist er ausdrücklich darauf hin, dass die Empfehlungen an den jeweiligen Kontext anzupassen sind. Diese Prinzipien taugen nicht nur für natives Android, sondern auch als nützliche Prüfung bei der Bewertung von Technologiekandidaten: Wie viel Geschäftslogik wandert in das Werkzeug, wo liegt der Datenzugriff, und lassen sich Module einzeln testen?Android Developers — Guide to app architecture

Legen Sie ein Versuchs-Repository an und bauen Sie den riskantesten vertikalen Schnitt durchgängig auf. Identität, eine echte API, lokale Speicherung, Benachrichtigungen, Barrierefreiheit und die Auslieferungsstrecke gehören in diesen Schnitt. Ein reiner Prototyp aus statischen Bildschirmen zeigt weder das Integrations- noch das Lebenszyklusrisiko.

4. Angenommenes Szenario: Eine hybride Entscheidung für eine Außendienst-App

Dieses Szenario ist angenommen; es ist weder ein Kundenfall noch eine Zusage zu Laufzeiten. Stellen Sie sich vor, ein Wartungsunternehmen plant eine App für seine Techniker. Die Kernaufgaben sind Arbeitsaufträge einsehen, Fotos anhängen, Unterschriften einholen und Formulare ohne Verbindung ausfüllen. Im ersten Jahr kommen nur Firmentelefone zum Einsatz, später werden ein Kundenportal und Tablet-Unterstützung erwartet. Das Team ist stark in Webtechnologien, hat aber wenig Erfahrung mit mobiler Offline-Synchronisierung.

Der No-Code-Kandidat baut Formular- und Verwaltungsbildschirme schnell auf, stößt jedoch bei großen Fotowarteschlangen, der Konfliktauflösung und dem Test der Geräterichtlinien an Grenzen. Der native Kandidat bietet die größte Kontrolle, doch ein Team für zwei Plattformen ist nicht vorhanden. Beim Cross-Platform-Kandidaten entsteht ein kleiner vertikaler Schnitt mit Offline-Daten, Kamera und Versand im Hintergrund; die kritische Synchronisierungsschicht wird als Modul entworfen, das vom Framework getrennt bleibt.

Die Entscheidung lautet nicht, das gesamte System in einem Werkzeug zu bauen. Die Techniker-App entsteht cross-platform, während das Verwaltungspanel im Web bleibt; Identität und Dateiübertragung werden als verwaltete Dienste eingekauft. Sollte die Geräteverwaltung ausschließlich auf Android festgelegt werden, wird natives Android als Schwelle für eine erneute Bewertung festgehalten. Dieser Weg nutzt das heutige Team, ohne so zu tun, als wäre ein künftiger Richtungswechsel kostenlos.

5. Rechnen Sie die Gesamtbetriebskosten über den Lebenszyklus

Das Angebot für die erste Version ist nicht die Gesamtsumme. Designanpassung, automatisierte Tests, ein Gerätelabor, Store-Konten, Beobachtbarkeit, Sicherheitsaktualisierungen, SDK-Sprünge, Korrekturen zur Barrierefreiheit und Betriebssystemwechsel gehören ins Budget. Prüfen Sie bei eingekauften Diensten, wie sich der Preis mit steigender Nutzung entwickelt; bei eigenem Code kalkulieren Sie zusätzlich den Verlust von Spezialisten und die Kosten der Wartungsbereitschaft.

Modellieren Sie auch die Wechselkosten von Anfang an. Können Sie Daten in einem Standardformat exportieren, stecken die Geschäftsregeln in der proprietären Ablaufsprache des Anbieters, können Ihre Tests eine neue Umsetzung überprüfen, und lassen sich Nutzersitzungen und Abonnements übertragen? Ein Ausstiegsplan heißt nicht, alles mühelos neu schreiben zu können, sondern unumkehrbare Abhängigkeiten bewusst zu wählen.

Vergessen Sie die Ökonomie des Teams nicht. Eine am Markt beliebte Technologie ist für Ihr Team nicht automatisch günstig. Einstellungsdauer, Senioritätsverteilung, Lernkurve und Kapazität für Code-Reviews zählen zum Lieferrisiko.

• Spielen Sie Lizenz-, Infrastruktur- und Drittanbietergebühren über drei Jahre durch.
• Planen Sie Kapazität für Betriebssystem- und Framework-Sprünge ein.
• Rechnen Sie Testgeräte, Beobachtbarkeit und Supportaufwand hinzu.
• Sichern Sie die Portabilität von Daten und Geschäftsregeln vertraglich ab.
• Verankern Sie kritisches Wissen bei mindestens zwei Teammitgliedern.

6. Sechs-Wochen-Plan für die Technologieentscheidung

In Woche eins bestimmen Sie die Nutzeraufgaben und die Funktionen, die nicht ausfallen dürfen. In Woche zwei halten Sie die Vorgaben zu Plattform, Sicherheit, Daten, Barrierefreiheit und Auslieferung fest. In Woche drei und vier bauen Sie denselben riskanten vertikalen Schnitt mit höchstens zwei starken Kandidaten. In Woche fünf vergleichen Sie die Ergebnisse zu Leistung, Geräten, Offline-Verhalten, Tests und Auslieferung. In Woche sechs erstellen Sie ein Entscheidungsprotokoll mit Gesamtkosten, Team und Ausstiegsbedingungen.

Das Entscheidungsprotokoll sollte nicht nur den Gewinner enthalten, sondern auch die abgelehnten Optionen und die zugrunde liegenden Annahmen. Legen Sie Auslöser für eine erneute Bewertung fest: eine neue Plattform, eine aufwendige Geräteanbindung, eine Lizenzänderung, eine Leistungsschwelle oder eine veränderte Teamstruktur. So wird die Technologieauswahl kein ewiges Treuegelöbnis, sondern eine belegbare und nachvollziehbare Produktentscheidung.

• Wir haben die kritischen Nutzeraufgaben und Qualitätsschwellen festgehalten.
• Wir haben die Matrix aus Zielgeräten und Betriebssystemen geprüft.
• Wir haben den riskantesten vertikalen Schnitt mit echten Integrationen erprobt.
• Wir haben den Umfang der plattformspezifischen Arbeit geschätzt.
• Wir haben Wartungs- und Lizenzkosten über drei Jahre modelliert.
• Wir haben einen Ausstiegsplan für Daten, Code und Geschäftsregeln erstellt.
• Wir haben die Auslöser bestimmt, die die Entscheidung neu eröffnen.

7. Grenzen und Fehlermodi: Ein Werkzeug ersetzt keine Produktstrategie

Der häufigste Fehler besteht darin, den Anteil gemeinsamen Codes zum Erfolgsmaßstab zu machen. Selbst wenn der größte Teil des Codes geteilt ist, kann für die entscheidenden Prozente Expertise auf beiden Plattformen nötig sein. Umgekehrt erzeugen getrennte native Apps ohne saubere Modularität denselben Fehler zweimal. Eine No-Code-Lösung kann schnell starten und sich in eine verworrene Kette von Erweiterungen verwandeln, sobald die Sonderanforderungen zunehmen. Jeder Ansatz wird teuer, wenn er schlecht umgesetzt wird.

Auch ein Benchmark-Ergebnis ist nicht das gesamte Nutzererlebnis. Eine Animation, die auf dem Laborgerät flüssig läuft, kann auf einem älteren Gerät, bei aktivierten Einstellungen zur Barrierefreiheit, in einem schwachen Netz oder unter Hintergrundbeschränkungen einbrechen. Store-Richtlinien und Plattform-APIs ändern sich. Archivieren Sie die offizielle Support-Seite zum Entscheidungsdatum, benennen Sie eine verantwortliche Person für Upgrades und wiederholen Sie den kritischen Ablauf auf echten Geräten.

Die letzte Grenze ist die Organisation. Technologie ohne Eigentümer veraltet selbst mit der besten Architektur. Die Wahl sollte auf die Lösung fallen, die Ihr Team entwickeln, testen, beobachten und sicher aktualisieren kann. Module einzukaufen, die nichts zur Differenzierung des Produkts beitragen, und die Kernfunktion bewusst selbst zu kontrollieren, ist meist der ausgewogenere Weg zwischen Build und Buy.