2

My app is getting rejected due to a missing info.plist key.

Missing Info.plist key - This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSPhotoLibraryUsageDescription key with a string value explaining to the user how the app uses this data.

I know how to "fix" it. It's just as simple as it sounds, just add NSPhotoLibraryUsageDescription to my info.plist with a description of what it's used for.

The problem is that I'm not using anything that should trigger this requirement. I do not want to add this description without knowing what it's for.

The only thing I can think of that could cause this problem right now is that one of the external frameworks I'm using via CocoaPods has something to do with it.

This is my podfile:

def myPods
    pod 'HockeySDK',          '4.1.2'
    pod 'ReactiveCocoa',      '2.4.7'
    pod 'TTTAttributedLabel', '2.0.0'
    pod 'GoogleMaps',         '2.1.0'
    pod 'GoogleAnalytics',    '3.17.0'
end

target 'MainApp' do
    myPods
end

target 'BetaApp' do
    myPods
    pod 'Instabug', '7.0.5'
end

I know for a fact that Instabug requires this key (along with the key for Microphone usage), but I'm not always including Instabug, as you can see. Let's say I have two targets; MainApp and BetaApp. They each have its own info.plist. In BetaApp's info.plist, I have included the keys required. In MainApp I have not included them, because Instabug is not used in MainApp. When I now try to upload the MainApp to AppStore I get this rejection. I have also tried removing the Instabug-pod completely (even though it's just present in the BetaApp), and it still happens in MainApp.

I have never had this rejection in MainApp before (it's not a new app, just an update). I think I have updated GoogleMaps since last release, and maybe some of the others as well, but I have no idea how to find out why Apple thinks I have to implement NSPhotoLibraryUsageDescription.

Is there a way to find out what part of my app is triggering this requirement?

I assume that if I implement the keys, they will never actually be triggered, and the user would never be prompted to allow access to the photos library (because I have no code that attempts to access the user's photos library), but I'd like to know why this is happening, and I'm reluctant to add it before I know..

Sti
  • 7,686
  • 8
  • 57
  • 107
  • As I can see for a pod spec **HockeySDK** use **AssetsLibrary** and **Photos** frameworks for default – Sergey Mar 09 '17 at 13:51
  • @Sergey I noticed that as well, at https://cocoapods.org/pods/HockeySDK, but as it states at the **4.1.1**-post there, I have to add the info.plist key `If you are using an older version of the SDK`. As I'm using **4.1.2**, I expect I'm in the clear of this.. – Sti Mar 09 '17 at 13:56
  • If you don't use all functional you can change your pod file to this **pod "HockeySDK", :subspecs => ['CrashOnlyLib']** This specification don't use this frameworks. – Sergey Mar 09 '17 at 14:02
  • The only thing I could think of is that Apple searches the app's binary (it's strings, to get the selectors and so on) for _black-listed_ classes/messages -- and maybe this list is not that up-too-date (so they didn't realize that newer hockeys don't use that feature any more) – Andreas Oetjen Mar 09 '17 at 14:09
  • @AndreasOetjen I think it's mistake **HockeySDK** developers, the default specification don't contains Photo framework, but this specification contains AssetsLibrary framework. https://github.com/bitstadium/HockeySDK-iOS/issues/402 – Sergey Mar 09 '17 at 14:16
  • @Sergey Good find! I'm currently implementing the `'CrashOnlyLib'`. Hopefully I'll soon find out if that was the cause of it. Even if this isn't the cause of my problem, I should use `CrashOnlyLib`, so thanks for that! Will update when I know more. – Sti Mar 09 '17 at 14:36
  • @Sergey, I just uploaded a new binary to iTunesConnect, now using `CrashOnlyLib`, and sadly I still receive the rejection. I still thank you for the tip about this subscpec though, will use it. Got any other suggestions?:) – Sti Mar 09 '17 at 15:44

1 Answers1

6

I'd suggest you to follow instructions found in this answer

I understand that this might sound dumb to add NSPhotoLibraryUsageDescription key for no reason, however binary validation on the Apple's side is the process you don't have control over so it's simpler just to add this key.

As for the background reason, I believe, Apple validator looks for UIImagePickerController usage in binary, not only AssetsLibrary or Photos framework linkage. So if you'd like to get your app submitted & approved, you have either sanitize around this, or simply add required key.

If you think, you don't use it, take a look at ReactiveCocoa/UI/UIImagePickerController+RACSignalSupport.m, so, unless you are not ready to have a custom ReactiveCocoa or avoid it's usage, you'll have to deal with NSPhotoLibraryUsageDescription

Community
  • 1
  • 1
Petro Korienev
  • 3,937
  • 6
  • 31
  • 43
  • 2
    Thank you, you are quite correct! I actually found out about this a few days ago, just forgot to add it as an answer here. I deleted the `UIImagePickerController+RACSignalSupport` files (+ includes) and re-uploaded the new binary to iTunes, and no rejection. Now that I know for sure what the reason behind the rejection was I am perfectly happy with providing the `NSPhotoLibraryUsageDescription` because I know for sure it will never be prompted (rather that than manually deleting and editing a multiple files from a cocoapod, not just for my sake). Good find! – Sti Mar 12 '17 at 17:37