0

I have come across an issue with Apple's in-app auto-renewable subscriptions that I can’t seem to figure out. I have successfully implemented subscriptions in my iOS/iPadOS app, including checking the eligibility for introductory offers. All works as expected.

However, one of my subscriptions is an annual subscription for which I would like to add an introductory payUpFront offer in which the initial price is higher than the recurring price. This to retain and reward users for their ongoing subscription. For example: A one off payment for the first year of $29.99, then recurring at $19.99 per year until cancelled. I have set this up in App Store Connect without issues and the subscription is approved by Apple:

enter image description here

Already during my sandbox testing (on device) I noticed that when I tried to purchase this subscription, the native purchase sheet never shows the upfront costs of $29.99 and only shows the recurring $19.99 per year.

enter image description here

The issue is not related to its eligibility since I have another subscription alongside it in the same subscription group for which the introductory offer is correctly shown in the native sheet. Moreover, when I alter the price of the troublesome subscription to be lower than the recurring price of $19.99, the native sheet then does show the introductory price. I have tried re-creating the subscription altogether as well and this did not result in any change in behavior.

Since I thought this could be just a bug on Apple’s side in the sandbox environment I decided to continue and submit my app for approval. Nevertheless, now that my app is approved (set to pending developer release), I just tried this subscription again after downloading my app with a promo code and unfortunately the native purchase screen still shows the incorrect price, thus not taking into account the introductory payUpFront price of $29.99 for the first year. As mentioned before, all other subscriptions in the same subscription group do show their correct introductory offer, albeit none of those are set-up with a higher price than the standard one.

In my understanding the price of a payUpFront subscription can either be lower or higher than the recurring price. This does not hold for payAsYouGo subscriptions which need to offer a discounted price only. This is verified by trying to input a higher price on a payAsYouGo subscription in App Store Connect which will then result in a corresponding error message. This is not the case for payUpFront subscriptions, App Store Connect accepts any price for those. Hence, according to my understanding I have set-up my subscriptions correctly. The issue might therefore be on Apple’s side. Nevertheless, given the implications this potential bug might have for thousands of developers, this would probably be well documented on the internet and stackoverflow. However, I can’t find anything about this issue.

Has anyone experienced a similar issue or is it simply not possible to use payUpFront subscriptions with a higher price than the standard recurring price, even though all Apple documentation and App Store Connect imply this is possible? Is there another work-around around this issue?

Thank you so much for your help!

rdor
  • 101
  • 1
  • 4
  • Has the App Store user you are testing with ever purchased an item from that subscription group before (during testing)? Perhaps apple is detecting this as a second year? – Paulw11 Nov 20 '21 at 20:45
  • Thank you for your comment and suggestion. Unfortunately that is not the case. Other subscriptions in the same group also show/allow their introductory offer and all return true on their introductory offer eligibility. The SKProductDiscount object in the introductoryPrice parameter of the SKProduct also match the set-up in App Store Connect ($29.99 payUpFront for 1 period and 1 unit of year). The issue is present both in the sandbox as well as on the production version. I tested on various devices with different Apple ID's, some unrelated to test accounts. I tried different iOS versions too. – rdor Nov 21 '21 at 00:01

0 Answers0