I don't think the section you quote tells the whole story
> If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase.
> Apps may use in-app purchase currencies to enable customers to “tip” the developer or digital content providers in the app.
Using "must" for unlocking features and "may" for tipping is pretty odd if they need to be treated identically.
This is especially clear if you look later in the document where an almost identical phrasing is used in the other direction:
> If your app enables the purchase of real-time person-to-person services between two individuals you may use purchase methods other than in-app purchase to collect those payments.
> If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments
Certainly the person-to-person transactions aren't required to use purchase methods other than in-app purchase despite the use of "may" in the same context.
This section could probably invalidate it although its extremely confusing because only "reader" apps (3.1.3(a)) are allowed to direct to other purchasing methods but physical goods apps are required not to use IAP. How would they avoid using IAP if they can't direct to other mechanisms?
> Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase, except as set forth in 3.1.3(a).
I'm outside of the edit window on this comment otherwise I would make this more prominent, but way below in the "Other" section they do actually have a "monetary gift" rule that aligns with what the dev says:
> (vii) Apps may enable individual users to give a monetary gift to another individual without using in-app purchase, provided that (a) the gift is a completely optional choice by the giver, and (b) 100% of the funds go to the receiver of the gift. However, a gift that is connected to or associated at any point in time with receiving digital content or services must use in-app purchase.
Although I think it still depends on what Apple means by "associated at any point in time with receiving digital content or services". I think they may be intending to allow something like GoFundMe or Venmo, while disallowing something like Reddit gold where users give gifts based on the digital content created even though that content isn't gated by payment.
Perhaps the developer's use of Bitcoin complicates things as well. Does Apple consider that a "monetary gift" or "digital content" or both?
True. Apple can also choose to stand their ground, which would likely work if the developer doesn’t have the resources to fight a court battle. There may be other viable strategies for them to remove this application in whatever legally valid way.
Still, a plaintext interpretation (as far as I can tell) of Apple’s current rules seems to favor the developer, given the circumstances.
Why go to court instead of changing the rules the next day so that the app more obviously violates them and remove it anyways?
What developer are gonna to go to court for the few weeks or months when his app was removed for ambiguous reasons?
Terms and conditions mean nothing for Apple. They are solely to restrict developers how Apple wants. They give developers no rights in practice. Only the illusion.
Yes, I think their phrasing in that sentence is vague. It should be structured like the functionality one to make clear that tipping _may_ be added, but if implemented it _must_ use in-app purchases.
However, since tipping is not listed in the exceptions, one should read it as not being allowed.
Agreed, from historical context it definitely seems like the intention was confirming for developers that tipping is a valid use case for IAP and not creating an exemption, but I can see why a motivated party would read it differently, and it is made even more confusing by the App Store review notice seemingly acknowledging that some tips are exempt.
So can't people who want to offer an in-app "tip the developer" feature simply comply (without paying Apple's commission) by selling a token physical good such as a button, sticker, t-shirt, or other merchandise?
It sounds like that should be allowed. But I think that fulfilling button, stickers and t-shirts orders is pretty expensive, and only makes sense if people give big tips (eg. if someone tips 5€, there's not going to be much left after you pay someone to mail them a sticker).
> If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase.
> Apps may use in-app purchase currencies to enable customers to “tip” the developer or digital content providers in the app.
Using "must" for unlocking features and "may" for tipping is pretty odd if they need to be treated identically.
This is especially clear if you look later in the document where an almost identical phrasing is used in the other direction:
> If your app enables the purchase of real-time person-to-person services between two individuals you may use purchase methods other than in-app purchase to collect those payments.
> If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments
Certainly the person-to-person transactions aren't required to use purchase methods other than in-app purchase despite the use of "may" in the same context.
This section could probably invalidate it although its extremely confusing because only "reader" apps (3.1.3(a)) are allowed to direct to other purchasing methods but physical goods apps are required not to use IAP. How would they avoid using IAP if they can't direct to other mechanisms?
> Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase, except as set forth in 3.1.3(a).