In-App Subscription Model Limitations

I am working on an app that offers a paid subscription plan for businesses that is based on seats (ie. 1 seat = $10/mo, 2 seats = $20/mo). The business model is similar to Dropbox for Business where the company pays for a subscription that has a number of seats and their employees occupy those seats.


If I understand Apple's documentation correctly, there is no way for a business to manage in-app subscriptions on behalf of their employees.


Would we be violating Apple's guidelines if we tell the user to contact their administrator in order to activate their account? As far as I can tell, we would be, but since Apple does not provide a method for employee subscription management, how can we do it any other way?


Thank you

Replies

If I understand what you are writing - one entity (the employer) makes a subscription (i.e. time period - defined) purchase from one device and other entities (the employees) use the rights purchased on their separate devices.


A new guideline allows this:

"Apps may enable gifting of items that are eligible for in-app purchase to others. Such gifts may only be refunded to the original purchaser and may not be exchanged."


It is easy to set up a credit system using a consumable IAP or a non-renewing subscription IAP because both can be purchased in multiple copies. Once purchased you would set up an exchange or token system that allowed one user to 'gift' the rights to another user. For example, a token that referenced a CloudKit record and once the CloudKit record was used through that token it would cancel itself (so it couldn't be used by multiple people). (The CloudKit record could contain the StoreKit receipt.) Then email the token. Or use MCSession to wirelessly transfer rights from the employer to an employee. A consumable (which never expired but was 'consumed') could be sold in quantity 1000 and be good for one day access to a seat. (Caveat - once gifted it can't be regifted, only returned.)


This is hard to do with autorenewable subscriptions. The problem is how do you sell 14 seats? You would need multiple products - 1 seat, 2 seats, 4 seats, 8 seats. And the user would need to purchase a strange combination of subscription products to get 14. And what if they then wanted 2 more?

Thank you for your response. It seems that even if apple was to allow the company to gift subscriptions to their employees, the employees would have to use their personal Apple IDs to receive the subscription and then somehow hook it up to their work email that they would use to login. Seems like an overly complicated solution to a simple problem.

>If I understand Apple's documentation correctly, there is no way for a business to manage in-app subscriptions on behalf of their employees.


Define 'manage'...do you mean just pay for, or just track use of, or just decide who gets them...? Are they one time, do they expire, are they tied to restricted devices? Are they session based, localized, offered in certain countries only?


Is this about SAS?

The employees do not purchase the IAP and they do not use their Apple ID. The IAP is purchased by the employer and the employer then transfers (gifts) the rights to use the IAP to the employees. You have to figure out how to transfer those rights from one device (the employer/gifter) to the other devices (the employees/giftees). You have to limit the number of times each purchased IAP can be so transfered to 1. This transfer is easily done through CloudKit or through MCSession or throough a simple exchange*.


*The app in the employee hands generates a random number that represents a "RequestNumber". That number is entered into the Employer device. If the employer device has an extra IAP to gift then that IAP is removed from the employer's device and a new "GrantNumber" is generated that is simply a hash of the RequestNumber and some SecretSeed in the app. (Or you can use srandom(RequestNumber + 1936241) to generate the next random number where 1936241 is your app's SecretSeed.) That new number is a "GrantNumber". It is eneterd into the employee's device and the employee's device checks to be sure the GrantNumber is the correct GrantNumber for its RequestNumber. If so, it has been gifted the IAP. This can be done with email links or through CloudKit or through MCSession - but that is harder then displaying numbers on the screen.