Thanks for your comment and for sharing your experience.
> Having been at a company that tried this: The number of poorly-behaved or outright abusive clients is a huge problem. Having a client become popular with a small group of people and then receive some update that turned it into a DDoS machine because someone made a mistake in a loop or forgot to sleep after an error was a frequent occurrence.
Ok, but this could be easily solved by having rate limits on api?
> The secondary problem is that when it breaks, the customers blame the company providing the service, not the team providing the client. The volume of support requests due to third party clients became unbearable.
I would say this is subjective/arguable in general.
It's what happens, it's almost by definition not subjective. The world is full of people geeky enough to use third party clients but not geeky enough to understand the nuances of service evolution. Their reasoning goes like this: yesterday it worked, today it doesn't. I didn't change my client, so it must have been the service that changed. Therefore, it's the service's fault.
This type of reasoning is typically reinforced by the third party app developers themselves, who will tweet "XXX broke their APIs today, really sorry, working hard to get you an update that works around their $@!%#! engineering" and other stuff that not-so-subtly encourages people to blame the service.
Also, don't discount the abuse aspect. Closing clients and out-iterating them is a proven strategy for winning the abuse war, and as all users care about abuse but very few care about third party clients, losing the latter to please the rest of the user base is an easy decision to make.
To be fair, the chances of a breaking server change being unintentional or a natural evolution versus being a hostile move from the provider are about 50/50. AOL was known back in the day for making actively hostile changes to AIM for the sole purpose of breaking third party clients.
Today I'd say the chances of it being a hostile move are more like 75/25.
There is no limit that avoid both false nevative and false postives