Missing Purpose String in Info.plist

[Martin]

Hello,

When I upload an app to Apple that includes the Google AdMob SDK I get the following email from Apple:

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

Since my app is not using any location data itself this must be because of the Google AdMob SDK. Obviously the Google AdMob SDK is using location data.

At the moment Apple has still approved my app although I have received this automatic email directly after the upload. But I guess they won't approve it in near future.

So I in future I probably really have to add the purpose string even if my app itself does not use location data, just because I have the Google AdMob SDK implemented?

Apple also says: "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 would it be possible to  get a AdMob SDK that does not use location data? I also don't want the Google AdMob SDK to use location data. So what should I do to make sure that Google AdMob is not using location data and my apps will also be approved by Apple in future?

Thank you so much!

Kind regards,

Martin

[Mobile Ads SDK Forum Advisor Prod]

Hi Martin,

Thank you for the detailed write-up on this. Let me see what I can do to help you.

As per checking, the SDK doesn't require you to include NSLocationWhenInUseUsageDescription to be in the Info.plist. Inline to your questions below and as per documentation, the SDK automatically sends location data only if the user enabled location services for the app and wouldn't require this explicitly. 

That said, could you check if there are any other dependencies in your app that are requesting location permission?

Regards,
Mark Albios
Mobile Ads SDK Team

ref:_00D1U1174p._5001UBo9qd:ref

[Martin]

Hi Mark,

My app never requests the users location data.

I think Apple recognizes that the Google AdMob SDK is potentially able to get the users location data (which is indeed the case, as you confirmed that), even if it only sends it if the user enabled location services for the app.

Apples automated email notification after uploading the app said:

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

The Google AdMob SDK must be the SDK that Apple recognized could potentially use the users location data.

I think that probably means that Apple will soon require the purpose string because the Google Ads SDK could potentially use location data?

Although for now my app got through the app review without any problems, I'm afraid that it won't in future if the AdMob SDK continues to potentially use user location data.

What do you think? I understand that message from Apple so that developers who use AdMob either have to include a purpose string (even if the app doesn't request location data), or Google needs to "release a version of their code that doesn't contain the APIs" (as the Apple email said).

Kind regards,

Martin

[Mobile Ads SDK Forum Advisor Prod]

Hi Martin,

Thank you for getting back to me. I will raise this to the rest of the team to get further insights on your concern and get back to you as soon as I receive updates from them.

Regards,
Mark Albios
Mobile Ads SDK Team

ref:_00D1U1174p._5001UBo9qd:ref

[Mobile Ads SDK Forum Advisor Prod]

Hi Martin,

Hope you are doing great.

Could you provide me with the Google Ads SDK version you're using when you encountered the message?

Thanks,

Mark Albios
Mobile Ads SDK Team

ref:_00D1U1174p._5001UBo9qd:ref

[Martin]

Hi Mark,

I have recently uploaded updates for different apps that include the AdMob SDK in versions from 7.31.0 to 7.42.2 and I have received the message for every app automatically from Apple directly after uploading it (before submitting it for review).

And all of these apps never need location data and never ask the user for accessing their location. I think Apple probably recognizes that the AdMob SDK is potentially able to get the users location.

Kind regards,

Martin

[Mobile Ads SDK Forum Advisor Prod]

Hi Martin,

Thank you for providing me with the additional details. I'll circle back this to our Engineering team and get back to you for any feedback.

Regards,

Mark Albios
Mobile Ads SDK Team

ref:_00D1U1174p._5001UBo9qd:ref

[Mobile Ads SDK Forum Advisor Prod]

Hi Martin,

This is Sam from the engineering support team.

The SDK does not directly include or call any location code, it only takes advantage of it if it is already present in the app and checks whether the permission has already been given. The SDK never asks for the permission.

Given that this has always been the case since Apple made this announcement, and the recent change has likely been in place for a couple of months but you are the first person to raise this concern with us, we wonder if there is something else in your app that is causing this issue to be raised.  Are you linking any other 3P libraries? Are you also linking Core Location framework or do any of your other dependencies require it? Note the Mobile Ads SDK does not require the core location framework.

Regards
 

Sam

ref:_00D1U1174p._5001UBo9qd:ref

[Vito Valov]

I have found the same issue. Email with the warning from Apple received.

None of the other pods I use, link to CoreLocation AFAIK. 

[Mobile Ads SDK Forum Advisor Prod]

Hi Vito,

Thanks for reporting, we are taking this issue as something we may need to address, however we need to verify it is a real issue.

Can you please advise perhaps which libraries your app is using and if you have any location related functions in your app also?

Regards
 

[Mobile Ads SDK Forum Advisor Prod]

Another thing I'd like to check - is this the first review of your app or is it just an update?

ref:_00D1U1174p._5001UBo9qd:ref

[Vito Valov]

It is an update. App was live for years in App Store

[Vito Valov]

Sure:

pod ‘Firebase/Core’

pod ‘Firebase/AdMob’

pod ‘Fabric’,

pod ‘Crashlytics’,

pod ‘ReachabilitySwift’,

pod ‘OneSignal’,

pod ‘YPImagePicker’,

[Mobile Ads SDK Forum Advisor Prod]

Thanks for that, I see this thread - https://github.com/OneSignal/OneSignal-iOS-SDK/issues/368 suggests that this is an issue with the OneSignal SDK - there are many reports there dating back at least 6 months.

Given that we have had only these two reports of this issue, I suspect that that is the more likely cause of the issue.
Regards

Sam

ref:_00D1U1174p._5001UBo9qd:ref

[Vito Valov]

I can confirm that a new build without OneSignal dependency has been successfully approved by iTunes Connect.

However, I still wonder how Firebase/AdMob SDK can do what's on this link:

https://developers.google.com/admob/ios/targeting#location

Whenever the app has location access, admob will be able to get it. But how if it's not having the issue of onesignal? 

[Martin]

Hi Sam,

I'm so sorry for my late reply, but unfortunately I couldn't answer earlier.

My app is indeed linking Core Location framework. I will remove this in the next update and see if I'll still get this message from Apple.

Thank you so much!

Kind regards,
Martin

[Mobile Ads SDK Forum Advisor Prod]

Hi Martin,

Thanks for confirming.