Apple requiring Location purpose strings in RN apps < 0.60

[fiznool]

Resolution: Geolocation is no longer bundled with React Native as of RN 0.60

Starting with 0.60, Geolocation will not be part of React Native and should not cause any further issue. If you use Geolocation, the extracted module can be found at https://github.com/react-native-community/react-native-geolocation.

Summary

Starting spring 2019, all apps submitted to the App Store that access user data will be required to include a purpose string. We are aware of an issue where bundles that include React Native are automatically rejected if the Info.plist does not include a purpose string describing how the app makes use of location services, even in cases where the app does not make use of the Geolocation API.

As suggested by Apple and shared in this thread by @hilkeheremans, to work around this, please add the following keys to your Info.plist:

• NSLocationAlwaysAndWhenInUseUsageDescription
• NSLocationAlwaysUsageDescription
• NSLocationWhenInUseUsageDescription

This workaround and a long term fix is discussed in @hramos's comment.

A sample of the rejection email sent by Apple is included here:

"Missing Purpose String in Info.plist File. Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting spring 2019, all apps submitted to the App Store that access user data will be required to include a purpose string.If you're 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. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy)."

If you are running into this issue, please read the above thoroughly before commenting. Keeping the thread focused on a long term fix would be ideal.

---

Original Issue

Environment

Run react-native info in your terminal and paste its contents here.

React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Memory: 93.31 MB / 16.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 10.9.0 - /usr/local/bin/node
Yarn: 1.9.4 - /usr/local/bin/yarn
npm: 6.2.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
Android SDK:
Build Tools: 23.0.1, 25.0.2, 26.0.3, 27.0.3, 28.0.0, 28.0.1
API Levels: 23, 25, 26, 27, 28
IDEs:
Android Studio: 3.1 AI-173.4819257
Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
npmPackages:
react: 16.4.2 => 16.4.2
react-native: 0.56.0 => 0.56.0
npmGlobalPackages:
calvium-react-native-cli: 0.9.1
create-react-native-app: 1.0.0
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7

Description

Building a RN app and submitting to the Apple App Store results in an automated email, asking to add the following keys to the Info.plist file:

• NSLocationAlwaysUsageDescription
• NSLocationWhenInUseUsageDescription

This happens even if you don't use Geolocation at all in your app.

The source of the issue appears to be the use of requestAlwaysAuthorization and requestWhenInUseAuthorization here. It seems that the presence of these API calls in the bundled app code is enough to trigger the request for the necessary keys to be added to the Info.plist file.

Related issue on the Expo forums: https://forums.expo.io/t/rejected-from-app-store-missing-location-string/13029/3

Reproducible Demo

react-native init SampleApp

Build the app for release, upload to the App Store.

[pedpess]

I have been dealing with the same issue recently. It might be that RN bundle is adding Geolocation even if we don't need it.

I'm using normal react-native init though. However, It seems that Expo team had the same issue and they had to ship a fix for that: https://forums.expo.io/t/rejected-from-app-store-reason-is-missing-info-plist-key-but-never-uses-location-or-permissions-module/9232/12

[hramos]

The linked-to code shouldn't run if your plist is not configured with either of these keys, but I can see how Apple may have systems in place that send automated emails based on these methods been present. Can you give us an example of the email they sent? Are you given an option to appeal the finding?

[fiznool]

Sure, here you go:

[pengcao1]

auto send email format like below

We identified one or more issues with a recent delivery for your app, “xxxxxx”. Your delivery was successful, but you may wish to correct the following issues in your next delivery:
"Missing Purpose String in Info.plist File. Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting spring 2019, all apps submitted to the App Store that access user data will be required to include a purpose string.If you're 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. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy)."
After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.

[pavjacko]

Apple's "official" info on how to handle it:
https://developer.apple.com/documentation/corelocation/choosing_the_authorization_level_for_location_services/requesting_always_authorization

[pedpess]

@pavjacko This guide that you sent is in case you wanna use location services, which is not related to this specific issue. @hramos May you know if RN is bundling Geolocation service by default into react-native lib? This may be the case.

[pavjacko]

UPDATE to my comment above:

After some digging, looks like this is the offending code:

Located here:

node_modules/react-native/Libraries/Geolocation/RTCLocationObserver.m

specifically:

#import <CoreLocation/CLLocationManager.h>
#import <CoreLocation/CLLocationManagerDelegate.h>

...

if (!_locationManager) {
  _locationManager = [CLLocationManager new];
  _locationManager.delegate = self;
}

...

if (![CLLocationManager locationServicesEnabled]) {
  if (errorBlock) {
    errorBlock(@[
      RCTPositionError(RCTPositionErrorUnavailable, @"Location services disabled.")
    ]);
    return;
  }
}

