I'm testing an in-app purchase and have been jumping between the French, UK and Australian app stores to do so. I know it's a edge case but I'd like to be able to update the price of the purchase on the screen when the user changes stores as I have been. Is there a notification for this or do I have to poll the product's priceLocal property?
You shouldn't hard code the prices anyway. Use the products local price.
If apple changed the price tiers, or exchange rates changed dramatically and apple changed a locale price, then your app would have the wrong prices in it.
It should be possible to register an observer on the property as on all other properties with addObserver:forKeyPath:.
Related
As you iOS devs know, you can only set one price tier for your app and in-app products in the app store. However, you can (theoretically) publish it as separate apps in different countries with different prices. I would like to do the same with in-app products of the same app - define alternative in-app products, and control their visibility in the app depending on user's country. I don't want to use NSLocale or NSTimeZone because they can be changed in settings. I want to know the country that the app store / user is connected to.
For example, I want to offer an auto-renewing subscription for most users, but I know that auto-renewing subscriptions are not available in the Israeli app store, so I want to show a non-renewing subscription exclusively to Israeli users, and not show them the auto-renewing one. Is there a reliable way of achieving this?
Thanks,
Avi
After investigating further, I discovered that when querying products in store-kit, SKProduct returns with a property named priceLocale, which consists of the country code and currency code. The country code of priceLocale seems to be consistent with the user's app store.
To sum up, doing these steps will get the result, however in a slow and not straightforward way:
Define an in-app item;
Query that item in your app;
Determine user's country according to [product.priceLocale objectForKey:NSLocaleCountryCode];
Show the user the relevant products your app supports in their country.
I have an Iphone application in which i am trying to implement non renewable subscription.I had done it a manner that after the purchase i am adding that details to user account information.so he can get it on all the devices.I have a login at the start of my application.And after associating the reciept data with the user account i was finding out the expiry date in my server from the purchase date in the reciept data, by using that information i was showing the buy button again to my user.But the apple is rejecting it for the reasons
11.6: Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
Can anybody know the exact mechanism to implement nonrenewable subscriptions ?
From your description it sounds like your login when they start your app is mandatory. Apple forbids this. They insist that the login be optional, but it must still be available to everyone who wants to use it (when using non-renewing subscriptions).
What I did on my app was, next to where I show the user's purchased subscription level, I have a button that says Save your account.... And when they click it it describes to them how, if they create an e-mail and password than they can share their subscription across all their devices and they can restore their account if their iPhone gets lost or stolen. You want to incentivize the user to do this because a better experience for them means a better experience for you. You could even offer them a perk, like 2-weeks free if they create an account. And since you're using non-renewing subscriptions, you have the power to do this since you're calculating your own expiration date, instead of letting the app store do it for you.
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.
After a user purchases an app from the app store, and runs it, is it possible for the app to know how much the user paid for it? Does Apple have any APIs that can access this type of metadata about the actual purchase of an app?
If not, I suppose I could fall back to looking up the country of the user, doing currency conversion rates, and then lookup the price of the app at the time of purchase. That's another thing, is it even possible to know when a user has purchased an app? They could purchase an app, and then not run it for days or weeks, so I cannot assume the date they first launch the app was also the date of purchase.
Any thoughts on how to obtain this information?
This isn't possible through any kind of API. What you can do is have the device send data back to your server on first launch with location and date. This way, you can mark them in your DB as xx paid yy on this date. You know what yy is currently because you run the server and the app page. Make this info accessible somehow on your server, and when you need it in the app, call your servers method to retrieve it.
I am looking into the iPhone in app purchased models and need to implement a subscription. Ex content will be available for 24 hours. Now the most important thing is that it needs to be available on all the other devices, so bought on the iPhone, viewable on the iPad. I'm not sure how this works ? I need to store some information on the developer server but is this the transaction id and current date/time so when launching the app on the iPad, you will attempt to buy the content again. Apple will see that this user already bought that and hopefully returns the transaction ID. At that moment I can verify if the time limit it still valid or not.
Can anyone confirm this method off working?
If this is correct is there a 'renew'?
Correct me if I am wrong.
You just need to store the "receipt-data", don't need to store transaction id and current date/time. Obviously you have to create the kind of product as "subscriptions", this will ensure that the purchased product is shared on all user's devices.
How to verify a receipt with the AppStore.