Hello Thanks in Advance,
Am currently working on App Store InApp rating. I knew about the policy that apple allows only 3 rating once in 365 days.
So I would like to know that what happens if I request for rating more than 3 times in 365 days. Does it still show the rating popup and refuse to submit or it works something like in the developer environment(Rating and submitting but do not reflect in the app store).
No matter how many times you request the review prompt, the system will show the prompt a maximum of three times in a 365-day period.
Development: Shown every time the you request the prompt.
Related
I have implimented SKStoreReviewController in My app. I just want to know how the functionality works. I need to satisfy below requirements.
I need to disply popup in all the 3 cases
For first 10 successful logins
After every 90 days
I don't want to disply rating popup never if he provide the rating.
How do I know if a user gave the rating and also I need to send
response to server if user gave the rating.
SKStoreReviewController submit button is active after your app is live in appStore. The submit button is automatically disable when you're running in debug mode. It's only active when you're launching your app in appStore. That is not mistake from apple or Xcode.
Thank you.
Apple provides some suggested best practices and sample code for requesting reviews.
In answer to your requirements:
This is definitely not best practice; after 10 successful logins might be a reasonable time to ask for a review, but asking each time the user logs in will probably just be annoying.
Again, asking after 90 days is probably a reasonable interval.
By design there is no indication to your app as to whether the review request was shown, nor whether a review was left.
You can link directly to the App Store page where the user can provide a review, however you still have no indication of whether the user actually left a review or simply cancelled out of the web page.
The sample code I linked to shows how to track whether you have requested a review for the current version of your app. You cannot know whether the user has actually reviewed the current version.
My App does not actively prompt the user to rate the app on the App Store, it only includes a "Rate this app" page in the app settings. So the user has access the page manually and only after he taps on a Do Rate button, he is redirected to the App Store.
Of course the UI of SKStoreReviewController is much more straight forward than redirecting the user to the App Store app to leave his review. So I simply changed the call to the App Store URL to a call of [SKStoreReviewController requestReview].
This works fine in all my tests: The rating dialog is presented every time I tap the review button.
However I wonder how this will behave outside the debug environment in real live. According to the Apple docs, [SKStoreReviewController requestReview] is limited to 3 prompts per App per year.
How will the app behave once this limit is reached? Will pressing the review-button (= [SKStoreReviewController requestReview]) have no effect or will there be some kind of feedback?
How do I know if I can sill use [SKStoreReviewController requestReview] or if I have to send the user to the Store manually?
What exactly does 3 prompts per App per year mean? Is this really per App or per App Version?
Is there any limitation to the interval between two [SKStoreReviewController requestReview] calls? Is using it three days in a row as legit as using it every 4 month?
Disclaimer
Although I can't quote an official response (and I can't guarantee how long these findings will remain true), I just spent some time reverse engineering the logic and it seems to be pretty simple.
Requesting a Review:
When you request a review, StoreKit sends a message to com.apple.itunesstored.xpc, which is responsible for enforcing and tracking limits. If request limits haven't been reached, the XPC process tracks the request and responds with an app review token. Otherwise, it responds with nil.
After the XPC response has been received, StoreKit checks to see whether the token was nil. If it is non-nil, an SKStoreReviewViewController is instantiated and presented in an internal UIWindow. Otherwise, the request is silently ignored. There is no callback or notification you can listen for, and while there is some code in the XPC handler for logging errors, I didn't see any sources of errors in the XPC process.
Validating Limits
As far as the logic behind the limits, it's quite simple. There are two conditions that must be met:
The user must not be prompted more than three times in the past 365 days, regardless of app version.
The user must not be prompted if they rated the app in a prior request, unless:
Their last rating was more than 365 days ago
AND The application version has changed
Although Apple recommends waiting for further engagement over a few weeks before requesting another prompt, at the moment, there is no logic that prevents you from prompting the user three times within three minutes. Those prompts will count for all three of your prompts for the next 365 days though.
tl;dr
StoreKit will silently ignore any excess requests and you can't determine when that happens.
Although you could track your requests yourself to know when you need to redirect to the App Store vs request a review, Apple may change the logic at any point in time. There is no way to programmatically query your limits.
Three prompts per year means three prompts within the past 365 days, regardless of app version. (Updating the app clears the "never prompted again" requirement though.)
There is no limitation of interval between two request review calls.
For your situation, I'd recommend using the new App Store URL that brings users directly to a review composition screen. This will work more consistently while still following the HIG guidelines (since it's in response to a button press).
To automatically open a page on which users can write a review in the App Store, append the query parameter action=write-review to your product URL.
Background
I have an application that supports in-app purchase with Apple subscription (in particular auto-renewable plans).
Using the WWDC 2016 slides material, in the Manage Subscription page, (inside iTunes & App Store -> View my Apple ID), we have this:
in which the user is allowed to change the current subscription plan (and also to cancel it). So far, so good.
Case scenario
I would like to simulate the scenario of a user changing account (or cancelling the current subscription) from the Manage Subscriptions page.
My issue (and possible solutions)
Thus, I am now facing the issue of testing the reported scenario.
It seems to conflict with Sandbox Account for testing purposes. In particular: if I try to login with the sandbox Apple ID into the iTunes Store & App Store page, I of course receive the message: iTunes Account creation not allowed (as reported in this question).
The most straight-forward solution seems the one reported in this thread (shortly: let the subscription plan auto-renew for 5 times with 5 minutes period, after which we should receive the 21006 error). Anyway, I am not sure that it could be applied to this case, since it seems only including the cancel my subscription case.
Another thread comes directly from the apple forum (this thread) but: (1) something is strange, i.e. the iTunes account creation not allowed error seems not to appear when logging into iTunes with sandbox accounts - while it happens to me systematically) and (2) even after logging in, the subscriptions are reported not to be shown.
I expect that everything works using a real Apple ID, but this is something I don't really want to do.
Conclusion (?) and question
So, finally :), my question. Is there a way to test the reported case scenario (or an equivalent one) without using a real apple ID, thus without triggering a real transaction? I don't really want to believe that the current sandbox testing mechanism does not include it.
Thanks in avance to all!
An iTunesConnect Sandbox test user account can test auto-renewing subscriptions but that account cannot login to iTunes and utilize the Manage Subscriptions.
Only Option
The only option I have seen being utilized is to essentially get your app fully approved for the app store (do not auto-release). Once approved, use a promo code to download and live test the Manage Subscription scenarios. If it all checks out, release the app. (I cant seem to find the link for this but will add it here if I come across it.)
Other Notes Testing Auto-Renewing Subscriptions
Duration times are shortened when test your auto-renewable subscriptions. Additionally, test subscriptions only auto-renew a maximum of six times.
Reference Link
~Emphasis is mine
1 week = 3 minutes
1 month = 5 minutes
2 months = 10 minutes
3 months = 15 minutes
6 months = 30 minutes
1 year = 1 hour
This thread has a response posted from an Apple Developer in regards to this situation. Link
I am having a problem trying to get the business model of my client to work with iOS in app purchases. We are using Parse.com as a backend for this app.
There are two type of users for this application consumers and posters. Posters are able to post an add for a business and the consumers are able to view those ads. The information for the ads are being stored in the Parse backend.
The problem that I am having is this.
The client wants to have 4 different durations for each ad 1 month 3 month 6 month and 1 year. I have set these up on the iTunes connect account as consumables because the duration it stored in Parse.
I can make the purchase the product just fine but the problem is that I have no way of tying a transaction to a specific add I can only determine which of the products (1 month, 3 month, etc that they bought) and the user can have multiple ads.
I also have the problem of since the ad information is stored on Parse I cannot invalidate it unless the user opens their device.
One way to solve this by making your in-app purchase an intermediate "currency" such as "credits" - The user then purchases a number of credits and when they post an ad it consumes the appropriate number of credits from their balance.
This way you do not need to associate a particular ad with a particular purchase - you simply verify the balance is sufficient for, say, a 3 month posting, deduct the credits from the balance and put the ad in the database with the appropriate duration field.
I am facing a strange behavior with In-App-Purchase in iOS while testing with sandbox. Few things I observed, Please make your comments where I am wrong.
I know sandbox has small time interval for subscriptions like 30 minutes for 6 month subscription. I am using subscription model, when I am trying to purchase same item multiple time, it allows. Is that OK ? As per my understanding, it should allow only once to purchase and in subsequent call, it should say "Already purchased".
When I am restoring my previous purchase. Storekit is calling updateTransations with large number of previous transactions. Don't know why it is returning these large amount like 100, 200 ,245, 360, 650 seems like Random in every restore.
Please make your comments. Thanks in advance.
Regards,
OP
Dear All,
As I did not get reply on this thread. We have done testing an make the app live, app is working fine. Here are my comments that might be helpful to others.
When testing with sandbox, since time interval is not same as live app. You get 5 minutes for 3 month subscription and so on, so once your subscription expire your subscription will be renewed. If you will make one more payment request if subscription is live, you will get popup for already purchased.
Apple sends a large number of transactions, we need to add condition by our own, so that we will identify the current transaction and will process that only, rest will be ignored.
Hope this will help you all.
Thanks,
Om