I want to share In-App purchased product identifiers from one app(say "App1") to another app(say "App2"). Both run on iOS 7 devices. And more importantly since "App2" was released long time back, both the apps have different Team IDs. When the user clicks on a "Restore purchase from App1" button I want "App2" to unlock certain features based on the purchases the user has made in "App1". What is the best way to achieve this?
I dont want to use UIDocumentInteractionController or UIActivityViewController because that would require unnecessary user interaction.
Key chain items or iCloud key-value storage cannot be shared because both the apps have different Team IDs.
Can't use an exclusive server through which the two apps can communicate.
You cannot do this by using the IAP API. You could store the information on your server and unlock it for a user, however, this is against the App Store Review Guidelines:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected.
And technically you would not be using the API if you checked against your own server and provided the content through that.
Now this looks possible for subscriptions with App Bundles: https://developer.apple.com/documentation/storekit/in-app_purchase/offering_a_subscription_across_multiple_apps
You can offer customers auto-renewable subscription services that are accessible through multiple apps across one or more operating systems.
In order to offer this functionality, your server must grant access to the subscription content across all apps, despite the user having purchased the subscription within a specific app. You can use a unified account management database along with server-side receipt validation to validate a user's purchase and ensure in-app transactions are handled. By entitling subscription access from your server, you can provide users the ability to access your subscription across multiple apps.
It's Possible using Authentication API
step 1: When purchased product successfully to store status inside API
step 2: Then call API every time of didFinishLaunching to check purchase status and use multiple APP
Another benefit is make payment without any payment gateway...
Related
Currently I'm working on an app for a social network, where users have to purchase premium membership to unlock some extra features.
At first I used auto-renewable subscriptions, but my app got rejected. They told me to use non-renewable subscriptions and:
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
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
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
The most logical way to transfer subscriptions in my case would be by using registration, as user can't view the content (or purchase subscriptions) without registering and logging in. So this means that registration is required.
Will my app get rejected again? If yes, then what workaround would you suggest?
Any help would be greatly appreciated.
Yes and No.
If you force your user to register (especially with email address) =
REJECTED
If you make registration optional and let the user to use your app
with limited access = APPROVED
(The above statement was from my own experience and understanding. Please correct me if I'm wrong.)
First my app got rejected for using auto-renewable subscriptions.
But second time my app got rejected (this time non-renewable). The reason is, my app requires user registration. In apple's term, 'requires' means 'force'.
If you choose to use user registration to meet this requirement,
please keep in mind that it is not appropriate to require user
registration. Such user registration must be made optional. It would
be appropriate to make it clear to the user that only by registering
will they be able to access the content from all of their iOS devices;
and to provide them a way to register later, if they wish to access
the content on their other iOS devices at a future time.
From the above, the highlighted lines makes it clear that, the user registrations MUST be optional. If the user wish to access on other iOS devices, they can choose to register. But there is a catch again.
The catch is,
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
So what I'm going to do is,
I would let the user to buy subscriptions without registration. But I will auto register the user with the unique ID to identify the user later. And showing the user, that, they have to register with an username and password in order to access the subscription among other iOS devices.
I would not force the user to register with email address. Instead, I will use 'username' as mandatory and 'email' as optional, but stating that, it's recommended to enter the 'email' so that, it would be easier in case of password recovery.
This is my experience with apple's in-app purchase so far.
Please correct me if I was wrong any where...
Auto-renewing subscriptions are only for periodical content like magazines, newspapers, etc that appear in the newsstand app. Apple will flat out reject any use of Auto-renewing for any other purpose. You have to use Non-renewing Subscriptions for "Services". Best info for this is http://developer.apple.com/news/pdf/in_app_purchase.pdf
As for the user registration chicken-and-egg scenario, you can get the app approved if it allows registration of anybody regardless of in-app purchases. That is to say, only allow the IAP after the user has registered. Your "Free" users can just have limited content.
I don't think that Apple would reject an app just for requiring registration, unless that registration's sole purpose was to allow a user to share their subscription across all their devices. In that case, Apple insists that you provide an optional method for the user to share the subscription.
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 am working on a application which has a more peculiar requirement. Basically it is something which is not targeted at end users but at a system integrator who will embed an iPad into a larger system and sell it to an end user as a whole.
However, the problem I'm facing is that the system integrators could simply purchase the app once and then keep cloning thousands of iPads from a single iTunes account, my company would not get any revenue from this.
Is there any way around this. I've looked at in app purchases but according to the guidelines I'm supposed to give in app purchase restore functionality so I guess if I don't the app won't get approved.
I could use external authentication servers I guess, but that may be viewed as circumventing the app store.
I've loked at the volume B2B stuff but I'm not quite clear on how that works or if it would help me in this case.
Any ideas?
Thanks
Last time I checked an application can only be installed on five devices, and then the other ones simply refuse to install the application.
If this system integrator managed to circumvent this, it's he who is breaking the App Store rules.
You can't use the App Store mechanisms as you described (you can't change iTunes). In-App purchases of non-consumable items must include a restore option so the user can restore it on all his devices even if it's thousands (this also for subscriptions etc). If you won't enable that you would be rejected.
You can think you can send the Device-ID for each device that purchase the item and have control over that(or any information) but apple would simply reject your app because it's forbidden to send device-ID.
If your service is online you can simply use some kind of tokens created on your servers which would be given to each client (from some kind of private key), This way you must be connected to each purchased item (only those would contact your servers and you would grant access).
Security wise you must consider leaving some of the functionality on your server side. This is not illegal same as you can't access Facebook without username& password.
And now for the easy way, Define your service as consumable item for in-App purchase(if you can). What does it mean? Lets say you are selling a special feature like "Ad-Free" you can sell credits that would be consumed with each app open or any other process you have in mind, You can even set this credit to 1 million for 0.99$ (so the user never gets to that) but still the consumer would have to buy it again and again for each device and it would be absolutely legal by Apple. Pay attention that the problem would be on the consumer side such as that if user have deleted his app you should find a way to help him or refund him on next buy. Also, If you can and would use this method pay attention to save those credits on the restored folder on the device, so if the user would upgrade or restore the device he would still have the credits he bought.
Pay attention that if you are going to use in-App there are lots of methods to steal this content on jailbroken devices and you must use your own server to check the buying process (according to Apple).
Another important thing is that the app without the in-App purchase must have some value to the user.
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.
I'm developing an iOS game where the users can buy some amount of internal currency (say 1000 golds) by a Consumable In App Purchase.
How to restore a Consumable Purchase if the users want to transfer their balance from one device to another?
In Apple's docs it says that we have to use our own server. But how to get user's Apple IDs? Or may be there is some other way to track consumable purchases?
If what you want to do is to share the products the user buys across different devices; you will need to:
Keep the game state in the server and obtain it from the device.
Identify users somehow, i.e. username/pass.
Update the game state in the server each time the user buys/consumes/gains products
If you only need to share state across different installs on the same device, you could just use the device ID to identify the user.
You will need to be able to store the users state in a manner independent of the device they are using to access your game. So this would mean implementing a server based user profile with authentication (and appropriate security), or using some third party service.
Note that since iOS 4.1 you have the ability to use GameKit, which provides alot of these benefits for you. If you use GameKit then you will be able to retrieve user information from GKPlayer, and use this information to store currency amounts and other state in your own server.