I need to create purchase system that allows user to use part of app for limited time (1 month), optimally with auto-renewal. My app is non-newsstand app.
Is there any possibility to accomplish this with auto-renewable/non-renewable subscription or should I use Consumable?
For better understanding, what I want to accomplish:
Lets say I have Facebook app. User want to search for another users, so he buys searching option for 1 month. Week later he want to put more than 10 photos so he buys another option. At this point he have 2 functionally independent options with different end time.
Yes. Set different product identifiers for each functionality you are offering. To those product identifiers based on the way you are offering give it auto-renewable/non-Consumable. You cannot use two options combined. You have to chose based on your requirement.
Related
I have an App with 2 different Modes.I want each Mode to have it's own store for In-App purchases.I'm having a hard time find any policy information or info about having more than one In-App store inside the same App (that could be because it's not a problem at all).
If it's not okay to have "2" stores, would it be okay to have them be the same store and then just filter out the ones that shouldn't be available in that particular Mode?
Simply use the mode to select which of two different sets of in-app purchases are shown to the user. You are free to show or hide in-app purchases as you like, however be clear to the user about any previous purchases!
You can show what ever you want in your shop, but all users should be able in a way or another to buy the same product otherwise it can be seen as discrimination in some countries and it's illegal.
If the in-app purchases are clear functionalities of one mode and the user choses which mode he uses then I don't think there is a problem. But if you force assign a mode to a specific user without him knowing or being able to do anything about then you can have problems, especially if the functionalities are different.
And for example, I worked for some companies which use tiers for consumable (if you already purchased the cheap package, the more expensive one are shown) and this was a problem of discrimination. The solution was allowing any customer to contact support to get access to lower (or higher) tiers. Then even if it's not in the shop they have the possibility to buy the IAP if they want to.
I'm walking through In App guide and trying to figure out how to deal with buying multiple products. Let's say I have 3 features available to buy via IAP and I want to have option to select which ones user is willing to buy, then buy all selected at once. Should I create only 3 products (for each feature) or should I create one product for each possible combination of available features (like: A, B, C, A+B, A+C, A+B+C...) ? I tried to google it, but I have nothing so far, not sure if I'm asking good question or what. Can anyone direct me somewhere, some tutorial or advice?
The In App Purchase SDK present only the paymentWithProduct: method which enable only one product as parameter. You may only set the quantity to be more than 1.
If you want to propose package of In-App you should register them as separate In-App on itunesConnect and propose them in your app. But if you don't set a price different than the sum of the separate products, I don't see a real advantage to the user.
From my understanding, Windows Phone now allows in-app purchases. I would like to empower my users to signup for one-of-three subscription levels within my app. However, I do not understand how to enable this type of scenario. I see the option to add an "In-app product". However, in my case, I'm not sure of the following:
Am I offering one product or three separate products (one for each subscription level).
I don't understand the "Product Identifier" is this an identifier for the subscription or the identifier of my app? If its the former, shouldn't I just toss a GUID in here?
Thank you,
It may be worth taking a look at the overview on MSDN - your product identifier is the one you submit (as a person) via the development dashboard - it's also the one that your app can enumerate to see the list of available products, and the product id you'd use to purchase.
As far as I'm aware, you cannot have products that are (for example) £10 per month though - of course you could do something like have bundles on a pricing structure that exchange for something within your app, maybe £5 for 5 music downloads, £9 for 10 etc. rather than "a £10 per month for unlimited" (difficult to give a generic example though)
Consider following example. Let's say we have an app in which professional writers write stories from a web based UI. And then these stories become available for user of the iOS app as in app purchase items.
As you may know we need to create in app purchase products in advance. But in our situations it means that for each of the story created by the writers we will have to create a new IAP product and wait for Apple to approve it.
To circumvent this, I am planning to create generic "consumable" products in IAP like story worth $1.99, story worth $2.99, so on, so forth. Then in the Application UI I will show the list of stories of created by the writers and show corresponding prices for the stories as specified by the authors when they created the story. Once the user taps on the buy button, I will show the purchase for the generic consumable product of the same price and complete the in app purchase process.
Now the question is will Apple approve of such implementation? Does it fit with their IAP policy? I am asking as I couldn't find a guideline for a workflow such as this.
Another approach to implement this is by implementing an in app credit/currency system, like games use. Where people buy credits/coins and then they purchase items with coins. This is a tried and tested approach but it doesn't fit in my analogy of the app, hence the question.
What you want to achieve is perfectly feasible, the only thing is your purchasable content has to be dynamic. You will have to download the product IDs from a server rather than having them hardcoded in your app.
To refer to your example, I can imagine a table view being fed with a list of objects that would have the SKProduct ID stored on them. You would have to do this because, at the time of writing, you can't retrieve all the available product IDs for your app from Apple servers. I know it's a pain in the ass they didn't implement this feature but to be honest, if they haven't already I don't think they will ever do.
This is the method I'm referring to: initWithProductIdentifiers
You provide it with a NSSet with all the identifiers you want to retrieve, but if you provide an empty set or a nil, it doesn't reply with all the existing. You can file a bug with a Apple if you feel this doesn't work as it should. Please check this SO answer if you still have any doubts: link
Another important thing to note is, you will have to upload your products manually. Apple doesn't expose any API in order to have the process automated. This means, every time a writer uploaded something to your server, you would have to log in into iTunes connect and create a product. Plus, you would be limited to 10,000 products because that's the maximum amount of different products you can register with Apple. I'd also recommend you to have a quick read to the iTunes Connect guide, which has some important information like the one I just mentioned: iTunes Connect
Regarding 3rd party frameworks, like the aforementioned UrbanAirship, they will just save you from having to implement receipt validation on your servers. Apart from that, I don't see any major advantages.
Said this, I'd recommend you to reconsider your business model. Is it really worth it all the hassle of uploading the products one per one? Or is it better to go the subscription way, in which your users pay a fixed amount of money for downloading a number of articles per month. You could have different tiers, like, basic, premium (unlimited downloads) an so on and control the delivery of the articles from your servers. That's up to you, but for me the answer is pretty clear.
Pritam
For delivery dynamic content you should be using a Subscription, not a consumable. Using a subscription solves your problem by allowing you to charge for each update AND distribute new content at the same time.
You can looking into 3rd party services like UrbanAirship that will significantly reduce the amount of time you spend trying to dynamically deliver your content, track subscriptions and expirations, etc.
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,