I need to create a custom ui for mic permission, is there a way to do it.
below is code code how permission block works.. it seems difficult with this call? App Shazam is doing it.
[[AVAudioSession sharedInstance] requestRecordPermission:^(BOOL granted){
if (granted) {
NSLog(#"granted");
} else {
NSLog(#"denied");
}}];
I am not aware of any way that you can circumvent the UIAlertViews presented by Apple that ask the user for permissions. What you can do however is this:
Present a view explaining in greater detail why you need the specific permission. With two buttons as Shazam does. And tell the user the user that tapping OK will present an alert to confirm.
If user taps ok, trigger some action (e.g. location) that requires the user's permission or use the system provided way of asking for permission (e.g. mic).
If the user taps "don't allow" you can still in the future present the interface again. With more explanation.
This approach is better than to always use the system's permission dialogue right away, as this can usually only be denied once from within the app. Using a custom view before the alert view allows you to ask more often.
We have also published a framework to help you with that: https://github.com/iosphere/ISHPermissionKit
For iOS >= 7.0
in you app.plist add this key: NSMicrophoneUsageDescription and your desired customized prompt. More details here: https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW1
Related
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 am using this method to ask user for the calendar permission requestAccessToEntityType:EKEntityTypeEvent completion:^(BOOL granted, NSError *error) but what i want is that when user clicks on Button named as GrantPermission, then the permission should be granted without showing the alertView which is of IOS builtin, is there any way to do this?
I want to do this because when user clicks on Dont Allow then i show a alertView which says that user have to manually turn on permission from settings and when user manually turns on this permission then the app crashes.
There is no way to grant permission without displaying the native alert view, as it provides an added level of security (without it developers would just be programatically granting permission to everything).
If you want to mitigate against getting into the situation where the user needs to manually grant permission from the Settings app you could display a "pre-permission" alert where you offer the user some information as to why they might want to allow it, followed by actually asking the system for permission which will in turn display the built in alert.
FWIW This isn't my idea, nor is it that new. This TechCrunch article goes into a lot more detail about the UX of asking for permissions on iOS.
Note that you could still end up in the situation where the user needs to manually grant permission - if they "accept" your alert but deny the actual system alert. In this case you will need to figure out why your app is crashing, maybe post another question regarding that.
How do I programmatically request location updates permissions?
I mean, I what to control, when does the native popup asking for "Your current location" pops
purpose:
I what to control that if there is no permissions, to present something and only then to ask for them (apple native popup). How to that?
You don't control the "Apple native popup".
You know whether the desired services are available through CLLocationManager class methods (locationServicesEnabled, authorizedStatus, etc). If location services are switched off, you can just start using a location manager anyway (e.g. startUpdatingLocation) - that is your only way of getting the system dialog asking the user to switch them on. Be prepared for the possibility that the user won't do so.
Of course nothing prevents you, having detected that you have been denied authorization, from putting up your own alert requesting that the user switch to Settings and authorize you.
My iOS app wants to display the users current location. Nothing special - but to do so, the first time the app is ran (or more to the point, the first time an MKViewMap in the app is displayed, I guess...) .. the user is asked for permission (which is awesome).
eg.
Now, if the user accidentally says DON'T ALLOW or decides to (later on) give permission ... is there technically a way we can reset their previous decision and when the app is restarted, ask them again automatically when the MKViewMap is next rendered again?
The user can enable or disable that option in the setting of the iphone. To do this, user have to select the Privacy option in the Setting Menu, and then select the Location Services option and than search the desired app to whom user want to enable or disable the permission and perform desired function by switching the toggle button on or off.
As it was a Private API provided from Apple the alert cannot be shown up again. Alternatively, we can check manually and show an alert like this.
The following can be read in the Apple docs:
"...it is recommended that you always call the locationServicesEnabled class method of CLLocationManager before attempting to start either the standard or significant-change location services. If it returns NO and you attempt to start location services anyway, the system prompts the user to confirm whether location services should be re-enabled. Given that location services are very likely to be disabled on purpose, the user might not welcome this prompt."
If I understand it right the alert will pop up everytime you try to get the users location, but it's not recommended to do so.
Link to full post:
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW1
No you cannot do so. Rather than this, you can just check the latitude and longitude value and show alert to the user that enable the service from settings.