Beeinflusst die Wahl der Programmiersprache für iOS das Agenturangebot und das spätere Wartungsbudget?

Habt ihr schon genau definiert, was die App eigentlich können soll? Geht es um Barcode-Scannen via Bluetooth, Live-GPS-Tracking im Hintergrund oder komplexe Kamera-Animationen? Wenn es nur um Standard-Datenbankabläufe wie Produktlisten, Bestellbestätigungen und Push-Nachrichten geht, lohnt es sich vielleicht gar nicht, die 110.000 TL Aufpreis für Native zu zahlen. Aber sobald hardwarenahe Integrationen ins Spiel kommen, geht Cross-Platform hintenraus meistens richtig ins Geld.

Wir haben letztes Jahr eine ähnliche Bestell-App entwickeln lassen. Haben 180.000 TL bezahlt und auf Cross-Platform gesetzt – im ersten Jahr lief alles glatt. Nach einem Betriebssystem-Update ging dann aber plötzlich das Kamera-Modul für den Barcode-Scanner nicht mehr. Die Agentur meinte, die genutzte Open-Source-Bibliothek werde nicht mehr gepflegt und sie müssten das Modul von Grund auf neu bauen – dafür wollten sie 45.000 TL extra. Mehr als die Hälfte unserer anfänglichen Ersparnis war mit diesem einen Bugfix direkt wieder futsch.

Dieser Mythos von wegen „native ist immer das einzig Wahre“ wird am Markt schon ziemlich übertrieben. Heutzutage laufen selbst bei Banking- und riesigen E-Commerce-Apps etliche Screens über Cross-Platform oder Web-Views. Wichtiger als der Tech-Stack der Agentur ist eigentlich, wie seniorig das Team in der jeweiligen Sprache wirklich ist. Eine mit schlechter Architektur zusammengezimmerte native App verursacht am Ende deutlich höhere Wartungskosten als eine sauber aufgesetzte Cross-Platform-Lösung.

Aus technischer Sicht solltet ihr das Hauptaugenmerk auf das Dependency Management legen. Bei Cross-Platform-Sprachen gibt es immer eine Bridge-Schicht zwischen dem App-Kern und dem Betriebssystem. Genau diese Schicht kann bei jedem großen OS-Update zu Verzögerungen führen. Fragt die Agentur, wie viele Third-Party-Plugins abseits der standardmäßigen Paketmanager genutzt werden. Je mehr externe Plugins drinstecken, desto drastischer steigen später die Folgekosten bei Updates.

Punkte, die Sie vor den Verhandlungen mit der Agentur zwingend ins Lastenheft aufnehmen sollten: 1) Es muss bestätigt werden, dass der Quellcode gängigen Clean-Architecture-Standards entspricht und lückenlos dokumentiert ist. 2) Die verwendete Sprache muss zwingend auf einer aktuellen Version mit LTS (Long Term Support) basieren. 3) Bei Projektabnahme ist eine vollständige Übersicht aller externen Bibliotheken inklusive Lizenzen und Versionsnummern zu übergeben. 4) Für den Fall, dass die Agentur den Support einstellt, muss eine Schritt-für-Schritt-Anleitung vorliegen, mit der ein anderes Team das Projekt reibungslos aufsetzen und weiterführen kann.

wir standen vor genau demselben dilemma. als wir dann später freelance-entwickler gesucht haben, mussten wir feststellen: die meisten die hybrid anbieten sind noch recht frisch dabei und können keins von beiden systemen wirklich richtig. als das ding dann gegen die wand gefahren ist, mussten wir doch auf native umsteigen dann wenn das budget da ist und sowieso nur ios geplant ist, erspart man sich mit von anfang an sauberem native jede menge kopfschmerzen.

Bei der Prüfung der Angebote sollten Sie den Leistungsumfang des Wartungs- und Supportvertrags niemals losgelöst von der Entwicklungssprache betrachten. Unabhängig von der Technologie sichern eine vertraglich festgelegte Service-Level-Vereinbarung (SLA) sowie festgeschriebene monatliche Wartungspauschalen Ihr Unternehmen ab – insbesondere bei Personalwechseln auf Entwicklerseite oder Betriebssystem-Updates. Lassen Sie zudem zwingend die bedingungslose Übertragung aller Urheber- und Nutzungsrechte am Code im Vertrag verankern.

Vor zwei Jahren haben wir uns bei einer ähnlichen B2B-Großhandels-App für den billigen Weg entschieden. Dachten uns: Ist ja bloß ein einfacher Katalog mit Bestellmaske. Die Agentur hat das Projekt abgeliefert und acht Monate später dichtgemacht. Als wir den Code dann einem anderen Entwickler gegeben haben, schlug der die Hände überm Kopf zusammen: Das basierte auf einer uralten Framework-Version, die überhaupt nicht mehr supportet wurde. Ein kompletter Neubau war am Ende billiger als das Ding zu flicken. Seitdem wissen wir: Man darf nicht nur auf den Stack schauen, sondern muss vor allem die langfristige Wartbarkeit hinterfragen.

Richtig. Zugangsdaten sollten auf den Firmennamen laufen, nicht auf persönliche Konten.

Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt. Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Danke, genau die Antwort, die ich gesucht habe. Wenn wir ohne Messung entscheiden landen wir immer wieder am selben Punkt.

Ich hoffe, das hilft dir weiter.

du hast recht.

Da hast du recht. Das Teuerste an übernommenen Systemen sind unbekannte Abhängigkeiten.

Aus Erfahrung weiß ich das.

Ich erkläre mal die technische Seite. Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten. An deiner Stelle würde ich so vorgehen.

kannts du das etwas genauer erklären? übrigens nur weil alle es tun, heißt es nicht, dass es richtig ist.

viel Erfolg.

Kannst du das etwas genauer erklären? Das günstigste Angebot ist oft das am wenigsten durchdachte.

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

Ich spreche mal aus der Gegenperspektive ich bin auf der Lieferantenseite. Wer bei ios programmiersprache hetzt stolpert alle an derselben Stelle.

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

Ich habe keinerlei Erfahrung mit ios programmiersprache, deshalb frage ich. Das allein zu versuchen, ist der teuerste Weg.

Da ist mir noch ein Punkt unklar. Ein Change-Request-Prozess verlangsamt die Arbeit nicht, sondern beschleunigt sie.

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