Agentur schlägt „Flutter für iOS und Android“ vor – bindet mich diese Entscheidung später?

Bei iOS-Updates kann es – wenn auch selten – durch Änderungen an der Rendering-Engine oder an OS-Komponenten zu kleineren Darstellungsfehlern kommen. Lassen Sie sich ins Angebot unbedingt eine Klausel schreiben, dass die Agentur bei neuen iOS-Hauptversionen mindestens 1 Jahr lang Kompatibilitätsupdates garantiert.

Wir haben letztes Jahr unsere Logistik-Tracking-App mit Flutter gelauncht. Statt zwei separater nativer Teams haben wir mit einem einzigen Team 210.000 TL ausgegeben. Aktuell haben wir 12.000 aktive Nutzer, und von den Beschwerden betrafen gerade mal 2 Ruckler in der UI – und das auch nur auf uralten Geräten.

Die meisten Agenturen werben mit 'eine Codebasis für zwei Plattformen', um Kosten zu drücken schauen sich aber die iOS Human Interface Guidelines nicht mal an. Wenn am Ende eine iOS-App herauskommt, die sich wie Android anfühlt, hagelt es von iPhone-Nutzern sofort schlechte Bewertungen.

Verlangen Sie von der Agentur mindestens drei Flutter-Apps, die sie bereits im App Store veröffentlicht hat. Laden Sie die auf Ihr eigenes iPhone herunter und prüfen Sie Scroll-Verhalten, Tastatur-Einblendung und Übergangsanimationen ganz genau.

Müssen Ihre Techniker vor Ort offline arbeiten? Haben Sie gefragt, wie die lokale Datenspeicherung und Synchronisation gelöst werden soll? Der eigentliche Flaschenhals ist meistens nicht das UI sondern die Synchronisation der lokalen Datenbank.

wir nutzen das seit zwei jahren und hatten null probleme... nativ hätte das budget locker verdoppelt für den anfang braucht man das echt nicht.

Ergänzung: Wurde unten schon gefragt, die Antwort habe ich im zweiten Beitrag geschrieben.

Wenn Sie später auf nativ umstellen müssen, heißt das nicht, dass die App gescheitert ist – im Gegenteil: Es zeigt dass das Geschäft massiv gewachsen ist. Wenn der Tag kommt haben Sie auch das Geld um neuen Code zu finanzieren. naja für den Moment zählt erst mal Geschwindigkeit.

Beim Umstieg auf Nativ landet zwar der UI-Code im Müll, aber die Backend-Architektur bleibt komplett erhalten; 280.000 TL sind für diesen Testballon ein absolut vertretbares Budget.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

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

ich stimme voll und ganz zu. halt jeder nicht schiftlich festgehaltene Punkt ist einer an den sich beide Parteien später unterschiedlich erinnern.

das wars entschuldige, wenn ich zu lang war.

Ich probiere es aus.

Du hast recht, ich bin denselben Weg gegangen. Der Zahlungsplan sollte an die Projektphasen gekoppelt sein, nicht an den Kalender.

Wenn im Vertrag nicht steht, wem der Code gehört, habt ihr bei der Trennung keine Verhandlungsmacht mehr. An deiner Stelle würde ich so vorgehen.

Hier lauert eine Falle die ich nicht unerwähnt lassen möchte. also fehler auf der flutter mit ios entwicklung-Seite sind meist rückgängig zu machen aber teuer.

Im Großen und Ganzen richtig, aber ein Punkt fehlt. Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später.

An deiner Stelle würde ich so vorgehen.

Ich stimme zu, möchte das sogar besonders betonen. Das allein zu versuchen, ist der teuerste Weg.

Aus Erfahrung weiß ich das.

Bei mir war es genau umgekehrt, deshalb schreibe ich das. Wenn ihr es zum ersten Mal macht, fangt klein an die Skalierung kommt später.

Das günstigste Angebot ist oft das am wenigsten durchdachte.

Das habe ich auch erlebt. also scheut euch nicht zu fragen wer nicht fragt, zahlt am Ende mehr.

Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste. Das wars, entschuldige wenn ich zu lang war.

Genau so ist es. Zugangsdaten sollten auf den Firmennamen laufen, nicht auf persönliche Konten.

Wenn der Umfang wächst, müssen entweder Zeit oder Budget wachsen. Eine dritte Option gibt es nicht. An deiner Stelle würde ich so vorgehen.