A locksmith app is a dispatch board bolted to a legal record.

What the work order has to hold before the door opens

California writes the requirement out field by field. A locksmith who knowingly and willfully opens a residence or commercial establishment for someone else, by any method involving an on site inspection of a door or entrance, records five things about the person requesting entry: name, address, telephone number, date of birth, and driver's licence or identification number. The street address and that person's signature go on the same work order form. It applies whether or not you are being paid, so the favour for a neighbour is a record too.

Two details decide how you store it. The copy is retained for two years and is open to inspection by the bureau or by any peace officer during business hours. And it carries the name and licence number of the locksmith who performed the service, not just the company. So the record belongs to a person and a date, and it has to outlive that person leaving the firm. A mobile locksmith job app that files jobs under a customer name and nothing else answers neither question.

That is why a photo of a paper form in a group chat fails. It is not searchable by date, not attached to a technician, and nobody can produce the one from March when it is asked for in September. A form on the phone, with the identification photographed at the door and the signature taken on glass, puts the same fields somewhere you can query. That does not make you compliant. It makes the record findable, which is the part that usually breaks.

The advertising rule runs the same way: every advertisement by a licensee carries the business name, the business address or telephone number, and the licence number as it appears in the bureau's records, and a business card counts as an advertisement.

California Business and Professions Code, Chapter 8.5, Article 7, conduct of a locksmith business

Getting the job to the van, and knowing it was taken

A locksmith dispatch app has one job that sounds trivial and is not. Move a new callout from whoever answered the phone to whoever can be there first, and know inside a minute whether it was taken. The obvious mechanism is a push notification, and a push notification is the wrong thing to trust on its own. The shape is the same as a tow truck app: someone stranded, a queue of calls, and an arrival time that decides whether they wait or ring the next number.

Apple describes its push service as best effort. It may reorder notifications sent to the same device token. If it cannot deliver one immediately it may store it for thirty days or less, depending on the expiry you set, and try again when the device is next online. It stores only one notification per bundle identifier, so when two jobs go out while a phone sits in a basement, the phone can wake to one of them. Notifications can also be throttled and in some cases not delivered. Do not assume the Android side behaves identically.

So the notification is a tap on the shoulder, not the dispatch. The job lives on your server with a state: offered, accepted, on the way, on site, finished. The phone asks for the current list every time it opens, so a missed notification costs nothing. Acceptance is a row you write when the technician taps accept, holding the technician, the job and the time. That row stops two vans driving to the same address, and it answers the question nobody wants asked later, which is why nobody went.

On whether a Newly build can do this, here is what we actually saw. The documentation says push notifications connect from a card in the chat, that a test send is available from the Deploy panel, and that reaching a real handset means installing a TestFlight build and allowing notifications on it. We read that in the documentation rather than watching a job land on a technician's phone, so treat the exact behaviour as unconfirmed until you have sent one yourself. Recording acceptance is not a platform feature anywhere. It is a row your own app writes.

Apple, sending notification requests to APNs

The price on the phone and the price on the doorstep

Locksmith pricing has a bad public reputation and most of it comes from one gap: a number given on the phone and a different number once the door is open. California states the duty plainly. A licensee must not fail in any material respect to complete the installation, repair, opening or modification of a lock for the price stated in the contract for services.

So the quote is not a scribbled note, it is the thing you are held to. In software terms the callout fee, the labour rate and the parts sit on the job record before anyone drives, timestamped, with the customer's agreement attached. Anything added after arrival is a separate line with a reason and a time, not an edit to the original number. An app that lets the final total be typed freehand at the end has deleted the only evidence that the customer agreed to it.

The document is close to an estimate app for contractors: a priced offer, a record of what changed, and an invoice that traces back to both. What differs is the clock. Nobody reads a written estimate by email while standing in the rain at midnight, so acceptance has to be capturable in about ten seconds, by a text message with the price in it or a tap on the technician's screen at the door.

Two smaller things save arguments. Record why a price moved, in the customer's words rather than a code. And keep the callout fee separate from the work, so a job cancelled when the keys turn up still has a defensible line on the invoice.

What a callout at three in the morning needs

Most disappointment with an emergency callout app comes from designing for the nine to five job and hoping the night works itself out. It does not. At three in the morning there is no dispatcher, the customer is standing outside their own house, and the only person making decisions is the technician who picked up.

Three things earn their place. A rota the app reads, so the job goes to whoever is on call instead of waking everyone. An arrival time the customer can see without ringing back, because silence is the main reason a caller books a second locksmith while waiting for the first. And a check in, because sending one person alone to a stranger's address at night is a safety question before it is a software question. A tap for on site and another for clear, each with a time on it, costs nothing to build.

Be careful what you promise about location. Live technician tracking is the feature customers ask for and the one that eats the battery, needs permissions the customer has to grant, and behaves differently once the phone is in a pocket with the screen off. Read what a phone really gives you for getting to the callout before you build a promise on top of it.

The plain version works well. A text when the job is accepted with a name and a number, a text when the technician sets off with an honest arrival time, and a text on arrival. Three messages, no map, and most of the reassurance the map was supposed to deliver.