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.
Related
I have a basic query here. My app has a bit longer signup process. While testing I came across a bug where, whenever amidst the process if the user goes out of the app or kills the app, the remaining process is just left and it migrates to the a specific page, that i want the user to usually go to already.
Example if I have 5 ViewControllers and then a default 6th and if the users kills the app on 3rd VC, and then restart the app, it'll go to the 6th vc and ignore the rest of signup.
How do I avoid this. is using NSUserDefaults an optimal option. If yes How do i exactly implement it.
Cheers!
Yes, using NSUserDefaults to store the previous state of an app is common. (However, apps that have a server backend may store some data there too.)
Use the keychain to sensitive data (e.g. account details). (You must never ever store sensitive information in NSUserDefaults because it can be read.)
What you store in NSUserDefaults (and the keychain) depends on your application. If fields are filled in and/or options selected during the process, you need to store that.
Be pragmatic: It's very nice to users store app state. It can however get rather complicated. Don't waste time (with chances for bugs) trying to cover situations that don't occur often.
I am currently working on an app that is going to use the users iCloud information, namely first name, last name and e-mail address as a way to automatically sign-up for the app, instead of filling out a huge form.
Currently the only way I see to get to this information, is to ask the user for permission using the only CloudKit permission type available (userDiscoverability).
CKContainer.default().requestApplicationPermission(CKApplicationPermissions.userDiscoverability, completionHandler: { (status, error) in
....
})
The problem with this is, is that the definition of userDiscoverability is:
The current user is discoverable (through the user's email address) to
other users of the app
Which leads to the default dialog shown here:
The problem is, is that I want access so that i can use the information above to sign someone in automatically (and use it for when someone changes devices, loses their device, etc) so that they don't have to sign up again. Therefore the dialog shown here isn't relevant to what I need it for and the users of the app are going to be confused as to why other users of the app will see that they are using the app(and in fact there is no functionality in the app to allow this at all anyhow).
Like other privacy entries available in Xcode, is there one available somewhere for CloudKit where I can add my own custom message so that I can customize the reason I need permission?
I know that others people have offered solutions, like providing your own custom dialog before the system asks or providing a Page View Controller to explain what's going on but I would like to avoid that. Apple really needs another permission type here but for the time being, thats all we have.
Suggestions/Comments/Feedback welcome.
I'm taking a look at the new requestReview() API that uses SKStoreReviewController. The documents state:
"Although you should call this method when it makes sense in the user experience flow of your app, the actual display of a rating/review request view is governed by App Store policy. Because this method may or may not present an alert, it's not appropriate to call it in response to a button tap or other user action."
Does anyone have any experience using this API. What exactly are the factors that determine if the rating view is shown or not? I'm guessing it's not shown if called too frequently.. Anybody have any insight on this? Thanks!
You're right that it won't show if called too frequently.
SKStoreReviewController will only allow prompting a user to review your application 3 times at most, even if you ship more versions than that during the year.
There might be more restrictions beneath the surface as well.
Source: http://daringfireball.net/2017/01/new_app_store_review_features
According to iOS Human Interace Guildelines
The system automatically limits the display of the prompt to three occurrences per app within a 365-day period.
Should and event store's requestAccess(to:completion:) be called
as early as possible (e.g. in application(_:didFinishLaunchingWithOptions:)
only before EKEventSource should be used for the first time?
Does Apple recommend one or the other option (for iOS 10)?
Why nag the user any sooner than necessary?
A user will be more comfortable if the request for permission comes when they actually try to do something they know requires access to the event store.
If you request permission too soon, the user is going to wonder why the app is asking when they haven't even done anything with the app yet.
And what if your app needs access to multiple sources such as camera, photo library, contacts, and events? It would be terrible to just nag the user over and over for all of them up front. Only ask when the source is actually needed and the user probably fully understands that the action they just took (like take photo) requires the specific permission.
What I would like to know is whether there is anything wrong (in terms of the law, and App Store guidelines) with storing information about your application, and broadcasting it to an online location for gathering.
Specifically, an application which would normally not connect to the internet, connecting when it starts up and storing usage information like time of day, the device ID, and how long the person uses it for.
I'm guessing this sort of behavior is fine so long as you get the users consent first?
It’s fine if you ask the user first and give him an option to turn this feature off. We were once spanked out of the App Store simply for uploading a new game high-score record without a cancel button. It’s quite a long time and the rules might have changed, but better safe then sorry and your users will like the confirmation screen, too.