I have some doubts using In app purchase. AFAIK only the first In app purchase is approved along with the binary. This is my current state,
I have my app already in AppStore with one weekly subscription.
Now I wonder if the following roadmap is possible:
Update the current IAP UI
Send to apple Apple Review more Weekly and Monthly subscriptions plans(some of them just change the introductory price)
My backend will decide which plan will showed to the user.
My problem now is I'm not able to update my current approved IAP, I modify the name, description and screenshot but when I save the changes the IAP is still Approved. Is it possible update a approved IAP? what about if I want to change the background?
On the other hand, I have another IAP waiting for review the last 5 days. Is it normal? Have I to send along with the binary to the app store review?
Related
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
Our app is moving from paid to free, and in the process, moving a key functionality from being included to activating via In-App purchase. Obviously, we don't want current users who paid for the app functionality to be charged again in the In-App purchase for functionality they already had. So on the update by the user, we want to 1) identify current users and 2) make it so they don't see the In-App purchase in the first place, sort of 'faking' the In-App purchase so that the app will appear to them exactly as it did before.
The app does not have a backend, so we have to determine current users from new by examining the saved user data fields for certain values. I do understand that if a previous user has deleted the app from their device that nothing can be done, and I don't mind charging them for the In-App purchase, since they never used the app anyway.
But for those current users who update and assuming we can examine the saved user data and determine that they are current users, what would be a good way to bypass the In-App purchase and make the app look like they already got it, when in fact they never paid for it? Thanks!
Here's what I would do - keep in mind this will take some time:
Set up a server (I prefer EC2) with mySQL on it. Plenty of tutorials about this.
Submit an update to your app that sends the user's UUID to your server.
Wait. This is the hardest part. You'll need to wait until satisfactory majority has updated to your app. That majority percentage is up to you to figure out. It could take months for this to happen.
Make your new, free, app send the UUID to the server.
Check to see if the UUID is in the DB.
If it is, set whatever you would have set when an in-app purchase was made to true.
You have several options:
Free in-app purchase for a limited time:
You would create a free tier in-app purchase content and release an update that somehow makes the user sign up for it. This way, when your user switches devices they can restore the purchase and regain the functionality.
Wait for a period so most people use the in-app purchase content
Change the tiers and release your app as free
Dual versions
Make a demo version of your app. Note this can be rejected by Apple.
Create a file in the filesystem
Make a file in the filesystem and save into iCloud. The app will check for the file and thats how you would determine if the user has paid for the app (or should buy the in-app purchase).
iCloud will synchronise the file between user's devices and it will make sure that whatever device the user uses the app will see the user as 'paid'.
I hope this helps, currently having this problem myself.
I have a magazine app, and I want to provide users a one year auto-renewable subscription, and for non-subscribed users, they can use non-consumable IAPs to pay for each issue and then download it. What is the best way to implement it?
For auto-renewable subscription I don't think it's a problem. I can follow the tutorial at http://www.viggiosoft.com/blog/blog/2011/10/29/at-newsstand-and-subscriptions/ to finish this part. But for the non-consumable IAP part, I'm not sure. Do I need to add all the non-consumable IAPs for future issues before I submit the app? If I do this, how could Apple review my IAPs, because the future issues are not prepared at the reviewing time. Or, can I add non-consumable IAPs after my app is published to the App store? For example, every time when a new issue is ready in our server, we add a new non-soncumable IAP in iTC, and also set the product id to the issue in the server. When the non-subscribed user click that issue, the purchase for the specified product id will start. Is it possible?
After some research I found that the best way to implement it is to set up a new non-consumable IAP at each time when you want to publish a new issue.
The only problem is that, each IAP needs to be submitted for review, and before it is approved, the users who try to buy the issue will get an error message: "Cannot connect to the iTunes store". I haven't figured out how to know that the IAP is in review, so I can popup a nicer message like "Issue is review, please wait" other than a confusing error message.
I have a magazine app, and I want to provide users a one year
auto-renewable subscription, and for non-subscribed users, they can
use non-consumable IAPs to pay for each issue and then download it.
What is the best way to implement it?
You should accept your solution, but here is another case, maybe it helps you or others:
The subscribers can have they magazines, which are not in at iTunes Server, but at your hosting. Those magazines not need to bypass the apple review.
It depends whether you want a user to be able to permanently have a record stored in their app receipt of the issues they have bought. You might want this, if you want a user to be able to delete the app, with all associated content, then later re-install the app, and be able to download the specific back issues they purchased previously—all without having any user account on your own server. The use of a non-consumable in-app purchase also enables you to give them access to these issues across multiple devices that are signed in to that Apple ID, again without having to run your own user account-server combination to track purchased issues.
If these features don't matter to you, then there is a solution you could consider that is much simpler where you don't have to keep creating new in-app purchase products. Have a consumable in-app purchase product that is called something like Purchase One Issue. When a person buys this product, they get one credit and they can use this to select the issue they wish to be given access to. Your app then gives them access to that issue. You could also of course reverse this process in the UX: they pick the issue, click buy, you send them into the purchase process for the Purchase One Issue product, and you automatically give them access to the selected issue since they already selected it.
Note: consumable in-app purchases are not stored in the app receipt, so a user couldn't use this approach to 'restore previous purchases'. In scenarios where this is acceptable however, this is a much less labour intensive approach once set up.
I've read all the in-app documentation and I've tired of fighting with App Review Board, that's why I'm asking for your advice.
Please, help me to choose the right type of in-app purchase for my app and to upgrade my app to use a subscription in-app model (non-renewing subscription is also possible).
This app has an entertaiment text and photo content, which is dynamicaly updated twice a day.
I've got a free version, which has:
Ads
Limitations (limited number of new messages)
No photos
And premium-account with:
No ads
No limitations
Photo content
I want to sell this content like subscription (you can buy a premium-account for a period of time), also I've get a mechanism, that allows to use premium-account from every device you have and you can restore your purchases easily, but App Review Board writes:
The App Review Board evaluated your app and determined that the
original rejection feedback is valid. Your app does not comply with:
11.15
The Purchasability Type for one or more of your In-App Purchase
products was inappropriately set.
Your In-App Purchase is currently flagged as Auto-Renewable
Subscription. However, it would be more appropriate to use the
Non-Consumable In-App Purchase type because the product is used to
unlock features of the app. Non-consumable products are only purchased
once by users and are always available on all devices that are
associated with that user's iTunes account.
How should I change my app to sell my content as subscription?
I am implementing a digital magazine project for a client. Auto-renewable subscriptions for a period of 3/6/12 months have been included as a feature. My question is while using in-app purchase, is there any way for the server to map the user?? Anyway to identify a particular user is using it? I have done extensive research and know that apple doesn't allow the user's apple-id to be mapped?? Is there any other way to identify a particular user?
The problem arises for subscription. If an user has undertaken a subscription for let's say 3 months, then my app has to show DOWNLOAD button for all the 3 months instead of the regular BUY button. But when a new magazine is launched on to the storefront, how would the app know that this person is subscribed or not and convert the BUY to DOWNLOAD?
When a user buys a subscription, you should store the receipt on your server. This receipt, in a way, becomes your way to identify the user's account. Whenever you want to check the status of an account, send that receipt to iTunes for verification and it'll respond with the latest receipt for that subscription, along with the expiration date. Since you've made a note of which specific device that receipt came from, you can provide the proper UI to that user.
Now, if the user installs your app on a new device they can tap a Restore button that you've provided in your app. That button will call restoreCompletedTransactions which will send all the Auto-Renewing receipts for that user's Apple ID to the device.