-
Notifications
You must be signed in to change notification settings - Fork 24.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing NSLocationAlwaysUsageDescription in Info.plist without any GeoLocation Usage in 0.61.5 (ITMS-90683) #28200
Comments
Thank you for filing a new issue. The old one was closed after Geolocation was removed from core, but it looks like this needs some follow up. |
@maschad Thanks for the PR. Hope this will get merged. |
Did apple approve your build after you applied the fix? @felix-voicehub because currently I don't have a means of how I could write a test for this |
@maschad I'm only on testflight currently. With "fix" you mean just manually applying your PR to my repo? |
@felix-voicehub yes, or you could do it via |
#28300) Summary: This PR is to address #28200 Even though GeoLocation was extracted from the Core, there are still libraries i.e. the CoreLocation.h library included which cause Apple to reject Apps, as mentioned here. This removed all references to the CoreLocation library that where remaining. ## Changelog [iOS] [Removed] - Message Pull Request resolved: #28300 Test Plan: - Flow check passes. - RNTest built successfully. Differential Revision: D20441145 Pulled By: shergin fbshipit-source-id: 03faa4d20dc15cea931b42f34f13814df9c94a01
@maschad It took me a while but I finally applied the 2 PRs (https://github.com/facebook/react-native/pull/28326/files and https://github.com/facebook/react-native/pull/28300/files) to my own repo. I am still getting an E-Mail from Apple, however, instead of 2 notices (
|
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions. |
Yes this is still an issue. Just tried again with a new RN project on 0.63.1. |
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions. |
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
Yes, this is still an issue. Just tried again with a new RN project on 0.72. Can I simply remove the permission, if I am not using any location service, then no need to add this permission in the info.plist. |
Why is |
Description:
I am getting E-Mail from Apple after submitting to App Store Connect regarding ITMS-90683. It basically says that I have to include
NSLocationAlwaysUsageDescription
andNSLocationWhenInUseUsageDescription
in my Info.plist because they say that myNow, I do not use any of react natives geolocation functions. I have scanned my whole repo for anything regarding these APIs, and the only thing which came up was
RCTConvert+CoreLocation.h
(https://github.com/facebook/react-native/blob/master/React/Views/RCTConvert%2BCoreLocation.h) and it's ".m" file. These do import "CoreLocation", which could be enough to trigger this E-Mail, as suggested here.See this issue for explaining the whole background: #20879.
React Native version:
Steps To Reproduce
Expected Results
As Geolocation was supposed to be extracted from the core, I wonder why I still get this warning. I do not consider adding the mentioned values in my plist, as I expect that it will most likely show on some user facing screen that the app is using location services when it is definitely not.
The text was updated successfully, but these errors were encountered: