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.
Related
I am using this SKStoreReviewController to add rating and review to my app. But there is one thing I am confused about.
As an example, lets say the popup will appear after 30 days. In the 30th day the popup will appear every time for one particular user or just once ?
Is Apple taking care to not show the popup to same user multiple times in a day or I have to add the logic inside code for myself ?
You can trigger when to show the Rating view by calling this method: requestReview()
However, it's not guaranteed that it will show/ask the user for rating. It's completely governed by apple. You can check lines from Apple docs related to the same.
Excerpt from Apple docs.
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.
Apple is taking care of it. Have a look at requestReview() method of the SKStoreReviewController. A call to this method may or may not present an alert to review.
There is not much details provided by Apple for this. But in one of the docs Apple do quote that the developer should handle the flow and logic to display the popup. But again weather that popup is shown or not its upon Apple.
Apple Docs:
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.
The following are some apparently useful points listed in this medium article(Though the source it mentions have no details of the sorts):
You should only call request review when it makes sense in the user experience flow of your app, and then call the method only after the user has demonstrated some engagements on an app.
You have no control over exactly what’s happening and the dialog displayed or its callbacks, that is determined entirely by the system.
The system may or may not show a rating prompt, it’s not appropriate to call the API in response to a button tap or other user action because it is not going to happen every time.
No matter how many times you call the API, the system will only show up to a maximum of 3 prompts to the same user in a 365-day period.
The App Store defaults to showing ratings and reviews only for your app’s most recent version.
The User can turn off this in settings.
Apple might mandate this flow in future.
Hope this helps.
The documentation says that an app can ask a User three times per year via SKSToreReviewController to place a rating.
Most suggest to save a variable in UserDefaults and call the function after a couple of uses. What happens if you call the function more than three times per year? Will the App Store just ignore the calls and after a year asks for a rating again or will you get some kind of error?
And what happens if the app has been updated (ie. a jump from version 1.0 to version 2.0)? Will the 3 requests be reset?
In short, you choose the appropriate time to display the alert, but the system will decide whether to actually show the alert or not. So don't worry about "over-calling" as long as you don't call it as a response to user interaction.
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.
Highlight mine.
https://developer.apple.com/documentation/storekit/skstorereviewcontroller/2851536-requestreview
As for your second question, the only reference I can find regarding how many times it might be displayed is "3 times per year". It doesn't mention 3 times per app version or update. Use this API wisely.
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.
I am creating an app, which needs to do something when the user presses the power button 5 times.
I figured out that it's difficult to implement in iOS, but I think it's not impossible. How do I listen for power key events, even when the app is running in the background?
Can anyone help me to find solution?
you can tap a power key once and also you cannot detect the event from your application, this is not possible in iOS as far now, better try a different way to send alert with in your app, set some conditions with in your app and then send a alert based on those conditions if satisfied, I think this would be better,
Somehow ,If you try to override the existing functionality of the power key, apple will reject your app I think so,
You can't directly get the power button events. But there are notifications which you can count like UIApplicationProtectedDataWillBecomeUnavailable or UIApplicationWillResignActiveNotification. Or just register for all low level notifications with CFNotificationCenter and see if you find something fitting like com.apple.springboard.lockstate.
I don't think you can override system level actions like holding the power button, pressing the home button, overriding the mute sound switch within your own app. iOS system doesn't exactly behave like an normal computer OS, it's to much more limited.
Apple is not allowing you to use hardware components completely. They have added some restrictions. They provided the method in the app delegate i.e. applicationDidEnterBackground can catch the home button press .Also they has provided the the API's to access the camera,bluetooth etc .At least this much of API's I know which provided by apple publicly to access the hardware. You cannot access the other hardware elements in your application which not provided publicly by apple .If you are able to do this by any way then also your application will not approved by apple .
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.