I have requested a quota increase on the YouTube Data API.
I am getting the impression I’m being given the run around or no one inside of Google actually works on this.
I requested a quota increase over 3 weeks ago, and every time I email them, I get a very generic:
We understand your concern about the Quota. As informed earlier your request is being reviewed by our Quality Compliance Team. Their review takes longer time and hence is causing the delay. Any update that we receive from them will be shared with you immediately.
But it’s been 3 weeks.
Has anybody else had the same experience? If so, how long did it take to get approved?
Related
We get the user cancels in the next 30 days from our database and we call to Apple one to one
https://buy.itunes.apple.com/verifyReceipt
We want to call for a list of user cancels in the next 365 days which can be a huge list.
I look for that in the documentation and in google but I couldn't find if there is a limit on the number of requests to Apple.
Does anyone know that?
After contact Apple's support, there are not query limits.
I have this endpoint implemented several months ago and I make a huge number of requests every day without any problem.
It's the only way to verify the status of each receipt because their webhook doesn't seem reliable.
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.
The YouTube Analytics API provides access to estimated revenue through the Metrics API. However, these are just estimates, and are not the final amount that creators are actually paid. Anecdotally, actual revenue can often be significantly different from these estimates. YouTube documentation notes that:
Finalized revenue can be found in the downloadable monthly reports approximately 10 days after month end and are visible on the AdSense payment page within 15 days after a month’s end.
Is there any way to access this data through an API? I don't mind waiting 15 or even 30 days to get access to this, but I need to get the actual final amount that the creator was paid in a month, and I need to get that information per-video. I haven't found anything in the Analytics API so far, but I'm not intimately familiar with the YouTube API so I may be missing something.
I'm implementing a trial then subscribe model into my app which allows the user to use the app for free for 14 days, then at the end of the trial it'll alert them that the trial ended and they need to subscribe to continue use.
I'm doing this settings an NSDate object in standardDefaults the first time the app is opened. Then it compares the current date with the stored date, and compares the returned time interval to the number of seconds in 14 days.
My question is this: Do standardDefaults stay in memory if the user deletes the app? If not, how can I prevent a user from deleting then redownloading the app to restart the trial period?
Apple is quite proud about their sandboxing concept and the fact, that if a app is deleted, all the data will be deleted.
The only way of ensuring this information won't be lost will be to save it to a Database on a server and periodical check from your app.
This as technical solution. But make sure, if Apple will allow this in there AppStore if you plan to release it there.
Apple forbids trial versions, though I am not sure, if you could deliver in-app purchased content free for a while and later start billing.
But the main rule is: what ever was given to the user for free must stay free.
There are some apps that have trial periods for certain features. Look at the Puffin Browswer or ChessFree they both offer features that expire. Puffin allows for flash support (actually really cool feature!) and after a few days that feature is removed. Although the rest of the browser is still accessible the main purpose of it is removed.
ChessFree gives you points that you can use for different things, lessons, playing games, taking moves back, etc... I am not sure what happens when you run out of points but it appears that you cannot really do anything anymore.
If I were to implement something like this I would just save a variable in the keychain telling how many days they have left or the date they installed it (as a string). That way it will not be deleted if the app is uninstalled (keychain items stay stored even if the app is removed, so just always check/decrement/increment that as you wish). I would probably keep some features available to users that reach the expired time limit (like Puffin) but I honestly believe that is up to you.
After a lot of digging we have paypal adaptive payments working in the sandbox with embedded/chained payments using the paypal_adaptive gem. Now the time has come to try out the live payment system, and as far as I can tell it seems that paypal is no longer giving out the X-PAYPAL-APPLICATION-ID needed to use the service (?).
The submission process described in this thread no longer seems to exist, and eventually I noticed this message in the sidebar :
The application submission form and application management tools (MyApps) for PayPal apps are currently offline so that we can launch a new and improved tool.
If you have questions about your app that has already been submitted, please select the "What's Up with My App?" option on our contact form.
We appreciate your patience while we work to improve x.com.
We've invested a reasonable amount of time getting everything working via the sandbox, and there was no indication during this time that the live service was unusable, though in hindsight we should have picked this up sooner. Nor can I find any information as to when this happened, and how long it's expected to be offline for.
I have sent a mail via the support system but am yet to hear back - does anyone have any idea what's going on with the adaptive payments service or when it might be available again, or if there's any other way to apply for an X-PAYPAL-APPLICATION-ID?
It came back up last night.
Despite repeated attempts by me and other members of paypal's dev community, we didn't get a concrete date until it was back up (I only noticed because I check every morning).
You can fill in an application here: https://www.x.com/user/my-account/applications/new
Depending on how advanced your integration is, they will generally give you a live AppID and approve the app automatically, then a human will review your app in the next 2 days or so - although I would suppose that there is a bit of an avalanche of app submissions going on at the moment so they might take a bit longer.
as an aside: strangely enough it was me that posted the original question that #recurser linked to, I guess this explains the 500 views :)
After some more digging, it appears that it is scheduled to return November 7th~8th.
Its already Nov 15 and it still is offline, after spending almost 2 days on this i havent found any response from paypal people.