if ([CLLocationManager authorizationStatus] == kCLAuthorizationStatusDenied) {
  if (errorBlock) {
    errorBlock(@[
      RCTPositionError(RCTPositionErrorDenied, nil)
    ]);
    return;
  }
}

Apple code BOT picks on the usage of this API.

OPTION1
according to apple docs: https://developer.apple.com/documentation/corelocation/choosing_the_authorization_level_for_location_services/requesting_always_authorization
(if you really have to submit urgently) would be to add NSLocationWhenInUseUsageDescription to your Info.plist
But this doesn't really solve problem if you simply don't want to use and therefore inform user about this

OPTION2: Update your Podfile to look like (specific subspecs are up to your needs ofc) this:

pod 'React', :path => '../node_modules/react-native', :subspecs => [
  'Core',
  'RCTImage',
  'RCTNetwork',
  'RCTText',
  'RCTWebSocket',
  'DevSupport',
  'CxxBridge',
  'RCTAnimation',
  'RCTLinkingIOS',
  # 'RCTGeolocation', ///THIS NEEDS TO GO AWAY
  'RCTVibration',
  'PrivateDatabase',
  'RCTActionSheet',
  'RCTSettings'
  ]

I'm going to run the submission and see if it works.

BUT BEWARE if you use some other library which utilizes location code above you will still have the issue.
I know about these 2:

• react-native-simple-compass
• react-native-maps

[zzorba]

For those not using a Podfile to compile your application who come across this issue -- deleting the RCTGeolocation.xcodeproj from your Libraries folder in XCode fixed this issue for me (provided your app does not actually need GeoLocation, either directly or through a third-party library).

After removing that, I was able to upload a build to iTunesConnect without receiving any warning email about the absent location strings.

[christianbach]

The same solution (removing RCTGeolocatiion) worked for us to.

…

On Fri, 31 Aug 2018 at 17:20, Daniel Salinas ***@***.***> wrote: For those not using a Podfile to compile your application who come across this issue -- deleting the RCTGeolocation.xcodeproj from your Libraries folder in XCode fixed this issue for me (provided your app does not actually need GeoLocation, either directly or through a third-party library). After removing that, I was able to upload a build to iTunesConnect without receiving any warning email about the absent location strings. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20879 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG_BHDuZLACTSwK0EXKPQkdNb8MO-_eFks5uWVQfgaJpZM4WOcZB> .

[eflath]

Mine is a use-case not mentioned here: I'm using location services, but I only want to request permission to track location "when in use." The current library code for requestAuthorization (pasted below from RCTLocationObserver) uses the app's plist to determine which type of location permission to request, but Apple's automated review process sees that the function requestAlwaysAuthorization might be called and so they require you to include the 'Always' usage descriptor in your plist. Seems like a catch-22 to me.

RCT_EXPORT_METHOD(requestAuthorization)
{
  if (!_locationManager) {
    _locationManager = [CLLocationManager new];
    _locationManager.delegate = self;
  }

  // Request location access permission
  if ([[NSBundle mainBundle] objectForInfoDictionaryKey:@"NSLocationAlwaysUsageDescription"] &&
    [_locationManager respondsToSelector:@selector(requestAlwaysAuthorization)]) {
    [_locationManager requestAlwaysAuthorization];

    // On iOS 9+ we also need to enable background updates
    NSArray *backgroundModes  = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"UIBackgroundModes"];
    if (backgroundModes && [backgroundModes containsObject:@"location"]) {
      if ([_locationManager respondsToSelector:@selector(setAllowsBackgroundLocationUpdates:)]) {
        [_locationManager setAllowsBackgroundLocationUpdates:YES];
      }
    }
  } else if ([[NSBundle mainBundle] objectForInfoDictionaryKey:@"NSLocationWhenInUseUsageDescription"] &&
    [_locationManager respondsToSelector:@selector(requestWhenInUseAuthorization)]) {
    [_locationManager requestWhenInUseAuthorization];
  }
}

[hramos]

Is there no way to appeal these? The API is clearly not used, it's a false positive from the automated review process.

[sanjay-io]

We're attempting to add a npm postinstall script to package.json that'll remove these references:

{
  "scripts": {
    "postinstall": "sed -i '' 's/requestAlwaysAuthorization/requestWhenInUseAuthorization/' ./node_modules/react-native/Libraries/Geolocation/RCTLocationObserver.m; # https://github.com/facebook/react-native/issues/20879#issuecomment-416913061",
  }
}

Hopefully that'll resolve the issue.

[eflath]

@SanjayTCP you might be interested in patch-package we're using this to plug a few holes in other npm packages and it feels a lot more robust than ad-hoc scripts. I've been considering using it to apply a patch that makes the changes we need in RCTLocationObserver

