Angebote erwähnen React Native, Flutter, Native – welches Framework für unsere erste App?

Rein technisch trennt sich die Spreu vom Weizen erst beim Hardware-Zugriff. React Native kommuniziert über eine Bridge mit nativen Komponenten, während Flutter die Pixel direkt über die eigene Rendering-Engine zeichnet. Bei Bestell- und Rechnungsmasken reden wir hier über Millisekunden, das merkt kein Endnutzer. Wenn ihr die Hardware nicht extrem beansprucht, reichen beide Frameworks völlig aus.

Wir haben vor zwei Jahren eine ähnliche B2B-Großhandels-App mit React Native gelauncht. Die Entwicklung hat 30.000 Dollar gekostet, für Betrieb und laufende Wartung zahlen wir im Schnitt 4.000 Dollar im Jahr. Hätten wir das nativ gebaut, bräuchten wir zwei Entwickler, da hätten die Betriebskosten schon im ersten Jahr unser Budget gesprengt.

Der Single-Codebase-Ansatz klingt auf dem Papier super, kann bei OS-Updates aber echt nerven. Wenn eine neue Betriebssystem-Version rauskommt, wartet man manchmal wochenlang darauf, dass bestimmte Packages nachziehen. Klärt mit der Agentur vorab ganz genau, wie der Support bei Versionsupdates geregelt ist.

die agentur mit dem nativen angebot arbeitet wahrscheinlich sonst nur mit konzernen das geld könnt ihr euch echt sparen. ehrlich gesagt dem restaurantbesitzer ist wichtig dass die app flüssig läuft und nicht ob da swift drunterliegt flutter reicht dafür dicke.

Für die Entscheidung würde ich folgende drei Kriterien heranziehen: 1) Referenzen der Agentur bei vergleichbaren B2B-Projekten, 2) Komplexität externer Anbindungen wie Barcode-Scanner oder Kartenmaterial, 3) der Stundensatz für Wartung und Support nach Projektabschluss.

Habt ihr schon besprochen, wie die App an euer bestehendes ERP- oder Buchhaltungssystem angebunden wird? Mehr als die Wahl des Frameworks haut oft rein, ob die API-Endpunkte schon stehen oder nicht. Wenn eure Datenbank noch nicht für mobile Schnittstellen bereit ist, stellen die Agenturen dafür gern saftige Zusatzkosten in Rechnung.

wir stehen grad vor einer ähnlichen Entscheidung. wenn man mit Cross-Platform anfängt und die App irgendwann sttark wächst muss man dann zwingend auf Native umstellen? müsste man zu dem Zeitpunkt dann wieder alles komplett neu schreiben?

Ladet euch einfach zwei Apps herunter, die die Flutter-Agentur umgesetzt hat, und testet den Bestellablauf selbst durch. Wenn das flüssig läuft und die Referenzkunden zufrieden sind, nehmt das Angebot für 28.000 Dollar. Die gesparten 27.000 Dollar steckt ihr lieber ins Marketing und in die Einarbeitung eurer Kunden.

Ich bin ein kleines Unternehmen, ich erzähle es aus meiner Sicht. Der Zahlungsplan sollte an die Projektphasen gekoppelt sein, nicht an den Kalender.

Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

wie habt ihr das Problem gelöst? der meiset Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

nur als Notiz könnte nützlich sein.

Du hast recht. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Wenn es jemand anders macht, würde mich das auch interessieren.

Ich fasse kurz zusammen, was bisher gesagt wurde. Wer bei frameworks für mobile app-entwicklung hetzt, stolpert alle an derselben Stelle.

Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später. Das war's, entschuldige, wenn ich zu lang war.

Ich möchte etwas fragen. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll.

Wenn im Vertrag nicht steht, wem der Code gehört, habt ihr bei der Trennung keine Verhandlungsmacht mehr. Wenn deine Situation anders ist, ändert sich das natürlich.

Das wusste ich nicht.

Danke, genau die Antwort, die ich gesucht habe. Fehler auf der frameworks für mobile app-entwicklung-Seite sind meist rückgängig zu machen, aber teuer.

Nur als Notiz, könnte nützlich sein.

wir sind auch eine Zeit lang an derselben Stelle hängen geblieben. halt schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

viel Erfolg.

ich stimme zu. kein Prozess ohne Dokumentation verbessert sich weil man nicht weiß, was man verbessern soll.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt.