| 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. |