Skip to main content
Version: 2.1.4



Alerts will be searched in locally cached data received per the SkyPath.dataQuery configuration. No server request will be made here.

By default, SDK will use a predefined configuration for searching turbulence alerts, see AlertQuery for more details. So it will be a good start to use the default values of AlertQuery().

There are 2 ways to get turbulence alerts:


Manually when needed. For example, on every location update, or by time intervals or distance passed. This will have all currently found turbulence alerts despite whether they were found in the previous query.

let query = AlertQuery(altRange: altRange, route: route?.coordinates)
let result = SkyPath.shared.alerts(with: query)

It blocks the current thread, so using a separate background thread is recommended.


Automatic monitoring. SDK will check for turbulence on every new location update. When found, an alert will be reported via SkyPathDelegate.didReceiveAlert(alert:). This will not report the same turbulence alert multiple times in a row, but it could report the same alert that was reported previously if there were other alerts in between. So it will report only once in cases A1 A1 A1 A1 but will report 3 times in cases A1, A2, and A1.

let query = AlertQuery(altRange: altRange, route: route?.coordinates)
SkyPath.shared.startMonitoringAlerts(with: query)

When the AlertQuery changes you can call only startMonitoringAlerts(with:) with a new query without stopping it first.

Based on the AlertQuery properties, SDK filters server reports. All AlertQuery properties have default values. Configure it per your needs.

There are two modes: route and beam.

  • Route mode is used when route line coordinates or a polygon are set in the query. It can use polygon or route line coordinates and width around to make a corridor.

  • Beam mode is used when no route is provided. It is configured by angle span, and distance from the current location.

When got a turbulence alert you can show it in the app with the local iOS notification if the app is in the background.

It is safe to call startMonitoringAlerts and stopMonitoringAlerts multiple times. However, it works as enable disable, so no need to call it again after starting monitoring until stopped monitoring and needs to start again. You can also check SkyPath.shared.isMonitoringAlerts if need to call startMonitoringAlerts or stopMonitoringAlerts.


To test the notification you need to simulate a flight towards some turbulence area that meets AlertQuery criteria (see the SDK API docs for more details), so the turbulence reports will be in the query corridor altitude, proper severity, etc. The following will describe the simple steps for testing using the default AlertQuery parameters.

  1. Find on the map some turbulence hexagons with a Moderate severity level at an altitude of, for example, ~38,000 ft.

  2. Simulate a flight to fly at ~38,000 ft (same hexagon turbulence report altitude, so report will be within searching altitude corridor) towards that Moderate turbulence hexagon on a distance of more than 100 NM, for example, 150-200 NM.

  3. By default, turbulence alerts are searched in a beam mode within 100 NM ahead, so when you fly at a distance closer than 100 NM the hexagon turbulence will be in range. Make sure that based on the current speed, it will require at least a few minutes to cover this distance.

  4. The turbulence notification should arrive.

These quick steps are valid if the default query parameters are used. Please take into account any customizations you made in AlertQuery for testing. For example, if the severity to alert is set to Moderate-Severity and above, you'll need to find a corresponding Moderate-Severity hexagon and so on.