Skip to content
All projects
02 · MOBILE APP · PERSONAL PROTECTIONLive site

Hector: An iOS and Android app with the iOS build in the cloud

Screens of the Hector app: choosing protection, live tracking of the team, order review and the SOS screen
  • Mobile app
  • Team Lead

Stack:

  • Vue 3
  • TypeScript
  • Vite
  • Capacitor 8
  • Pinia
  • Vue Router
  • vue-i18n
  • VueUse
  • Tailwind CSS 4
  • vee-validate
  • zod
  • maska
  • Vitest
  • Vue Test Utils
  • Storybook
  • oxlint
  • ESLint
  • oxfmt
  • Husky
  • mise
  • Leaflet
  • OpenStreetMap
  • lottie-web
  • View Transitions API
  • miragejs
  • Codemagic
  • TestFlight
  • BrowserStack

used by me

Role
Frontend Team Lead
Team
15 people: 5 frontend, 4 backend, 2 designers, 2 QA, a PM and a DevOps engineer
Timeline
Since June 2026
Status
In development, demo build for the client
My role

What I did

  • Architecture and stackChose Vue 3 and Capacitor over React Native, Flutter and native. Wrote the guidelines: Tailwind without separate styles, all text through i18n, no as casts and no comments, tests in the AAA format.
  • Project startSet up the project: Capacitor with live reload, Tailwind, Storybook, linters, pre-push, the environment via mise, a README on running it in the emulator and the simulator.
  • CodeTime and date wheels with seamless looped scrolling, a phone mask, an accordion, i18n with the device locale, the first versions of the order review and active order screens.
  • The team and the clientSet tasks and priorities for four more developers, reviewed and merged PRs. They wrote the animations, the iOS part, the signals and the maps from my tasks. I presented the app to the client myself.

Context

Business

Hector is a personal protection and chauffeur service in Europe and the UAE. A client books protection or a car, pays for the order, follows the team on a map and presses SOS in a dangerous situation.

Protection agents have their own account: duty status, assigned orders and the route, arrival check-in, SOS alarms from clients.

The situation

There was no app: this is a new product built from scratch to the client's specification since June 2026.

The client needs everything to work on iOS and Android. The team works remotely from different cities, each on their own work computer, and an iPhone and a Mac are not part of a developer's core set of devices. So the iOS build and testing had to be set up so they would not depend on the devices at hand. On top of that the app works with device APIs, for example it reacts to a double tap on the back of an iPhone.

Process, architecture and decisions

The order flow

  1. 01ConfiguratorProtection: the number of agents, armed or not, dress code, a K9 handler, language. Or a car with a driver. Route, date, duration. In development: order state in Pinia, date and time wheels with seamless scrolling, address search through Photon and Nominatim, so the client puts an order together on one screen in a couple of minutes
  2. 02ReviewThe client checks the order and sends it to a manager. In development: the order review screen and a phone mask, so the manager gets the order with no mistakes in the contacts
  3. 03PaymentAn itemized invoice, a status timeline, the order can be edited. In development: the active order screen with a status timeline. Editing an order takes the client back to the configurator with the data kept, so they do not build the order again
  4. 04Live trackingThe team on the map with ETA, the SOS button at hand. In development: a Leaflet map and a route through OSRM. The SOS button is pinned to the screen, so there is no need to look for it in a dangerous situation

Why Vue and Capacitor

The stack was chosen around the team's strengths. The frontend developers are confident with Vue, and I know its ecosystem well myself. So from day one the team built the product instead of learning a new tool: this shortened the road to the demo and lowered the risk of errors. Vue with Capacitor brings other advantages too: one codebase for iOS and Android, an interface in plain CSS that lets Hector's complex design with gradients, glass and transparency match the mockups exactly, and access to the phone's features through plugins: biometrics, secure storage, system buttons. React Native and Flutter were considered too, but they would have given less freedom in the layout and taken time to learn.

