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.
Related
I am building an App using Flutter(this is my first App in Flutter) for Android and iOS platforms. Some of the functionalities of the App are locked. Users can unlock these functionalities either with a one-time payment or a subscription.
Below are the exact features which will be paid one:
to upload more files after the free limit, the user needs to make a one-time payment
to unlock a feature that is related to AR, the user needs to make a one-time payment
to access some data, the user needs to purchase subscriptions
I am using Stripe for all of the above cases.
I have gone through the documentation for in-app purchases for Apple and the clauses in 1.3.1 are quite confusing for me.
So, is it mandatory to use only the in-app purchase mechanism provided by Android and Apple in this case? Is there a chance that my app gets rejected on both platforms?
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.
The mobile application I am building has got payment features (both for buying some coins and subscription of (1 month, 3 months and 12 months) for premium accounts. Here, I should not directly ask card details to pay for the users, instead I need to the user's device stored payment to pay for the mobile application (it may depend on ios and android) I am building. Also, how do the subscription works and keeps making charges to the mobile application timely?
Actually, I need help with the implementation mechanism. I am new to this kind of scenario.
For iOS payment you should go with in-app purchase. It is apple's payment gateway. It has facility to create different subscription plan with duration. So, all things which you want that managed by apple. Same way for android , google have also same mechanism for payment(in-app feature).
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
I am in the early stages of scoping an app that targets a specific vertical market. It is not consumer orientated. The organisation developing the app has existing web-based products and established infrastructure for registering user accounts and billing for those products, and the app should inter-operate with these products. To that end, I have a few questions:
1) If the app that has functionality that can only be enabled from outside the app (for example, via a separate web site) and where the developer bills the user for doing this:
Q1. Can this App be distributed using Google Play?
Q2. Since enabling the functionality takes place outside of the app, does the developer have to use Google Play's payment system to bill for it?
2) If the app which allows a user to create an item of content on a separate web site, so that they can subsequently modify it on that site and be billed for doing so (eg, a bug tracking app that charges for creating a bug record on a site):
Q3 Does this count as an in-app purchase and require use Google Play's payment system to bill for it?
Where can I find definitive statements from Google on these scenarios? I am only finding material that relates to consumer applications where the purchasing and billing scenario is fairly simple.
I cannot shed much light on the potential "thou shalst not have any payment methods beside me" aspect of your question, but as per the technical side, the following aspects come to my mind.
Q1: Technically, the app could either be free on GP and use other payment methods, or it could use the Licensing Validation service.
Q2: The only secure way of deploying Google Play Licensing is to perform all integrity checks on your own secure server. The app could request the GP LVL info and pass it to your server. You could use the GP LVL user ID (an obfuscated binary app-specific byte string) to identify the user and negotiate with your app any password details you may want to implement. Of course, in this scenario, I would expect the user to feel like he already payed so the registration on the server side should be smoothly integrated. If an "enabling"/"authentication" step is additionally required on the server side, I'm not so sure I'd use the GP LVL.
Q3: You could use GP IAB V3 consumable in-app purchases for this (or V2 subscriptions but it sounds more like a per-item payment). Again, this is only secure if you generate a per-purchase developerPayload for the buy Intent on your server and validate it when the app looks at the user's purchases. Validation again must take place on your server, or else you'll have to include your app's public key in your app, which is a major step towards your app getting cracked.
In general, if you have a user management of your own which is to be used, it is important to know that the GP info is relatively anonymous (LVL: obfuscated, IAB V3: no info in the direction of the app at all). So a reliable, use-case oriented binding between "your" accounts and the GP experience would be key here, I'd say.