[wawgoingdad]

I'm using library react-native-permissions, even I'm not asking for Bluetooth and Apple Music usage and bunch of others, this library seems to make my app get bundled with all of its capabilities.

[eflath]

To add to my comment above, the patch I created using patch-package looks like this

--- a/node_modules/react-native/Libraries/Geolocation/RCTLocationObserver.m
+++ b/node_modules/react-native/Libraries/Geolocation/RCTLocationObserver.m
@@ -202,20 +202,8 @@ RCT_EXPORT_METHOD(requestAuthorization)
     _locationManager = [CLLocationManager new];
     _locationManager.delegate = self;
   }
-
-  // Request location access permission
-  if ([[NSBundle mainBundle] objectForInfoDictionaryKey:@"NSLocationAlwaysUsageDescription"] &&
-    [_locationManager respondsToSelector:@selector(requestAlwaysAuthorization)]) {
-    [_locationManager requestAlwaysAuthorization];
-
-    // On iOS 9+ we also need to enable background updates
-    NSArray *backgroundModes  = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"UIBackgroundModes"];
-    if (backgroundModes && [backgroundModes containsObject:@"location"]) {
-      if ([_locationManager respondsToSelector:@selector(setAllowsBackgroundLocationUpdates:)]) {
-        [_locationManager setAllowsBackgroundLocationUpdates:YES];
-      }
-    }
-  } else if ([[NSBundle mainBundle] objectForInfoDictionaryKey:@"NSLocationWhenInUseUsageDescription"] &&
+  // Only support 'WhenInUse' location authorization to avoid being caught in Apple's automated review process
+  if ([[NSBundle mainBundle] objectForInfoDictionaryKey:@"NSLocationWhenInUseUsageDescription"] &&
     [_locationManager respondsToSelector:@selector(requestWhenInUseAuthorization)]) {
     [_locationManager requestWhenInUseAuthorization];
   }

obviously this patch is very specific to our situation, but it's working and the same pattern would work for any of the situations described in this thread.
I imagine a proper solution would involve preprocessor directives so that we could selectively include the right authorization requests at compile-time based on the content of your plist

[msageryd]

@huyquocmai https://github.com/yonahforst/react-native-permissions#app-store-submission-disclaimer

[manask88]

anybody still getting this warning? The last time i got this was on Aug 31. It seems like the code in RCTLocationObserver is still the same so i wonder what happened. Perhaps Apple is now smarter about this?

[ericlewis]

@manask88 I just got the warning today, except they didn't even allow my app in. It is a problem for sure.

[trevordunn]

Apple officially started cracking down on this today. Apps uploaded to TestFlight are being denied.

[brayanL]

I added NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription so the app was accepted for Apple.

[hilkeheremans]

Add the following (raw) keys with a reason to info.plist:

NSLocationAlwaysAndWhenInUseUsageDescription
NSLocationAlwaysUsageDescription
NSLocationWhenInUseUsageDescription

The actual description you add is not extremely relevant, I added a message like “this permission stems from a library we use and will never be called anyway. If you see this, deny access.”

[DanGDroid]

I am using geolocation only while in use - with the right permission in info.plist.
i am uploading my app for over a year to appStore and once before i was rejected for sensitive user data -NSLocationAlwaysUsageDescription but i added NSLocationAlwaysAndWhenInUseUsageDescription and it passed for the last months but today was rejected again, is the only solution to add another dummy description NSLocationWhenInUseUsageDescription to plist?
p.s i also added in the past the NSBluetoothPeripheralUsageDescription description although i dont have any BLE usage in my app!?

[diegolmello]

My app was rejected too. Is there any workaround?

[DinciPhoneDeveloper]

My app was also rejected. Is there any solution?

[fiznool]

@diegolmello @PayalDinc the best workaround for now is to add the plist keys as outlined by @hilkeheremans above.

[tomisavolainen]

I removed libRTCGeolocation from our project, but still got NSLocationWhenInUseUsageDescription request from Apple. By removing the libRTCGeolocation library I was able to remove the NSLocationAlwaysUsageDescription request.

RN version 0.42.3.

[adamwhalley]

is this correct to work?

[hakkikonu]

Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're 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. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs.

So just add description for NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription if you're using <0.60

After adding descriptions for these keys my issue resolved and submitted correctly to Apple Store.

[adambaialiev]

the solution can be found here: zoontek/react-native-permissions#305

[akhilsanker]

Hi @hakkikonu, @matt-oakes

I have the same issue from app store. I am using RN 0.59, and my app is not using geolocation. I haven't enabled location in capability too. Even then getting this review comment from apple.
What should be a possible way to get the app pass the apple review without adding any description for NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription.
If adding the description is the only workaround, what description to be given, but the app is not even accessing user location.

Thanks

[amadeu01]

Hi, I have an app that was pre-0.60 and I upgraded to 0.60.4 and tried to deploy it to Apple Store, but I got ITMS-90683: Missing Purpose String in Info.plist Anyone with same issue with 0.60+ version?

[damathryx]

I am experiencing the same issue with @amadeu01.

[hakkikonu]

if you are not using location services really, just enter dummy description text for these fields.

[bpred754]

I am using RN 0.59.10, react-native-permissions, and I only need location data when using the app. In my scenario, users are seeing 2 location prompts, one for "When in Use" and another directly after for "Always". To fix this, I tell RN to skip automatic permission requests on app start:

navigator.geolocation.setRNConfiguration({ skipPermissionRequests: true });

Then, I tell react-native-permissions to only prompt for "When In Use":

Permissions.check('location', {type: "whenInUse"})

I originally found the answer to my issue here.

[export-mike]

the docs suggest its enabled by default in 0.61+ yet I cannot see any references to it in my podfile.
http://facebook.github.io/react-native/docs/geolocation.html#ios

platform :ios, '10.0'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
project 'myapp',
  'Dev.Debug' => :debug,
  'Dev.Release' => :release, 
  'Test.Debug' => :debug,
  'Test.Release' => :release, 
  'UAT.Debug' => :debug,
  'UAT.Release' => :release, 
  'Debug' => :debug,
  'Release' => :release

target 'myapp' do
  # Pods for myapp
  pod 'FBLazyVector', :path => "../node_modules/react-native/Libraries/FBLazyVector"
  pod 'FBReactNativeSpec', :path => "../node_modules/react-native/Libraries/FBReactNativeSpec"
  pod 'RCTRequired', :path => "../node_modules/react-native/Libraries/RCTRequired"
  pod 'RCTTypeSafety', :path => "../node_modules/react-native/Libraries/TypeSafety"
  pod 'React', :path => '../node_modules/react-native/'
  pod 'React-Core', :path => '../node_modules/react-native/'
  pod 'React-CoreModules', :path => '../node_modules/react-native/React/CoreModules'
  pod 'React-Core/DevSupport', :path => '../node_modules/react-native/'
  pod 'React-RCTActionSheet', :path => '../node_modules/react-native/Libraries/ActionSheetIOS'
  pod 'React-RCTAnimation', :path => '../node_modules/react-native/Libraries/NativeAnimation'
  pod 'React-RCTBlob', :path => '../node_modules/react-native/Libraries/Blob'
  pod 'React-RCTImage', :path => '../node_modules/react-native/Libraries/Image'
  pod 'React-RCTLinking', :path => '../node_modules/react-native/Libraries/LinkingIOS'
  pod 'React-RCTNetwork', :path => '../node_modules/react-native/Libraries/Network'
  pod 'React-RCTSettings', :path => '../node_modules/react-native/Libraries/Settings'
  pod 'React-RCTText', :path => '../node_modules/react-native/Libraries/Text'
  pod 'React-RCTVibration', :path => '../node_modules/react-native/Libraries/Vibration'
  pod 'React-Core/RCTWebSocket', :path => '../node_modules/react-native/'

  pod 'React-cxxreact', :path => '../node_modules/react-native/ReactCommon/cxxreact'
  pod 'React-jsi', :path => '../node_modules/react-native/ReactCommon/jsi'
  pod 'React-jsiexecutor', :path => '../node_modules/react-native/ReactCommon/jsiexecutor'
  pod 'React-jsinspector', :path => '../node_modules/react-native/ReactCommon/jsinspector'
  pod 'ReactCommon/jscallinvoker', :path => "../node_modules/react-native/ReactCommon"
  pod 'ReactCommon/turbomodule/core', :path => "../node_modules/react-native/ReactCommon"
  pod 'Yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

  use_native_modules!
end

[fritzfr]

I'm still having this issue with RN 0.61.5. I can not find any references what so ever to libRCTGeolocation or RCTGeolocation anywhere in my repo. My plists are clean of the mentioned strings. The only references regarding location is RCTConvert+CoreLocation.h and RCTConvert+CoreLocation.m. Are these 2 responsible for triggering this warning from Apple? @hramos

[fiznool]

Possibly - Apple runs static analysis on the bundled code and the presence of these files could trigger the warning. I haven't been involved in an App Store submission for some time now, so someone else with more recent exposure is probably better placed to comment than me!

…

[maschad]

Have you tried removing the CoreLocations.h from the RCTCameraRollManager.mm as well as the RCTConvert+CoreLocation.m and RCTConvert+CoreLocation.h classes?