Onesignal-ios-sdk: AppStore rejections for NSLocationWhenInUseUsageDescription

See https://github.com/OneSignal/OneSignal-Cordova-SDK/issues/363 for this.

Thanks for reporting this. Our team is investigating.

It's an issue happening to a lot of people on the developer forums, not sure if it's OneSignal related: https://forums.developer.apple.com/thread/101367

@peterpaulis Can you try something as a debugging step? Can you try removing the OneSignal SDK from your project and see if that resolves the issue?

You don't actually have to submit for App Store review, we just want to see if you can upload a build.

We're trying to reproduce this issue on our side, we've got some test apps, but our apps are not getting denied.

@peterpaulis We suspect Apple may have fixed this in the past hour or two, can you try uploading another build?

Can confirm this just happened to me as well.

I do not need the "Always" access to location, but it seems like the NSLocationAlwaysUsageDescription is now mandatory when using OneSignal SDK, and the location prompt will now ask for either "While using" or "Always" option regarding location access.
I very much do not like it, since asking for an "intrusive" permission that I do not even need doesn't seem appropriate.

Any way to configure the SDK so it does not try to ask for "Always" location permissions?

@habovh This seems to be happening to a lot of people, many of them don't use the OneSignal SDK in their app, so we don't think this issue is related to OneSignal.

NSLocationAlwaysUsageDescription is _not_ mandatory with the OneSignal SDK. It will work just fine if you only use NSLocationWhenInUsageDescription. The problem seems to have been an issue with Apple's review system, and it seems they are rolling out a fix. We will continue to keep investigating the problem.

In the mean time, can you try completely removing the OneSignal SDK from your project and see if Apple will accept a new build? You don't need to submit it for review, we just want to isolate the issue.

Ok, I can confirm that Apple is aware of this issue and their engineers are looking into it.

It appears that Apple has resolved this issue. I will be closing the issue soon. If you are still encountering this problem uploading binaries, please reply

Hi,

I've just uploaded the newer version of the app to the App Store and I got below email from Apple. I am not using any sort of location service in the app although previous versions was uploaded perfectly.

-- 
Dear Developer,

We identified one or more issues with a recent delivery for your app, "". 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)."

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

After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.

Best regards,

The App Store Team

Anything from you guys will be a great help.

Thanks

Hi @OmarShoaib

Our SDK doesn’t access location directly, it uses reflection at runtime to see if your app has location enabled. Even then it will only access location unless you call setLocationShared(false)

Can you give a list of the dependencies in your app in addition to our SDK’s?

Thanks for quick reply @Nightsd01

BTW I forgot to tell you that I am using UnitySDK of OneSignal and the dependencies/plugins besides OneSignal that I am using are listed below

Vuforia
Sqlite3
NativeGallery
UnityOBBDownloader (Uses PlayServices)

They all are working fine until the last update.

I just started getting this message as well.

@OmarShoaib that is interesting, this issue used to be extremely rare, Apple may have changed things. We will look into this issue.

Happening to me now as well.
My iOS target is iOS 10 where this string was compulsory for applications needed this whenever accessing location apis.
When I had me iOS target as iOS11, apple did not give me any errors before.

Hi, just happening to me.
I'm using ionic, below version info
`cli packages: (/usr/local/lib/node_modules)

@ionic/cli-utils  : 1.19.2
ionic (Ionic CLI) : 3.20.0

global packages:

cordova (Cordova CLI) : 8.0.0

local packages:

@ionic/app-scripts : 3.1.11
Cordova Platforms  : ios 4.5.5
Ionic Framework    : ionic-angular 3.9.2

System:

Node  : v6.11.2
npm   : 3.10.10 
OS    : macOS High Sierra
Xcode : Xcode 9.4.1 Build version 9F2000

`
Plugin depencies
cordova-plugin-device 2.0.2 "Device"
cordova-plugin-document-viewer 0.9.10 "SitewaertsDocumentViewer"
cordova-plugin-file 6.0.1 "File"
cordova-plugin-file-transfer 1.7.1 "File Transfer"
cordova-plugin-inappbrowser 3.0.0 "InAppBrowser"
cordova-plugin-ionic-keyboard 2.1.2 "cordova-plugin-ionic-keyboard"
cordova-plugin-ionic-webview 2.0.2 "cordova-plugin-ionic-webview"
cordova-plugin-splashscreen 5.0.2 "Splashscreen"
cordova-plugin-whitelist 1.3.3 "Whitelist"
cordova-plugin-youtube-video-player 1.0.6 "CordovaYoutubeVideoPlayer"
onesignal-cordova-plugin 2.4.3 "OneSignal Push Notifications"

I have other apps with same depencies except OneSignal and I haven't store rejection.

I just tried again, I sent few build, switching iOS version 10.4 (issue detected) > 11.3 (issue detected) and back to 10.4 (no issue detected).
Maybe an Apple automatic code review system error?

