Wir entwickeln plattformübergreifende Apps mit React Native und Flutter — ein Team, eine Codebasis, beide Stores — und sagen offen, wann nativ die bessere Wahl ist.
Mobile Projekte scheitern häufiger nach dem Launch als währenddessen. Die Entwicklung ist fertig, die App erreicht beide Stores, und dann ziehen die Betriebssysteme weiter. Apple und Google veröffentlichen jährlich je eine große Version, setzen Schnittstellen nach Plan außer Kraft und ändern regelmäßig, was die Prüfung durchgehen lässt. Eine App, die niemand pflegt, lässt sich nach etwa achtzehn Monaten nicht mehr übersetzen, und ein abgelehntes Update ist zu diesem Zeitpunkt ein Neubau und keine Reparatur.
Das zweite wiederkehrende Problem ist, das Netz für verlässlich zu halten. Telefone verlieren den Empfang in Aufzügen, in Zügen und in genau den Gebäuden, in denen Außendienstmitarbeiter tatsächlich arbeiten. Eine App, die Konnektivität voraussetzt, produziert Ladesymbole, verlorene Formulareingaben und Support-Anrufe. Offline-Verhalten ist eine früh getroffene Entwurfsentscheidung und keine später ergänzte Funktion.
Beides sind ebenso Budgetfragen wie technische Fragen. Wir setzen die Erwartung lieber vor Projektbeginn, als etwas auszuliefern, das still abläuft.
React Native oder Flutter, je nachdem, was die App braucht und was Ihr Team pflegen kann. Plattformspezifischer Code dort, wo der Unterschied wirklich zählt, gemeinsamer Code überall sonst — und das ist fast überall.
Lokale Speicherung, eingereihte Schreibvorgänge und Konfliktbehandlung, entworfen anhand Ihrer tatsächlichen Nutzung statt wegdiskutiert. Arbeiten Ihre Nutzer in Lagerhallen, Kellern oder fahrenden Fahrzeugen, entscheidet genau das zwischen einer App, die genutzt wird, und einer, die liegen bleibt.
Einrichtung von App Store und Play Console, Signierung, Datenschutzangaben, Store-Einträge und der Prüfzyklus. Erste Einreichungen werden oft genug abgelehnt, dass Erfahrung hier echte Kalenderzeit spart.
Segmentiert, mit Einwilligung und an Ereignisse gebunden, von denen Menschen wirklich hören wollen. Die Erlaubnis für Mitteilungen wird einmal erteilt und dauerhaft entzogen — die erste Abfrage sollte also verdient sein und nicht beim Start abgefeuert werden.
Mobile Clients brauchen andere Schnittstellenformen als Browser — weniger Hin und Her, kleinere Nutzdaten und Versionierung, weil sich niemand zwingen lässt, gleichzeitig zu aktualisieren. Wir bauen die Schnittstelle mit diesem Blick oder passen eine vorhandene an.
Automatisierte Builds, gestaffelte Ausrollung und Absturzberichte vom ersten Tag an eingerichtet, damit ein schlechtes Release über das Dashboard auffällt und nicht über eine Bewertung.
Wir wählen daraus nach dem, was das Projekt braucht und was Ihr Team nach der Übergabe pflegen kann — nicht danach, womit wir am liebsten arbeiten. Ist bereits ein tragfähiger Technologiestand vorhanden, arbeiten wir darin weiter.
Techniker, Fahrer und Prüfer, die ihre Arbeit fernab vom Schreibtisch erfassen. Gefragt sind meist Offline-Erfassung, Kamera, Standort und ein Synchronisationsmodell, das einen Empfangsabbruch mitten im Formular übersteht.
Buchung, Bestellung und Kontoverwaltung, wenn die Nutzung häufig genug ist, um eine Installation zu rechtfertigen. Ist sie das nicht, empfehlen wir in der Regel eine gut gebaute responsive Website und sparen Ihnen das Budget.
Eine mobile Oberfläche über ein System, das Sie bereits betreiben. Die Arbeit betrifft häufig eher Schnittstellenentwurf und Anmeldung als die Oberfläche selbst.
Werkzeuge für Mitarbeitende, die über verwaltete Verteilung statt über die öffentlichen Stores ausgerollt werden, womit der Prüfzyklus vollständig aus Ihrem Release-Weg verschwindet.
Plattformübergreifend passt zur großen Mehrheit geschäftlicher Apps und kostet spürbar weniger in Entwicklung und Pflege, weil ein Team eine Codebasis betreut. Nativ wird zur besseren Wahl, wenn die App stark auf plattformspezifische Hardware setzt, dauerhaft hohe Bildraten braucht oder selbst das Produkt ist und sich exakt wie die Plattform anfühlen muss. Wir geben Ihnen eine klare Empfehlung für Ihren Fall statt einer Standardantwort.
Oft nicht. Wenn Menschen sie ein paar Mal im Jahr nutzen würden, ist die Installation eine Hürde und eine responsive Website bedient sie besser, zu einem Bruchteil der Kosten. Apps rechtfertigen sich über Nutzungshäufigkeit, über echte Gerätefunktionen — Kamera, Standort, Offline, Hintergrundsynchronisation — oder über die Notwendigkeit, auf dem Startbildschirm eines Telefons präsent zu sein.
Eine fokussierte erste Version braucht in der Regel 8 bis 14 Wochen einschließlich Store-Einreichung. Apps mit umfangreichem Offline-Verhalten, Zahlungen oder komplexen Anbindungen dauern länger. Die Store-Prüfung kostet Tage statt Wochen, sobald die Kontoeinrichtung stimmt, wobei eine Erstprüfung länger dauern kann.
Realistisch zwei bis vier Releases im Jahr: Betriebssystem-Updates, Aktualisierungen von Abhängigkeiten und SDKs sowie regelmäßige Änderungen der Store-Anforderungen. Das ist dauerhaft und nicht optional — eine ungepflegte App lässt sich irgendwann nicht mehr übersetzen. Wir sehen es lieber, wenn Sie das von Anfang an einplanen.
Ja, und wir empfehlen es. Ihr Unternehmen sollte die Konten für App Store und Play Console sowie die Signaturschlüssel besitzen. Falls Sie sie noch nicht haben, richten wir sie gemeinsam mit Ihnen ein.
Schicken Sie uns das Problem und die Randbedingungen, die Sie bereits kennen. Wir melden uns mit dem, was es unserer Ansicht nach braucht, einem Vorgehen und einer realistischen Größenordnung — oder mit der Auskunft, dass wir dafür nicht die Richtigen sind.
Wir entwerfen und bauen den Teil des Produkts, den niemand sieht, bis er ausfällt: Schnittstellen, Datenmodelle, Anmeldung und die Anbindungen, die ein Unternehmen zusammenhalten.
Wir gestalten Oberflächen auf Grundlage von Belegen: was Menschen zu tun versuchen, woran sie heute scheitern und was die Umsetzung realistisch tragen kann.
Wenn Standardsoftware Ihr Team in Umwege zwingt, wird die Rechnung jeden Tag in Handarbeit bezahlt. Wir bauen Systeme, die zu dem Prozess passen, den Sie bereits haben.
