Permissions always returned denied even though user approved

[amandadahlin]

Describe the bug I'm having issues with the permissions. The users are prompted with the approve permissions to share read access to their StepCount, Workout, DistanceWalkingRunning and FlightsClimbed data. Even though they approve all I get status denied. All of them are set to approved when checking the Apple Health app and sharing tab.

To Reproduce

1. Initialize AppleHealthKit.initHealthKit ... when navigating to that component
2. Approve all read permissions when that is prompted
3. Checking auth status is status 1 (SharingDenied)

Expected behavior Once user approved permissions auth status should be set to 2 (SharingAuthorized) and data should be fetched from Apple Health.

Screenshots

Smartphone (please complete the following information):

• Device: iPhone 11 Pro Max
• OS: iOS16.1
• Version: 2

Additional context

• Latest react-native-health version is being used
• Same issue occurs when testing on multiple devices (e.g iPhone 13 Pro, iOS 16.1.1)

[GGGava]

Hello @amandadahlin did you manage to work around this? Is this still an issue?

[gbrvalerio]

+1 happening here

[swaroopbutala]

I see the same issue as well..

[GGGava]

Hey ppl 😄

After taking a better look at this issue, I need to clarify some things:

• In HealthKit, the term share permissions is synonymous to write permissions, so when the word share appears in the docs, it can be read as write. It's a little bit confusing 😅
• It's impossible to check the read permissions for each type. HealthKit doesn't allow it for privacy reasons. Per HealthKit docs:

  To help prevent possible leaks of sensitive health information, your app cannot determine whether or not a user has granted permission to read data. If you are not given permission, it simply appears as if there is no data of the requested type in the HealthKit store. If your app is given share permission but not read permission, you see only the data that your app has written to the store. Data from other sources remains hidden.

Our docs mentions that getAuthStatus should return all types as SharingAuthorized, although this isn't what is currently happening. Both the read and the write fields of the getAuthStatus return are being populated by the write authentication status, which is wrong.

tldr: Lib is bugged and returning the write auth status as the read auth status.

Honestly, I believe you can just ignore the read auth status, as HealthKit doesn't even allow us to get them.

[GGGava]

To contributors:

I believe we should deprecate this function in favor of one without anything related to read permissions, as it's pointless and just misleading. I can do that in the next few days, but contributions until that are welcome 😄.

[pjsandwich]

I have noticed the following behavior in addition to the above described behavior. I currently am sharing read permissions for HeartRate, RestingHearRate, SleepAnalysis, and ActivitySummary. Here is my request:

const permissions = {
        permissions: {
          read: [
            'HeartRate',
            'RestingHeartRate',
            'SleepAnalysis',
            'ActivitySummary',
          ],
          write: ['HeartRate', 'HeartRateVariability'],
        },
      }

      AppleHealthKit.getAuthStatus(permissions, (err, results) => {
        if (err) {
          console.log('error getting Healthkit auth status: ', err)
        }

        if (results) {
          console.log('results: ', results)
        }
      })

And this is the response:

results:  Object {
  "permissions": Object {
    "read": Array [
      1,
      1,
      1,
      1,
    ],
    "write": Array [],
  },
}

So it looks like in addition to receiving the confusing 1 value for reads, it looks like I'm not getting the same length response for other types (see where I have HeartRate which is authorized as read but not write, while HeartRateVariability - of which I have neither read nor write - doesn't return any value for write)

[StepsInvesting]

The read permissions return 1 regardless of the state, so we're checking the steps from the last 48 hours and marking them as denied if the step count is zero. It's working very well. As for getAuthStatus, it is useful because it returns 0 if Apple Health hasn't been initiated before, or if it was closed without approving or denying the permissions.

[ftaibi]

getAuthStatus

The read permissions return 1 regardless of the state, so we're checking the steps from the last 48 hours and marking them as denied if the step count is zero. It's working very well. As for getAuthStatus, it is useful because it returns 0 if Apple Health hasn't been initiated before, or if it was closed without approving or denying the permissions.

checking the steps is smart I might try that

[gbrvalerio]

yup we actually did a similar workaround, but checking for sleep data (as it was the data we needed)