Abdelrahman Hamdy Youssef
All work

Employment, Roboost

Roboost rider app

Listed on Google Play as “Roboost” (com.app.tayar)

The app delivery riders work from for a whole shift: offers, pickup, delivery, payment at the door.

My role
Sole mobile developer since mid-2023; about 1,300 of 1,302 commits in the current repository
When
2022 – present
Platforms
Android, iOS, Huawei AppGallery
Status
In production

Overview

Roboost sells delivery automation to restaurant and pharmacy chains. The rider app is the part a rider holds in their hand: it receives trip offers, walks them through each order step by step, takes payment at the door and keeps reporting their location for the whole shift.

In the recording

One whole trip: a trip offer with its countdown, slide to accept, arrive at the store, pick up, head to the customer, arrive, take cash, deliver and end the trip.

Recorded from the real appRecorded from the real Flutter app in the iOS Simulator. The app ran from a throwaway copy pointed at a local mock server with made-up data, with crash reporting and analytics switched off; nothing reached the production backend. The app’s fake-GPS check was turned off in that copy, because a simulator’s location is always simulated. Recorded with iOS set to its smallest text size.

The app’s source is private to Roboost. The stores, customers and orders in the recording are made up.

Screens

7 stills from the recording above. Select one to see it larger.

  1. 01Home on shift: queue position, custody and the last trip
  2. 02A trip offer fills the screen with its 30-second countdown; slide to accept
  3. 03The running trip: the store sits on the order card
  4. 04Arrived at the store; slide once the order is picked up
  5. 05The order: pickup, drop-off and the customer’s address details
  6. 06Arrived at the customer, with the late-delivery timer
  7. 07Delivered; slide to end the trip

Crash rate

Rider app crashes per installed device, per dayMonthly average, Dec 2022 to Oct 2026. Logarithmic scale. Source: Google Play Console export.
0.01%0.1%1%10%2023202420252026Feb 2023: 6.0%Oct 2026: 0.016%

Context

I joined Roboost in December 2022 straight out of ITI as one of two Flutter developers. Six months later I was the only one, and I have carried the rider app since: features, upgrades, store releases on three stores, and the crashes in between.

The app has to work on whatever phone a rider owns, on mobile data, outdoors, for eight hours at a time. Those constraints decide most of the engineering.

What the rider does in the app

A trip is a list of orders. Each order moves through fixed steps, and the rider advances it with a swipe rather than a tap, so a pocket touch can’t mark an order delivered.

  • Trip offers with a countdown, accepted or let go
  • Order steps: heading to store → arrived → picked up → heading to customer → arrived → delivered
  • Pickup checklist, proof-of-pickup photo and QR code pickup
  • Proof of delivery with photo and signature; odometer capture
  • Payment at the door: cash, Flash, Paymob and Fawry links, and Nearpay tap to pay over NFC
  • Custody, wallet, income, shift history and broadcast messages

Technical implementation

Each feature is split into data, domain and presentation. Repositories return a typed Result, so a failed request is a value the UI renders, not an exception it forgets to catch. Notifiers expose sealed states; the order step is an enum carrying its own colour and swipe label, so the button and the status pill can never disagree.

Live tracking runs in an Android foreground service so GPS survives the app being backgrounded. It sends the rider’s position every 25 seconds and flags rooted or jailbroken devices with each update.

Nearpay’s official Flutter SDK stopped compiling on current Flutter. I forked it, updated its dependencies, and the app now pulls the SDK from my fork.

Rider app feature layers: presentation calls domain, domain calls data; a native foreground service reports location alongside.PresentationRiverpod notifiers expose sealed statesOrder step enum carries its colour and swipe labelDomainEntities, repository contracts, typed Result<T>DataDio client and interceptors, Hive CE cacheNearpay SDK (fork), Paymob, Fawry, FlashAndroid serviceForeground serviceSends GPS every 25 sFlags rooted devicesSurvives backgroundingPlatformiOS notification serviceextension for image pushNFC tap to payShorebird code push
Fig. 1. Each feature is split into three layers. Failures travel up as values, so every screen has to decide what an error looks like.

Keeping it stable while changing everything

The app came to me on Flutter 2.10 with Provider. I moved it to Flutter 3.7 in early 2023, then Dart 3 and Riverpod later that year, and since then through 3.16, 3.19, 3.24, 3.27 and 3.32, including the Android Gradle plugin migration.

Between September 2025 and January 2026 I restructured it one feature at a time: from mixins that called the API directly, to MVVM, to clean architecture, then navigation to go_router. Releases kept shipping throughout.

Problems worth telling

Crash rate

Measured as daily crashes divided by installed devices: when I joined in December 2022 the app was at 3.5%, and it peaked at 6% in February 2023 as its install base doubled. Most of it was memory leaks and plugins set up or torn down in the wrong place. It is around 0.02% now, on four times as many devices. The chart keeps the regressions in: the rate climbed back to about 2.4% between late 2024 and spring 2025, and briefly to 0.5% in spring 2026, before coming down again each time.

Payment SDK that no longer built

Nearpay’s Flutter SDK depended on packages that no longer compiled. Rather than drop tap-to-pay, I forked the SDK, updated it and kept maintaining it.

Stack

  • Flutter
  • Riverpod 3
  • go_router
  • Dio
  • Hive CE
  • flutter_map
  • Firebase
  • Kotlin
  • Swift
  • Shorebird