Add a location feature to an AI mobile app: purpose, precision and permission

A worked example: where the task becomes difficult

A fictional delivery app lets a driver confirm arrival at a depot. The product needs a one-time check-in, not a full movement history. The generated code starts background tracking and logs every coordinate. Replace that broad behavior with the approved task and use controlled locations for tests. Keep the timestamp and accuracy context so an approximate reading is not mistaken for exact proof.

Decisions to make before implementation

Choose foreground or background access only from an actual requirement. Define how accuracy, unavailable readings and manual alternatives affect the check-in. Device settings and platform permissions can vary. Decide who can view stored coordinates and when they expire. A location reading should not be used for unrelated monitoring simply because it is technically available.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Write the check-in purpose, required precision and retention boundary.
• Inspect the runtime’s current permission and location contract.
• Implement a point-of-use request with denial and unavailable states.
• Verify a controlled reading and the approved server record without continuous logging.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement one-time depot check-in under this approved location policy. Use the project’s current location API and request access at check-in. Preserve accuracy and timestamp context, handle denial and avoid background tracking. Restrict stored coordinates and verify a controlled server record. Do not add unrelated monitoring.

Failure modes that an attractive preview can hide

An inaccurate coordinate can produce a false rejection if a strict boundary ignores reported accuracy. Do not assume GPS availability indoors. Repeated permission prompts can degrade trust without changing the user’s decision. Avoid exposing precise positions in public analytics or unrestricted diagnostic logs.

Technical references: Expo: location

Acceptance checks and the evidence to retain

Keep the permission scope, accuracy rule, stored-data boundary and checked device behavior. Record untested platform states instead of promising universal location reliability.

Specific answers

Common questions