The whole runsheet, offline.
Nightdock is the driver-facing companion app for a last-mile or regional freight carrier. It carries the day's manifest, sequences the stops, hands off to turn-by-turn navigation, scans parcels on pickup and drop, captures photo-and-signature proof of delivery, records exceptions and keeps hours-of-service in view. It is built for the driver in the cab and at the door — and for the dispatcher who needs every stop reconciled by the end of the shift — so it has to finish a stop in a basement dock with no bars and reconcile itself the moment signal returns. The carrier, the consignees and every number shown in these screens are fictional.
A BuildspaceLabs reference build. We designed Nightdock in-house to show how we approach native mobile — it is not a client engagement, and every name, record and figure inside these screens is fictional demo data.
Nightdock is designed twice — once in the iOS idiom and once in Material 3 — on top of a shared domain core, rather than one layout wrapped twice for both stores. The frameworks below are the stack each side is specced against.
3 surfaces from the build — 2 in the iOS idiom and 1 redesigned in Material 3 on Android. Everything inside the frames is fictional demo data.
The screen a driver opens at 05:40 and returns to forty times a day: run header with an offline sync chip, dark route map with 14 numbered stops and a pulsing active pin, segmented progress rail, hours-of-service meter, the Stop 07 hero card with Navigate and Arrive, the upcoming stop list with a time-at-risk flag, the collapsed done-today section and a sticky Scan action.
The ninety seconds at the door as one vertical capture flow: consignee card with window, arrival stamp, gate code and driver note; a three-step rail through parcel scanning, photo proof and signature; delivery-outcome control; a can't-deliver path; and an action bar that stays disabled while it names what is still missing.
The same run, the same records and the same numbers as the iOS home — the taller viewport simply fits one more stop row — rebuilt with an M3 top app bar, assist-chip row, elevated next-stop card, linear progress indicator, list items with tonal surface steps, an extended Scan FAB and a navigation bar with a pill indicator.
The case for building this twice rather than wrapping a web app. Each one is designed around an operating-system capability a browser either cannot reach or cannot be trusted to hold.
Every scan, photo, signature and exception is written to on-device SQLite first and queued in a durable outbox that survives a force-quit or a flat battery mid-run, then replays in order with conflict resolution once signal returns. A web app's storage is evictable and its critical path is the wire.
AVFoundation + Vision on iOS and CameraX + ML Kit on Android read Code 128, GS1-128, ITF-14 and QR at camera framerate with torch control — plus hardware-trigger support for rugged Zebra and Honeywell handhelds over the DataWedge intent API, which a browser cannot bind to at all.
60 m geofences arm the next stop and stamp the arrival time from an Android foreground service with a persistent run notification, and from an iOS background-location mode, while the phone sits in a cradle.
Vector tiles for the day's bounding box are pre-downloaded and stop sequencing runs on-device, with deep-link handoff to Apple Maps or Google Maps for the actual driving leg.
Photos are compressed and stamped with EXIF time and GPS fix accuracy before they ever leave the handset, signatures come off the touch digitizer with pressure, and the whole queue is encrypted at rest through Keychain and the Android Keystore.
Bluetooth LE and USB-OTG pairing to cab-mounted Zebra ZQ-class label printers and ring scanners, plus CarPlay and Android Auto scenes that show only the next stop and a Navigate action while the vehicle is moving.
The target architecture this build is specced against, chosen per constraint rather than per habit — the stack shifts with the problem.
Nightdock is a reference build, so there is nothing to buy on this page. If your team has a problem that needs this kind of depth — offline for a full shift, real sensors, work that has to happen with the screen off — tell us about it and we will tell you honestly whether we are the right people to build it.