A dog walking app is a client record, a round, and a walk that proves itself.

One phrase covers three different apps

A dog walker booking app is mostly a calendar with rules. Recurring weekly slots, a cancellation window, a cap on how many dogs go out at once, and which dogs are allowed in the same group. A dog walk tracking app is mostly a record of one event: a start, an end, a path, a photo and a short note. A pet sitting app is a third thing again, because a drop-in visit or an overnight stay has no route at all, and the proof is that somebody was in the house at the right times.

Picking one first matters more than it sounds. The booking side is shaped around a client and a repeating slot. The tracking side is shaped around a single walk that belongs to one or more dogs. Build the tracking side as a field on the booking and you will spend the next month unpicking it, because walks get split, swapped and covered by somebody else.

Past roughly six walks a day, the booking side stops being a calendar problem and becomes an ordering problem. Four pickups across a town, each with a window and a group that has to match, is the same shape as a route planning app. Worth knowing before you design the schedule screen around a plain list of times.

What the record holds before, during and after

The dog record is what separates a working app from a good looking one. Per dog: name, breed, weight, whether it pulls, whether it is reactive to other dogs or to bikes, whether it can go off lead and where, feeding after the walk, medication, the vet practice and the microchip number. Per household: the address, how you get in, where the lead and the towel live, whether there is an alarm, and who else holds a key.

Access is the field people leave in a chat thread and the one that causes the incidents. A key safe code, the lock box location, the neighbour with the spare. Put it on the household record, keep a note of who opened it, and think carefully before storing a door code next to an address in something you share loosely with cover walkers.

During the walk the app captures very little. A start time, a path, one or two photos, a note. Afterwards it is producing a record somebody may read weeks later, which behaves exactly like a proof of delivery app record: a timestamp, a photo, a note, and the identity of the person who did it. Store it as its own record rather than as a tick on the booking, and it stays answerable when the booking is edited.

The field every walker asks for and no product designer writes down: whether the dog relieved itself, and whether it looked normal. It reads as a joke until a client asks, and it is often the first thing they read.

Recording the track with the screen locked

This is where a dog walk tracking app goes wrong. The walker presses start, puts the phone in a pocket, the screen locks, and the track comes back as a straight line from the first point to the last. Nothing crashed. The app was suspended, which is what the operating system is supposed to do.

Apple is direct about it. On iOS the system suspends most apps shortly after they move to the background, and suspended apps do not run and do not receive location updates. The system queues those updates and delivers them when the app runs again. Tracking the precise path of a hike or a workout is one of the cases Apple names as a real reason to ask not to be suspended. To get it, the app needs the location background mode, and it has to start a background activity session while it is still in the foreground.

Two consequences for the design. A walk cannot begin from a locked phone, so the start button has to be pressed with the app open, and the app has to restart the service itself if the system kills it mid walk. And iOS shows the background location indicator, the blue bar or pill, for as long as this runs. Warn the walker, or they will report the app as broken. Apple is blunt about the setup too: turning on the background updates property while leaving the matching Info.plist key out is a fatal error that terminates the app.

There is a cheaper answer worth putting on the table. A lot of clients do not want a polyline. They want to know the walk happened, how long it lasted, and that the dog is home. A start time, an end time and a photo at the turnaround point answers all of that with no background permission at all.

Apple, Handling location updates in the background

What background tracking costs you in the build

If the app is a React Native and Expo project, the rules arrive through the expo-location package. Expo is explicit: on Android you must request both foreground and background permission, on iOS the background request maps to Always, and the location value has to be in the UIBackgroundModes array in Info.plist. The Android side also wants a foreground service permission, which the config plugin can add.

The line that catches people out is that background location does not work in Expo Go at all, so you need a real build before you can try it once. Adding a location package and changing permissions in app.json are both native changes, which means waiting for a build rather than a live reload.

One thing we could not confirm, stated plainly. We did not watch a Newly build record a GPS track with the screen locked. Previews run on cloud simulators, and a simulator cannot answer a question about a phone locked in a pocket on a pavement. The only honest test is a TestFlight build on an iPhone you carry for an hour, and the same goes for any tool that tells you background tracking works. Walk with it before you promise it to a client.

If the app only draws the route after the walk, or shows a live pin while it is open on screen, none of this applies and you are in much simpler territory. Showing the walk on a map is then the whole of the job.

Expo, expo-location background location requirements