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
Related
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.
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 somewhat confused by the terms of the developer content policy (here). Is it possible to use Paypal (or any alternative paying method) instead of in-app purchase (iOS) and in-app billing (Android) for a monthly-recurring PREMIUM membership on my app?
A premium member can access more content and doesn't see ads, but by reading the guidelines, it seems that I must use the built-in in-app purchasing program, is that correct or am I just a bad reader?
Thank you in advance.
Dont know about android but your app will be rejected. According to section 11.2 of the App Store Review Guidelines for iOS (Login Required) any app that doesn't use In-App purchase will be rejected.
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
Additionally, note that any purchase of real world goods or services is not allowed as per section 11.3. I suggest reading the whole document, or at least section 11 (and 20 if it's a charity app). That should give you a pretty good idea of what's allowed and what's not.
Is it allowed to keep in sync auto-renewing subscription in Android and iOS via an online account?
That is to say : in Babbel, if I buy an auto-renewing subscription in Android (with the Android system of purchasing), it will be available on my iOS device.
In the same way, if I buy an auto-renewing subscription on iOS (via IAP), the courses will be available on Android too.
Everything is synced into my Babbel account.
Is it allowed (according to Apple guideline about IAP) so that I can reproduce this system in an app of mine? (The content sold being videos)
Thank you very much,
Jery
Yes. Both app stores have provisions to allow for this. (It's how Kindle, for instance, avoids being kicked out of the App Store even though you purchase content for it from Amazon directly).
There are drop-in libraries like Frac.as that handle the syncing part for you.
I want to know if its possible/legal(not against terms of service) to use the google checkout api for an android app to support in app purchases. The types of items being purchased would be something like extra coins where they can be purchased multiple times.
I know that this would require getting the user's credentials or pointing them to the checkout page or something. I want to know if its possible to do this within the app by opening a webview to the checkout process, and then getting a callback to a custom url on my server that will allow the app to see that the purchase was successful. Something like what the android market does for app purchases.
Thanks for any responses. I don't currently have code to show as I am researching into this before devoting time to create something I won't be able to use. Also maybe android will support native in-app purchases in newer versions of the sdk.
Spoke to (Android evangelist) Reto Meier at Google Tech Days about this and he said it is perfectly OK to do inter-app purchases in the market. You should comply to other regulations - most common is that you need to only buy content that is consumed on the mobile. Virtual "coins" are on quite thin ice, some countries ban issuing "virtual money" but you can do essentially the same with just little different paradigm. Hope this helps.
Android market documentation explicitly states that you can do check it.
http://developer.android.com/guide/market/billing/billing_admin.html#billing-refunds
Important: You cannot use the Google Checkout API to issue refunds or
cancel in-app billing transactions. You must do this manually through
your Google Checkout merchant account. However, you can use the Google
Checkout API to retrieve order information.