Entwicklung mobiler Apps

Sind die meisten Screens Formulare, Listen und Detailansichten, decken React Native oder Flutter beide Plattformen aus einer Codebasis ab. Nativ — Swift oder Kotlin — gewinnt bei Modulen nah an der Hardware: Kameraverarbeitung, Hintergrundortung, Bluetooth und aufwendige Grafik. Neuros stellt beides nicht gegeneinander: Der Großteil der App ist plattformübergreifend, das kritische Modul wird nativ geschrieben und per Bridge eingebunden.

Die meisten Ablehnungen stammen aus Richtlinien, nicht aus Code: fehlender Kontolöschungs-Flow, eine unbegründete Berechtigungsabfrage, Datenschutz-Labels, die nicht zum tatsächlichen Verhalten passen, und Zahlungsflüsse am Store vorbei. Neuros nimmt diese Punkte in die Pre-Release-Checkliste auf; Apples Review-Richtlinien und die Google-Play-Anforderungen sind Teil der Release Notes.

Ja. Neuros entwirft mobile Apps offline-first: Daten liegen in einer lokalen Datenbank auf dem Gerät, Nutzende können ohne Verbindung schreiben, und eine Sync-Queue wird geleert, sobald die Verbindung zurückkehrt. Ändert sich derselbe Datensatz auf zwei Geräten, ist die Konfliktlösung als explizite Regel formuliert — Last-Write-Wins oder feldweises Merge — sodass niemand Datenverlust zu sehen bekommt.

Der Launch-Tag ist der Beginn des Wartungsfensters, nicht das Ende der Arbeit. Neuros beobachtet nach dem Release die Rate absturzfreier Sitzungen, die Verteilung der OS-Versionen und die Store-Bewertung und führt einen geplanten Release-Kalender für Betriebssystem-Updates und Store-Richtlinienänderungen. Der Wartungsumfang ist vertraglich geregelt: Reaktionszeit, Fehlerpriorität und Anzahl der Releases pro Monat sind festgehalten.

Eine schlichte App für eine Plattform dauert 8–12 Wochen, ein Produkt für beide Plattformen mit eigenem Backend 12–20. Den Zeitplan bestimmt nicht die Zahl der Screens, sondern die Zahl der Integrationen — Zahlung, Identität, Karten und Unternehmensanbindungen bringen je eigene Testlast. Die Review-Zeit der Stores kommt zusätzlich in den Plan.