Another company that would like Apple to not expose functionality to their first-party ecosystem and refuse to expose it to third parties even with user consent.
If the functionality isn't available to anyone, fine, so be it. If the functionality exists on the Apple Watch, it should be done through an API.
Surprised there are professional developers who seem to be clueless about the vast difference in the cost of developing 3p API versus internal only functions. The basic difference between public and private has been captured in language design for decades now.
I'm well aware of the cost difference, but the cost of internal-only functions is potentially measured in antitrust actions.
Microsoft, post-antitrust action, made a very careful point of ensuring new functionality in first-party products like Office only used things that had public APIs.
Yeah it does seem like antitrust is the wedge employed by 3rd parties who would like Apple to do free R&D for them, most ironically by Spotify which holds are arguable monopoly on music streaming.
I’m glad that antitrust enabled a rich ecosystem of Microsoft Office alternatives and competitors.
Apple certainly doesn't have to do free R&D for third parties. They could, instead, not ship features that work exclusively with other Apple products. Or, hey, there's also the other valid option of "don't be the exclusive gatekeeper of the platform", they're welcome to take that one too.
When Apple goes up against governments over encryption, I'll cheer them on with everyone else. When Apple is engaging in https://en.wikipedia.org/wiki/Tying_(commerce) , I have zero sympathy for them.
You are at least an honest critic here in that you admit you'd rather Apple not build great features for its own customers if that means some hypothetical future company isn't allowed to hypothetically build its own version if Apple made some or all of its proprietary R&D available for free to this hypothetical competitor.
Most people pretend that all that effort is free and trivial to expose as API.
It’s not API. That’s the whole complaint of the post. Just because it’s implemented internally does not mean it’s ready for framework support. Have you ever built an API before?
Now we're just playing semantic games. There's a big difference between the level of effort that goes into internal API and public API, and clearly the ask here is Apple undertake that effort now and forevermore to support a public API for Pebble to use for free. You can map that distinction pretty easily onto my earlier comments without changing my argument at all.
