App Reject due to renewing IAPs

Question

chnbr OP

Created Mar ’20

Replies 3

Boosts 0

Views 1.6k

Participants 2

Hi,

I have submitted a new macOS app which was rejected due to:

Guideline 3.1.2 - Business - Payments - Subscriptions

Your app still uses auto-renewing subscriptions, but it is not an appropriate use of the service.

Next Steps

To resolve this issue, please change your in-app purchase product to a non-renewing subscription.

Background:

The app offers a "recording" service that is restricted to 90 sec. in the free version of the app. After 90 sec. the recording is stopped and a requester pops up informing the user about the limitation and offering to cancel or purchase. Our (re-newing) subscriptions offer an unlock feature that removes the recording time limit.

The reviewer states that this is not an appropriate use of re-newing subscriptions and recommends we should proceed with non-renewing IAPs. I have read the new review guidelines and could not find something that forbids this kind of business model for re-newing IAPs.

Did anybody else experience similar rejections or can someone explain what the exact reason for these rejections is ?

(The reviewer just states this to be not an appropriate use w/o furhter explaining where it really conflicts with the review 3.1.2 guidelines, which unfortunately is a very long clause.)

Any information is highly appreciated. Thanks.

Boost

Answer 1

PBK OP

Mar ’20

There are two types of subscriptions, auto-renewing and non-renewing. Until about four years ago Apple was quite restrictive as to what would qualify to be an auto-renewing subscription. It had to provide episodic content on a period consistent with the renewal period of the auto-renewing subscription - like a magazine with monthly issues or a daily newspaper. About 4 years ago they relaxed that to include data that was constantly updating itself - like stock quotes (that's when I switched from using non-renewing subscriptions to using autorenewable subscriptions). And then about 2 years ago they opened it up even more. But there are still some restrictions on what qualifies as auto-renewing. You seem to have fallen outside of that. You could try to appeal or resubmit hoping for a more flexible reviewer or you could give up and switch to a non-renewing subscription. Non-renewing subscriptions work quite well. (Because you can use CloudKit to handle 'restore' you no longer need a server to manage a non-renewing subscription.)

0

Answer 2

chnbr OP

Mar ’20

Thank you for explaining the historic evolvement of renewing subscriptions. Intererstingly my iOS counterpart of the app, which uses a very similar business model, did go through a few weeks ago w/o problems.

SInce this was already a "re-submission" this is not an option anymore and I already have appealed the review decission. Let's see what they say. BTW: Does anybody know how fast they respond on appeals ?

Could you please explain how you use iCloud to manage non-renewing subscriptions. For my re-newing subscriptions under iOS I do not use iCloud for restoring. I store the current expiration date insde the app (encrypted and persitently stored in keychain). When I encounter expiration I am analysing the receipt to either prolong the expiration date or disable functionality. All happens on device. The only drawback I am aware of is man-in-the-middle attack, but considering my numbers I just don't care about this.

How do you manage these things using iCloud ?

0

Answer 3

PBK OP

Mar ’20

If you decode the receipt on the device that received the receipt you do not have to worry about a man-in-the-middle attack since the receipt is signed with the device's IdentifierForVendor.

You need to restore the subscription to any other device owned by the same user. Actually, I forgot that receipts now contain the previous non-renewing subscription purchases so they can be used to resore purchases. But your can easily write the subscription to the user's key-value file or the user's userRecord. This has the disadvantage in that it allows the user to create multiple shared iCloud accounts and distribute the subscription. (But the advantage that it does not allow user's to share their App Store account and distribute the subscription that way.) It does not require decoding the receipt. So it depends on how concerned you are about security.

I do not know how to associate the user's iCloud account with their App Store account other than to link the two at the time of a purchase. (That is, in a call to updateTransactions with a state of 'purchase' credit the current iCloud account.)

0