Alex Ilovan Engineering & research
I design, build, and improve iOS, Android, and cross-platform apps — combining product thinking, scalable architectures, AI/IoT expertise, and years of technical leadership experience.
What I’m building
Architecture, hands-on engineering, and products in the real world.
Turning equestrian training moments into actionable insights. An AI-powered app for live coaching, solo rides, and groundwork reflections.
I led the iOS architecture and implementation — from shared state and authentication to resilient audio capture and background uploads.
Read the case study TL;DR + full technical article
Portfolio
Over the past 10+ years, I’ve worked across 50+ mobile projects.
A case study in end-to-end mobile systems design: SwiftUI architecture, lifecycle orchestration, authenticated networking, resilient audio workflows, and production-ready engineering.
Together with Sioux, we built the Coach-Copilot app for Equestic.
On the iOS side, I led the architectural direction and was responsible for how the mobile system was designed and implemented. That included defining the app structure, shaping shared state and navigation, designing the networking and authentication layers, handling lifecycle-aware behavior, and building the audio recording and upload workflows so they could hold up under real-world mobile conditions.
What made the project especially interesting was that it required much more than screen implementation. Coach-Copilot had to support authenticated session flows, push and deep-link entry points, lifecycle-heavy behavior, and durable audio workflows. From the mobile perspective, that pushed the work firmly into systems design rather than straightforward feature delivery.
Coach-Copilot is an AI-powered equestrian app delivered for Equestic through a collaboration between me as an external iOS contractor and Sioux.
On the iOS side, I led the architectural direction and implemented the foundations of the mobile system. The product supports live coaching sessions, solo-ride reflections, and groundwork reflections, helping coaches and riders capture training context and turn it into structured, actionable follow-up.
The main engineering challenge was not building individual screens. It was coordinating authentication, navigation, app lifecycle events, audio recording, local persistence, background uploads, backend activity state, and AI-assisted summaries under real mobile conditions.
My responsibilities included:
The app uses a layered structure:
Views focus on rendering and user interaction. View models and workflow types handle presentation and multi-step orchestration. Services coordinate feature behavior, while repositories and stores isolate networking and persistence.
Dependencies are assembled at the application boundary, where the app can select real or stub implementations. Shared state uses SwiftUI Observation, while navigation is managed separately through typed routes and an observable, main-actor-isolated router.
The app models live coaching, solo rides, and groundwork reflections through a shared activity workflow system.
Each activity defines its own:
This reuses common infrastructure without pretending that every activity has the same workflow. The activity lifecycle also provides shared operations for cancellation, recording start, recording finalization, and upload completion while routing each operation to the correct backend implementation.
Authenticated networking uses typed endpoints, repositories, a shared HTTP client, Keychain-backed token storage, and centralized refresh coordination.
An actor-isolated token refresh coordinator prevents several
simultaneous 401 responses from starting duplicate
refresh requests. Waiting callers resume after one coordinated refresh
succeeds or receive the same terminal authentication failure if it
cannot recover.
Lifecycle behavior is centralized rather than distributed across screens. It coordinates launch bootstrap, authentication revalidation, foreground and background transitions, notifications, APNs token synchronization, deep links, remote configuration, force-update checks, recording policy, background-upload completion, and telemetry.
Audio is treated as a subsystem rather than a single record-and-upload action.
The recording layer handles:
The newer local recording journal separates device-level recording state from backend activity state. It models recording, local finalization, finalized-asset creation, durable upload handoff, backend acknowledgement, and recoverable failure as distinct stages.
Its segmented-recording design gives each segment a stable identity, validated metadata, explicit state, and any known silence that must precede it. Closed segments remain immutable, allowing recording to continue safely in a new segment after interruptions or input-format changes.
Raw segments remain owned by the local journal until a finalized audio asset and a durable upload job have both been persisted. This prevents audio from being deleted during the handoff between local export and background upload ownership.
Uploads are implemented as persisted, actor-isolated workflows with three logical stages:
Jobs support deduplication, retry with backoff, progress reporting,
cancellation, persistence, and relaunch recovery. A background
URLSession continues transfers independently of the
foreground UI and reconnects restored system tasks to their persisted
job identities.
This deliberately separates local recording durability, finalized-asset durability, file-transfer completion, and business-workflow completion.
The same architecture also supports:
The test target contains 29 test files and 22 mock, spy, stub, and support files. Coverage spans repositories, services, shared state, routing, system integration, and presentation logic.
The result is a SwiftUI application designed as a coordinated production system rather than a collection of screens.
Its key architectural outcomes are:
Most importantly, the architecture supports the product’s real purpose: reliably preserving training moments and transforming them into structured information that coaches and riders can revisit and act on.
Go deeper into the architecture, engineering decisions, and tradeoffs.
Read the full technical article