App rejected due to NSLocationAlwaysUsageDescription

[lifenautjoe]

Just got an email from Apple in regards to the latest built

Dear Developer,

We identified one or more issues with a recent delivery for your app, "Openbook Social". Please correct the following issues, then upload again.

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

Best regards,

The App Store Team

I do not use the location of people in the app nor wish to do so or even ask for it.

I'm also calling setLocationShared(false). Still rejected.

This might be in regards to new privacy laws adopted on the 20th of the current month.

[Nightsd01]

@lifenautjoe as a temporary fix to get around this issue, I would suggest including an NSLocationWhenInUse string in your Info.plist. Our SDK will not request user location permission so your users will never see it. It’s pretty silly for Apple to be doing this...

In the long term it is planned to split the location code into a separate OneSignal+Location framework but for now that should fix the issue.

[lifenautjoe]

Unfortunately that does not work... Apple rejects it if it doesn't include both the NSLocationWhenInUse and NSLocationAlwaysUsageDescription.

I sense this will be a chaos in the upcoming days.

[Nightsd01]

@lifenautjoe then there shouldn’t be an issue with including both strings - they won’t end up getting used.

[coffeemao]

Can you remove the location feature? I also encountered the same problem。@Nightsd01

[JanC]

Hello,
I started to have the same issue. The reflection usage to get the CLLocationManager in OneSignalLocation.m#L142 might be the cause I believe. I wonder if Apple is now analysing the binaries also for class strings.

Maybe something like this would work:

NSString *clazzName = [NSString stringWithFormat:@"%@%@%@", @"CL", @"Location", @"Manager"];
if( (int)[NSClassFromString(clazzName) performSelector:@selector(authorizationStatus)] == 3) {

[jkasten2]

@JanC @lifenautjoe @coffeemao Do you happen to have the CoreLocation.framework link in your Xcode project? If so can you try removing and re-submit to Apple?

1. Select your project on left.
2. Select your app target.
3. Open the "Build Phases" tab.
4. Expand the "Link Binary With Libraries"
5. Select CoreLocation.framework and press delete.
   

Do you get the rejection right away after uploading or after a fews days, etc?

@JanC It is possible something like that might work. It's hard to say if app is using static analytics or some kind of runtime instrumentation that flags any access to the class. Let me know if you had the framework linked, and if removing that ends up fixing the problem.

[JanC]

In my case, it was rejected during the automated binary processing.

I do have the CoreLocation linked as I’m using some CL structs but not the actual user gps location.

I ended up adding the plist entry and the TestFlight beta submission was successful.

[summera]

@jkasten2 I don't have the CoreLocation.framework in my project and am receiving this warning after submitting builds to App Store Connect. Is there a short-term plan to find a solution here? I'd really like to avoid making changes to our Info.plist file since we aren't asking for the user's location.

[Nightsd01]

@summera adding these strings will not ask the user for location permission. As long as you call OneSignal.setLocationShared(false) you will be fine. Same if you don’t link CoreLocation.

Unfortunately there isn’t much we can do about Apple having overly-aggressive binary scans. In the future we will probably split out the location features into a separate framework but for now, adding the strings to your Info.plist is literally the only permanent fix.

[rgomezp]

Closing issue due to no response

[wtsnz]

@summera adding these strings will not ask the user for location permission. As long as you call OneSignal.setLocationShared(false) you will be fine. Same if you don’t link CoreLocation.

Unfortunately there isn’t much we can do about Apple having overly-aggressive binary scans. In the future we will probably split out the location features into a separate framework but for now, adding the strings to your Info.plist is literally the only permanent fix.

+1 to splitting the feature out into another framework to avoid this.

[danhhgl]

This is a bug! Ignore it.

[rgomezp]

@danhhgl ,
Did the above workarounds not work for you?

[danhhgl]

@rgomezp I got the same email "Missing Purpose String in Info.plist" for "NSLocationAlwaysUsageDescription " and "NSLocationWhenInUseUsageDescription". But after a few minutes, I got a successful email: "App Store Connect: Version 1.0.0 (1) for YOUR_APP_NAME has completed processing." I did nothing at all. So I think this is a bug, so you can ignore it.

[rgomezp]

Thanks for the details @danhhgl

[p3v9d5ui]

This is still happening for me. Is there no resolution for this yet, without adding the two Purpose Strings?

[sinosoidal]

What is the last OneSignal version where this doesn't happen? What has been the recommend guide lines for this?

[p3v9d5ui]

@sinosoidal , Just add the two permission strings (NSLocationWhenInUse and NSLocationAlwaysUsageDescription) to your build and call OneSignal.setLocationShared(false). The two permission strings satisfy the App store, but are never used because setLocationShared == false. I also don't like to have to do this, because it I understand that there is no other way around it.

[davidfgc]

Should OneSignal.setLocationShared(false) be called before or after OneSignal.initWithLaunchOptions? Does it matter?

[p3v9d5ui]

Before: https://documentation.onesignal.com/docs/sdk-reference#setlocationshared-method

[JulianAlonso]

Even with OneSignal.setLocationShared(false) apple launches the issue.
I know the strings will never be used, but, there is no way to fix this due we're not using the location?

[SteveBlackUK]

I get the wanting from Apple but then the build is approved for test flight. So as per some comments above, the email from Apple seems to be a bug more than an actual blocker.

I haven't yet tried to submit to the App Store, so perhaps it would be blocked there with out the plist update?

[rignaneseleo]

This still seem to happen today

[hakonk]

This is a similar issue to when the Google Analytics iOS SDK included symbols and linked against libraries that made use of the IDFA.

IMO, one should be able to opt in on functionality such as location sharing, where the default does not at all link against libraries where location related code is accessed. I believe this can be made possible with OneSignal too. Any thoughts?