In-App Purchases: Products vs Tiers

First, you don't need a different product for each country. You can localize the description. Second, yes, you can have only one 'product' at each price point and let the app describe the product. But then you lose some flexibility in being able to change the price of a product. You could have your app reference your website to get the description if that is an issue.

Hi,

thank you for the response.

Well, our idea is that the server-side will return the "product-ids" for each real product, so we will be able to control/change the pricing in real-time.

So, for example:

Real product name(s): "UK Regular 1month v1" and "Canada Regular 3months v1"

Both are priced the same: Tier 1 according to Apple.

We would like to create the following product in iTunes Connect: "tier1product" ( and we hope Apple Review will accept it ).

Then our server will return the information to the app like this:

{

products: [

{

"name": "UK Regular 1month v1",

"appleProduct": "tier1product"

},

{

"name": "Canada Regular 3months v1",

"appleProduct": "tier1product"

}

]

}

As you can see, our app knows how much each real product should cost ( or with what Tier it's associated ).

The question is: as far as I understand, this goes against the "default" Apple's Policy regarding the In-App Purchases.

Apple wants us to name the products in iTunes Connect like "uk_regular_1month_v1" ( with the Tier 1 associated with this product ) and like "canada_regular_3months_v1" ( with the Tier 1 associated with this product as well ).

Do you think Apple is OK if we create products like: "tier1product", "tier2product" ..... "tierNproduct"?

Best Regards,

Maks

Yes but...you have 2 different systems trying to define the same information. There will be conflicts.

Keep in mind that this will be the 'flow' for the user:

1) The user does something that expresses an interest in making a purchase (e.g. tap "Yes I want to subscribe")

2) the app gets information from the App Store (purchaseRequest) and from your website. The purchaseRequest returns to the app the fact that there is a 'tier1Product" and a 'tier2Product' available on the App Store for the app to purchase for, it believes, $1.99 and $2.99 in the country of the App Store that the user is registered. Your website recognizes that the user is currently in Uzbeckistan and therefore it thinks the 'tier1Product' will cost 4 drachmas and the tier2Product will cost 5 drachmas. Your app says "A One Month Uzbeckistan Subscription is available for 4 drachmas and a 2 month premium subscription is available for 5 drachmas."

3) the user selects one of the options you presented based on your app's interpretation, in context, of the website data

4) the app goes to the App Store to execute the purchase of the product

5) (HERE'S THE RUB...) the App Store asks the suer "Do you want to purchase one tier1Product for $1.99" - The user says 'no, I want to purchase a One Month Subscription like the app just offered and for 4 drachmas. What is a 'tier1Product? Why is it $1.99?

>I understand Apple's Guidelines it goes against them

That is my understanding as well.

Apple tends to discourage listing/showing prices on our own and you seem close to doing that which risks rejection by review. As well, users self-segregate themselves into their own home stores, so there is no need for you to operate at that level w/pricing...just localize as needed and let the store do the rest.

Hmm, don't think you got me right.

My server-side / web-site just providing product ids ( tier1Product, tier2Product ) based on the real product user wants to buy.

The prices will still come from the Apple Store.

Example:

Lets assume we have 2 UK real products "UK Regular 1month v1" and "UK Regular 3month v1". For the first we will be using tier1Product ( because it costs Tier 1 ) and second tier2Product ( because it costs Tier 2 ).

Lets also assume we have 2 Canadian real products "Canda Regular 1 month v1" and "Canada Regular 3 month v2". For the first we will be using tier1Product and for second tier3Product.

Then user ( doesn't matter where he is ) selects the country UK, server-side returns him data like:

{

products: [

{

"name": "UK Regular 1month v1",

"appleProduct": "tier1product"

},

{

"name": "UK Regular 3month v1",

"appleProduct": "tier2product"

}

]

}

And mobile app shows two products from UK with the prices taken from the App Store for tier1Product and tier2Product. And now yes - App Store will return prices based on user's country, it's OK for us.

If user selects the country Canada, server-side returns him data like:

{

products: [

{

"name": "Canada Regular 1month v1",

"appleProduct": "tier1product"

},

{

"name": "Canada Regular 3month v1",

"appleProduct": "tier3product"

}

]

}

And mobile app shows two products from Canada with the prices taken from the App Store for tier1Product and tier3Product. And now yes - App Store will return prices based on user's country, it's OK for us.

So, prices will still come from the App Store.

What do you think?

Ok, then yes it can be done but you have to make sure that the UIAlert that the App Store will present to the user to makes sense. Apple will display "Do you want to purchase 1 __________ subscription for $1.99?" . In some cases you want Apple to fill in "Canada Regular 3 month v1" and in other cases you want Apple to fill in "UK Regular 2 month v1". And as you describe above in both cases Apple will fill in the unusual (to the user) "tier2Product". So you need a name like "Level 2 Product" for that tier2Product. Other than this, it will work fine.

We will put our app name there. In this case the phrase will be meaningful to the user.

The question is, if apple will accept such a thing..

Change the name so they are different. "Do you want to purchase 1 .....Level 3 SuperDevStaticApp....subscription?"

Will Apple approve it???? No one can tell you; but why wouldn't they? After all, it will look perfectly reasonable when tested by App Review won't it?

I just realized there is another matter you need to handle here - you need to allow the user to copy the purchase from one device to another device owned by the same user. In your case you will need to transfer not the IAP product itself but the projection of that purchase onto your set of alternatives on your website. That shouldn't be very hard in your case but it an extra wrinkle that App Review may review.