Validation had issues: bundle should contain a NSHealthUpdateUsageDescription key

[rozhkovs]

I ran into the following problem: when I made an archive of the application and wanted to validate it, I get the following error:

2025-03-11 03:45:04 +0000 [MT] Validation for archive Wise had issues:
(
    "<IDEDistributionIssue: severity(error), error(Error Domain=ContentDelivery Code=409 \"Validation failed\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=Validation failed, NSLocalizedRecoverySuggestion=Missing purpose string in Info.plist. Your app\U2019s code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the \U201cWise.app\U201d bundle should contain a NSHealthUpdateUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. If you\U2019re using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. For details, visit: https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources. (ID: @@@ )})>"
)

I expected that there would be no problem with this, because I specified "NSHealthUpdateUsageDescription": false,

I am using Expo 52 with the following configuration:

[
  "@kingstinct/react-native-healthkit",
  {
    "NSHealthShareUsageDescription": "Health data is essential to keep track of your health",
    "NSHealthUpdateUsageDescription": false,
    "background": false
  }
],

npx react-native info

System:
  OS: macOS 15.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 191.95 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 21.1.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 4.5.2
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.9.2
    path: /opt/homebrew/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.14.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.1
      - iOS 18.1
      - macOS 15.1
      - tvOS 18.1
      - visionOS 2.1
      - watchOS 11.1
  Android SDK:
    Android NDK: 22.1.7171670
IDEs:
  Android Studio: 2024.2 AI-242.23339.11.2421.12550806
  Xcode:
    version: 16.1/16B40
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: javac 17
    path: /usr/bin/javac
  Ruby:
    version: 2.7.5
    path: /Users/sergey/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 17.0.0
    wanted: ^17.0.0
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.77.1
    wanted: 0.77.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

[robertherber]

Maybe try specifying NSHealthUpdateUsageDescription, or is there a particular reason you don't want to?

There's probably something in your code (or potentially in the library) that causes this validation error to trigger. I don't think I've tried actually validating and submitting an app without the NSHealthUpdateUsageDescription, just verified it builds ok.

[rozhkovs]

@robertherber Thank you for your interest!

I don't want to specify NSHealthUpdateUsageDescription because the app doesn't update any data. Either I need to find some reason to put something there (but that would be a lie.))

Yes, if I specify NSHealthUpdateUsageDescription, everything is fine, but that's not quite what I expect when I set "NSHealthUpdateUsageDescription": false.

I haven't encountered a review from Apple regarding these permissions yet, so I don't know how the practices really are; maybe it's not a big deal.

[robertherber]

I haven't experienced any issues with AppStore review just for adding descriptions, I'm 80% certain you'll be just fine :)

[robertherber]

@rozhkovs Did you figure this one out?

I haven't tried without specifying this string. But the Apple APIs actually requires us to request both (we're actually sending an empty Set with write permissions even when only requesting read permissions).

[robertherber]

Since the underlying APIs called requires us to specify write permissions (even as an empty array) I'm not sure omitting this value makes sense. Will update the types in the Config Plugin to reflect this.