The Risky Parts of a Flutter Driver App

Where field apps fail

A driver app spends most of its life in the background, on a phone the operating system is trying to save battery on. The screens rarely cause incidents. The platform integrations do.

Background location

• Track only while a delivery is active, and stop the moment it ends.
• Foreground services and permissions differ between Android and iOS, and store review checks them. Write the permission text for the user, not for the policy.
• Change this code carefully and test it on real devices with the screen off.

Push notifications

• Handle three states separately: foreground, background, and terminated.
• Android caches notification channel settings. After changing sounds or importance, test on a clean install, otherwise you are testing the old channel.

Biometric app lock

Lock the app without locking the driver out of an active delivery. Decide what happens when biometrics are unavailable, changed, or cancelled, and test each case.

The backend contract

Mobile releases cannot be rolled back instantly, so the API has to stay backward compatible for as long as old app versions are in use. Keep endpoint definitions in one place, and coordinate status-transition changes with the backend before shipping.

How we work

Our Rveta driver app is a Flutter app backed by a Laravel API. It ships with maintenance runbooks, an upgrade risk report, and a manual device smoke-test checklist, because the risky parts are exactly the ones automated tests do not cover.