Then after many tests, I removed OneSignal for compatibility issue with YouTubePlayer plugin and replace it by another notification plugin. Same issue with this second notification provider. The only way to solve the Apple mail issu is to add key to the info.plist like this :
<key>NSLocationAlwaysUsageDescription</key> <string>Send Geolocated notifications</string> <key>NSLocationWhenInUseUsageDescription</key> <string>Send Geolocated notifications</string>
Adding entry in the config.xml doesn't make required update to the info.plist file.

I think it's because of Unity itself. We do not use this SDK but got the same message from App Store Connect just moments ago.
Unity includes a file called iPhone_Sensors.mm. In that, there's the following code:

void LocationService::StartUpdatingLocation()
{
    if (gLocationServiceStatus.locationStatus != kLocationServiceRunning)
    {
        CLLocationManager* locationManager = gLocationServiceStatus.GetLocationManager();

        // request authorization on ios8
        if ([locationManager respondsToSelector: @selector(requestWhenInUseAuthorization)])
            [locationManager performSelector: @selector(requestWhenInUseAuthorization)];

        locationManager.desiredAccuracy = gLocationServiceStatus.desiredAccuracy;
        // Set a movement threshold for new events
        locationManager.distanceFilter = gLocationServiceStatus.distanceFilter;

#if PLATFORM_IOS
        [locationManager startUpdatingLocation];
#else
        [locationManager requestLocation];
#endif

        gLocationServiceStatus.locationStatus = kLocationServiceInitializing;
    }
}

The documentation for requestWhenInUseAuthorization says:

When the current authorization status is kCLAuthorizationStatusNotDetermined, this method runs asynchronously and prompts the user to grant permission to the app to use location services. The user prompt contains the text from the NSLocationWhenInUseUsageDescription key in your app’s Info.plist file, and the presence of that key is required when calling this method.

It seems that Apple changed something in their processing, so that triggers the message now.

Thanks for the helpful info. It looks like Apple is simply scanning the bitcode for any usage of location services. Our SDK accesses location services indirectly to avoid a crash if an app doesn’t use location services, so they must be scanning strings too....

It’s a bit ridiculous considering how many dependencies/frameworks use location services but only under certain conditions that may not be applicable to some apps.

I’ll keep this issue open until we’ve found a solution.

As a temporary workaround, if you don’t use location-based push notifications, you can call OneSignal.setLocationShared(false). That will turn off location access from our SDK. If you add the location permissions to your info.plist, Apple will stop sending you those warnings, but as long as your app never requests location permission, the plist strings will go unused.

Thumbs up! @EthanCG and @Nightsd01

For now, I've just added both OneSignal.SetLocationShared(false) and NSLocation permission strings and uploaded the binary. Voila! No error emails. And there's no popup of location permission in the app as well. So, that might be a possible workaround at the time.

Thanks all

Without making any changes, I did not get any emails from Apple today after pushing a build to the App Store.

We have heard that this was a bug with Apple's static analysis for new build uploads and was fixed - we have not heard any additional complaints so I'll be closing this issue.

If anyone sees an email like this in the future please post here.

Just received this exact same email. No new plugins were added and the previous builds were accepted just fine.

We got the same email today too. Not sure if it's another one-time deal or Apple really believes that we are using location APIs. I searched the xcode project generated by Unity's iOS build for "NSLocation" and I found only libOneSignal.a having a match.

UPDATE: CLLocationManager is found in both Unity's iPhone_Sensors.mm and libOneSignal.a. OneSignal uses it indirectly through NSClassFromString. iPhone_Sensors.mm uses it explicitly.

UPDATE2: Unity has a LocationService API built-in which uses iPhone_Sensors.mm. Even though we don't use LocationService in our app, CLLocationManager does seem to be linked in the final output of our iOS app because of it. I'm not sure whether libOneSignal.a's implicit use is also considered by Apple. But as long as we are using Unity, it doesn't seem like we can get away with it without providing NSLocationAlwaysUsageDescription. This seems to be Apple's new policy for "spring 2019".

@VitorGit Can you check if you have the Core Location library in your Xcode project. If so can your remove it?

@gnoph Thanks for all the details. If you remove the Core Location library from the generated project do you get compile errors with iPhone_Sensors.mm? I would assume so but it is possible there are preprocessors handling this.

Hi, @jkasten2.

Thanks for the hint. I just realized that the CoreLocation usages from iPhone_Sensors.mm are conditional on UNITY_USES_LOCATION preprocessor macro, which is currently defined to 0 in our project. That is, our app does not depend on CoreLocation framework. The framework is included in the project but not tagged with any targets. Removing it from the project does not affect the build. I haven't tried App Store submission yet.

Now I think our app does not have explicit references of CoreLocation APIs in the binary at all. I guess Apple somehow detected it in OneSignal library, even though it's used indirectly.

@VitorGit Can you check if you have the Core Location library in your Xcode project. If so can your remove it?

