Recently my app was rejected because I have accidentally included two subscription groups that I did not intend to sell. In the current App Store Connect UI, I don't see a way to remove the subscription groups from this version, or entirely from the account. These items have never been on sale. Does anyone know how to fix this issue?
Thanks!
Related
I tried submitting an app made with bakerframework in the magazine category and i got the following:
To submit an app with the category Magazines & Newspapers, you must offer at least one auto-renewable subscription. Set one up in In-App Purchases.
However with the changes in in-app purchases a couple of years ago, apple disabled the option to give a free in-app subscription for a magazine.
So I tried a non consumable in app purchase. And got that message.
Then I changed the categories for the app to see whether it would accept an upload and still get the same message.
Does it keep track of your submissions and not accept changes in categories in itunesconnect?
I tried disabling subscriptions all together in the app and deleted all teh in app purchase settings in itunesconnect and STILL get the same error.
Does anyone have a solution or a similar experience with this?
Any help would be much appreciated.
i had the same issue the last two days.
It was because the build of my app was using the «Newsstand kit» and when developers use the Newsstand plist key in their app, they are required to have at least one auto-renewable subscription before submitting the app for review.
So with a new build without the «Newsstand kit», it worked ;)
The same issue occurred for my app so I have sent a request to the Apple Support team. They sent me the following answer:
Thank you for confirming this metadata was set correctly. After investigating further, it seems that this issue may be due to the fact that your app's category is set to Magazines and Newspapers but there is no free or auto-renewable subscription tied to the app - which is required for all Magazines and Newspapers apps.
Auto-Renewable Subscriptions allow users to access content or services within an app on an ongoing basis. At the end of the subscription duration, the subscription automatically renews until the user chooses to cancel. For more info, please see the following:
Offering Subscriptions
In-App Purchase Programming Guide
In-App Purchase Configuration Guide
If you are still unable to submit your app for review after including a free or auto-renewable subscription in your app, please let me know.
Kind regards,
We're working on updating a Bigcommerce app (Previously submitted and currently live). It just so happens that we need to modify the scopes needed (we need access to products now).
Once changed, will our app go into pending mode and require resubmit? Will there be down time? if so, what will happen to current users that have the apps installed will they be able to use the parts of the app that use the scopes we already have permissions for?
Also, Will the current customers be prompted to approve of the new scopes the next time they try to start our application? how is this done?
After a change on the BigCommerce end, this is something you are able to do within the Developer Portal There's more info available about the scope update flow here.
Does anyone have any idea when/if Shopify will offer 'customers/created', 'customers/updated', and 'customers/delete' webhook events?
It would be great to be able to have our app notified when merchants are making changes to their customer records via their Store admin, or when someone creates a customer account without having completed an order.
They now exist! Check them out at http://api.shopify.com/webhook.html
Background
My iOS app supports multiple user accounts, but the user can only be logged into one account at a time. The app also offers a subscription service ("credits" in the form of a renewable In-App Purchase).
I'm having trouble keeping the in-app subscriptions separated to the specific user account that bought them. If a user buys credits on Account One and then signs out, and another user signs into Account Two (on the same device), the SKPaymentQueue still proceeds with the renewal process for the purchases from Account One (and, consequently, triggers the logic that unlocks those credits).
Question
What is the correct method of handling renewable in-app purchases for an app that supports multiple accounts? Is there any way to keep purchases from "overflowing" into other accounts on the same device? What else should be kept in mind?
I'm pretty sure what you're trying to do isn't possible. In-app purchases are tied to the Apple ID that purchased them. That means that if the user is logged into an Apple ID that has purchased the subscription, you are always going to be told it is available. A single user can't purchase the same subscription multiple times. The only way would be to force an Apple ID change when they change users in your app, which I'm almost certain you can't do.
I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).