WeatherKit App Review checklist
Weather features combine data source trust, location, forecast limits, and user decisions. Review readiness depends on explaining where the forecast comes from and what happens when it is unavailable.
Use WeatherKit for a clear forecast or weather-data feature, minimize location access, cache responsibly, and show fallback states. Apple WeatherKit provides weather data through native frameworks and REST. AppReviewReady interpretation: create a forecast-source and location proof record before submission.
Name the weather decision the app supports
Weather can support planning, safety, sports, travel, logistics, agriculture, events, wardrobe, or smart-home decisions. The app should explain whether forecasts are informational, advisory, or tied to a workflow.
Avoid overstating forecast certainty. A weather feature should not imply emergency reliability, medical safety, or route safety beyond what the product actually provides.
Minimize location use
- Manual city or saved place should work when precise location is denied.
- Approximate location may be enough for many forecasts.
- Background location should not be requested merely to refresh weather cards.
- Location and weather queries should match privacy-label answers.
- Widgets, notifications, and Live Activities should not reveal sensitive places unexpectedly.
Show data source and freshness honestly
Users should understand whether a forecast is current, cached, stale, unavailable, or based on a saved location. If the app combines WeatherKit with other sources, label that integration clearly.
AppReviewReady interpretation: weather data can affect safety decisions. Show timestamps, confidence limits, or unavailable states where a stale forecast could mislead the user.
Test weather and location failure states
- Open with location allowed, denied, approximate, and unavailable.
- Search for valid, invalid, and unsupported locations.
- Simulate no network, stale cache, API error, and quota or auth failure.
- Verify widgets and notifications use the same location and timestamp semantics.
- Check privacy policy and labels for location, weather queries, and analytics.
Prepare WeatherKit review evidence
Use a sample location that works for review. Do not require the reviewer to be in a specific region to understand the feature.
After launch, monitor stale forecast age and API error rate by market. Weather features can appear broken when only one provider region or one cached city was tested.
If weather drives recommendations, explain whether the app is giving convenience advice or safety-critical instructions. Forecast data should not be overframed as a guarantee.
For severe-weather messaging, verify the source, region, and freshness before showing high-urgency alerts or lock-screen surfaces.
If the app stores favorite places, test deletion and account sign-out with widgets still installed. A widget should not keep showing a sensitive saved location after the user removes it from the app.
For travel or logistics apps, test crossing time zones and changing saved units. A forecast displayed for the wrong local day, unit system, or saved city can undermine the reviewer's confidence in the whole feature.
WeatherKit review path: Weather feature: [forecast, alert] Location mode: [manual, approximate, precise] How to trigger: [steps] Data source shown: [where] Stale/unavailable behavior: [message] Privacy fields: [location/query] Sample location: [city]
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 WeatherKit readiness
Review location use, forecast source, cache behavior, and privacy before submission.
Open the tool