Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple App Store Warning #34

Open
tielur opened this issue Nov 1, 2016 · 2 comments
Open

Apple App Store Warning #34

tielur opened this issue Nov 1, 2016 · 2 comments
Assignees

Comments

@tielur
Copy link

tielur commented Nov 1, 2016

I received this warning when I recently submitted an app that uses ClusterPrePermissions from the app store:

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.

I'm not using the Calendar permissions at all, I'm only using microphone permissions.

@tielur
Copy link
Author

tielur commented Nov 1, 2016

It seems like the Apple app store code analysis is seeing the use of EKEventStore within the ClusterPrePermissions library and rejecting the app unless I include the NSCalendarsUsageDescription in the Info.plist.

@rsattar
Copy link
Owner

rsattar commented Nov 2, 2016

Hey there,

Yeah, this has been on my mind for a while, ever since Apple announced that people will need usage descriptions filled out in their apps.

The easiest thing to do for now would be to go ahead and add the usage descriptions for:

NSCalendarsUsageDescription
NSPhotoLibraryUsageDescription
NSCameraUsageDescription
NSMicrophoneUsageDescription
NSCalendarsUsageDescription
NSLocationWhenInUseUsageDescription
NSLocationAlwaysUsageDescription

... to your app's Info.plist.

The real fix would be to either:

  1. Add #ifdef statements all over the place, or
  2. Switch each permission into a separate CocoaPod subspec, or
  3. Rewrite this library in a way to genericize some the repeated flows.

The problem with (1) is that it makes the code ugly, and adding new permissions will continue to be hard/unmaintainable. The problem with (2) is the extra cognitive load of managing the pods.

Solution (3) is the ideal one, I think. Especially given that the library is still using UIAlertViews and all. A Swift-based solution might help tremendously, with typed enums and enums with associated values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants