I have an app in the Apple app-store where some extra features are offered through a couple of one time in-app purchases. I want to transfer that to a subscription model. To make it more acceptable for those who already bought the old IAP I want to give them the first year free. However, I have problems implementing this.
Alternative 1:
Create an "Introductory offer" (one year free) for the new subscribed IAP. But I can't see a way to control who gets that offer, which means all new buyers will benefit from it.
Alternative 2:
Create a "Promotional offer". But that is only meant for getting old subscribers back. So there is no way for a new buyer to use that offer (I think).
Alternative 3:
Create two completely different IAP, one with an introductory offer and one without. That would work, but is a clunky solution that I want to avoid.
Are there any other alternatives?
You are not allowed to change someone who bought an IAP with no expiry date to a subscription. Doing this will likely lead to Apple intervening and unlisting your app.
They bought your IAP with the understanding it was an eternal licence. You can only bill NEW customers on a subscription.
You’ll need to keep record of those who purchased the IAP and new customers who purchase a subscription.
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
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.
In my app, I would like users to buy a subscription for Backup, Sync, and more.
so I found out that Apple offer two kinds of subscription IAP:
Non Renewable Subscription
Auto Renewable Subscription
which should I use, given that I don't have a server, and I rely on iCloud for the sync?
Auto-renewable in-app purchase are allowed only if your app provide new content each time (or often) the user pays. (like provide new magazine, video...)
If your purpose is to do a premium subscription which give access to so premium functions (so no logic of periodical new content), Apple will reject your app.
You will find much more explanations on the subject here: The limited world of auto-renewable subscriptions
I don't know much about this, but I think it is quite difficult to get Apple to accept an auto-renewable subscription for anything but Newsstand apps. For other use cases, I think they prefer you to adopt the non-renewable subscription.
You could also consider a one time payment to 'unlock' the feature, rather than a subscription, since you aren't actually paying any ongoing costs (e.g. storing data).
I'm building an app that will provide users with an evolving directory of companies in their local area (location-based) that manufacture green/sustainable products. I want companies to be able to add themselves to the app by purchasing a subscription using in-app purchase. This would be a 1 year subscription.
Just read this in the iOS Standard Agreement: 2.3 Content and services may be offered through the In-App Purchase API on a subscription basis (e.g., subscriptions to newspapers and magazines). Rentals of content, services or functionality through the In-App Purchase API are not allowed (e.g., use of particular content may not be restricted to a pre-determined, limited period of time).
If the service is only for a year, does this preclude me from doing the above? Anybody have any insight on any of this? I'd appreciate your input - I can't get any info from Apple. Thanks.
My guess is that you are not allowed to do that. As you really cannot restrict who subscribes for a year – it might be any user – you probably cannot offer this. The IAP doesn't provide any content or service to the user other that a listing. As you probably need an external data source (e.g. a web application) I would suggest moving the subscription there. This is just my opinion and I am no lawyer so I might be completely wrong here.
You can do it. See the image below. You just have to choose the right option.
You can find it itunesConnect in the app detail section.
For your case I suggest Consumable is appropriate and have to maintain a check that wether its been a year or not since the last magazine purchase or what so ever your scenario is.
I'm about to take my first foray into In-App purchases, and I'm not quite sure how to handle my situation. At top is my situation, with some actual questions in bold at the bottom. Any advice would be appreciated.
I'm designing an app that will have a LOT of in-app purchase content. Every day, around 20 or 30 new items will be generated for sale. 3 or 4 days worth of items will be for sale at any given time, and after that they go away.
So we're talking a lot of items. Way too many to add to submit to Apple for a unique ProductID each day.
Of all these hundred items, there are actually only 4 or 5 different types of item. So I'm thinking I'll need to make 1 SKProduct for each type. Under the hood (and invisible to the user) the will actually be buying a credit good for 1 item of type X. After the transaction goes through, I send the receipt AND the requested item to our server. Our server stores that and sends the file back. If they want a 2nd file, they need to buy a 2nd credit and repeat the process. Of course to the user it will be presented like they're buying Item 1, Item 2, and Item 3 directly.
To make this even more complicated, we also want to offer a 3 month subscription (at a significantly higher tier) for those who don't want to buy their items ala carte.
1. Does this sound like a good approach?
Will Apple be okay with this? If not, what possible alternatives do I have?
2. Optimally we'd like to allow people to re-download items they've already paid for.
Would a good approach be to make each credit non-consumable, and since I've already stored the receipt info on the server I can match it to whatever item they should get? If this is too complicated or against Apple's rules, we may just make the item consumable since the item is only good for a few days anyway...
3. Is there anything else I'm overlooking here?
Thanks for any insight you guys can provide.
Take a look about what the iOS Development Program License Agreement says about treating In App Purchases like credits:
2.1 You may not use the In App Purchase API to enable an end-user to set up a pre-paid account to be used for subsequent purchases of
content, functionality, or services, or otherwise create balances or
credits that end-users can redeem or use to make purchases at a later
time.
2.2 You may not enable end-users to purchase Currency of any kind through the In App
Purchase API, including but not limited to any Currency for exchange,
gifting, redemption, transfer, trading or use in purchasing or
obtaining anything within or outside of Your Application. “Currency”
means any form of currency, points, credits, resources, content or
other items or units recognized by a group of individuals or entities
as representing a particular value and that can be transferred or
circulated as a medium of exchange.
Correct me if I'm wrong, but if your approach does not unlock/add functionality or change the behavior of the app by buying an In App Purchase, my guess is that this could be problematic when trying to get Apple's approval.
Hope this helps,