Eine mobile Anwendung ist nicht fertig, wenn sie im Store liegt. Sie ist fertig, wenn klar ist, wie das nächste Betriebssystem-Update behandelt wird.
Typische Ausgangslagen
- Eine App soll auch dann funktionieren, wenn keine Netzverbindung besteht.
- Android und iOS sollen dieselbe Fachlogik abbilden, aber ihre jeweils eigenen Bedienmuster respektieren.
- Daten sollen auf dem Gerät bleiben – aus Datenschutzgründen oder weil es kein Backend gibt.
- Der Review-Prozess eines Stores blockiert Releases, ohne dass jemand den Grund kennt.
Technische Aufgaben
- Native Entwicklung mit Kotlin für Android und Swift für iOS
- Lokale Datenhaltung entwerfen: Schema, Migrationen, Verschlüsselung, Backup-Verhalten
- Offline-first-Architektur, wenn die Anwendung ohne Netz vollständig nutzbar bleiben muss
- Berechtigungen, Datenschutzangaben und Store-Anforderungen beider Plattformen bedienen
- Release-Prozesse aufsetzen, die auch bei kurzfristigen Korrekturen tragen
Vorgehen
Plattformunterschiede werden nicht versteckt, sondern benannt. Eine gemeinsame Fachlogik ist sinnvoll; eine gemeinsame Oberfläche, die auf beiden Systemen fremd wirkt, ist es selten.
Bei lokaler Datenhaltung wird früh geklärt, was ein Gerätewechsel bedeutet und was bei einer Deinstallation passiert. Diese Antworten gehören in die Architektur und nicht in die FAQ.
Systemkontext
AuraHarmony ist die eigene Produktentwicklung von EicDevCon in diesem Feld und zeigt die genannten Entscheidungen an einem realen Fall.