I am requesting permissions for the Music Library but this question is equally appropriate for any permissions that can be requested.
I have set the key and value in the project plist:
Privacy - Media Library Usage Description: Access to Media Library may be required to integrate music. This can be configured in Settings.
I have then added the code to display the native alert:
MPMediaLibrary.requestAuthorization { status in
}
This is all working as expected.
The issue is that I want to set the title of the permissions alert to a custom title.
I would like a custom title instead of:
AppName would like to access Apple Music, your music and video activity, and your media library
I can see many reasons why this wouldn't be configurable, Apple not wanting people lying, or being able to lie, about the permissions being requested being the main one.
It would be great to know whether this is possible and then any indication of how to do it if so. Otherwise the knowledge that it isn't possible is equally as valuable.
You can't change the fixed title of the message. Your own message is shown below the bold title.
Your specific privacy message should explain to the user why your app needs access. That's the best you can do.
Related
For example, the VLC app was able to somehow get my username (or device name?) without me ever giving it this info. Here is a screenshot that shows the VLC app greeting me by name in the app switcher. How is this possible if I never gave the app this information? Which API could it be using to obtain this info?
This is possible due to UIDevice class. It doesn't require permissions in order to get some basic system information, after all it's just your name (if you were to ask for location/health data/contacts/etc that would be something else and thus user permission is mandatory).
For more information refer to official documentation here https://developer.apple.com/documentation/uikit/uidevice
That's not VLC but rather iOS.
iOS suggests apps based on time and location of your device. The name is taken from your iCloud Account. VLC is not aware of that banner.
if UIImagePickerController.isSourceTypeAvailable(.photoLibrary) {
let imagePicker = UIImagePickerController()
imagePicker.sourceType = .photoLibrary
imagePicker.allowsEditing = true
self.present(imagePicker, animated: true, completion: { })
}
Even if I set access to Photos in Settings to "Never" with above code I can still present image picker and show photos. I'll check for PHPhotoLibrary.authorizationStatus() before showing it, but I would like to know is this expected behaviour?
Okay, you can sort of piece this together from answers and comments already, but to try to tell a more complete story...
In iOS 11, UIImagePickerController runs as a separate process from your app. That means:
Your app can't see the user's whole Photos library — it gets read-only access just for whichever asset(s) the user chooses in the image picker.
Because of (1), your app doesn't need the standard privacy authorization for Photos library access. The user explicitly chooses a specific asset (or multiple) for use in your app, which means the user is granting your app permission to read the asset(s) in question.
You can see more about this in the WWDC17 talk on PhotoKit.
(By the way, this model matches what you've seen in the Contacts framework since iOS 9; if you show contact picker, your app only gets a one-time drop of contact information for the contact(s) the user picked, not ongoing read/write access to the Contacts database, so the contact picker doesn't require special privacy permission.)
PHPhotoLibrary and its authorization status reflect the global read/write permission for Photos access that users can control from Settings > Privacy. (That's the one where your Info.plist needs NSPhotoLibraryUsageDescription.) Any use of the PHPhotoLibrary API requires this permission, regardless of whether your app's use of that API is only for writing or only for reading. This has been true since PhotoKit was introduced in iOS 8.
If you're not using PHPhotoLibrary, PHAsset, etc, there are narrower permission options that are new in iOS 11 (and not part of the Photos.framework API):
As noted above, UIImagePickerController doesn't need blanket Privacy Settings permission because each use grants one-time read access for the specific assets chosen.
If you need only to add new assets to the Photos library, use UIImageWriteToSavedPhotosAlbum or UISaveVideoAtPathToSavedPhotosAlbum. With those you can put NSPhotoLibraryAddUsageDescription in your Info.plist — then the system's Privacy Settings will make clear to the user that they're not giving your permission to see or modify existing assets, only to add new ones.
If the user grants add-only permission, it applies only to those UIKit functions — attempting to use PHPhotoLibrary will still prompt for (and require the Info.plist key for) read/write access.
See this part of the WWDC17 talk for more on the add-only privacy setting.
Is this expected behaviour? - YES.
From the docs - https://developer.apple.com/documentation/uikit/uiimagepickercontroller/1619144-issourcetypeavailable
true if the device supports the specified source type; false if the specified source type is not available.
It tells you if the device supports the source type and not if the app has the permission to access it.
As you already mentioned in the question, PHPhotoLibrary.authorizationStatus() would be correct way to check this.
This (new) behaviour does sound logical to me, here's why. When using UIImagePickerController your app doesn't actually get access to any photos. It only sees the one your user has picked, when that happens; and if the user taps Cancel in the picker none of those become available to the app.
PHPhotoLibrary is part of a separate framework, Photos, where you can do a lot of stuff with the user's photo library, and therefore need permission.
So if you are only using UIImagePickerController I'd suggest not mixing Photos stuff in.
Disclaimer: haven't heard of any official statement from Apple folks. This forum thread looks relevant, maybe we get a reply there. UPD: there it is, same idea.
Also, if you're evil enough you can theoretically fiddle with UIImagePickerController view hierarchy at runtime and examine whatever the user sees there. But that's again for Apple to deal with, we should just be nice :-)
UIImagePickerController and PHPhotoLibrary responsible for different areas.
You should check both: auth status and source availability.
PHAuthorizationStatus
Information about your app’s authorization to access the user’s Photos
library.
isSourceTypeAvailable
Discussion
Because a media source may not be present or may be unavailable,
devices may not always support all source types.
For example, if you
attempt to pick an image from the user’s library and the library is
empty, this method returns false. Similarly, if the camera is already
in use, this method returns false.
if UIImagePickerController.isSourceTypeAvailable(.photoLibrary) {
let imagePicker = UIImagePickerController()
imagePicker.sourceType = .photoLibrary
imagePicker.allowsEditing = true
self.present(imagePicker, animated: true, completion: { })
}
Even if I set access to Photos in Settings to "Never" with above code I can still present image picker and show photos. I'll check for PHPhotoLibrary.authorizationStatus() before showing it, but I would like to know is this expected behaviour?
Okay, you can sort of piece this together from answers and comments already, but to try to tell a more complete story...
In iOS 11, UIImagePickerController runs as a separate process from your app. That means:
Your app can't see the user's whole Photos library — it gets read-only access just for whichever asset(s) the user chooses in the image picker.
Because of (1), your app doesn't need the standard privacy authorization for Photos library access. The user explicitly chooses a specific asset (or multiple) for use in your app, which means the user is granting your app permission to read the asset(s) in question.
You can see more about this in the WWDC17 talk on PhotoKit.
(By the way, this model matches what you've seen in the Contacts framework since iOS 9; if you show contact picker, your app only gets a one-time drop of contact information for the contact(s) the user picked, not ongoing read/write access to the Contacts database, so the contact picker doesn't require special privacy permission.)
PHPhotoLibrary and its authorization status reflect the global read/write permission for Photos access that users can control from Settings > Privacy. (That's the one where your Info.plist needs NSPhotoLibraryUsageDescription.) Any use of the PHPhotoLibrary API requires this permission, regardless of whether your app's use of that API is only for writing or only for reading. This has been true since PhotoKit was introduced in iOS 8.
If you're not using PHPhotoLibrary, PHAsset, etc, there are narrower permission options that are new in iOS 11 (and not part of the Photos.framework API):
As noted above, UIImagePickerController doesn't need blanket Privacy Settings permission because each use grants one-time read access for the specific assets chosen.
If you need only to add new assets to the Photos library, use UIImageWriteToSavedPhotosAlbum or UISaveVideoAtPathToSavedPhotosAlbum. With those you can put NSPhotoLibraryAddUsageDescription in your Info.plist — then the system's Privacy Settings will make clear to the user that they're not giving your permission to see or modify existing assets, only to add new ones.
If the user grants add-only permission, it applies only to those UIKit functions — attempting to use PHPhotoLibrary will still prompt for (and require the Info.plist key for) read/write access.
See this part of the WWDC17 talk for more on the add-only privacy setting.
Is this expected behaviour? - YES.
From the docs - https://developer.apple.com/documentation/uikit/uiimagepickercontroller/1619144-issourcetypeavailable
true if the device supports the specified source type; false if the specified source type is not available.
It tells you if the device supports the source type and not if the app has the permission to access it.
As you already mentioned in the question, PHPhotoLibrary.authorizationStatus() would be correct way to check this.
This (new) behaviour does sound logical to me, here's why. When using UIImagePickerController your app doesn't actually get access to any photos. It only sees the one your user has picked, when that happens; and if the user taps Cancel in the picker none of those become available to the app.
PHPhotoLibrary is part of a separate framework, Photos, where you can do a lot of stuff with the user's photo library, and therefore need permission.
So if you are only using UIImagePickerController I'd suggest not mixing Photos stuff in.
Disclaimer: haven't heard of any official statement from Apple folks. This forum thread looks relevant, maybe we get a reply there. UPD: there it is, same idea.
Also, if you're evil enough you can theoretically fiddle with UIImagePickerController view hierarchy at runtime and examine whatever the user sees there. But that's again for Apple to deal with, we should just be nice :-)
UIImagePickerController and PHPhotoLibrary responsible for different areas.
You should check both: auth status and source availability.
PHAuthorizationStatus
Information about your app’s authorization to access the user’s Photos
library.
isSourceTypeAvailable
Discussion
Because a media source may not be present or may be unavailable,
devices may not always support all source types.
For example, if you
attempt to pick an image from the user’s library and the library is
empty, this method returns false. Similarly, if the camera is already
in use, this method returns false.
My react-native app needs to create a calendar event, it doesn't need to view, edit or delete event. I tried to use few react-native libraries which handle calendar but I needed to grant permissions for a calendar in each of them.
I have no knowledge of Objective C or Swift, but I would like to know if it is even possible in either native or react-native way.
Every advice is very appreciated. Thanks!
Short answer is no.
You do need to be granted permission to create a calendar event.
The Human Interface Guidelines section about requesting permissions
Users must grant permission for an app to access personal information, including the current location, calendar, contact information, reminders, and photos. Although people appreciate the convenience of using an app that has access to this information, they also expect to have control over their private data. For example, people like being able to automatically tag photos with their physical location or find nearby friends, but they also want the option to disable such features.
In the apple docs it specifies that you need to add an entry to the info.plist. This text is used when the permission is requested.
Important: If your iOS app links on or after iOS 10.0 and you need to access Calendar data, be sure to include the NSCalendarsUsageDescription key in your Info.plist file.
Your app will crash without this key added to the info.plist.
This is the case for native apps, so the same will apply for react-native.
I'm trying out this code: http://github.com/akpw/AssetLibraryPhotosViewer to access photos on my iPhone.
However when I run the application, I get an alert that says the application is trying to access my photos - and then I can allow this or decline.
Can I disable this when using the AssetLibrary, or does this message always appear?
If I can't turn this off, and I press "Don't Allow", can I still make the app access my photos?
Following on from answer above. This will appear once. If you allow access then it will not show again and you will have access to the photo's. If you disallow it then you will not be allowed to access this and the alert dialog will not appear again.
This permission can be changed at any time by the user in the settings app (Under Location and Privacy, or a variation of that.) This has been around since iOS 6 I believe.
You are never able to programtically state that access has been granted, the system handles the permissions which are shown to the user.
This is a security feature of the OS that cannot be disabled. If a user does not give your app permission to access the photo library your app will not be able to access any photos. Given this ability your app should be able to handle the situation gracefully from a UI/UX perspective.
For more information take a look at this guide from Apple about iOS security guidelines (page 47 takes about accessing personal data) iOS Security