Earlier quoted context omitted.
> How many years will it be before audio on the Linux OS doesn’t suck? Bad example. It's a bad example because in order to achieve that Linux has has many, many sound API's over the years. Most of them interacted in bad ways. Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. If a great, reliable sound system depended on the ability to iterate on API's Linux's should hav…
> Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. > ... > Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. Or as I put it in…
And my point was I don't agree. It's not that it's public. It's that it's in use.
> They can, all they have to do is push out an update for those watches.
An update they can't be sure every watch has done. The usual solution is to that situation is to plan for it from day 1, design the watches so the very first ones you release can detect that's happened, and when it has issue an error message like "sorry, you'll have to update your watch to continue". Compare to: you design an API, as part of the design it queries what version the servers support, and issues a message like "your new end point doesn't support me any more, you need to upgrade something". Sounds very similar, doesn't it?
Example: ssh will stop running if your old client connects to a new server. It's a public API.
Example: SSL/TLS has moved through multiple incompatible versions. It's a very public API.
So apparently the API being public didn't stop transitioning to new, incompatible versions when the need arose. What will stop it is not designing your API with upgrades in mind. If you don't do that, you will end up in a world of pain regardless of whether the API is public or not.
You say it slows things down, but that's not necessarily correct either. Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem.