Außendienst, Service und Fahrer verlieren die Verbindung: im Keller, in der Tiefgarage, auf dem Land. Eine App, die das nicht einplant, fällt genau dann aus, wenn sie gebraucht wird.
Wir entwickeln native iOS-Apps, Cross-Platform-Apps und installierbare Web-Anwendungen und binden sie an ERP, Auftragssystem oder eigenes Backend an. Welcher Weg der günstigere ist, entscheidet der Bedarf, nicht der Trend.
Drei Entscheidungen vor der ersten Zeile Code
Die Kosten entstehen nicht beim Bauen, sondern bei drei Entscheidungen, die am Anfang beiläufig getroffen und später dauerhaft bezahlt werden.
Offline-first ist eine Architekturentscheidung, kein nachträglicher Zwischenspeicher. Das schwierige Problem ist nicht das Speichern, sondern der Abgleich: Wer gewinnt, wenn zwei Geräte denselben Auftrag offline geändert haben?
Der teuerste Posten ist selten der Bau, sondern zwei getrennte Codebasen dauerhaft zu pflegen. Ob sich das rechnet, hängt an Kamera, Sensorik, Hintergrundprozessen und Offline-Anspruch.
Viele Unternehmen brauchen keinen Store-Eintrag, sondern einen mobilen Prozess. Eine installierbare Web-App erfüllt das oft schneller und ohne Review-Zyklen.
Vier Arbeitsbereiche, die sich in echten Projekten als die tragenden herausgestellt haben.
Auftragsdaten, Fotos, Unterschriften und Statusmeldungen funktionieren ohne Verbindung und gleichen sich ab, sobald wieder Netz da ist.
Wenn Kamera, Sensorik, Hintergrundverarbeitung oder tiefe Systemintegration zählen, ist nativ die ehrlichere Antwort.
React Native oder eine installierbare Web-App, wenn beide Plattformen dieselbe Fachlichkeit brauchen und zwei Codebasen sich nicht rechnen.
Eine mobile App steht selten allein. Sie hängt an Warenwirtschaft, Auftragssystem, Karten und Zahlungen.
Vier Schritte, in denen die Plattformentscheidung nicht am Anfang steht, sondern nach der ersten Frage.
01
Zuerst klären wir, was mobil wirklich passieren muss und wo die Verbindung ausfällt. Erst danach ist die Plattformfrage überhaupt beantwortbar.
02
Nativ, cross-platform oder Web wird begründet festgehalten, inklusive der Folgekosten. So bleibt die Entscheidung später überprüfbar.
03
Getestet wird auf echten Geräten und mit echtem Verbindungsabbruch, nicht nur im Simulator mit stabilem WLAN.
04
Betriebssystem-Updates, Review-Zyklen und Fehlerbilder aus dem Feld gehören zum Produkt, nicht zur Nachsorge.
Belegte Arbeit
Nativ, cross-platform oder beides. Die Angaben unten beschreiben veröffentlichte Funktionen, keine Roadmap.
Native iOS- und macOS-App mit SwiftUI, Swift, StoreKit und Kamera-Integration. Im App Store veröffentlicht.
React Native für iOS zusammen mit einer Next.js-Web-Anwendung, Firebase und Push-Benachrichtigungen.
Web und natives iOS in einem Produkt: Node.js, PostgreSQL, Swift, Apple Maps und Stripe.
iOS mit Swift und Android mit Kotlin, dazu SUNMI-Kassenhardware und Stripe Connect.
Ein mobiles Projekt lohnt sich nicht immer. Diese Gegenüberstellung spart beiden Seiten ein Gespräch.
Eine Pauschale wäre unseriös, weil dieselbe Bildschirmzahl je nach Anforderung sehr unterschiedlich viel Arbeit bedeutet. Die Kostentreiber sind der Offline-Anspruch, die Anzahl der Plattformen, die Integrationen und der laufende Store-Betrieb. Wir schneiden lieber einen kleinen ersten Umfang, der eine echte Frage beantwortet, statt eine Zahl zu nennen, die später nicht hält.
Vier Fragen entscheiden das: Brauchen Sie Kamera, Sensorik oder Hintergrundverarbeitung? Muss die App ohne Netz arbeiten? Ist ein Store-Eintrag fachlich nötig oder nur gewünscht? Und gibt es jemanden, der zwei Codebasen dauerhaft pflegt? Erst danach ist die Antwort eine Entscheidung statt eines Geschmacks.
Dass Aufträge, Fotos, Unterschriften und Statusänderungen ohne Verbindung erfasst werden und sich später abgleichen, ohne Daten still zu überschreiben. Der Nutzer sieht, was noch nicht übertragen wurde. Der schwierige Teil ist nicht der lokale Speicher, sondern die Regel, wer bei einem Konflikt gewinnt.
Ja, inklusive der Review-Runden und der üblichen Rückfragen zu Berechtigungen, Datenschutzangaben und Testzugängen. Ein Store-Review kann eine Version zurückweisen; das gehört zum Ablauf und wird eingeplant, nicht als Überraschung behandelt.
Betriebssystem-Updates, geänderte Store-Richtlinien und Fehlerbilder aus dem Feld erzeugen laufend Arbeit. Wer das nicht einplant, hat nach einem Jahr eine App, die auf neuen Geräten nicht mehr startet. Wir klären den Betrieb vor dem Launch, nicht danach.
Beschreiben Sie den Ablauf, der mobil funktionieren soll. Wir sagen Ihnen, ob dafür eine native App nötig ist oder ob es günstiger geht.