Flutter in the field: building for low connectivity
I built an app for tracking cattle. The cattle have better network coverage than the people counting them.
1. Assume the internet is a rumor
When your users are standing in a field three hours from the nearest tower, 'just call the API' is comedy. Offline-first isn't a feature here — it's the whole personality of the app. Every action writes to local storage first and syncs later, like a diary that occasionally phones home.
The golden rule: the user should never see a spinner where they expected a checkmark. They tapped 'save.' It's saved. The cloud will find out eventually, the way distant relatives find out about a wedding.
2. Sync conflicts are just two people being right
Two field officers edit the same goat record offline. Both are confident. Both are correct in their own little timeline. Now they sync, and your app has to play marriage counselor.
Last-write-wins is easy and occasionally cruel. I keep a version field and let the newer change win, but I log the loser so nobody quietly loses an afternoon of work. Goats deserve accurate records.
3. Make it fast or make it forgiven
On a budget Android phone in 32-degree heat, every dropped frame feels personal. I keep widgets cheap, lists lazy, and animations short enough that nobody notices the phone is sweating too.
Performance is a feature you only get credit for when it's missing. Nobody tweets 'this app opened at a reasonable speed.' They absolutely tweet the opposite.
