Apple Watch Ultra: Does an underwater compass app require the full Submerged Depth and Pressure entitlement to operate below 6 meters?

Hi there,

I'm planning to develop a simple underwater compass app for Apple Watch Ultra 2, intended for recreational scuba diving down to 40 meters.

The app itself does not need depth or pressure measurements beyond 6 meters. Its primary function is compass navigation using heading data.

During a dive, however, I would like the app to:

  • remain frontmost and visible throughout the dive;
  • use Water Lock;
  • use an underwater-depth WKExtendedRuntimeSession;
  • continue receiving compass heading updates;
  • allow interaction through physical controls such as the Digital Crown and Action Button;
  • remain operational below 6 meters, potentially down to 40 meters.

I understand that the Shallow Depth and Pressure capability limits CMWaterSubmersionManager depth/pressure data to approximately 6 meters, while access to depth/pressure data down to 40 meters requires the full Submerged Depth and Pressure entitlement.

My question is:

If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters?

In other words, does the 6-meter entitlement limit apply only to depth/pressure data, or does it also limit the ability of an underwater compass app to remain operational during a scuba dive below 6 meters?

Target hardware: Apple Watch Ultra 2.

Thanks in advance!

Answered by DTS Engineer in 907752022

First off, as a disclaimer, this is the kind of behavior you really to do your own testing to understand and verify. I've answered below based on my own understanding and analysis of CoreLocation and watchOS, however, the system is big and complicated enough that it's entirely possible I've overlooked something.

In any case:

If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters?

Yes and no. In terms of "direct" impact, there doesn't seem to be any difference between the two entitlements and I'd expect the system to basically work "the same" with either entitlement.

HOWEVER, what "Submerged" does change is that it shifts the devices definition of "Max Depth" from 6m to 40m. The issue here is that the device is going to start warning you when you cross that threshold and I'm not sure[1] how disruptive that will be to the user.

[1] Diving and owning an Apple Watch Ultra are both pleasures I've been unable to indulge.

__
Kevin Elliott
DTS Engineering, CoreOS/Hardware

Accepted Answer

First off, as a disclaimer, this is the kind of behavior you really to do your own testing to understand and verify. I've answered below based on my own understanding and analysis of CoreLocation and watchOS, however, the system is big and complicated enough that it's entirely possible I've overlooked something.

In any case:

If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters?

Yes and no. In terms of "direct" impact, there doesn't seem to be any difference between the two entitlements and I'd expect the system to basically work "the same" with either entitlement.

HOWEVER, what "Submerged" does change is that it shifts the devices definition of "Max Depth" from 6m to 40m. The issue here is that the device is going to start warning you when you cross that threshold and I'm not sure[1] how disruptive that will be to the user.

[1] Diving and owning an Apple Watch Ultra are both pleasures I've been unable to indulge.

__
Kevin Elliott
DTS Engineering, CoreOS/Hardware

Thank you, Kevin. This is very helpful and clarifies the distinction I was trying to understand.

For this particular app, I don't need depth, pressure, or temperature data at all. The goal is simply to build an underwater compass that remains frontmost and operational during a recreational scuba dive, using heading data and physical controls while Water Lock is active.

I'll proceed with the Shallow Depth and Pressure entitlement and test the behavior on an Apple Watch Ultra 2 during an actual dive below 6 meters.

I'm particularly interested in seeing what happens when the watch transitions to pastMaxDepth: whether the extended runtime session and compass continue operating normally, and how intrusive the maximum-depth warnings are.

I'll report my findings here after testing it underwater, since this may also be useful to other developers considering similar apps.

Thanks again for the clarification!

For this particular app, I don't need depth, pressure, or temperature data at all. The goal is simply to build an underwater compass that remains frontmost and operational during a recreational scuba dive, using heading data and physical controls while Water Lock is active.

One thing you need to be aware of here is that which entitlement and/or background category(s) you're allowed to use is determined by the functionality you provide to the user, NOT your app’s technical needs. So, an app that doesn't provide ANY depth-related information, then you may not[1] be allowed to use either of our depth entitlements. You may want to consider integrating depth data into your design, both because it would be useful to the user and to minimize any issue with App Review.

[1] App Review is ultimately responsible for making these determinations, so if you want more formal guidance on this, you'll need to contact them directly.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you, Kevin. That distinction is helpful.

The current prototype provides compass navigation only, but our planned next step is to add current and maximum depth as a simple depth-gauge feature, before considering more advanced dive functionality.

We understand that adding depth information does not automatically establish eligibility for either entitlement, and that App Review makes the final determination. We will contact them for formal guidance on the appropriate entitlement and background category for that functionality, including use below 6 meters.

Is there a recommended channel for requesting this guidance from App Review before submission?

Is there a recommended channel for requesting this guidance from App Review before submission?

Sorry about that, I forgot to include the link. Their contact info is here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware