PermissionScope
PermissionScope copied to clipboard
nickoneill
Too many permissions for AppStore
Hey. If you are using PermissionScope with Xcode 8 GM and try to upload it to appstore you are gonna get errors like:
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSContactsUsageDescription key with a string value explaining to the user how the app uses this data.
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data.
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data.
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSMicrophoneUsageDescription key with a string value explaining to the user how the app uses this data.
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSMotionUsageDescription key with a string value explaining to the user how the app uses this data.
For some reason it thinks that I ask all those permissions. I even do not use any of these. Just the notification one.
Thanks @MaeseppTarvo, I'll add this to the readme. At the very least you should be able to add those string values and get past submission.
@bre7 Perhaps it's really time to do subspecs for each permission :/ Not sure how Carthage could work similarly.
One subspec per permission seems....too much. Isn't there a way to use weak linking like in ObjC ?
+1, seeing this as well.
Feels really weird to be adding usage descriptions for permissions we don't even use (Apple is already so picky about exactly how one uses different capabilities/permissions, so it makes me a bit nervous to "declare" we're using all of these).
For now I'd suggest forking and removing unused permissions (or editing the Pods project) 😞 Not sure if there's a perfect solution to these problem
Agree with @bre7. This feels pretty bad to add all these keys to my Info.plist, especially since i'm not using any of these. I think i'm going to remove PermissionScope for the time being until a fix can be determined.
@nickoneill I'd suggest putting a giant warning in the README. I have been waiting for my build for almost 2 hours and called Developer Support who also had no idea what was going on, and then thought to check my email which is when I found the problem.
There are some issues in SO like these:
[...] AdMob seems to have references to the Calendar so an app I have which uses ads, and does not use the Calendar itself, can't be submitted. Thanks Google!
A possible "solution" (albeit hacky) would be to enter all the required keys in Info.plist (it's even suggested by AdMob's team: https://groups.google.com/forum/#!msg/google-admob-ads-sdk/UmeVUDrcDaw/HIXR0kjUAgAJ)
If anyone needs it, I pushed a branch that's compatible with Swift 3/iOS 10 and uses the new UserNotifications framework. It only supports notifications and location. It's available here.
While more work, perhaps the correct solution is a core cocoapod, with the logic for each individual permission in its own pod. Or, while hacky if you are building from source there are always preprocessor flags you could wrap around each permission.
I know it won't be the prettiest or swift friendly option -- but what about using preprocessor flag per type of permission and then having to include the list of preprocessors in the project file?
@yuvalt We're not even sure what's causing the requirement at the moment - is it just linking the frameworks or the presence of the code itself? Waiting for more information right now.
@nickoneill It's the presence of the code itself. I didn't remove any framework links and my builds passed. I bet that Apple is looking for the import statement or specific classes.
I'm filing a code-level support request in an attempt to get more information on the issue.
I think the problem is actually much Apple sided. I think that if you have whatever piece of line about some permission inside code it just detects it and check if it is allowed. So I think there is nothing to do.
They are performing static analysis and finding the calls for the specific permissions and noticing the lack of the description in the plist file. Nothing more than that and you aren't going to get around it.
That's why I think preprocessing is the only way to go (need to be verified). So we can add a preprocessor definition like PS_INDIVIDUAL_PERMISSIONS and then PS_LOCATION, PS_CONTACTS etc... this way we can make sure that only the relevant code gets compiled. I can implement it quickly if people think it's the right approach.
@yuvalt I'm interested in this approach but wary of asking people to create flags in build settings because it's not always straightforward. Can you think of another way to turn preprocessor definitions on and off?
@emreavsar Your best bet in the short term is adding those plist items for the permissions that you're not using. Users will never see them until they're requested (which they never are) so no impact on your app.
@nickoneill thanks for the quick answer. Yep this looks like the quick-fix for the moment. Are you 100% sure that they're not listed somewhere but only requesting? (App Store Entry, Settings etc.)?
Thanks anyway. Looking for the update mate!
They're not listed in the app settings until they're requested. The code hasn't changed, it's strictly a change in Apple's review process.
@nickoneill I hear you, but that's the only thing I could think of. The user will need to define it under Build Settings -> Swift Compiler -> Custom Flags (it's not under Basic but rather under All). Painful. Anyway, all the could be optional and people can still just include all the descriptions in their Info.plist or just opt to use this. I'll be happy to issue a pull-request for this, if you're interested.
The only solution is that preprocessor flags have to be defined for the build process. There really isn't a way around it. Sadly you can't #define at the top of the .swift file because that would take care of it and make it easier.
But, it'll allow you to pick and choose which support you want which could be seen as a huge plus instead of having everything in there...
Hey friends, I got a suggested fix from Apple support, importing the framework is what causes the detection for API usage so give me your thoughts on this: each permission will have a single framework associated with it and you would have to import the framework specific to the permission that you're requesting, such as import PermissionScopeCamera, import PermissionScopeNotification, etc.
@bre7 I'm not convinced this is required... if we include many frameworks in a single podspec but don't import them anywhere, I've been given the impression that it will pass app review.
Meant subspec :D
@bre7 I'm not convinced this is required... if we include many frameworks in a single podspec but don't import them anywhere, I've been given the impression that it will pass app review.
Interesting. Guess we'll need to test it