I have a multiplatform app (Android, iOS, Windows) and implemented one license for the app. I have a webserver to make the license available across all the platforms. I use consumable in-apps to implement it. License is bought, added to a webserver and consumed.
It's consumable because it should be added to a webserver only once.
Everything was fine until now. (1.5 years since initial iOS release) Now my app got rejected. According to the apple I use incorrect in-app type. (I disputed that I have multiplatform app but they keep rejecting my app) But I do not understand what for do I need to use non-consumable in-app to make it comply to their guidelines. Any ideas what I did incorrectly and how to fix it? Should I completely remake licensing in my app?
They may be rejecting your app since users will have no way to restore their license if they reinstall the app, get a new phone, etc. Non-consumable purchases are permanently appended to the users Apple receipt file so they can be "restored" even years after they were purchased.
The other way to offer restore functionality is if you require all users to login with app specific accounts, where you can restore any purchases directly from your server.
Usually app review provides a rejection reason and violated guidelines. Anything here?
I had a phone call with Apple and they explained what they require:
Licenses must be non-consumable in-apps. Consumable in-apps may be only some kind of coins in the game and etc.;
non-consumable in-app should work without requiring registration;
If I want to have cross-platform license user may register account in our system and it should add the license from non-consumable in-app and check that this is the first time in-app with such id is used;
PS:
The idea with subscription sounds easier to implement and I decided to switch our licensing to non-renewable subscriptions as #Paulw11 suggested. The only disadvantage is that subscription must be time limited. So, I will have one year subscription.
Related
Is it possible to have the same in-app product(managed) in multiple apps? Such that if a user buys a premium upgrade in one of the apps, he gets premium upgrade in all of them.
Note that I'm not planning to maintain a user database currently and trying to find a solution using Google's in-app billing API alone if it's possible.
No, it's not possible, unless you build your own database. Entitlements are always related to an app (package name), which means if a user buys a SKU of App A, the Play Billing library can only pull entitlements for App A from its code.
We are developing a Point of Sale app available on iOS and Android platforms.
Our business model is such that, each user will have to pay us a customised cost based upon the number of his business outlets on half yearly or quarterly basis. Once the user will pay us that cost than he could use our apps on any number of devices, on any platform.
I want to know if it's compulsory to process subscription charge for iOS App through Apple In App Purchases. Or we can process subscription offline and show user a alter message to renew subscription directly from our portal if a user's subscription expires.
This is what my team found in developer Apple guidelines regarding similar situation:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So it is like confirmation of #siddharth-gupta statement.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation
You can accept payment through your website for the membership, but then you'll have to make sure you don't offer this as a way to pay for the subscription inside your app.
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
I'm planning to add In-App purchases to my Productivity app. Enhanced features are purchase products (e.g., freemium).
I would like to have user access to purchased feature on both Android and iOS, if he has purchased on any one platform. Technically I plan to store purchase information on server and have it retrieved whenever user logs-in on either device, and unlock the feature if already purchased.
Is this allowed in both iOS and Android?
Apple App Store Review Guidelines on Section 11 have this explained.
Points "11.1/11.2" and "11.14" sounds conflicting (or I'm missing something.).
On Android, I do not see this point mentioning in Policies.
If you had any experiences (w.r.t sharing purchase info between devices) that I should take care additionally, any suggestions are welcome.
I'd like to add a note about subscriptions. Here's the quote from Apple guide:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have both an iOS and macOS version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an macOS app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions
Link to Apple docs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Quote from Android docs:
You can also build on your existing external subscriber base from inside your Android apps
If you sell subscriptions on a web site, for example, you can add your own business logic to your Android app to determine whether the user has already purchased a subscription elsewhere, then allow access to your content if so or offer a subscription purchase from Google Play if not.
You can implement your own solution for sharing subscriptions across as many different apps or products as you want ...
Link to Android docs:
https://developer.android.com/google/play/billing/billing_subscriptions.html
At the moment of writing this answer (May 23, 2017) Windows Store doesn't have subscriptions but they were announced during the latest BUILD conference. Some details here and here
Subscriptions should be available later this summer.
Answering myself. I submitted to App Store mentioning this case and got it approved. I'm yet to submit to Google Play so not sure about it.
Below the snippet I mentioned in App Store review notes that may help some
If user already purchased premium outside the app(our website or
Android app), then we are unlocking Premium as soon as user
logs-in to the app on iOS device. We do not include any button or link
or information inside this app regarding purchasing outside. If you
have any concern or comments regarding this, please let us know.
Additionally mentioned that our in-app item's service is based on user data at our server and not solely on iOS platform. I think this is the key point that makes sense to reuse user's purchase of our service. However, I do not find this case mentioned clearly in App Store review Guidelines.
[Update for April 2019]
As I've already answer here - from developer Apple guidelines:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So like #siddharth-gupta explain in his answer:
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation
We have an application for the PC and we're thinking of writing an Android version of it. But I have a question about how Google Play and in-app purchases work.
On our PC version, the basic version of the app is free, and users upgrade to the paid version to get more features. But rather than "purchase" the app, they effectively "subscribe" - in other words, their upgrade is valid for a specific period of time, during which the extra features are available. They also get free updates and support during that time.
The mechanism for this is that they buy the upgrade and get a license key which they enter into the application. Every time they open the application, it pings our server to check whether the key is still valid. If it isn't, only the basic features of the application are available to them. Obviously they have to be online when they open the application, otherwise they can't ping the server.
The question is how we transfer this model to Android.
We want to make the app available in Google Play, so it has to conform to their rules, which I understand means users can download a basic version for free, and any subsequent purchase has to be done via Google Play, which is fine with me in principle. Rather than have a free app and a paid one, we'd prefer to have just one.
So my favoured option so far is to offer one app with the premium features locked until the user upgrades via an inapp purchase. My questions are:
1 - can the in-app upgrade contain a time limit?
2 - if the user has upgraded, is it technically possible for us to force the app to regularly ping our server in order to keep the extra features activated?
We offer refunds on demand for the software, because it's complicated to use, so if we do refund someone, I'd like to be able to deactivate their key on our server.
Grateful for any thoughts you have!
1) There are "consumable goods" and subscriptions
2) An android app can contact your server via e.g. http. But I'd prefer to do everything via google play, if possible.
3) Note that Google takes a percentage of the in-app purchase cost, so if you refund... will the Google also refund? See Android In-App billing cancel payment
Note also the limit of IIRC 20 goods per request in the API, the example code has a bug related to that limit.
I have a few questions connected to Android In-App Billing:
Is it possible to make a purchase from non-Market app? I understand that it would be a vulnerability, but I have no opportunity to find out if it's possible or not.
How can I get purchase state for a particular product? As far as I understand it can be done using RESTORE_TRANSACTIONS request, but it's not recommended to use very often. That's not a theoretical problem. My application allows users to buy content using in-app billing. Content can be downloaded from a server, and server must allow content downloading only if it was purchased. But it can't check if content was purchased or not without using signed response from Android Market.
How can I get price and description of an item from Android Market? Seems that I know the answer and it's "there's no way it can be done", but maybe I'm wrong. It would be very useful to have a possibility of retrieving item's price.
It's very interesting to me how you solved/are going to solve these problems in your apps. Answer to any of these questions will be appreciated.
In order:
1- Nope. The in-app billing process is part of Market. If the app comes from elsewhere, there's no way for Market to verify the origin/authenticity of the application.
2- It's your responsibility to store the purchase state for a particular product. From the doc:
You must set up a database or some other mechanism for storing users' purchase information.
RESTORE_TRANSACTIONS should be reserved for reinstalls or first-time installs on a device.
3- Unfortunately, at this time you're right. File a feature request!
In the meantime, one option is to set up a website with appengine, store listings of all your content & pricing there, and then manually sync prices listed on your appengine server with the updated prices in Market. Then have your Android app pull the data from the AppEngine server. This is much better than hardcoding price values into the app itself, since you don't need to have everyone update the app immediately to see accurate pricing whenever you change something. The only caveat of this method is that if the user is in a different country, in-app billing will display an approximated price in their native currency, and there's no way for you to determine exactly what price will be displayed to them.
Related, One of the Android Developer Advocates is giving a talk on LVL/IAP at IO, called "Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine." - It would definitely be worth your while to watch when they release the session videos on the website.