I've assumed that putting NSBluetoothPeripheralUsageDescription into info.plist will automatically trigger the alert view (at appropriate time) which will among the other things, show the (localized) error defined in InfoPlist.strings(current language). I assumed something like that, because of this statement from the docs:
NSBluetoothPeripheralUsageDescription (String - iOS) This key lets
you describe the reason your app uses Bluetooth. When the system
prompts the user to allow usage, the value that you provide for this
key is displayed as part of the alert.
Take a look at into this part:
When the system prompts the user to allow usage ...
IMO, this means that alert will be popped out automatically, rather than manually in the code by me.
I am using :
CoreBluetooth framework and many of its classes like:
CBPeripheral, CBCharacteristic, CBCentralManager etc. so I guess this alert should pop out. Of course, I can pop out the alert view by myself on the first use of Bluetooth, but I thought that point of these info.plist keys is, actually to warn the user automatically...
Not quite...
I would hate to have iOS automatically pop up every permission request dialog when the app first runs. Much better to allow me to show "Can I use the camera?" the first time the user gets to the section of my app where the camera is used, and "Can I use Bluetooth" when that section is used.
So, the strings are required so the users are not presented with generic "App wants to use Bluetooth" requests. Instead, you have to provide a suitably informative string (subject to the reviewer's opinion, of course).
But it won't be presented to the user until you want it to be shown.
Maybe you already answered the system popup and have an entry in the iOS settings? In this case iOS will not ask anymore.
Related
When I implement FaceID, I set on Info.plist the FaceID Usage Description, hence, everytime an user tries to use FaceID for the first time, iOS displays a prompt asking about FaceID permission.
But, I'm not sure why if I use Touch ID, a similar alert saying "Do you want to allow XXX to use Touch ID" does not appear asking for user permission. What it appears is an alert like this:
Is this behavior normal? Or how can I show that alert with TouchID?
This is a deliberate UX choice on Apple's part. It's having to do with the passive nature of Face ID (simply continuing to look at the device) vs. the intentional action a user takes to place their finger on the Touch ID sensor on the device. Without an interstitial asking for deliberate permission to use the feature, a user may inadvertently (successfully) authenticate with Face ID despite potentially having no intent to do so.
The behavior you detailed in your question is clearly documented in Logging a User into Your App with Face ID or Touch ID (emphasis mine):
Set the Face ID Usage Description
In any project that uses biometrics, include the
NSFaceIDUsageDescription
key in your app’s Info.plist file. Without this key, the system
won’t allow your app to use Face ID. The value for this key is a
string that the system presents to the user the first time your app
attempts to use Face ID. The string should clearly explain why your
app needs access to this authentication mechanism. The system
doesn’t require a comparable usage description for Touch ID.
I would like to customize the following part of the notification permission prompt:
Notifications may include alerts, sounds, and icon badges. These can be configured in Settings.
Is it possible to change this to my own text?
You are not able to customize this message. Read Here for more information.
The recommended way that most apps handle this is by first presenting their own dialog, then show the Apple system dialog.
So when it comes time to ask the user for notification permissions, first you trigger your own custom alert that says something like "Please allow your-app-name to send you notifications..." and maybe a brief description of why the user should allow this. With this alert, only add one action to the UIAlertController, I usually just have the action title set to "Ok" and use .default as the style. In the completion handler of this "Ok" UIAlertAction that is when you will trigger the Apple system dialogue which presents the generic UIAlertController with the option for the user to either accept or deny permissions for your app to send notifications.
So the flow is something like -> users reaches point in app where they have to decide if they want to accept or deny notifications permissions -> app presents UIAlertController that is essentially just an explanation of why the app wants/needs to send notifications -> once user taps "Ok" then trigger the generic system alert that actually makes the user choose to accept or deny notification permission.
There seems to be some psychological advantage to doing it this way. By sort of forcing the user to tap "ok" to notifications in the first dialogue, it primes them to tap "allow notifications" in the generic Apple dialogue displayed immediately after.
EDIT Dec 2020 -
Alternatively what I see a lot of apps doing now is offering an "Accept" action and a "Maybe later" action in their custom alert. If the user taps accept, then the app displays the Apple system alert which allows the user to actually Accept/Deny notifications. If the user taps "Maybe later" then the app does NOT display Apple's system dialogue. This way the user never taps DENY on the Apple system dialogue and therefore the app is still allowed to show it in the future without having to make the user manually change the app's notification preferences via the iOS settings app.
EDIT Mar 2021 - (see #blackjacx comment) Apple has rejected (at least 1) app(s) for using a "priming" dialogue before showing the system alert. So that approach seems like it is no longer allowed.
For anyone who is looking for an updated answer: This is now possible using Xcode 13 (not sure exactly what version introduced it but I was able to see it on Xcode 13.4.1 and not Xcode 13.1) by setting your custom text as the NSUserNotificationsUsageDescription key in info plist file. Unfortunately at the time of writing this, it looks like Apple released this feature with no documentation on it but I can confirm it works on devices with iOS 15.4 and above!
In XCode, you can now click your App name on the left to open it's settings, click on Info, then add a new key called "Privacy - User Notifications Usage Description" -> Then you can set the value to whatever you want that message to say.
No, this is system message, you can't change to custom.
No, I'm fairly certain that that part of the message is out of your control.
I do not believe you can change the iOS prompt, but should maybe make your own. See the guidelines that Apple has provided:
https://developer.apple.com/ios/human-interface-guidelines/interaction/requesting-permission/
Not the best resource because it does state that you can change the subtext (this is specifically for location, photos, etc.) but this, and others, have some good practices:
https://blog.clevertap.com/asking-for-ios-push-notification-permissions/
Basically, you should make your own prompt. Be sure to handle the cases where they have either said no, or turned it off in settings and redirect the user to settings, if so.
Displaying Custom Messaging Before the Alert Ideally, people already know why you’re requesting their permission based on context,
but if it’s essential to provide additional details, you can display a
custom message before the alert appears.
Make it clear that opening the system alert is the only action people
can take in your custom-messaging screen. People can interpret a
pre-alert message as a delaying tactic, so it’s critical to let them
quickly dismiss the message and view the system alert. If you display
a custom screen that precedes a privacy-related permission request, it
must offer only one action, which must display the system alert. Use a
word like "Continue" to title the action; don’t use "Allow" or other
terms that might make people think they’re granting their permission
or performing other actions within your custom screen.
Guidelines here :
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/
Just to add clarity to Uche Nkadi 's answer, add a "Privacy - User Notifications Usage Description" key in your app's Custom iOS Target Properties. This will change the message on the notification permission alert.
I would like to customize the following part of the notification permission prompt:
Notifications may include alerts, sounds, and icon badges. These can be configured in Settings.
Is it possible to change this to my own text?
You are not able to customize this message. Read Here for more information.
The recommended way that most apps handle this is by first presenting their own dialog, then show the Apple system dialog.
So when it comes time to ask the user for notification permissions, first you trigger your own custom alert that says something like "Please allow your-app-name to send you notifications..." and maybe a brief description of why the user should allow this. With this alert, only add one action to the UIAlertController, I usually just have the action title set to "Ok" and use .default as the style. In the completion handler of this "Ok" UIAlertAction that is when you will trigger the Apple system dialogue which presents the generic UIAlertController with the option for the user to either accept or deny permissions for your app to send notifications.
So the flow is something like -> users reaches point in app where they have to decide if they want to accept or deny notifications permissions -> app presents UIAlertController that is essentially just an explanation of why the app wants/needs to send notifications -> once user taps "Ok" then trigger the generic system alert that actually makes the user choose to accept or deny notification permission.
There seems to be some psychological advantage to doing it this way. By sort of forcing the user to tap "ok" to notifications in the first dialogue, it primes them to tap "allow notifications" in the generic Apple dialogue displayed immediately after.
EDIT Dec 2020 -
Alternatively what I see a lot of apps doing now is offering an "Accept" action and a "Maybe later" action in their custom alert. If the user taps accept, then the app displays the Apple system alert which allows the user to actually Accept/Deny notifications. If the user taps "Maybe later" then the app does NOT display Apple's system dialogue. This way the user never taps DENY on the Apple system dialogue and therefore the app is still allowed to show it in the future without having to make the user manually change the app's notification preferences via the iOS settings app.
EDIT Mar 2021 - (see #blackjacx comment) Apple has rejected (at least 1) app(s) for using a "priming" dialogue before showing the system alert. So that approach seems like it is no longer allowed.
For anyone who is looking for an updated answer: This is now possible using Xcode 13 (not sure exactly what version introduced it but I was able to see it on Xcode 13.4.1 and not Xcode 13.1) by setting your custom text as the NSUserNotificationsUsageDescription key in info plist file. Unfortunately at the time of writing this, it looks like Apple released this feature with no documentation on it but I can confirm it works on devices with iOS 15.4 and above!
In XCode, you can now click your App name on the left to open it's settings, click on Info, then add a new key called "Privacy - User Notifications Usage Description" -> Then you can set the value to whatever you want that message to say.
No, this is system message, you can't change to custom.
No, I'm fairly certain that that part of the message is out of your control.
I do not believe you can change the iOS prompt, but should maybe make your own. See the guidelines that Apple has provided:
https://developer.apple.com/ios/human-interface-guidelines/interaction/requesting-permission/
Not the best resource because it does state that you can change the subtext (this is specifically for location, photos, etc.) but this, and others, have some good practices:
https://blog.clevertap.com/asking-for-ios-push-notification-permissions/
Basically, you should make your own prompt. Be sure to handle the cases where they have either said no, or turned it off in settings and redirect the user to settings, if so.
Displaying Custom Messaging Before the Alert Ideally, people already know why you’re requesting their permission based on context,
but if it’s essential to provide additional details, you can display a
custom message before the alert appears.
Make it clear that opening the system alert is the only action people
can take in your custom-messaging screen. People can interpret a
pre-alert message as a delaying tactic, so it’s critical to let them
quickly dismiss the message and view the system alert. If you display
a custom screen that precedes a privacy-related permission request, it
must offer only one action, which must display the system alert. Use a
word like "Continue" to title the action; don’t use "Allow" or other
terms that might make people think they’re granting their permission
or performing other actions within your custom screen.
Guidelines here :
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/
Just to add clarity to Uche Nkadi 's answer, add a "Privacy - User Notifications Usage Description" key in your app's Custom iOS Target Properties. This will change the message on the notification permission alert.
I was attempting to use apple's HealthKit authorization modal in my App's settings, to allow a user to toggle their info on/off for sharing. It automatically pops up the authorization screen. However it seems to only do it once and then never again. At least until 24 hours later maybe, where it will prompt again if needed.
Is this meant to be used similarly to PushMessage requests, where a user is prompted once and then not ever prompted again from the same request?
I'm skeptical to add this modal prompt in the App's initial load as it is quite intrusive as a full screen modal; even if called only once ever.
Basically the user suppose to see it once (as when asking to grant push notification permissions, or access to contacts).
I have found out that for each datatype you want to share with Health app (or read), you got one shot with the modal prompt. This prompt might be a bit tedious to the user as it shows the entire types your app ask for permissions (both read and write), and I assume this is why Apple said a best practice of HealthKit is to ask the entire permissions your app need at the same time (though some might argue with that in a matter of UX).
If you wish to ignore Apple suggestions of this best practice, you can ask for read/write permissions for each datatype separately - Doing so will result prompting that modal sheet each time you ask the permissions to a different type.
In the bottom line, this permissions sheet is meant (by Apple) to be shown to the user once. You can find a way to pass that limitation (yet for a limit amount of times - depends on the amount of datatypes available), but I won't recommend bypassing Apple's guidelines (it is never a good idea).
A trick to use is to modify the Share/write types in your authorization, this will require the user to look at it again, thus pop it up every time.
Is it possible to customize the default alert message when the iPhone wants to use users current location. I want to change not only the text but also the default blue screen alert view. Is it possible ?
Thanks.
Not possible. From documentation,
Important: In addition to hardware not being available, the user has
the option of denying an application’s access to location service
data. During its initial uses by an application, the Core Location
framework prompts the user to confirm that using the location service
is acceptable. If the user denies the request, the CLLocationManager
object reports an appropriate error to its delegate during future
requests. You can also check the application’s explicit authorization
status using the authorizationStatus method.
The alert is prompted by Core location framework. We don't have any control over it.
EDIT : To add up, from this Apple developer forum thread (login required)
That alert is shown in a standard fashion for all applications for
privacy reasons. The user's current location is sensitive
information, and we want to be sure that they give their informed
consent to any use of it on the device. The way that we do that is by
providing a clear, consistent mechanism for the user to give their
consent. If applications were allowed to override or disable the
alert, then that consistency would be lost.
and the answerer is an Apple employee..
Years later, Apple did implement some customization options!
Have a look at the documentation
documentation
If you put one of the following key in your info.plist (depending on your usage of the location services), you can specify a custom string, that is displayed in the default alert additionally.
NSLocationUsageDescription (available since iOS6)
NSLocationWhenInUseUsageDescription (since iOS8)
NSLocationAlwaysUsageDescription (since iOS8)