Give App Review a deterministic way to reach every location-dependent feature

List every feature whose output depends on current location, a selected place, a service polygon, route movement, background delivery, or a regional backend. For each one, provide a production-safe way to reach a representative state. A manual city or address selector may be the right customer-facing fallback. A signed demo account connected to seeded data may be appropriate for an operational dashboard. A short public route fixture may suit an owned development mode when that mode is truly included and supported in the submitted product.

Do not assume that a reviewer will travel across a geofence, wait for a local business to open, or infer the intended sequence. If a feature requires special hardware or an environment that is hard to reproduce, Apple's review guidance says to be prepared with a demonstration or the required hardware. The demonstration must match the submitted binary and live backend; a video of a separate internal build cannot establish what the reviewer receives.

• Map every location-dependent branch to a reachable review fixture.
• Use public places and synthetic account data, never employee or customer locations.
• Keep customer-facing manual fallbacks available where they are part of the product.
• Make the submitted build and review backend the source of truth.

App Store Connect review information includes contact details, demo-account status and credentials, notes, and optional attachments. If sign-in is required, provide an account that remains valid throughout review and does not depend on one-time codes sent to an unavailable employee. State the initial screen, exact taps, fixture name, permission choice, expected result, and cleanup for each nonobvious feature. Include a responsive contact who can reproduce the same path.

Keep the notes concise enough to follow on a phone, but complete enough that the reviewer does not have to reverse-engineer a state machine. Identify temporary test data and its purpose. If there are multiple roles, list separate credentials and expected access. Explain whether location behavior follows the device coordinate, a manual selection, an account service area, or another input. Those signals often disagree, and leaving the precedence rule unstated can look like a defect.

• Provide a stable demo account and any secondary role credentials.
• Number the taps from a known initial state.
• Name the visible result and the data source that drives it.
• Include a contact who can answer during the active review window.

Request only the authorization the feature currently needs and present a clear purpose string before the system prompt. Test Allow Once, While Using, denied, changed later in Settings, precise location on, and precise location off when those states affect the product. If continuous or background access is essential, make the user benefit visible and confirm that the app still behaves responsibly when permission is reduced or revoked.

Review the privacy policy, App Store privacy details, integrated SDK behavior, and the data actually sent by the submitted build. A demo account is not a reason to collect real reviewer history or retain exact routes indefinitely. Seed fictional records and define deletion. Make any manual location alternative easy to find when it is part of the service; Apple's guidelines emphasize consent and appropriate use of location, and a reviewer should see the same honest explanation as a customer.

• Match purpose strings and prompts to a current user-visible benefit.
• Exercise denied and approximate states instead of treating permission as guaranteed.
• Keep App Store disclosures synchronized with the binary and its SDKs.
• Use synthetic demo data and a documented retention boundary.

Run the complete review script against the exact release candidate on a device that has not inherited the developer's account, permissions, or cache. Verify certificates, DNS, feature flags, seeded records, service-area versions, remote configuration, and rate limits. Keep the demo account outside automated cleanup. If a market or geofence result is cached, document the refresh boundary and make the expected transition visible rather than asking the reviewer to wait an unknown period.

After every controlled scenario, clear the fixture or manual choice and prove that the ordinary product state returns. Record a screen capture for internal support, the build identifier, backend dataset version, and the last successful preflight time. During review, monitor the demo path without collecting unnecessary reviewer location and respond through App Store Connect if clarification is requested. A successful local run is preparation; the maintained review path and accurate submission information are what make the experience reproducible.

• Test the release candidate from a fresh account and permission state.
• Protect review fixtures from expiry, rate limiting, and scheduled data deletion.
• Version backend data and make cache refresh behavior explicit.
• Verify recovery and keep a current support runbook during review.