AuraHarmony is EicDevCon's own product in the mobile space. This page focuses on the engineering side: architecture, data handling, platform differences and release processes.
Note
Product information, feature scope and app store links live on the product website auraharmony.app. This page covers the technical implementation only.
Why build our own products
Running your own product forces decisions that someone else usually makes in client work: which data model will still hold in five years? What happens when the user changes device? Who answers a store review question on a Friday evening?
That experience feeds directly back into mobile development work.
Architectural decisions
Native rather than cross-platform. Android and iOS are built with Kotlin and Swift respectively. The domain model is deliberately kept separate on each side, and interaction patterns follow the platform.
Offline-first. The application is fully usable without a network connection. That is not a later optimisation but the founding assumption of the data model.
On-device storage. There is no server synchronisation. That removes conflict resolution, account management and the question of who can see the data outside the device — the trade-off being that changing devices requires a deliberate user action.
Privacy by design. Data minimisation is an architectural decision here, not a setting that can be switched off.
Operations and release
Two platforms mean two release processes with different review times, different privacy declarations and different permission requirements. The process has to hold up when a fix needs to ship at short notice.
Decision
Going without a backend is a deliberate decision with a clear consequence: no synchronisation between devices, but equally no server-side data storage and no user account.
Discuss your technical starting point Open auraharmony.app (external link)