Travel time between jobs is a second appointment, so the diary has to book it.

How much travel time should you block between jobs?

Measure the gap door to door. It starts the minute you stop working on one job and ends the minute you start working on the next, which is a longer window than anybody expects. A map gives you the drive. It cannot give you the trolley down two flights of stairs, the fifteen minutes circling for a space, the buzzer nobody answers, or the unpacking at the other end. Those are the rows that make a day run late, and they are all travel time whatever you call them.

Parking is the one nobody books. In a dense city centre it can be larger than the drive it follows, and it is the row with the widest spread, which means it should set your padding rather than your average. The second most ignored row is the handover at the door: the greeting, the where shall I put this, the how did the last one go. Cutting that is how a good job earns a bad review, so it belongs in the gap rather than in the service duration where it quietly eats the next booking.

Then set one number per zone instead of one per job. Three zones is usually enough: same area, across town, and outer. Add a modifier for the times of day you know are bad, because the same two miles at eight in the morning is not the same two miles at two in the afternoon. Round every result up to your slot grid, since a gap of 37 minutes is a gap of 45 in a diary built on quarter hours. Zones also hand you a pricing boundary you can publish, which is easier to defend than a per mile rate because a customer can check which zone they are in.

One thing worth saying plainly: this problem only exists because you move. If the customer comes to you, there is no travel block at all and the constraint is room capacity instead, which is why a class schedule app has a completely different slot engine. If you run both a mobile service and a fixed venue in one app, keep the two engines separate from the first commit. Trying to make one set of rules cover both is where these projects get stuck.

Does the app need staff location in the background?

Almost certainly not, and Apple says so on the very page that explains how to build it. Its guidance is to consider carefully whether your app really needs background location updates, because most apps need location data only while someone actively uses the app. The uses it lists are tracking a hike or a fitness workout path, giving real time navigation instructions, generating time sensitive notifications, and taking immediate action when someone enters or exits a region. A diary that wants to know whether the van has left is not one of them. Two buttons, arrived and finished, answer the same question with no permission at all.

If you do need it, here is what it actually costs to set up. You enable the Location updates option under Background Modes in the Signing and Capabilities tab of your app target, and Xcode writes the keys your app needs into Info.plist. The property that turns it on, allowsBackgroundLocationUpdates, defaults to false. Apple is blunt about the failure mode: setting it to true while omitting the UIBackgroundModes key with the location value in your Info.plist is a fatal error that terminates the app. On macOS you do not need any of this, because the system does not suspend apps when they move to the background, and apps running in visionOS do not receive background updates at all.

The permission itself comes through a service session that requires either when in use or always authorization, created while your app is in the foreground, and recreated immediately on launch if the app terminates. Core Location sets when in use authorization implicitly when you process its newer update and monitoring events. For always authorization Apple tells you to inform the user that location updates arrive in the background, which is a transparency step rather than a dialog you can skip. There is also a background activity session, which Apple describes as an object that manages a visual indicator that keeps your app in use in the background. The indicator is the point: the person carrying the phone can see that you are watching.

Three review rules sit around this, all read on 14 October 2026. Guideline 5.1.5 Location Services says to use location services only when directly relevant to the features your app provides, and to notify and obtain consent before collecting, transmitting or using location data. Guideline 2.5.4 says multitasking apps may only use background services for their intended purposes, and names location as one of them. And guideline 5.1.2(i) says your app may not require users to enable system functionalities such as location services in order to access functionality, content or compensation. That last one catches staff apps whose rota screen refuses to load until location is granted, which is a very easy thing to build by accident.

Apple, Core Location, handling location updates in the background, read 14 October 2026

Which accuracy should the app ask the phone for?

Less than it asks for by default. Core Location documents seven accuracy constants: best for navigation, best, nearest ten metres, hundred metres, kilometre, three kilometres, and reduced. The last one is what you get when an app is not authorized for full accuracy. On iOS the default value of desiredAccuracy is kCLLocationAccuracyBest, the expensive end of that list, and it is what your app uses if nobody ever sets the property. On macOS, watchOS and tvOS the default is kCLLocationAccuracyHundredMeters instead.

Apple states the tradeoff in two sentences and no numbers. To reduce your app's impact on battery life, assign a value appropriate for your usage, and its own example is specifying kCLLocationAccuracyKilometer when you need the current location only within a kilometre. It also notes that more accurate location data takes more time to become available, which is the cost people forget: a high accuracy request is slower as well as hungrier, and your app may receive less accurate data for a period while the better fix is still being worked out. There is no published figure for the power cost of one constant against another, so any specific percentage you read elsewhere was invented by whoever wrote it.

Build for the reduced case, because some of your staff will pick it. If an app is not authorized for precise location, changes to desiredAccuracy have no effect and the accuracy is always the reduced constant. A feature that asks whether the van is near the next address still works at that resolution. A feature that draws the van moving along a road does not, and it will silently look broken for anybody who granted approximate location. Decide which of those two you are building before you write the permission string.

There is a cheaper service that suits a diary better than continuous updates. Significant location change monitoring delivers a notification as soon as the device moves 500 metres or more from its previous one, and Apple says not to expect notifications more frequently than once every five minutes. It ignores the distance filter property entirely. If your app is terminated while the service is running, the system automatically relaunches it into the background when a new event arrives, and you then have to configure a location manager and start the service again to keep receiving events. For answering has the van left the last job, five minutes and 500 metres is the right resolution, and it is a fraction of the cost.

Apple, CLLocationManager desiredAccuracy, read 14 October 2026

What should happen when a job runs over?

Decide it before the day it happens, because there are only three answers and all of them cost something. Absorb the overrun by shortening the next gap, which works once and then compounds. Push the rest of the day and tell every remaining customer, which is honest and loses you the last slot. Or cut the tail by moving or reassigning the final job, which protects the day and needs a rule about who gets moved. Pick one per job type, write it in a sentence, and put it where whoever answers the phone can read it.

Then make the message leave before the customer asks for it. The trap is building the warning on the engineer's phone, because that phone is in a pocket and the app is not running. Apple documents that the system suspends the execution of most apps shortly after they move to the background, that in this suspended state apps do not run and do not receive location updates, and that it enqueues updates and delivers them when the app runs again. It also says the system can terminate apps at any time to free up memory. So the trigger belongs on your own back end: a job that has not been marked complete by its end time, checked server side, which then sends the message and reshuffles the diary. Nothing about that needs the phone to be awake.

If a late job or an outer zone carries a charge, the store rule is the opposite of what most people assume. App Store Review Guideline 3.1.3(e), Goods and Services Outside of the App, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. Read on 14 October 2026. A visit to someone's home is consumed outside the app, and so is the travel to get there. That is a prohibition rather than an exemption, and getting it backwards is how an app gets rejected. Your own card processing collects it, and in-app purchases stay where they belong, unlocking things inside the app.

One neighbouring rule catches people who sell sessions as well as visits. Guideline 3.1.3(d), Person-to-Person Services, allows purchase methods other than in-app purchase for real time person to person services between two individuals, and names tutoring, medical consultations, real estate tours and fitness training. It then says that one to few and one to many real time services must use in-app purchase. A single appointment and a group class are not the same case, so if your app sells both, read that line before you wire the second one up. And if anything has pointed you at guideline 3.1.5 for a real world service, it is wrong: 3.1.5 is Cryptocurrencies, checked on the same date.

Apple, Core Location, handling location updates in the background, read 14 October 2026