As the documentation says:
queryPurchaseHistoryAsync():
Returns the most recent purchase made by the user for each SKU, even if that purchase is expired, canceled, or consumed.
So lets say I would like to make an IAP for the user to remove Ads forever from my app.
How do I decide with a fresh install if that user already purchased that IAP if this function also returns the "canceled" IAPS?
I would like to query the actually purchased IAPS, not everything. Becuase that way a user could unlock the Ad free version with a cancelled IAP.
To make it worse, the Purchase class doesn't have status like "cancelled" or "consumed" I cannot decide the state of the user's purchased IAPS.
Am I missing something here?
Thanks in advance
The billing client documentation states it checks for the user.
Then we have the question: Who is the user
If you look at the steps taken for the billing api on https://developer.android.com/google/play/billing/billing_library_overview then you see that a connection to google play is needed.
What happens then is that the current user on android, the account they are signed in with on google play and their mobile device is determined to be the user.
So if they purchased it via google play in app, it will always be assigned to that user on google play and that is what's being queried by this. No matter on which device they are logged in, Their tablet, smartwatch, phone, television, etc...
How to get a list of actually bought products
Instead of using async that gives you everything included abandoned shopping carts I suggest you use https://developer.android.com/reference/com/android/billingclient/api/BillingClient#querypurchases
That way Get purchases details for all the items actually bought and paid within your app. This method uses a cache of Google Play Store app without initiating a network request.
Note: It's recommended for security purposes to go through purchases
verification on your backend (if you have one) by calling the
following API:
https://developers.google.com/android-publisher/api-ref/purchases/products/get
If you read that API link it's easy to check with the online cache if the purchase was valid with a simple GET request.
Personally I would build in a check if the phone is suspect to be rooted before doing the manual background check with the purchases API that sends a request to the store.
Phones that are not rooted have a higher trust level, as the user are probaly not very tech savvy and will not have a shimmer of a clue how to circumvent such checks, and the google play cache will be updated regularly, reflecting trustworthy data.
When a phone is suspect to be rooted(you can read protected directories/write to them), then perform the check online if they bought the stuff each time you deem it neccesary.
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'm working on an app that will provide data from a web server to users but only if they've bought an in app purchase subscription. I understand the basics of IAPs but how do I securely make sure the data from the server is only accessible to the app, and only if the subscription has been purchased? I don't want to make the user set up an account, I just want to auth the app/purchase securely.
Thanks in advance :)
I'm going to use subscription model too with IAP.
AFAIK, you SHOULD NOT use a unique phone identifier like the IMEI of the phone to identify the user on your server. According to the Apple documentation, you MUST provide a way so that an user can restore his subscriptions on several devices!
Besides, a call to restoreCompletedTransactions of the SKPaymentQueue will restore ONLY nonconsumable products! Subscriptions are not supported by this method.
See these links :
http://developer.apple.com/library/ios/#technotes/tn2009/tn2259.html (section « Frequently Asked Questions », point 10)
iPhone - How to recognize the iTunes user of my app
The only way I know is to use a login/password to identify the user on the web server but this could be quite ugly...
However, if someone know another way, could he describe his solution ?
You should upload store receipts to your server, to be able to check them on Apple's site. And, with request you should upload phone identifier. And, of course, store somewhere in the database. After all, you will have information about which phone id has access to subscription.
And, when you will request subscription-related info from your server, you'll be able to check who has acces (via phone id) and who hasn't.
My team and I have an app which we're going to be submitting to the store pretty soon, but we know that we'll be selling the app to another company in the near future. Does anyone have any experience with moving an app's ownership to another account?
Specifically, when I sell an app to another company...
How do we move the app to their account (what's the mechanism)?
Can my users still get updates (released by the new owner) without having to re-buy/re-download the app?
Starting June 11, 2013 this has officially become possible.
Here's the official note:
Dear developer,
Apps can now be transferred from one developer to another within iTunes Connect, for example after an acquisition or when a distribution deal expires. Transferring the ownership of an app does not affect the app’s availability on the App Store. All ratings and reviews will be transferred and your customers will continue to have access to all available app updates.
To transfer an app, go to the app’s App Summary page in the Manage Your Applications module on iTunes Connect and click Transfer App. Make sure that:
• Your account is active
• You have accepted the most current version of your contracts
• Your app has at least one approved version
• Your app is in the Ready for Sale, Invalid Binary, Rejected, Developer Rejected, or Developer Removed from Sale state
• Any associated In-App Purchases are in the Ready to Submit, Ready for Sale, Rejected, Developer Removed from Sale, or Approved state
• You know the Apple ID of the recipient’s Team Agent and their Team ID.
For more information on app transfer, see the video tutorial on iTunes Connect. To find answers to common questions about app transfer, see the FAQ on iTunes Connect.
Regards,
The App Store team
UPDATE: THIS ANSWER IS OUT OF DATE. IT APPEARS TO HAVE BEEN CORRECT AT THE TIME IT WAS WRITTEN. THERE IS NO NEED TO DOWNVOTE IT, BUT DON'T BELIEVE IT EITHER!
Official answer is No. From the iTunes Connect FAQ:
I sold my app to another developer and can no longer distribute on the
App Store. Can I transfer the app to
the new developer's iTunes Connect
account?
At this time, apps cannot be
transferred to another developer
account. If you would like the app to
be sold through another developer
account, you will need to remove the
app from sale in the current iTunes
Connect account and upload the app
under the new iTunes Connect account.
Uploading the app to a new iTunes
Connect account will disable current
customers from receiving automatic and
free updates of your application. All
customer reviews, rating and ranking
information will also be reset.
Additional resources that confirm this, from FutureTap developer Ortwin Gentz, back when he purchased WhereTo? from Sophiestication Software:
transferring an iphone app last episode
carved in stone transferring an iphone app
Follow Up: After all: it is possible (as of late March 2010).
I haven't read all comments or other threads about this issue, so this might be obsolete, but it seems it's basically related to the iTunes-related structure of the appStore.
You can't be part of the Beatles and the Rolling Stones Bands...
Anyway, eventually, a colleague managed to get things sorted out, and we got our App (which was running under my private, single Dev account) running under a new, enterprise account. We kept our ratings, our #1 place in our category in the appstore, and all in all it went smooth (after several hours of phone-calls with apple).
As far as I can recall, the main problem was those help-desk folks were knowing things were going to change, but they didn't know by when and how. Probably due to iPad coming and related timelines involved). Anyway. It's possible, and it's pretty easy. Send your request, wait a couple of weeks (might be days by now), and you'll have the transfer. One issue though: They may have some bug in their migration code, because apple mixes firstname and lastname of the dev / master account after migration. well, who cares.
I had my own experience with this, and the answer I got from Apple Developer Relations (Although it took a month to get an email response and 6 weeks for the follow up phone call) was (in short) that they currently don't offer any way to transfer individual applications from one developer account to another.
He did so by saying that there was a single "Option" for doing this sort of transfer, which is to delete the app from the account that it is currently on, and then resubmit to the Apple store from the new account under the same name (but it would have a new appstore id). I pointed out (and he acknowledged) that this would delete any existing user reviews, ruin the upgrade path for existing users, break iAds, in-app purchases, and game center integration. So it really isn't a solution at all.
He also said that it isn't possible to transfer ownership of all your apps to another existing account (they seem to lack the granularity to move individual apps). However if I wanted to give up all my apps to another individual it could be possible by creating a corporation (probably S-Corp, although he didn't advise), transferring ownership of my account to the S-Corp (which would be allowed if I were a part owner), and then selling the s-corp to the new owner. (Yikes right?)
The method I plan to go with is the following (I'll update with my success), In my specific case I have a paid application that (.99) that I'm trying to transfer to another owner:
I will create a lightweight application using the same AppID that is designed to inform users that the Application has changed owners, and provide a link to the app store where they can download the new application. When launched will upload a hashed form of their UDID to a server (which I will now have to maintain) listing them as a previous customer.
I will upload this new lightweight app to my existing account as an upgrade to the other existing application (so that when users update, they will instead be marked as an existing customer, be presented with a message explaining the situation, and a link to the new app)
I will convert my paid app to being a light application that has some functionality, but requires an in-app purchase of .99 to get the full functionality. Additionally, this new app will check with my server to see if the UDID is in the existing customers database, and if so give them full functionality (without having to do the in-app purchase).
... ARGHH! :) It's an ugly experience for the customers and a whole hell of a lot of work for the developer... but the only option provided by Apple. (Although, I'm not sure that it will even work, as it's entirely possible that they will reject my lightweight "update" application from the store, and thereby prevent the hack upgrade path as well)
UPDATE: Too much work for the person that I was trying to give the application to. Ended up not proceeding with the plan. Think that it could probably still work, and would love to hear from anyone who tries it or pulls it off :)
iTunesConnect now allows App Transfers given certain app restrictions (no iCloud or Push Notifications apps are allowed currently. Local Notifications are ok, of course.)
See the iTunesConnect FAQ on App Transfers... https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/10.0.0.9.1.0.9.1.5.10.1
You can only initiate or accept a transfer if your iTunesConnect login has the "Legal" role permissions.
AFTER THE TRANSFER:
The teamId and bundleID will not change at all. Nor will any of the in-app purchase Ids.
In my company's developer account, I now see an app with EXACTLY THE SAME TeamID.BundleID as I saw in the source code that was purchased from the other company (and that source code was delivered separately, not via Apple)...
ex. BundleID = com.<some-other-company>.<purchased-app-name>
This bundleId is now listed among my other apps listed in iTunesConnect's Provisioning Profiles. I simply created new Development and Distribution/AdHoc provisioning profiles for my newly purchased app. Then I downloaded the new provisioning profiles into Xcode, just like for any of your own apps.
Quite painless. Thank you Apple.
What Lou Franco said.
Where To example is really good to consider, as they eventually had to settle for the fact that all existing customers need to buy the app again. Apple simply does not have the background infrastructure to change ownership.
Another bad consequence of the inherited made-for-music-sale-machine that iTunes originally was. Songs apparently don't change owners.
See here, for Where to resolution: transferring an iphone app last episode
Since now, this is now possible using iTunesConnect.
Apps can now be transferred from one developer to another within
iTunes Connect, for example after an acquisition or when a
distribution deal expires. Transferring the ownership of an app does
not affect the app’s availability on the App Store. All ratings and
reviews will be transferred and your customers will continue to have
access to all available app updates. To transfer an app, go to the
app’s App Summary page in the Manage Your Applications module on
iTunes Connect and click Transfer App. Make sure that:
Your account is active
You have accepted the most current version of your contracts
Your app has at least one approved version
Your app is in the Ready for Sale, Invalid Binary, Rejected, Developer Rejected, or Developer Removed from Sale state Any
associated
In-App Purchases are in the Ready to Submit, Ready for Sale, Rejected, Developer Removed from Sale, or Approved state
You know the Apple ID of the recipient’s Team Agent and their Team ID.
From what I understand, this can be done, but it requires manual intervention by the iTunes Store team, can take months to go through, and may involve some periods when your app is not on sale under either account. If you know who your customer is going to be, just put it under their account to begin with. If not, remember for the future that flipping apps is not an easy thing to do, and adjust your business model accordingly.
It is possible since June, 2013. You can transfer an app to another developer very easy - here is an official FAQ from Apple (available for registered developers).
Besides the already mentioned things I recognized, that certain issues may arise which are nowhere mentioned in the AppStore Guidelines or the documentation.
I found out several issues with apps having subscriptions (which are as of Jan 2015 not transferrable). After trying to transfer an app I found out via the FAQ in the iTC Developer Support Center aka Help Section the following things (Link to FAQ section)...
You cannot transfer apps that contain or use:
iCloud entitlements in any version of the app
Passbook entitlements in any version of the app
A SKU that matches the SKU of one of the recipient's apps, including previously-removed SKUs
In-App Purchase product IDs that match the In-App Purchase product ID of one of the recipient's apps, including previously-removed In-App Purchases
Approved auto-renewable, non-renewing, or free subscription In-App Purchases, including previously-removed In-App Purchase subscriptions Sandboxed Mac apps that share the Application Group Container Directory with other Mac apps also cannot be transferred.
To transfer any of these types of apps, the recipient must create the app as a new app. Current customers, ratings, and reviews cannot be transferred to the new app.
Also the usual requirements are:
To transfer an app, make sure that:
The transferor and the recipient have active developer accounts and accepted the most current version of all master agreements that are currently in effect
The app has at least one approved version
The app is in the Ready for Sale, Invalid Binary, Rejected, Developer Rejected, or Developer Removed from Sale state
Any associated In-App Purchases are in the Ready to Submit, Ready for Sale, Rejected, Developer Removed from Sale, or Approved state
You know the Apple ID of the recipient’s Team Agent and their Team ID If the app uses iAd, the transferor and the recipient must have accepted the most current version of all iAd contracts.
Hope that helps avoid mishaps before you try to transfer an app.
As ownership transfer is currently not-supported and an "exception process", it makes sense not to count on it as your mode of operation.
The big problem you're facing is: the app is tied to a developer account and you want to keep YOUR developer account after you transfer the app.
Hence, why not set up a NEW developer account, the sole purpose of which is to be the holder of this one app and, when you sell the app, you can just transfer the developer-account credentials to the new owner.
At that point, they can update the name, address, company name, bank info, etc.
Of course, your transfer contract will have some verbiage explaining how, in the interim, any moneys you get from Apple will be fwded to the new owner (put a time limit -- like 90 days -- on this so they don't take forever to update the info.)
I've not tried this, but it seems like a viable solution. Again, the problem is that the app is tied to developer account and you don't want to transfer yours. Hence, this Just Makes Sense™.
Recent update from iTunes Connect:
I sold my app to another developer and can no longer distribute it on the App Store. Can I transfer the app to the new developer's iTunes
Connect account?
No, you can’t transfer the app to another developer account on iTunes
Connect. To add the app to another account, remove the app from the
current account and upload it to the new iTunes Connect account.
Note that uploading the app to a new iTunes Connect account will
disable current customers from receiving automatic and free updates of
your application. All customer reviews, rating, and ranking
information will be reset. You will not be able to reuse the app name
and SKU in the old account. If you have uploaded a binary or used the
app with the iAd Network, your Bundle ID will not be reusable either.
Guess I'm late to the party but Apple just added a button to iTunes Connect to do just this. Sign into your iTunes Connect account, go to 'Manage Apps' and click on the app you want to transfer. In the section on the top right, there's a button to transfer your app now.
Cheers!
As far as I know there is no way to transfer apps to a different user/company. I think the app should be in your customers account from the beginning. Otherwise you probably have payment problems too (people paying you instead of your customer).
Why not just sell the app to a customer before releasing it. If they want to see it running before it is released, just sent them a version built with an ad-hoc certificate.
The are additional considerations:
If you just can switch ownership of the Application behind the scenes, thus changing the contract, but not the application itself, you might be fine.
But if you're just going to transfer your source code, the future owner of the app will have to sign it with his own certificate, which will basically render the app as a "new" one.
Users will lose their settings (if your app did some configuration persistence) and they'll lose the app history in the appstore (ranking, etc.).
As per a new announcement from Apple today (just after iOS 7 release) this has become possible .
It says "Apps can now be transferred from one developer to another within iTunes Connect, for example after an acquisition or when a distribution deal expires. Transferring the ownership of an app does not affect the app’s availability on the App Store. All ratings and reviews will be transferred and your customers will continue to have access to all available app updates."
Something helpful:
Apple site documentation with new itunesconnect UI released in Sep,5,2014
Transfer code using github
Note: Use agent role account, and maybe you should click "Agreements, Tax, and Banking" to request Contracts first.
I don't believe that you can transfer ownership to another account. But a simple solution would be to add URL schemes to your app to allow data to be transferred from your app to a new app that your customer would release with the same source.
The new app would have to be free though (maybe the lite version?), so your old customers wouldn't be forced into buying it again. The only real downside I can see of this is that the new app would basically be starting over again from a marketing perspective, which is no minor thing of course!
Mobile Orchard had an article on data migration from Lite to Paid versions of an application that may be of interest:
Lite-to-paid iPhone application data migrations with custom URL handlers