Mobile Apps
One app for your team or your customers — on iPhone and Android, and in places with no signal.
Where it usually goes wrong
The people entering the data are not at a desk. They are in the warehouse, on the site, in the gym — where the signal is poor or gone. An application that waits for a server response there stops being used within two weeks.
What you get out of it
- One app for both systems, not two invoices
- Works in the basement, the warehouse and on the train
How we do it
One build instead of three
iOS, Android and a web version from the same code. Not the right call for every app, but for most where graphics performance is not the point.
Offline is the normal case, not the exception
In the gym, the basement, the warehouse, on a train. Waiting for a server response there means losing. Our apps write locally first and sync later. The sync layer is the real work, not the interface.
Use what the platform offers
In Time at Work the running timer shows as a live activity on the iPhone lock screen. A location trigger starts tracking on arrival. Details like that decide whether an app gets used or deleted.
Multiplayer means connections drop
In Exen someone loses signal regularly, sometimes the host. The round continues anyway. Those cases cost more testing than everything else combined.
What we work with
- React Native
- Expo
- TypeScript
- SQLite
- Tamagui
- Socket.IO
Demonstrated by
The first step
Tell us where your people are standing when they are meant to use the app. More depends on that than on the interface.