We just got an App Store rejection:

We found that your app uses public APIs in a manner not prescribed by Apple, which is not in compliance with the iOS Developer Program License Agreement, as required by the App Store Review Guidelines.

In particular, section 3.3.1 of the iOS Developer Program License Agreement specifies:

"Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs"

Specifically, we found your app uses a HealthKit API (HKHealthStore) with no HealthKit features or functionality.

We actually don't use HealthKit - it's not imported as a framework or in our app's 'Capabilities'. The only mention of HealthKit is in JLPermissions. I suspect the problem is similar to this issue from another project: https://github.com/iosphere/ISHPermissionKit/issues/15 - i.e., merely the mention of HealthKit is enough to upset Apple's reviewers.

For now, I'm going to remove JLPermissions from my Podfile, and use a custom version which does not refer to HealthKit (for safety, I may also remove references to Calendar, Reminders, Microphone, and Locations)

Hey there,

I'm trying to get this to work with UIUserNotificationSettings permissions only (I don't want/need remote notifications, just local ones). I'm using Swift, this is what I'm doing:

JLNotificationPermission.sharedInstance().remoteNotificationType = UIRemoteNotificationType.None
JLNotificationPermission.sharedInstance().userNotificationSettings = UIUserNotificationSettings(forTypes: UIUserNotificationType.Sound | UIUserNotificationType.Alert, categories: nil)

After that I call the authorizeWithTitle() method. If I don't allow the permission, I get the expected behaviour. But as soon as I allow system permissions, I don't get anything printed. When I check for the authorizationStatus(), it is set to JLPermissionDenied.

Any ideas what possibly needs changing?

Includes permission checks for Facebook, Microphone Access and Health the same way as all the other checks. Also fixes warnings related to notification and location access.

Notifications were not checked against the system API. Instead, they were only being checked against what the library stored in NSUserDefaults, rendering the result unreliable most of the time.

This commit fixes that issue.

Steps to reproduce:

1. Enable location services, ask user for location permission, and gained.
2. Disable location services, restart app, ask user for location permission, still gained, but failed to get the location data.

Should we do this? I don't know if we can conflate the location services enabled and authorized state .

We have interactive notifications in our app and need to supply custom settings to register for notifications. I preserved old functionality, and added an overload. Want to take a look and merge?

Thanks! Justin

I was having issues grabbing the device's push token from - (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(nonnull NSData *)deviceToken and I found out that it only worked after calling [[UIApplication sharedApplication] registerForRemoteNotifications].

Doesn't JLNotificationPermission need to call [[UIApplication sharedApplication] registerForRemoteNotifications] in order to retrieve the device's push token for remote notifications? Let me know if I'm doing this wrong. Thanks for the great work @jlaws!

Recently I found a problem, if I check user permissions in the background thread, UIAlertView will not be displayed.

Although this is common sense, I think the library should do some appropriate precautions to prevent such problems(rather than let users to do this).

I'm trying to get my head around the push notification part of JLPermissions.

From what I can see [[JLPermissions sharedInstance] notificationsAuthorized] will return NO if my app has notifications enabled in a previous version, which didn't use JLPermissions.

MyApp 1.1 (NO JLPermissions)
(user agrees to permissions)
MyApp 1.2 (WITH JLPermissions)
(JLPermissions assumes user has not agreed)

Should I also check the systems's push notification status ( using this answer on stack overflow http://stackoverflow.com/a/9898632/121646 ) before attempting with either of the authorizeNotifications methods?

@jlaws apparently this piece of code

[library enumerateGroupsWithTypes:ALAssetsGroupAll
          usingBlock:^(ALAssetsGroup *assetGroup, BOOL *stop) {
              *stop = YES;
              self.photosCompletionHandler(true, nil);
          }

Gets called more than once; apparently the *stop = YES; is not working as expected (I'm assuming).

But on my tests I'm showing the custom UIAlertView; after tapping "allow" I'm getting the system's dialog (so far so good); upon allowing again the photosCompletionHandler gets called twice. (at least).

The microphone permission would always return not determined when calling authorizationStatus. Fixed a few other things such as the labels in the example and the missing auto layout for the last three permissions.