@gnoph Thanks for all the details. If you remove the Core Location library from the generated project do you get compile errors with iPhone_Sensors.mm? I would assume so but it is possible there are preprocessors handling this.

@gnoph Good to hear that removing the library still lets you build. It might be that Apple detects it's use at runtime when evaluating the app so removing Core Location means that OneSignal won't even try to check permission. The might be doing some static analysis though, it's hard to say.

Keep us updated on what your latest submission results in.

Same problem here, email says

Dear Developer,

We identified one or more issues with a recent delivery for your app, "MY APP NAME". 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)."

Best regards,

The App Store Team

Is it a bug from Apple? What we suppose to do with that?

Parts of the OneSignal iOS SDK allow apps to use location targeting for push notifications (geofence notifications). Apple appears to now be scanning apps for any code that uses location services, even if the app doesn’t actually use it.

Which is....senseless and annoying.

In the short term I would recommend putting an NSLocationAlwaysUsageDescription string in your Info.plist even if your app doesn’t actually use it. If your app calls setLocationShared(false) our SDK will not prompt the user for location permission.

It’s annoying, but that’s Apple for you.

In the long term, splitting out the location functionality into a separate OneSignal/Location Cocoapod library should be a more permanent fix.

@Nightsd01 After doing what you said (Adding NSLocationAlwaysUsageDescription and setLocationShared(false)) I'm getting the follow email...

Dear Developer,

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

Best regards,

The App Store Team

Probably their system is broken at this time.

@Nightsd01 After doing what you said (Adding NSLocationAlwaysUsageDescription and setLocationShared(false)) I'm getting the follow email...

Dear Developer,
We identified one or more issues with a recent delivery for your app, "MY APP NAME". Please correct the following issues, then upload again.
Best regards,
The App Store Team

Probably their system is broken at this time.

I've done the same, also same error. Hope it's a temporary App Store issue.

@jkasten2 We submitted the build without CoreLocation framework in xcode project and still got the same warning from Apple. The framework wasn't actually used before I removed it, it's just in the project but not linked to any of the targets. I think removing it didn't make a difference to the app binary.

@gnoph Good to hear that removing the library still lets you build. It might be that Apple detects it's use at runtime when evaluating the app so removing Core Location means that OneSignal won't even try to check permission. The might be doing some static analysis though, it's hard to say.

Keep us updated on what your latest submission results in.

Can anyone confirm that calling setLocationShared(false) without adding the strings to Info.plist works? Or are we supposed to do both things?

@bolino add the strings to your Info.plist. It’s a silly situation thanks to Apple but unfortunately that’s the current solution. Fortunately none of this will be visible to your users.

Same!

Please split the pod ASAP. Meanwhile I'm gonna be using Firebase Notifications. 🤷‍♂️

Had to fill this question to find out the answer that pointed me here.
https://stackoverflow.com/q/56777940/860311

Just use

NSLocationAlwaysAndWhenInUseUsageDescription

instead of NSLocationAlwaysUsageDescription + NSLocationWhenInUseUsageDescription

Apple is so stupidly secrete about their tweeks..

Same in v2.13.

ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).

ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).

Thanks for the helpful info. It looks like Apple is simply scanning the bitcode for any usage of location services. Our SDK accesses location services indirectly to avoid a crash if an app doesn’t use location services, so they must be scanning strings too....

It’s a bit ridiculous considering how many dependencies/frameworks use location services but only under certain conditions that may not be applicable to some apps.

I’ll keep this issue open until we’ve found a solution.

As a temporary workaround, if you don’t use location-based push notifications, you can call OneSignal.setLocationShared(false). That will turn off location access from our SDK. If you add the location permissions to your info.plist, Apple will stop sending you those warnings, but as long as your app never requests location permission, the plist strings will go unused.

hi @Nightsd01 . I realize your replies here are couple years back now. But I'm experiencing this now as a warning (testflight only, I don't have a production build yet). And I was wondering if you know if we do use this workaround (thank you for that btw), do you know by any chance if "Location" will appear under "Information" on the app page in the app store? That's my concern as it might deter downloads since people may think we use the location when we actually don't. Thanks!

I just integrated OneSignal into my iOS app and got this warning tonight, after having submitted earlier builds that didn't.

Still getting this E-Mail:

ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).After you’ve corrected the issues, you can upload a new binary to App Store Connect.Best regards,The App Store Team | ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).After you’ve corrected the issues, you can upload a new binary to App Store Connect.Best regards,The App Store Team
-- | --
ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).ITMS-90683: Missing Purpose String in Info.plist - 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 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. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).After you’ve corrected the issues, you can upload a new binary to App Store Connect.Best regards,The App Store Team

I sometimes get the warning, sometimes don't.

Silly question, but what would somebody put into NSLocationAlwaysAndWhenInUseUsageDescription (or NSLocation*)? I mean, afterall the app isn't using it...

@MihaMarkic 'We need to access your Location to send you proper notifications' for example