Die Shiny-Bibliotheken – Bluetooth, Hintergrundaufgaben, Push, Standort und Synchronisierung für .NET – haben die Marke von 40 Millionen Downloads überschritten und stehen in der Projektdatei von Apps, die Sie kennen. Wir haben sie geschrieben, wir pflegen sie, und wir arbeiten mit dem .NET-MAUI-Team von Microsoft zusammen. Wenn Ihre App draußen im Feld auf echten Geräten funktionieren muss, ist das die Tiefe, die Sie einkaufen.
Die Geräteseite des Geschäfts, aufgebaut auf einem Fundament, das bereits im Produktiveinsatz ist.
Produktive Apps mit .NET MAUI, für iOS und Android sowie Umstellungen von Xamarin auf MAUI – einschließlich der Hintergrund-, Offline- und Lebenszyklus-Themen, an denen die meisten Teams scheitern. Wir arbeiten mit dem .NET-MAUI-Team von Microsoft zusammen, seit es MAUI gibt.
BLE Central und Peripheral, Geräteflotten und Hardware-Integration. Wir haben die Bibliotheken geschrieben, die die Branche dafür nutzt.
Standortverfolgung, Geofencing und Telematik für Fahrzeuge und Teams, die dort arbeiten, wo keine Verbindung garantiert ist.
Apps für Apple Watch, Wear OS, CarPlay und Android Auto, die Ihre mobile App ans Handgelenk und ins Armaturenbrett bringen – gemacht für einen kurzen Blick oder einen Sprachbefehl, nicht für einen geschrumpften Handybildschirm. Die Verbindung zwischen Telefon und Uhr läuft über eine Bibliothek, die wir selbst geschrieben haben.
Ein Budget kauft Entwicklungsmonate. Die Frage ist, wofür diese Monate verwendet werden. Bei einem vernetzten Produkt – alles mit einem Gerät, einem Hintergrundprozess oder einem Offline-Szenario – fließt ein großer Teil des ersten Jahres in Infrastruktur, die für Kunden keinen sichtbaren Wert hat und die Tausende Teams schon einmal geschrieben haben.
Beispielhafte Anteile – die genaue Aufteilung hängt vom Projekt ab. Was sich nicht ändert: auf welcher Seite der Linie Sie ein Entwicklungsteam dafür bezahlen, etwas nachzubauen.
Umsatz und Feedback kommen früher, weil der Zeitplan nicht mit einem Quartal Grundlagenarbeit beginnt.
Die riskantesten Teilsysteme – Hintergrundarbeit, Synchronisierung, Gerätekonnektivität – sind produktiv bewährt, bevor Ihr Projekt startet.
Weniger Code in Ihrem alleinigen Besitz heißt weniger zu patchen, zu portieren und personell abzudecken – in jedem Jahr nach der Übergabe.
Die Ecke, die die meisten Projekte opfern, haben wir bereits bezahlt – öffentlich und über 25 Jahre –, und sie ist in der Zusammenarbeit enthalten. Was Ihnen das bringt, ist einfach: Mehr vom Jahr fließt in das Produkt, das Sie bauen wollten, und weniger in den Weg zur Startlinie.
Jede Zusammenarbeit kann mit einem dieser Angebote beginnen. Jedes hat einen Namen und einen vor Beginn schriftlich festgelegten Umfang. So ist die erste Entscheidung eine kleine – und Sie sehen, wie wir arbeiten, bevor Sie sich auf etwas Größeres festlegen.
Für Apps, die bereits auf .NET MAUI laufen – Startzeit, Abstürze, die sich nur auf echten Geräten reproduzieren lassen, und Hintergrundaufgaben, die nach einem OS-Update nicht mehr auslösen.
Eine gewichtete Liste von Korrekturen, die schwersten davon bis auf die Codezeile diagnostiziert.
Jedes Plugin und jede Plattformabhängigkeit Ihrer Xamarin-App dem zugeordnet, was sie in .NET MAUI ersetzt – der Schritt, an dem die meisten Portierungen ins Stocken geraten.
Ein Migrationsplan, der auf Nachschlagen statt auf einer Recherchephase beruht – und eine echte Schätzung.
Ihre Hardware im Austausch mit einer echten App unter iOS und Android – Scannen, Verbinden, Wiederverbinden und Synchronisieren im Hintergrund, auf echten Geräten, nicht im Simulator.
Der Beweis, dass der schwierige Teil auf echten Telefonen funktioniert, und ein kalkulierter Weg zur produktiven App.
Jedes Angebot erhalten Sie zum Festpreis, sobald wir den Umfang gesehen haben – und ein Festpreis bleibt fest. Brauchen wir länger, ist das unser Problem, nicht Ihres.
Die UI-Umstellung entscheidet das selten – die Liste der Abhängigkeiten schon. Die zweiwöchige Abhängigkeitsanalyse ordnet jedem Plugin seinen Ersatz zu und macht daraus eine gestaffelte Schätzung.
Nein. Meist ist es sinnvoll, weil sie Open Source sind, bereits im Produktiveinsatz und von denselben Leuten gepflegt werden, die die Arbeit machen. Sie sind nie an eine private Hilfslösung gebunden, die nur der Dienstleister versteht.
Ja. Die meisten Bluetooth-Probleme liegen an der Grenze zwischen App und Firmware, und wir sind es gewohnt, über diese Grenze hinweg zu arbeiten – auch wenn es darum geht, einem Lieferanten zu sagen, was sich auf seiner Seite ändern muss.
Unsere Stärke ist .NET MAUI und .NET für iOS und Android, einschließlich des nativen Plattformcodes darunter. Wenn eine native App für Ihr Produkt die richtige Wahl ist, sagen wir es Ihnen.
Erzählen Sie uns von der App, den Geräten und davon, wo sie eingesetzt werden. Wir sagen Ihnen, wo es normalerweise schiefgeht – und wie wir das vermeiden würden.
