I am looking to start selling an app on the Apple app store however currently the app uses our own servers to generate a license to the customer once they have purchased it. How can our existing licensing system which uses our own servers be implemented if a customer purchases the app from the App Store instead?
The application license will be a yearly renewable one. Therefore, so far, from what I have read, the app on the App Store could just come with an auto-renewal option (opt-out of course) so that would take care of the subscription cycle but how can our own server issue the customer the one year license which they could then renew from iTunes using the auto-renew function of the App Store?
I am sorry if this is not clear but it would go like this:
Customer downloads application from app store with a one year auto
renewal subscription.
Customer pays.
The app store verifies the
payment.
Once payment is verified it contacts our server to create a
license for that purchase and for one year.
That license is sent back
from our server to the purchased app to unlock the subscription.
Please correct me if my understanding on how this works is wrong but if anyone can point me in the right direction or give examples of how an application on the app store can successfully issue licenses from their own server then I would be very grateful.
As an example, look at "Aviation Exam". They let you buy subscriptions on-device as in-app purchases, or on their own website. In each case the details are synced to a user's account on their own server, so the same exam can be used from any device.
Look at the Apple documentation for how in-app purchase subscriptions work on iOS. Then your app can send details of a purchase to your servers, and download further information.
Edit; after discussion in comments:
If you want payment to go via Apple then it has to be via App Purchase or In-App Purchase. In-App Purchase specifically supports the idea of buying a subscription for a limited time. This is explained at the second link above.
If you want the user to create an account on your server you can either have a page in the app for them to input their details, or you can bring up a web page served from your website. Either way, the info can go to your server and it can create an account.
The key thing is, if payment went via Apple then inside the app is the only place you know this. The app can send this info to your server. You need some common identifier (i.e. a user-name) that is known to your server and to your user, then the user keys it in to your app and it can all be matched up.
There is nothing complicated here, to a decent software developer. All they need is an existence proof such as I gave at the top, and they can figure out how to link the info together.
Edit 2
Some tutorials for in-app purchase listed at: In-App purchase server model
Lots of low-level detail at: Verify receipt for in App purchase
If you prefer to handle payment yourself, not via Apple, then the situation is very different. Now, your own systems have to keep track of what has been bought, when subscriptions run out, etc. To begin with, the app won't know this at all. However, once you identify the user by having them enter credentials (username/password), you can fetch all the details from your back-end system to the app and proceed as above. Again, this is all visible in the example I gave at the beginning, which supports both Apple and non-Apple payments.
One thing to note: if you handle payment yourself then Apple isn't getting its 30% cut, which is the usual App Store commission, so they may not like this. The guidelines say:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
That's pretty clear-cut, but since there are apps that rely on subscriptions or content purchased elsewhere, they don't seem to follow these rules in every case. Even the Amazon Kindle app was allowed back, once they took the 'buy' button off.
Related
I developed an iOS app for my client which consists of three primary functionalities:
Masterclasses
Clever Closet
Vision Board
I have a website from where you can purchase the masterclasses. So, the Clever Closet and Vision Board are free of charge. You can login with the credentials from the website, but also you can register a new account (without access to masterclasses or external links to payments). Firstly, I tried to use buttons with external redirect to the website, but I found out this is not allowed so I removed them.
Right now, my app was rejected from the App Store submission based on:
Hello,
Thank you for your resubmission. Upon further review, we
identified an additional issue that needs your attention. See below
for more information.
If you have any questions, we are here to help. Reply to this message in App Store Connect and let us know.
Guideline
3.1.1 - Business - Payments - In-App Purchase We noticed that your app includes or accesses paid digital content, services, or functionality
by means other than in-app purchase, which is not appropriate for the
App Store. Specifically: Your app accesses digital content purchased
outside the app, such as memberships and courses, but that content
isn't available to purchase using in-app purchase.
Next Steps
The paid
digital content, services, or subscriptions included in or accessed by
your app must be available for purchase using in-app purchase.
Apps that offer paid digital services and content across multiple platforms
may allow customers to access the content they acquired outside the
app as long as it is also available for purchase using in-app
purchase. See Guideline 3.1.3(b) Multiplatform Services for more
information.
If you have any additional information to provide
regarding the digital content and services in your app and how the
guidelines apply to them, please reply to this message in App Store
Connect and let us know. If there is information you'd like us to
consider in our review of future submissions, please feel free to
include it in the App Review Information section of App Store Connect.
My client doesn't want to use in-app purchases, we are providing purchasing these masterclasses on our website. Isn't my app a Reader App?
3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines,
newspapers, books, audio, music, and video). Reader apps may offer
account creation for free tiers, and account management functionality
for existing customers. Reader app developers may apply for the
External Link Account Entitlement to provide an informational link in
their app to a web site the developer owns or maintains responsibility
for in order to create or manage an account. Learn more about the
External Link Account Entitlement.
Also, I do not want to use the External Link Account Entitlement, so it should be simple. What do you think?
My app was finally approved, because I mentioned that is a Reader App using their guidelines, so I had right about it and regarding the fact that Apple try to force you to use their IAP!
I am developing an iOS application where all payment related things are on existing website, our app don't have any payment related thing in it. A user adds payment details on website and select appropriate plan and can use it on both website and iOS app.
So please tell me that if i have nothing on app for using In-App purchase then it will be get approved on app store or get rejected just because app is not giving them their 30% share?
I need some expert advise...
I just read through that exact section of the developer guidelines, and it confirms that that is prohibited. A recent example of such apps being rejected: apps using Dropbox were being rejected (the Dropbox API had a button that could navigate users to their website to upgrade their account instead of having it take place in-app, where Apple would have gotten a percentage).
A quote from that article:
In case you’re wondering what the reasoning these apps are getting for rejection, here’s what Apple is responding with:
11.13
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines.
Specifically, your app enables to user to create accounts with Dropbox and Google.
Well that sucks. Apparently at some point when using an app that utilizes the Dropbox SDK, you can create an account for the service if you don’t already have one. At that point, there’s a link to a desktop version of Dropbox that lets you upgrade your account. That’s exactly what Apple isn’t a fan of.
My suggestion would be to make them available for purchase via an in-app purchase, charge 30% more for it (so you make the same amount as if the user made the purchase on the web or on Android), but make the user's job post last for 30% more time. This isn't quite fair for you because, if you make $100 off John for an 30-day listing, you would still only make $100 off me for a 39-day listing (assuming I bought the listing via the iOS app). That said, there is no incentive for me to pay for the listing via the iOS app because I am paying $130 (30% more than John) for it and the additional days.
Best of luck.
http://thenextweb.com/apple/2012/05/02/apps-using-dropbox-are-being-rejected-because-apple-is-playing-hardball/
The link on App Store Review Guidelines mentions:
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.
I am not sure how Netflix does this. New users cannot signup on iOS App, but can sign up on website, purchase subscriptions and use in iOS App.
I have developed an app like money wallet (e.g. paytm), where user can request money to each other and transfer money to each others account. with every transaction of user, Admin will get some fixed percent commission.
As app is for one small town only,right now user will have to manually contact admin to load money in his wallet or to withdraw it.
I want to submit my app on iTunes store. I know to use any digital content, services, unlock features we need to use In App Purchase. And for any physical good we need to go with any other third party payment gateway.
So I am confused that will apple approve my app or not. Please help.
Thanks,
First, you never know if Apple will approve or not. The only way to know for sure is to submit and see what happens.
Your description of features sounds like you are probably taking the correct approach.
Its important to use In app purchase for unlocking content/features:
Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
And equally for real world purchases to use something else:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
The complete guidelines can be found here https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
And again, its Apples own words:
This is a living document, and new Apps presenting new questions may
result in new rules at any time. Perhaps your App will trigger this.
I tried to submit using paytm integration sdk, and after that my app got rejected
following is reply from App Store
Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app or its metadata enables the purchase of content, services, or functionality in the app by means other than the in-app purchase API, which is not appropriate for the App Store.
Next Steps
While the payment system that you have included may conduct the transaction outside of the app, if the purchasable content, functionality, or services are intended to be used in the app, they must be purchased using in-app purchase, within the app - unless it is of the type referenced in guideline 3.1.3 of the App Store Review Guidelines.
Please see attached screenshots for details.
Since your App Store Connect status is Rejected, a new binary will be required.
We run a SAAS Web app and are going to be launching our app in Apple’s app store (up to now we’ve had a mobile Web app).
We want to offer the ability to purchase a subscription in app due to the ease of use for our customers. No problem, we know how to do that.
The question we have is whether there is an easy way to keep our web app's db updated with the user’s current subscription status so if they access our Web app we know whether their subscription is valid.
Ideally it would be great if Apple offered a web hook option where they would post an update to a url on our server. From what I've read this isn't an option.
We can always post the data to our server from the iPhone app when the user logs in, but if the user doesn’t log in on the iPhone for a while the subscription status recorded on our server will be out of date.
How are other people handling this? Are we missing something?
Update:
The closest I've found is this thread: https://forums.developer.apple.com/message/70707#70707
The app gets a receipt the first time it buys a subscription or
restores a subscription. The app can send that original receipt to
anyone's server. Anyone's server can then use that orignal receipt to
verify the current subscrition anytime it wants. You can't do that
with a non-renewing subscription but with a non-renewing subscription
the user must purchase the extension from the iOS device each time
period.
Followed up with this:
https://hetzel.net/2011-04-01/server-side-auto-renewable-subscription-receipt-verification/
And from Apple it sounds like they definitely do not make any provisions on their end for synchronization:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have
both an iOS and OS X 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 OS X 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.
Late to the party, but I think this is a relevant reply to this question:
https://stackoverflow.com/a/47537279/543423
Hopefully this is helpful to someone :)
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.