> If it was just a tax, it'd be bad enough. But Apple's in-app payments solution is severely lacking in terms of features and capabilities.
You’re approaching this from the premise that you pay a commission for payment processing, when in actuality the primary purpose of the commission is to collect payment for the use of Apple’s IP. All the rest is secondary to that.
Nevertheless, even from the payment processing premise there are some questions that come up when reading your comment.
> You cannot issue a partial refund.
True. It’s either all or nothing.
Closest thing to a partial refund would be pushing the renewal data back on subscriptions, either individual or for all subscribers of a specific product e.g. if you had a widespread issue
> Actually, you can't refund a customer at all.
Nope you can’t directly refund a customer.
You can have a say in refunds for consumables by informing Apple if the consumables have been consumed and you can offer a refund sheet in your app so that the customer doesn’t have to contact Apple themselves, but ultimately Apple’s decision mechanism is the final arbiter.
In my experience both by keeping tabs on users reached out to CS to ask for a a refund, tracking refund requests via the refund sheet in apps, analyzing refund history and notifications and personal experience of me as a user and that of others in my circles, refunds are issued generously, close to 100%.
It seems they have a “Yes, unless” policy, where the unless is mainly tied to having a history of requesting refunds.
A decent amount of developers actually complain about how easily Apple gives refunds going by posts I see on different forums, but I prefer it this way.
> If Apple declines the refund for whatever reason, you and the customer are just screwed. Literally had to buy a gift card to give a customer so we could make them whole.
This seems like a rather extreme solution. Was there a big issue with your app that compelled you to do this?
> You cannot offer a discount and free trial at the same time.
Depends on what you mean by this.
If you mean a free trial and after that a discounted rate you can just create a new product at that discounted rate and enabled the free trial.
If you mean a trial and then a temporary discount then no, there’s no direct native way of doing this. Presumably because you can just calculate the discount into the introductory offer instead of confusing the user with having to track two time periods, the period of the free trial and the period the discounted rate is in effect.
But close to native is using offer codes and enabling eligibility for introductory offers. Then your users will get the introductory offer first (i.e., free trial) and renew at the offer tied to your offer code (i.e., discounted rate).
You can also use this to give longer free trials during certain periods, the introductory trial will stack with the trial set on the offer code.
Nevertheless, I was partial to utilizing the DeviceCheck framework before all of this was possible.
Check if this device is new, if so, enable free trial and after that trial offer discounted introductory offer.
Benefit of this was that users appreciated not having to initiate a purchase flow to get access to the free trial, risking a charge at the end if they forgot.
Downside is that it’s tied to device and not Apple ID, so technically users can get a free trial on multiple times, if that’s something you’re concerned about.
> When trying to create a different subscription group to A/B test our pricing, we somehow got cursed with a reviewer who did not understand the concept long after it was released. New app builds with bug fixes completely unrelated were getting rejected. It took weeks of escalations before they finally relented.
That’s a shame. What did they get hung up on? Not being able to see certain products in the app?
> Promotional pricing is so frustrating to setup between Introductory Offers, Promotional Offers, and Offer Codes.
What did you find frustrating about it?
> You cannot generate ad-hoc pricing for anything
Depending on how “ad-hoc” you’re talking about, wouldn’t offer codes fulfill this desire?
> You’re approaching this from the premise that you pay a commission for payment processing, when in actuality the primary purpose of the commission is to collect payment for the use of Apple’s IP. All the rest is secondary to that.
The IP I'm paying for is all tied to their payments platform. I would rather use none of it. I'm also paying separately for the right to develop and publish on their store via their annual fee.
> A decent amount of developers actually complain about how easily Apple gives refunds going by posts I see on different forums, but I prefer it this way.
We have a subscription offering, so the consumables experience may be different.
> This seems like a rather extreme solution. Was there a big issue with your app that compelled you to do this?
No. We have a freemium model with a subscription pro tier. The user was on the paid plan for a few months and messaged us that he actually gets enough value out of free tier features and would like a refund. It's very understandable that many decision makers in that position wouldn't issue a refund. But a single negative review can hurt us a lot, so we try to go out of our way to avoid that happening.
> If you mean a trial and then a temporary discount then no, there’s no direct native way of doing this. [...]
Yeah, this is the scenario I'm describing. Creating new products is laborious with setting international pricing and replicating for different discount levels across monthly and annual recurring subscriptions.
> Depending on how “ad-hoc” you’re talking about, wouldn’t offer codes fulfill this desire?
The use-case was to enable "Pay what you think is fair" pricing with a slider. Similar to what TrueBill/RocketMoney does.
You’re approaching this from the premise that you pay a commission for payment processing, when in actuality the primary purpose of the commission is to collect payment for the use of Apple’s IP. All the rest is secondary to that.
Nevertheless, even from the payment processing premise there are some questions that come up when reading your comment.
> You cannot issue a partial refund.
True. It’s either all or nothing.
Closest thing to a partial refund would be pushing the renewal data back on subscriptions, either individual or for all subscribers of a specific product e.g. if you had a widespread issue
> Actually, you can't refund a customer at all.
Nope you can’t directly refund a customer.
You can have a say in refunds for consumables by informing Apple if the consumables have been consumed and you can offer a refund sheet in your app so that the customer doesn’t have to contact Apple themselves, but ultimately Apple’s decision mechanism is the final arbiter.
In my experience both by keeping tabs on users reached out to CS to ask for a a refund, tracking refund requests via the refund sheet in apps, analyzing refund history and notifications and personal experience of me as a user and that of others in my circles, refunds are issued generously, close to 100%.
It seems they have a “Yes, unless” policy, where the unless is mainly tied to having a history of requesting refunds.
A decent amount of developers actually complain about how easily Apple gives refunds going by posts I see on different forums, but I prefer it this way.
> If Apple declines the refund for whatever reason, you and the customer are just screwed. Literally had to buy a gift card to give a customer so we could make them whole.
This seems like a rather extreme solution. Was there a big issue with your app that compelled you to do this?
> You cannot offer a discount and free trial at the same time.
Depends on what you mean by this.
If you mean a free trial and after that a discounted rate you can just create a new product at that discounted rate and enabled the free trial.
If you mean a trial and then a temporary discount then no, there’s no direct native way of doing this. Presumably because you can just calculate the discount into the introductory offer instead of confusing the user with having to track two time periods, the period of the free trial and the period the discounted rate is in effect.
But close to native is using offer codes and enabling eligibility for introductory offers. Then your users will get the introductory offer first (i.e., free trial) and renew at the offer tied to your offer code (i.e., discounted rate). You can also use this to give longer free trials during certain periods, the introductory trial will stack with the trial set on the offer code.
Nevertheless, I was partial to utilizing the DeviceCheck framework before all of this was possible. Check if this device is new, if so, enable free trial and after that trial offer discounted introductory offer.
Benefit of this was that users appreciated not having to initiate a purchase flow to get access to the free trial, risking a charge at the end if they forgot.
Downside is that it’s tied to device and not Apple ID, so technically users can get a free trial on multiple times, if that’s something you’re concerned about.
> When trying to create a different subscription group to A/B test our pricing, we somehow got cursed with a reviewer who did not understand the concept long after it was released. New app builds with bug fixes completely unrelated were getting rejected. It took weeks of escalations before they finally relented.
That’s a shame. What did they get hung up on? Not being able to see certain products in the app?
> Promotional pricing is so frustrating to setup between Introductory Offers, Promotional Offers, and Offer Codes.
What did you find frustrating about it?
> You cannot generate ad-hoc pricing for anything
Depending on how “ad-hoc” you’re talking about, wouldn’t offer codes fulfill this desire?