Architecture

  • APPVue 3 SPA

    Inside a Capacitor shell on Android and iOS. Pinia keeps the order, the configurator, assigned orders and signals.

  • NATIVENative plugins

    Biometrics, secure storage for the PIN, the keyboard, the system Back button, safe area for iPhone cutouts.

  • APIBackend REST

    Its own HTTP client with interceptors. In the demo a miragejs mock server that follows the contract stands in for the API.

    • auth
    • configurator
    • orders
  • MAPSMaps

    OpenStreetMap: Leaflet for the map and live tracking, Photon and Nominatim for address search, OSRM for the route.

All text goes through vue-i18n and the locale comes from the device, so a new language is one more file. The mock server follows the API contract, and neither the frontend nor the demo waits for the backend.

Silent signals

A client assigns actions to a double and a triple tap on the back of an iPhone and to four buttons of a lock screen widget. Each signal sets who receives it, what to do and how fast to react: the bodyguard comes over, the driver brings the car, the dispatcher is only informed.

The app catches a signal through a URL scheme, including on a cold start. It is a prototype for now and is hidden in the demo build.

Data security

Signing in to the app is protected the way banking apps do it: with a PIN, Face ID or a fingerprint. The PIN is kept in a protected part of the phone that other apps cannot reach. If the session expires, the app returns to the sign-in screen by itself, so a stranger cannot keep working in someone else's account. Clients and protection agents see only their own sections.

Quality and releases

Vitest and Vue Test Utils: 177 files, about 1,700 test cases next to the code, including the session, PIN, safe area and keyboard services. Storybook with accessibility checks. Another developer writes Playwright E2E tests for the demo scenarios: sign-in, an order from the configurator to completion, SOS, the profile, the agent account.

  1. pre-push tests and lint of changed files
  2. Codemagic iOS build in the cloud
  3. TestFlight the app on an iPhone

I set up the pre-push with tests and lint and the iOS build in Codemagic. Android is built as a signed bundle from Android Studio.

We work in one-week sprints with a demo at the end of each. Tasks live in Jira, one branch per task, PRs with review.

For the client this process means predictability. Every week they see a working version at the demo and can correct the course before a mistake gets expensive. The cloud iOS build and TestFlight make it possible to show the app on a real iPhone at any moment. For development, tests next to the code and the pre-push check catch errors before review, and five developers change shared code in parallel without breaking each other's work.

Challenges

01

The iOS build in a distributed team

Problem
Everything has to work on iOS. The team is spread across different cities and works on its own devices, and an iPhone and a Mac for building and debugging are not part of a developer's work set. We needed a way to build and test iOS without being tied to a specific device.
Solution
The iOS build moved to the Codemagic cloud: a simulator variant and a signed .ipa uploaded to TestFlight. A script patches the native project on every build, otherwise an app built with Xcode 27+ closes right after launch. We tested on BrowserStack cloud devices and through TestFlight.
Result
The app reached a demo on iOS and Android. The demo build fixed bugs that show up only on an iPhone: a double tap zoomed the screen, the header slid under the status bar, the bottom of a sheet went under the home indicator.
02

Complex visuals in a WebView

Problem
Gradients, transparency, a glass header, a parallax sheet, transitions between screens: on iOS visuals like these keep breaking.
Solution
The intro was made with Lottie instead of a video: the video was heavy and lost quality. Transitions are built on the View Transitions API. While preparing the demo we gathered the visual bugs into one list and closed them one by one.
Result
Of about 20 visual bugs in the demo, all but one are closed. The interface in a WebView looks like a native app.

Metrics and results

  • 26screens for the client and the agent
  • ~1,700test cases in 177 files
  • 55reusable components
  • 2platforms from one codebase: iOS and Android

The app reached a demo build for the client. There are no business metrics yet: it has not been released.

Let's talk

Need an iOS and Android app with a complex design?

I will pick a stack that fits the team, set up the project and bring the app to a demo on both platforms.

Discuss a project in Telegram Open the live site