App Review · location-app readiness
Give App Review a deterministic way to reach every location-dependent feature
A location-based app can work perfectly near the development team and still be impossible to review elsewhere. The reviewer may have a different permission state, market, network, clock, account, or physical position. A strong submission provides a stable demo account, public test fixtures, exact steps, expected results, privacy explanations, and a maintained backend. The goal is not to influence the review environment; it is to make the owned app's real behavior reproducible without requiring travel.
How should a location app prepare for App Store Review?
Build a production-safe demonstration path that uses an owned backend and non-sensitive public fixtures. Supply a valid nonexpiring demo account when sign-in is required, list any app-specific settings, explain each location permission, describe the expected screens, and attach a short video only when hardware or an environment is difficult to reproduce. Test the exact submitted build from a fresh permission state, keep the review service online, and verify that normal behavior returns after each fixture.
Create a review path that does not depend on the reviewer's city
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.
Write review information as an executable script
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.
Align permissions, privacy disclosures, and feature behavior
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.
Preflight backend, cache, recovery, and support
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.
Location-app review package matrix
Prepare one verifiable artifact for each likely source of reviewer friction, and keep it synchronized with the submitted build.
| Review dependency | What to provide | Preflight proof |
|---|---|---|
| Required sign-in | Valid demo username, password, roles, and any special sign-in note | Fresh-device login succeeds without employee-only approval. |
| Location permission | Purpose, requested level, expected choice, and denied-state path | Every relevant authorization state reaches intentional UI. |
| Service area or region | Public fixture, precedence rule, seeded backend result | The submitted build resolves the documented market. |
| Geofence or movement | Short owned fixture, expected event order, and visible result | Entry, exit, duplicate handling, and cleanup match the notes. |
| Background behavior | Why it is needed, user-visible control, and reproduction steps | A real device run shows delivery and a clear way to stop it. |
| Special hardware | Hardware requirement, attachment or video, and support contact | Evidence uses the release candidate and current service. |
| Backend and cache | Fixture version, availability owner, refresh rule, recovery steps | A clean session and a return session both pass. |
| Privacy disclosure | Current policy, App Store answers, deletion and SDK inventory | Observed release behavior matches the submitted declarations. |
Prepare the submission from the reviewer's point of view
Treat review access as a supported production workflow with clear evidence, not a last-minute note written after upload.
Inventory hidden dependencies
List login, permissions, coordinates, service areas, clocks, feature flags, hardware, backend data, cache, and role requirements.
Build public demo fixtures
Seed non-sensitive accounts and locations that demonstrate real product branches without needing the reviewer to travel.
Write exact review steps
Provide credentials, numbered actions, permission choices, expected screens, signal precedence, cleanup, and a responsive contact.
Reconcile privacy and metadata
Verify purpose strings, privacy policy, App Store privacy answers, screenshots, description, and SDK collection against the release build.
Run a clean-device preflight
Use the submitted candidate with fresh permissions and cache, record the dataset version, and verify each role plus recovery.
Maintain the path through review
Keep accounts and services available, monitor nonpersonal health signals, and reply promptly with accurate clarification if Apple asks.
Frequently asked questions
Does App Review require a demo account for every location app?
A demo account is needed when sign-in is required to use the app or reach reviewed functionality. If the app has no sign-in dependency, provide the other settings and steps needed to reproduce location behavior.
Can review notes ask Apple to use a specific location?
Notes can describe app-specific settings, fixtures, and exact reproduction steps, fixtures, and exact reproduction steps for your own product. Prefer a built-in supported demo or public fixture and explain its limits; do not depend on altering an unrelated service or undisclosed behavior.
Should I attach a video of a geofence feature?
A concise video helps when required hardware is difficult to reproduce hardware or an environment is difficult to reproduce, but it should show the submitted build and current behavior. It complements, rather than replaces, a functional binary and accurate notes.
What if the reviewer denies location permission?
The app should provide intentional denied-state behavior, a clear explanation, and a route to Settings or a manual alternative when appropriate. Test and describe that path instead of assuming permission will be granted.
How do I prevent a review demo account from expiring?
Exclude it from routine cleanup, avoid unavailable one-time-code dependencies, monitor only the account's service health, document an owner, and retest it immediately before and during the submission window.
Sources
- Apple primary sourceApp ReviewApple's preparation guidance for settings, demo accounts, special environments, hardware, and review information.
- Apple policy sourceApp Review GuidelinesThe current technical, privacy, safety, and completeness requirements governing a submission.
- App Store Connect referencePlatform version informationThe review notes, contact, and nonexpiring demo-account fields associated with an app version.
- Apple API referenceApp Store review detailsThe contact, demo-account, notes, and attachment structure supplied for App Review.