MapKit and directions App Review checklist
Map features mix location, business data, directions, and user trust. Review readiness depends on whether the map tells the truth and handles location denial gracefully.
Use MapKit features that match the app's real map task: display places, annotate data, calculate routes, show user location, or guide movement. Apple MapKit documentation provides maps and location-related presentation tools. AppReviewReady interpretation: create a map data and route-state ledger before submission.
Define the map task
Map features can support discovery, routing, asset tracking, check-in, delivery, field work, property search, or event navigation. Each task has different accuracy, privacy, and fallback requirements.
If the map is decorative, do not request location. If the map guides real movement, test accuracy, route changes, and failure states more carefully.
Audit annotations, overlays, and business data
- Place names, addresses, hours, and categories should be current or clearly sourced.
- User-generated pins need moderation and reporting if public.
- Routes should not imply official emergency, safety, or professional guidance unless supported.
- Map attribution and third-party data terms should be respected.
- Private locations should not appear in screenshots, widgets, or notifications without consent.
Handle location permission and denial
A user can deny precise location, grant approximate location, or turn location off entirely. The map should still show a useful search, manual entry, or default region when possible.
AppReviewReady interpretation: a route feature that collapses without location is not necessarily wrong, but it needs a clear explanation and a path to continue.
Test route and map edge states
- Open the map with location allowed, denied, approximate, and unavailable.
- Search for a valid place, invalid place, closed place, and out-of-region place.
- Calculate a route, change destination, go offline, and recover.
- Test dark mode, low bandwidth, stale cache, and missing map tiles.
- Verify support and privacy pages explain location and map data use.
Prepare MapKit review evidence
Provide sample locations that work from the review environment. Do not require the reviewer to be physically near a business, venue, or asset to see the core behavior.
After launch, monitor no-result searches and route failures by region. Map problems often appear as content quality issues rather than crashes.
If the app lets businesses or users edit map data, keep an audit trail and moderation route. Bad place data can create safety, fraud, or reputation problems.
For route guidance, avoid language that suggests professional navigation accuracy unless rerouting, road closures, and hazards are handled appropriately.
For venue, campus, or event maps, test temporary closures and renamed locations. Review risk increases when the app presents stale operational data as if it were live guidance.
If maps are tied to user accounts, verify saved places, recent searches, and shared pins are removed or anonymized according to the account-deletion promise. Location history can become sensitive even when each individual map view looks harmless.
MapKit review path: Map task: [search, route] Location required: [yes/no] How to trigger: [steps] Sample origin/destination: [places] Denied-location behavior: [manual entry] Data source: [first-party, MapKit] Offline behavior: [message]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check map readiness
Review location use, map data, route states, and privacy before submission.
Open the tool