[TheDong]

Garmin pays apple already for a developer license to have an app to pair garmin watches.... and yet 90% of the features of the apple watch simply cannot be implemented for a garmin watch, no matter how much they pay, because those APIs are private to apple watch.

Yes, apple did the R&D to figure out how to let their watch filter notifications by app, and it must have cost them so much to be able to filter notifications that it has to be locked into their watch. That's not them being intentionally anti-competitive, it's just R&D costs, sure, I'm sure it cost a ton to make that private API.

[shuckles]

Yes, the $99/yr Garmin pays covers the 40 minutes of labor it would take annually for an Apple engineer to support this I'm sure.

[TheDong]

You said "no cost to developers", that part's not true. you're of course right that it's not really enough money to be relevant though.

The more cogent argument is that if apple doesn't want to spend money making their phone work with smartwatches, they do not have to make it work with smartwatches.

They want it to work with watches so users buy the phone.

If they want it to work with _only_ their watch, then sure, they make more money, but they also harm the user and market in the long-term by making it so competitors aren't on an even playing field.

Do you just kinda believe anti-competitiveness doesn't exist?

Should apple be allowed to make it so you can't communicate with android users at all to increase sales (which they already more-or-less did)? Should they intentionally make it so you can't play the music you purchased on non-apple devices by breaking "iTunes for windows"?

[const_cast]

The API already exists, they just don't let other people use it because they're greedy. There's no additional maintenance burden.

[lucketone]

Technically cost is not zero.

1. Api designed for internal use could take shortcuts and let’s say use secrets that are and should be internal, or run things as root or something.

2. Proper API maintenance includes at least documentation and some kind of update path/schedule. Internally it’s simpler. (E.g. you must be sure not to leak secret stuff in docs)

But in the end I agree with the notion that these changes for Apple are not a huge burden. (Existing behaviour is anticompetitive)

[const_cast]

I agree, but IMO they should already have this done if the API is properly designed. It might not be, but if so they should change it anyway.

[thatfrenchguy]

I mean, even if you assumed that it would actually take 40 minutes (it likely doesn’t), I suspect Apple engineers working on this cost the company more than $249k a year

[shuckles]

Wow sounds like the $99/yr the commenter was saying developers "pay" Apple is a trivial amount and cannot be used to justify the development of an entire SDK that maybe a dozen companies will use.

[bigyabai]

But Apple already justified building a secure, private, on-device SDK that exactly one (1) company will be guaranteed to use.

I see no reason it cannot be a private entitlement similar to the other sensitive entitlements on iOS.

[shuckles]

Internal API is not an SDK. It regularly astounds me how many commenters on a so-called hacker forum seem to think it is. Is everyone else publishing their tightly coupled business logic code as API these days? Is that what GraphQL is?

[zrobotics]

I would hope that security critical parts of the OS that can't be exposed as an API aren't being used to communicate with the apple watch. Why would the apple watch need access to these APIs that can't be publicly exposed? Is there any reason beyond apple wanting to make sure other smartwatches are second class citizens in their ecosystem?

This isn't exposing business logic, this is an operating system vendor deciding what it exposes to vendors. There is clearly an API that the apple watch is using to communicate with the OS, why shouldn't other vendors be allowed to access this?

[bigyabai]

Apple can revoke the entitlement if it's abused, as they've done many times in the past with signed apps. Nobody (including the EU) is demanding that it be an zero-auth free-for-all API, only that competitors can use it. It's not an absurd demand and there is absolutely precedent for Apple individually trusting competitors in this regard.

If you're astounded by hackers asking practical questions, maybe you should stop carrying water for corps and see how your back feels. Let's talk shop, what are the roadblocks Apple faces here?