1

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.

Kevin Brown-Silva
  • 40,873
  • 40
  • 203
  • 237
Ian Walker
  • 103
  • 2
  • 7
  • I don't think Apple lets you sell software with that kind of licensing. They want you to use their own licensing terms (and subscription management). – Thilo Jun 20 '14 at 11:10

1 Answers1

1

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.

Community
  • 1
  • 1
Bryan
  • 11,398
  • 3
  • 53
  • 78
  • Thanks so much for this Bryan! I am not a developer. I am just doing the research to see how feasible it would be for our developers to do this. I took a look at the Apple documentation and it makes no real sense to me. You mention this 'then your app can send details of a purchase to your servers, and download further information.' basically we have our own license server to generate licenses so would it be feasible for the app to be downloaded and then they purchase a subscription which takes them to a signup page (in the app) which creates a license on our server for them? – Ian Walker Jun 23 '14 at 00:51
  • Is it a primary requirement to have payment handled via Apple? Your question seemed to imply that, but now I'm not so sure. – Bryan Jun 23 '14 at 09:43
  • Yes. Payment would be handled by Apple. The issue is how the user can download the app and then purchase a subscription (e.g. one year/one month) by creating an account on our servers to then log in and access the software with the paid features. – Ian Walker Jun 24 '14 at 00:47
  • Thanks very much for this Bryan. I don't suppose you know of any websites or tutorials which explain the iOS Server Product Model and how it works and how it can be implemented? If we did not want Apple to handle payment (we would do it) how would that change things? – Ian Walker Jun 30 '14 at 09:41
  • Hello Brian. I did that but it says I do not have enough reputation points. Sorry. I am kind of new to how this site works. – Ian Walker Jul 02 '14 at 03:57
  • OK, I think I've covered your last question. – Bryan Jul 02 '14 at 17:08