search

rsattar / ClusterPrePermissions

Cluster's reusable pre-permissions utility that lets developers ask the users on their own dialog for photos or contacts access, before making the system-based request. This is based on the Medium post by Cluster describing the different ways to ask for iOS permissions (https://medium.com/p/96fa4eb54f2c).
MIT License
1.2k stars 109 forks source link

Apple App Store Warning #34

Open tielur opened 7 years ago

tielur commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.