Earlier quoted context omitted.
> Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. 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 watch…
> It's not that it's public. It's that it's in use. And an API that isn't public can have its use restricted to a controlled set of environments and places, which inherently makes it easier to update. > 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. Until the EU decides that a public API that changes…
The usual solution is not to break the existing API, but to add new features and deprecate old ones. I doubt the EU will demand Apple not improve their API's.
The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden, but it can't be that bad as Linux, Windows and Android have maintained old API's for literally decades, so I'm sure Apple would cope.
Or to put it another way, the fact that Apple has to support a depreciated API for a while doesn't mean they are forced to use it. If they want to make a change, they publish their shiny new API and move to it immediately. The existence of the old one doesn't need to slow Apple down at all.
> In fact, TLS is a great example of this
If you're using it as an example of how a public API can't evolve then it's a lousy example. TLS did evolve, and fairly rapidly. The fact that some people elected to stay with the old version doesn't change that.
Frankly for most people BEAST didn't matter, as what they were doing on the internet didn't need a lot of security. But when it did matter, like say for a bank, then you were forced to upgrade. And guess what - that new browser still worked with old sites that support the new version. So some people chose to not move didn't slow the protocol's evolution at all. I think you are confusing the rate of adoption of something new, and the rate new things can arise and change. They are at best vaguely related.
And to state the obvious, the old SSL API's being public had no effect on speed of the introduction a new version, which is the opposite of what you seem to be claiming.