Independent Engineering · Mobile
Wenn eine progressive Web-App nicht reicht — weil offline gearbeitet werden muss, weil die Hardware mit muss (Kamera, Barcode, Bluetooth, NFC), weil sie im App Store gefunden werden soll. Wir bauen iOS- und Android-Apps mit .NET MAUI für Microsoft-nahe Stacks, React Native für breite Cross-Platform-Projekte oder native Swift/Kotlin, wenn die Aufgabe es verlangt.
Entscheidungs-Hilfe
Eine native App ist teurer und aufwendiger zu betreiben als eine Web-Anwendung. Vier Szenarien, in denen sich der Aufwand lohnt — und drei, in denen Sie besser bei einer PWA bleiben.
Außendienst-Techniker im Maschinenraum, im Untergeschoss oder am Mast. Kein WLAN, schwankendes Mobilfunk-Signal. Auftrag muss trotzdem abgearbeitet, dokumentiert und später synchronisiert werden. Eine native App mit lokaler SQLite und Sync-Engine ist hier ohne Alternative.
Lager-Inventur mit Barcode-Scanner. Asset-Tagging via NFC. Verbindung zu Bluetooth-Sensoren in Industrie- oder Gesundheits-Settings. Browser-APIs decken einen Teil ab — aber nicht stabil genug für tägliche Nutzung mit hunderten Operationen pro Schicht.
Endkunden suchen Sie über Apple App Store oder Google Play. Eine PWA, die nur über eine URL erreichbar ist, taucht dort nicht auf. Wenn der App Store Teil des Vertriebskanals ist, brauchen Sie eine echte App mit App-Store-Eintrag.
Wenn die App mehrmals täglich, jeweils 30+ Minuten genutzt wird — Logistik-Tour, Krankenpflege, Service-Außendienst — zählt jede Sekunde Latenz und jedes Quäntchen Akku. Native Apps sind hier deutlich performanter und energie-effizienter als Web-basierte Alternativen.
Internes Tool, das gelegentlich am Smartphone genutzt wird, kein Offline-Bedarf, keine Hardware-Integration. Hier baut man eine progressive Web-App mit Next.js: 60 % der Funktionalität, 25 % der Kosten, kein App-Store-Approval-Cycle.
Daten-getriebene interne Mobile-Anwendungen mit 5–50 Nutzern, die ohnehin in einem Microsoft-Tenant arbeiten. Hier ist Microsoft Power Apps typisch in 4–8 Wochen produktiv — ohne dass jemand einen App-Store-Approval-Prozess durchstehen muss.
Tech-Stack
Eine Stack-Entscheidung ist langfristig — Mobile-Apps leben drei bis fünf Jahre, oft länger. Wir wählen pro Projekt bewusst und begründet, statt eine Hauspräferenz zu erzwingen.
Microsofts Cross-Platform-Framework, Nachfolger von Xamarin Forms. Ein C#-Codebase deckt iOS, Android, macOS und Windows ab. Sinnvoll, wenn Sie ohnehin Dynamics 365, Power Platform oder einen .NET-Backend-Stack nutzen — die Auth-Bibliotheken (MSAL), die Dataverse-Anbindung und die Microsoft-Identity-Story sind hier am ausgereiftesten. Unser Default für B2B-Field-Apps mit Microsoft-Integration.
JavaScript/TypeScript-basiertes Framework von Meta, mit dem größten Ökosystem an Open-Source-Komponenten. Sinnvoll, wenn das Web-Team in TypeScript denkt und Code-Sharing zwischen Web und Mobile nützlich ist (z. B. Validierungs-Logik, API-Clients). Wir nutzen typischerweise mit Expo, das Build-Tooling und Update-Pipelines vereinfacht.
Wenn AR-Funktionen (ARKit / ARCore), CoreML-Inferenz auf dem Gerät, professionelle Audio-/Video-Verarbeitung oder pixelgenaue UI-Animationen gefragt sind, gibt es zur nativen Entwicklung keine Alternative. SwiftUI für iOS, Jetpack Compose für Android. Hier liefern wir sortenrein nach Plattform — höherer Aufwand, dafür maximale Plattform-Tiefe.
Offline-fähige Apps brauchen einen lokalen Datenspeicher, typischerweise SQLite — direkt oder via Realm bzw. WatermelonDB. Sync-Strategien (last-write-wins, operational transforms, CRDTs) wählen wir nach Konflikt-Verträglichkeit. Bei D365-/Dataverse-gestützten Apps nutzen wir den Microsoft Field Service Sync-Mechanismus oder bauen einen eigenen, falls nötig.
Authentifizierung läuft über OAuth 2.0 mit PKCE, Tokens werden im plattform-eigenen Secure Storage abgelegt (Keychain auf iOS, Keystore auf Android). Bei Microsoft-Integration nutzen wir MSAL (Microsoft Authentication Library), das Conditional Access, MFA und Single Sign-On out of the box mitbringt.
Drei Project-Shapes
Welche Form passt, hängt davon ab, wie weit Sie sind und ob die App ein eigenständiges Produkt oder Teil einer größeren Plattform werden soll.
Sie wissen, dass eine App gebraucht wird, aber nicht, ob nativ oder cross-platform, ob mit eigenem Backend oder via Dataverse, ob ein Store-Approval realistisch ist. Wir validieren technische Annahmen, klären Plattform-Strategie, prüfen Apple-/Google-Konten und liefern Entscheidungs-Vorlage + Roadmap.
Vom Spike zur veröffentlichten App. Wir bauen die Kern-Workflows in einem .NET-MAUI- oder React-Native-Codebase, richten Build-Pipelines (TestFlight, Play Console internal track) ein und führen den Store-Approval-Prozess. Erste echte Nutzer können nach 3–4 Monaten testen, öffentliche Veröffentlichung ist je nach Komplexität nach 5–8 Monaten realistisch.
Sie haben bereits eine App im Store, brauchen aber laufende Weiterentwicklung — neue Features, OS-Updates (jährlich), Drittanbieter-SDK-Migrationen. 1–2 Mobile-Engineers arbeiten in Ihrem Team mit, in Ihrer Pipeline, mit Ihren Reviews.
Microsoft-Integration
Wenn Sie ohnehin im Microsoft-Stack sind, vereinfacht das eine Mobile-App-Strategie deutlich. Vier konkrete Anker-Punkte, an denen wir tief integrieren:
Dynamics 365 Field Service — als Backend. Service-Aufträge, Disposition, Asset-Daten, Service-Berichte: alles im Field-Service-Datenmodell vorhanden. Wir bauen die Mobile-App entweder auf dem Microsoft-Field-Service-Mobile-SDK oder direkt gegen die Dataverse-Web-API, je nachdem wie viel Anpassung nötig ist.
Dynamics 365 Sales — als Backend. Außendienst-Apps mit Lead-Erfassung, Account-Übersicht, Termin-Vorbereitung. Offline-fähige Spiegelung von Konten, Kontakten und Verkaufschancen.
Microsoft Entra ID — als Identity Provider. Single Sign-On in die App via MSAL, Conditional Access (z. B. „nur erlaubt aus Deutschland"), MFA via Authenticator. Kein eigener User-Login, keine separate Passwort-Verwaltung.
Microsoft Intune — als MDM und Verteilungs-Kanal. Für interne Apps verteilen wir über Intune Company Portal, statt über App Store / Play Store. Dazu Compliance-Policies (Geräte-Verschlüsselung, PIN-Zwang, Remote-Wipe). Sinnvoll, wenn die App nicht öffentlich sein soll oder unternehmensweite Geräte-Steuerung gefragt ist.
Souveränität bei Mobile
Backend-Hosting in der EU — vollständig kontrollierbar. Eigenes Backend bei Hetzner, STACKIT, IONOS oder OTC. Datenbank, Object Storage, Identity-Provider — alles unter EU-Recht und ohne Cloud-Act-Exposition. Bei Microsoft-Backend (Dataverse) gilt die Microsoft-EU-Daten-Boundary-Zusage, die Schrems-II-Risiken nicht eliminiert, aber begrenzt.
App Stores — nicht souverän, aber unausweichlich. Apple App Store und Google Play sind US-Infrastruktur. Bei öffentlich verteilten Apps ist das die Realität. Bei rein internen Apps gibt es Alternativen: Intune Company Portal, Apple Business Manager mit privatem Distribution-Programm, Sideloading auf Android.
Telemetrie EU-konform. Crash-Reporting via Sentry self-hosted (oder Sentry-EU-Tenant), Analytics via Plausible oder Matomo (statt Firebase Analytics oder Google Analytics 4). Push-Notifications via APNs / FCM lassen sich nicht vermeiden, aber wir reduzieren die Payload auf das Notwendige und verschlüsseln sensitiv inhaltliche Anteile.
Datenmodell und Lokalspeicher. Im Secure Storage des Geräts (Keychain / Keystore) liegen nur Auth-Tokens. Geschäftsdaten in einer SQLite-Datenbank, verschlüsselt mit dem plattform-eigenen Datenträger-Schutz. Bei sehr sensiblen Daten zusätzlich auf App-Ebene mit AES-256 (z. B. SQLCipher).
Weiterführend
Das Backend für Ihre Mobile-App — TypeScript/NestJS/PostgreSQL, EU-gehostet, in Ihrem Code-Besitz. Oder die Web-Variante als progressive Web-App, falls eine native App nicht nötig ist.
Für interne Mobile-Apps mit 5–50 Nutzern oft die schnellere Antwort. Canvas-Apps für formulargetriebene Use Cases, Model-Driven für Dataverse-zentrierte Anwendungen.
Wenn die Mobile-App das Werkzeug für Service-Techniker ist und der Standard-Funktionsumfang reicht — Microsofts Field-Service-Mobile-SDK ist der direkteste Pfad.
Bevor Sie einen App-Store-Konto eröffnen: Plattform-Strategie, Build-vs-Buy, Backend-Wahl, Verteilungs-Modell. 45 Minuten am Whiteboard sparen 4 Wochen Konzept-Phase.
Häufige Fragen
Wenn die App offline funktionieren muss, Hardware-Zugriffe braucht (Kamera, Bluetooth, Barcode-Scanner, NFC, Background-Sync) oder im App Store/Play Store gefunden werden soll. Außerdem für sehr lange Sessions, in denen die Web-Performance an Grenzen stößt. In allen anderen Fällen prüfen wir zuerst, ob eine PWA reicht — sie ist deutlich günstiger zu bauen und zu betreiben.
Cross-Platform (.NET MAUI oder React Native) ist in 80 % der B2B-Fälle die richtige Antwort: ein Codebase, zwei Plattformen, deutlich kleineres Team. Native (Swift/SwiftUI für iOS, Kotlin/Jetpack Compose für Android) wird sinnvoll bei AR/VR, ML-Inferenz auf dem Gerät, Echtzeit-Audio oder UI-intensiven Consumer-Apps. Für Mittelstands-Apps mit Microsoft-Integration ist .NET MAUI in der Regel der pragmatischste Weg.
Über die Dataverse-Web-API mit OAuth-2.0-Tokens aus Microsoft Entra ID. Für Field-Service-Szenarien gibt es das Field Service Mobile SDK; wir bauen darauf, wenn der Standard-Funktionsumfang reicht. Für Custom-Workflows greifen wir direkt auf Dataverse zu, mit konfigurierbarem Offline-Cache und Sync-Logik.
Drei Wege: (1) Öffentlicher App Store / Play Store für Customer-facing Apps. (2) Enterprise-Verteilung über Microsoft Intune (Company Portal) — für interne Apps, die nicht öffentlich sein sollen. (3) Apple Business Manager / Apple Developer Enterprise Program für sehr große iOS-Flotten. Wir richten Build-Pipelines so ein, dass jeder Push auf Main automatisch eine TestFlight- oder internal-track-Version baut.
Drei realistische Pfade: (1) Microsoft-Stack — Dataverse + Power Platform-APIs + Azure Functions, wenn Sie ohnehin im Microsoft-Ökosystem sind. (2) Custom-Backend in unserem Stack — TypeScript/NestJS auf PostgreSQL, gehostet bei Hetzner oder STACKIT (EU-Souveränität). (3) Hybrid — Dynamics-Daten via Dataverse-API, ergänzt um eigenes Backend für Funktionen, die D365 nicht abbildet. Wir helfen bei der Entscheidung im Architecture-Gespräch.
Backend kann vollständig EU-souverän sein (Hetzner / STACKIT / IONOS / OTC). App Stores selbst sind US-Infrastruktur (Apple, Google) — daran kommt man bei öffentlich verteilten Apps nicht vorbei. Telemetrie (Crash-Reporting, Analytics) konfigurieren wir EU-konform: Sentry self-hosted oder Plausible statt Firebase Crashlytics. Push-Notifications laufen über APNs/FCM — hier ist die Frage, wie viel Payload man verschlüsselt überträgt.
Discovery-Spike (2–4 Wochen): klärt Use Cases, Plattformen, Backend-Strategie, App-Store-Konten — Festpreis. MVP einer einfachen iOS+Android-App via .NET MAUI: typisch 3–5 Monate. MVP einer App mit komplexer Offline-Sync und Hardware-Integration: 5–8 Monate. Embedded-Team (1–2 Mobile Engineers, monatlich): laufende Weiterentwicklung mit eigenem Produkt-Team beim Kunden. Konkrete Zahlen geben wir gemeinsam nach Discovery.
Ja. Wenn Sie schon ein REST/GraphQL-API oder Dynamics 365 / Dataverse haben, übernehmen wir den Mobile-Teil und docken an. Voraussetzung: das API ist dokumentiert (OpenAPI / Postman-Collection) und die Auth ist klar (OAuth 2.0, OIDC, JWT). Bei undokumentierten Backends startet das Projekt mit einem API-Audit.
30 Min · kostenlos · ohne Verpflichtung
30 Minuten, in denen wir Ihren konkreten Use Case durchsprechen — Plattformen, Backend, Verteilungs-Modell, App-Store-Realität. Kein Vorbereitungs-Druck, bringen Sie mit, was Sie haben.
Begleitende Dienstleistungen
Engineering-Projekte stehen selten allein — Lizenz-Logik, Architektur-Klärung, Quality-Gates, Wissens-Transfer und Folge-Betrieb laufen meistens parallel. Hier die häufigsten Begleitleistungen, die wir in Discovery-Spike, Sprint-Festpreis oder Application-Care-Verträgen zubuchen.
Vorab · Architektur
Bevor implementiert wird: Tenant-Struktur, Datenmodell, Sicherheitskonzept, Integration-Mapping. Ergebnis ist ein Architektur-Dokument, mit dem jedes Engineering-Team weiterarbeiten kann — auch ein anderes als wir.
Ansehen →
Vorab · CSP
Welche Lizenz-Bundles für welche User, welche Add-on-SKUs notwendig sind, wo Sie über- oder unterlizenziert sind. Als Microsoft Lizenzierungspartner bezogen — mit der Option, CSP nur als Kontrolle ohne Margenmaximierung zu nutzen.
Ansehen →
Während · Quality-Gate
Unabhängige Zweit-Meinung während eines laufenden Implementations-Projekts — egal ob wir es selbst durchführen oder ein anderer Partner. CMMI-basierte Quality-Gates, Risk-Reviews, Festpreis pro Gate.
Während · Adoption
Nicht der klassische 2-Tage-Workshop, der nach einer Woche vergessen ist — sondern ein dynamisches Lernprogramm über 4–6 Wochen mit Erstschulung, Anwendungsphasen und Aufbau-Sessions. Schulungs-Matrix für Rollen und Themen.
Ansehen →
Danach · Betrieb
Nach Go-Live: planbarer Application-Care-Vertrag mit Monatspauschale, SLA-basiert. Inklusive Releases, Hotfixes, Erweiterungen, Tenant-Hardening — und kontinuierlicher Begleitung statt nur Reaktion auf Ticket.
Ansehen →
Danach · Wissen
Wenn die ursprünglichen Entwickler weg sind, der Vorgänger-Partner nicht mehr greifbar oder die Dokumentation veraltet — Reverse Engineering der bestehenden Lösung mit dokumentiertem Ergebnis: Code-Map, Datenmodell, Customization-Inventar.
Ansehen →
