React-native: 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.

[pengcao1]

I have the same question in my app

Environment:
OS: macOS High Sierra 10.13.6
Node: 9.11.2
Yarn: 1.7.0
npm: 6.1.0
Watchman: 4.9.0
Xcode: Xcode 9.4.1 Build version 9F2000
Android Studio: 3.1 AI-173.4819257

Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: 0.55.2 => 0.55.2

[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 [e-mail]
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
https://github.com/facebook/react-native/issues/20879#issuecomment-417697117,
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.

[SanjayTCP]

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

[huyquocmai]

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?

[PayalDinc]

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.

[diegolmello]

@fiznool Yeah, as a workaround you're right. I mean a "fix workaround" until React Native fixes it.
I'm building a version without "Geolocation" in Podfile as mentioned above.
I'll upload to TestFlight as soon it passes on E2E and CI and I'll reply here if it works.

[Rojuinex]

I tried the solution with the Pod file but I'm still getting the email. Here is my pod file:

  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'Core',
    'CxxBridge', # Include this for RN >= 0.47
    'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
    'RCTText',
    'RCTNetwork',
    'RCTWebSocket', # Needed for debugging
    'RCTAnimation', # Needed for FlatList and animations running on native UI thread
    # Add any other subspecs you want to use in your project
  ]

[hramos]

I have asked previously but haven't received any direct answers. Has anyone appealed the rejection?

[hramos]

Are the apps rejected, or is this just an automated email?

According to the Expo thread at https://forums.expo.io/t/rejected-from-app-store-missing-location-string/13029/9 as well as the email sample posted last year, this is just an automated email with a suggested fix. If your app does not actually make use of location services, then this is a false positive that should not result in a rejection.

[diegolmello]

@hramos I think this kind of error doesn't have a way to appeal.
The entire bundle gets rejected and an apple email is sent like this:

"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)."

"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 NSLocationWhenInUseUsageDescription 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)."

[hramos]

In light of the new development, according to Apple's own rejection email, the workaround posted by @hilkeheremans is the correct way to deal with this at the moment.

While your app may not use location services, the capability to do so is something that is part of your app bundle through the use of the React Native project, and Apple's guidelines require adding a purpose string in this case. As an iOS developer, I don't feel great about adding purpose strings to the Info.plist for capabilities that the app does not actually make use of, but those are the rules laid out by Apple in their App Store.

As for a long term fix, the Geolocation component should be exported and removed from the core React Native library as part of the Lean Core project.

[hramos]

Considering this is a known issue with a workaround and long-term fix, please refrain from adding "me too" comments to the thread. Let's focus on sharing information about any new developments as well as discussing long term fixes.

[diegolmello]

@fiznool Yeah, as a workaround you're right. I mean a "fix workaround" until React Native fixes it.
I'm building a version without "Geolocation" in Podfile as mentioned above.
I'll upload to TestFlight as soon it passes on E2E and CI and I'll reply here if it works.

Just a feedback. Apple rejected this approach as well.

[Rojuinex]

@fiznool Yeah, as a workaround you're right. I mean a "fix workaround" until React Native fixes it.
I'm building a version without "Geolocation" in Podfile as mentioned above.
I'll upload to TestFlight as soon it passes on E2E and CI and I'll reply here if it works.

Just a feedback. Apple rejected this approach as well.

@diegolmello Removing the package from the Podfile for some reason doesn't actually remove the code from the bundle. If you comment out the offending lines in RCTLocationObserver.m your app will build and upload correctly. I'm not entirely sure but I suspect this has something to do with ReactCore pollyfilling the geolocation object here.

https://github.com/facebook/react-native/blob/81fcaa151df4f81e1751719173376bebedb42f36/Libraries/Core/setUpGeolocation.js#L25

[diegolmello]

@Rojuinex I followed @hilkeheremans' workaround and it worked.

[gtebbutt]

An alternative workaround to fully remove the functionality seems to be removing libRCTGeolocation from Build Phases -> Link Binary With Libraries in Xcode.

It's passed the automated checks, where an identical build with the link intact did not. Will see within a few days whether anything is flagged at review time.

[eflath]

since this thread is active again, I want to reiterate the fix I posted a while back. I think this is a clean solution that does not require supplying a usage descriptor for access your app will never request.

[cvharris]

@gtebbutt fixed the issue for me. I had originally removed RCTGeolocation from my Podfile but still saw this issue. Removed the libRCTGeolocation library from Build Phases -> Link Binary With Libraries and now I can see it in TestFlight

It makes sense that if you're not declaring Geolocation in Pods you shouldn't have it in the Libraries, but I think it is there automatically when you do a new React Native project. It would be helpful to see all the cleanup steps necessary if you switch to installing React with Pods instead, like which Libraries should stay in that list. I've never seen a snapshot of that before in the docs.

[gerbyzation]

Had this issue a while ago as well, using the same solution as @gtebbutt solved it for us.

[ExplicitlyImplicit]

Tried both @eflath and @gtebbutt solutions without any luck (libRCTGeolocation did not exist under Link Binary With Libraries). Running react native 0.39.2.

[cpojer]

We had discussions about this at Facebook and with the React Native core contributors and decided to move Geolocation out of React Native altogether, as part of the Lean Core (#23313) effort. Given the high-priority, we expect to do this quickly and remove the geolocation code entirely with 0.60 (the next release).

The code for this module will be here: https://github.com/react-native-community/react-native-geolocation and we will ask people who depend on the geolocation module in React Native to install that starting with 0.60. This means that people who depend on it will have an explicit opt-in, and apps that do not need geolocation won't run into issues with app store reviews.

[cpojer]

Diffs are now landing in React Native to remove this module, the repo I mentioned above is about to be ready and there are workarounds outlined in this issue. Starting with 0.60, this will not be part of React Native and should not cause any further issue. We are hoping to cut 0.60 within the next two weeks and stabilize over the next month or so. I'm going to close this issue since there is no more action we can take from the React Native side, but feel free to keep commenting if necessary.

[matt-oakes]

Version 1.0.0 of the newly extracted module is now on NPM. Details about using it are here:

https://github.com/react-native-community/react-native-geolocation

[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: https://github.com/yonahforst/react-native-permissions/issues/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?