[falcolas]

Unpopular opinion: What else do you expect Apple to do with applications that are no longer in compliance with their rules and regulations for the platform?

They could make you happy and grandfather applications in, but then that creates a different "rage" inducing scenario for new applications.

Regardless of whether you agree or disagree with their platform rules changes, the change was made, and now needs to be enforced.

[rorykoehler]

Is there IAP in the Gmail app?

[jacobr1]

Question on the background: did Apple announce this change long in advance and this start enforcing it (as advised) after the window for remediation elapsed? Or was it sudden?

A sudden change is just bad form if that was the case.

[swerling]

Apple announced it way back in about 2011 or 2012.

Here is the sequence of events for our company:

2012-ish: apple requires IAP be an option if you have payment subscriptions. This date might be slightly off, I think it was way back then.

2014-ish: We launch an app that has no recurring subs. So we are still in compliance with their terms.

2017: We add a concept of membership, with braintree managing the subscriptions. Unbeknownst to us, we are now in violation of their terms.

2019: Apple notices the subs, and freezes our app updates

So we were indeed in violation of their terms, ones they had made known long before. We did not know it, but we were. Apple let us know 2 years after the fact by preventing us from publishing a bug fix release.

[falcolas]

Disclaimer: Not an app developer, for either mobile platform.

I heard about this change about a month ago on a couple of news platforms. Specifically, I heard that Apple would be requiring apps which have out-of-app purchasing mechanisms to offer the same products via in-app purchasing.

Also, this is a remediation period. Existing apps aren't being taken down (short of repeated version update submissions which don't comply with the new rules), the new updates are simply being held to the new standard.

[linuxftw]

My thinking is the same. Apple could have just updated their platform, broke the existing app for all current users and new users, and they would have been dead in the water.

There were a lot of users that were angry that their application that worked on WinXP didn't work on Vista/7. The platform moves forward, with or without you.

[swerling]

I think this is wrong, and really the crux of the problem. The app store is not a platform, it is a marketplace.

Apple has used control of that marketplace to impose a technology that we would not otherwise use and adds no value to our product.

[linuxftw]

The marketplace is a part of the platform. Apple controls the platform.

[lostmsu]

The platform can't prevent apps from accepting money outside IAP. It has to be people.

[swerling]

Point taken.

But I would suggest, for that point to really resonate, Apple would have to make some changes in how they enforce these rules, and other aspects of IAP:

1. Provide a grace period

Apple blocked our app release one release after we did a major makeover on the app, switching from Objective C to react native to bring it in line with our 2 other apps. We expected to experience teething issues and quickly release bug fixes as a result. We could not. Given how it went down, we had to implement IAP as fast as we could, giving us a fair amount of tech debt.

2. Make sure the rules are enforced equally for all apps

See linked article for details

3. Allow developers to pay an entry fee for placing their app in the Apple App store as an alternative to implementing IAP

Apple is forcing developers to use a technology that they dont want, one that some developers may feel degrades their ability to provide the best product to their customers. They are using their position as the gatekeeper to the app store to do that.

Let us into the app store with a fee instead of forcing us to expose a feature we have no control over ourselves.

4. Improve their API

The truth is, their 'API' isnt really an API, in the sense that say Braintree or Stripe give you. You are provided a 'receipt', which is really a window onto a state machine. The 'receipt' changes over time and tells you the history of the subscription. But that history is incomplete. For example, the history wont tell you the amount of a given transaction, it's just not there. You have to deduce it from the associated payment plan. But that is hard too, since the payment plan price may change over time to test the market.

Another problem with their implementation is that Apple does not send webhook events for some subscription events -- they only send send webhook events during state transitions of a subscription. So for example if the user makes a monthly payment, there is no webhook sent, since their subscription did not change state. But we need to know these things as it impacts our messaging with our users, so we are forced to write daemons that poll apple to update the receipt and see if any new events have occurred that may require user messaging.

It is a cumbersome and awkward 'API', one I do not belive many companies would voluntarily choose were they not forced to do so.

4. Give us more control over IAP

We have a 'customer is always right' approach at our company. If a user asks for a refund, they're probably going get it. Unless they purchased something using IAP. We have no control over an IAP subscription -- for those, we must direct the user to contact apple and see if they can get a refund there. Apple does not have a 'customer is always right' approach to their users. Should they refuce a customer a refund that we would have given, that blows back on us.

That is really the tip of the iceberg, there are other things we have to cede control over to Apple that effect our relationship with our own customers, especially relating to marketing and testing price points.

[innagadadavida]

Apple seems to have either missed these companies were subscription based, another possibility is some of these companies started as free services and then added a paid subscription later.